28.04.2014

05.03.2014

03.12.2013

26.11.2013

15.11.2013

10.10.2013

03.10.2013

05.09.2013

svn 4454

15.08.2013

01.08.2013

19.07.2013

14.07.2013

26.06.2013

19.07.2013

11.06.2013

16.05.2013

08.05.2013

01.05.2013

24.04.2013

Nach zweimaligen Aufbau im Whiteboard in das selbe InDesign®-Dokument sind die von der Musterseite losgelösten Rahmen verdoppelt. Baut man im Desktop auf, werden die Rahmen NICHT verdoppelt.

Also, ganz nüchtern betrachtet ist das ein InDesign®-Bug. Man ganz es ganz einfach und ohne Comet-Plugins nachstellen :

1. Neues Dokument mit einer Seite erzeugen
2. Auf der rechten Musterseite einen Rahmen anlegen
3. Auf die "normale" Seite gehen und dort den Musterrahmen freistellen (Cmd-Shift-Click auf den Rahmen)
4. Den Rahmen ein wenig verschieben
5. In der Seiten-Palette die Musterseite noch mal auf die Seite ziehen (also die Seite noch einmal mit der aktuellen Musterseite verbinden)

Und jetzt sieht man es schon : Der Rahmen ist ZWEIMAL da. Glasklare Sache.

In CS6 funktioniert es teilweise: Nur der Fall, dass die GLEICHE Musterseite erneut gesetzt wird, ist jetzt okay. ändert sich die Musterseite, bleiben auch hier freigestellte Musterelemente auf der Seite stehen.

Das Problem ist gefixt sowohl für alle Comet-Funktionen, die Musterseiten setzen können als auch für Javasscript und alle Bordmittel, in denen Musterseiten gesetzt werden. (Freigestellte Musterseiten-Rahmen werden also z.B. auch dann richtig von den Seiten entfernt, wenn die Musterseite manuell über die Palette 'Seiten' verändert wird.)

Achtung I: Das klappt nur bei Rahmen, die mit installierten Comet-Plugins mind. ab v3.3 R3637 freigestellt wurden! Musterseiten-Rahmen, die vorher oder ohne Comet-Plugins freigestellt wurden, bleiben auf den Seiten stehen.

Achtung II: Wird ein freigestellter Rahmen dupliziert (aber warum sollte man das tun?), werden auch die Duplikate gelöscht!

Wenn ich die Preview-Details aufmache, schlägt mir folgender Fehler entgegen:

"Fehler beim Lesen des TIFF-Bilds. Das Bild ist u.U. beschädigt oder inkompatibel. Speichern Sie das Bild mit anderen Einstellungen, und versuchen Sie es erneut."

Eigentlich ja eine klare Anweisung. Er kann das Bild nicht lesen.

Aber, das Preview-Panel meckert nicht und auch in den Preview-Details zeigt er eine Vorschau. Nur die Fehlermeldung ist komisch.

Gefixt.

Adobe kann solche TIFFs zwar als Bilder in Dokumenten platzieren. Aber die API-Aufrufe zum Ermitteln der Bilddaten zeigen den o.g. Fehler. Der Dialog ist leider auch nicht unterdrückbar.

Das ist gefixt.

14.04.2013

Im XML von documen::export_ sollten eigentlich auch die Informationen von Bildrahmen enthalten sein :

<PictureBox>
...
</PictureBox>

Bildrahmen werden aber leider nur als reguläre Rahmen ohne Bildinfos exportiert.

Ab CS5 hat Adobe das Verfahren geändert, wie die Informationen von Bildrahmen ermittelt werden. Seither fehlen die Bilddaten in der Ausgabe von document::export_.

Ist gefixt.

Die mit document::export_ geschriebenen XML-Dateien sind fehlerhaft. Die Dateien sollen Kommentare der Form

<!-- Page 1  ************************ -->

enhalten. Leider werden aber die spitzen Klammern als < und > dargestellt.

Das ist gefixt.

In der Doku steht: Ab Version 3.1 R 1730, 5. Feb. 2010] Listeneinträge können auch mit Hilfe eines Skriptes geladen werden. Sehr cool. Das Beispiel funktioniert auch.

Aber... wie komme ich denn jetzt an die ID des Platzhalters, bzw. des Produktes.

n reinem SQL wäre das mit dem Tag "<selected.stringID>" möglich... und in C-Script?

Die Platzhalter-relevanten Infos kannst Du so bekommen:

ItemRef	frame    = item::alloc ();
int		s, e;
int		ID		= 0;
char	sid	[5000];

textmodel::selection (&s, &e, frame);
if (s >= 0)
{
	plid = placeholder::get_value (frame, "ID", s);
	strcpy (sid, placeholder::sget_value (frame, "StringID", s));
}

Die Produkt-relevanten Infos bekommst Du so:

StringList	sl		= stringlist::alloc (3, kSelected);
char		row1[5000];
int			tid		= 0;

if (stringlist::length (sl) > 0)
{
	tid	= stringlist::getint (sl, 0, "PageitemID");
	stringlist::gettext (sl, 0, "Num", row1);
}

... obwohl optisch keiner zuerkennen ist.

Das Problem trat immer dann auf, wenn ein Platzhalter bis in den internen Zellentrenner lief.

Das Problem ist gefixt.

int main ()
{
	int i = 4294967290;
	
	wlog ("", "%d\n", i);
	
	i = 4294967296;
	wlog ("", "%d\n", i);
	
	return 0;
}

Mit diesem Skript erhält man - leider - die Ausgabe

-6
0

Was ein bisschen, nun ja, verwirrend ist.

Im Normalfall werden so große Zahlen nicht benötigt. Intern werden aber z.B. gFrame, gDocument, gNewValue, ... als ADRESSE auf eine im Plugin definierte Variable an die Skripte übergeben. Und diese Adressen können durchaus so große Werte annehmen.

Das ist gefixt.

ACHTUNG

Der Fehler ist ein schwerer. Er betrifft alle Releases ab R3398.

DIE RELEASES R3398 - R3605 SOLLTEN DAHER NICHT VERWENDET WERDEN!

Wird ein Rahmen verschoben, folgen alle Notizen, die auf den Rahmen zeigen, diesem Rahmen nach. Das ist schön. Sind die Rahmen aber InDesign®-gruppiert, funktioniert das nicht.

Gefixt.

Bei Notizen, die auf InDesign®-Gruppe verweisen, werden mitunter die Pfeile von den Notizen zur jeweiligen Gruppe nicht richtig gezeichnet : Verschiebt man die Gruppe auf eine andere Seite des Spreads, zeigt der Pfeil plätzlich ins Leere. Wird die Gruppe wieder auf die Seite der Notiz zurückgeschoben, wird der Pfeil wieder richtig gezeichnet.

Gefixt.

Gibt es irgendeine Möglichkeit, die Gestaltungsmethoden einer Tabelle aufzurufen, ohne die Tabelle dafür neu aufzubauen?

table::build hat jetzt einen zusätzlichen Parameter, der die Werte -1, kPreAction, kPostAction, kPreActionTable, kPostActionTable haben darf. Die Werte ungleich -1 unterdrücken den Aufbau der Tabelle/Zelle und führen nur die angegebenen Tabellen-Gestaltungsregeln aus.

Habe ich die Möglichkeit die Option, den grünen Hacken rechts unten in der Produktrecherche in CScript abzufragen? So könnte ich diese Einstellung in diversen Skripten berücksichtigen.

Mit den Funktionen

list::get_autoload
list::set_autoload

geht das jetzt.

In CS 6 R3355 the quality of the preview is too low even if requesting the highest possible quality.

Die Einstellungen ..., kJPEGGreatQuality haben lediglich Einfluß darauf wie das erzeugte Bild gesichert wird. Sie haben KEINEN Einfluss auf die Qualität des Previews selbst.

Die kann man eigentlich nur über zwei Eistellungen ändern : Die Grösse des Previews in Pixel oder die Auflösung. Das Erste wird zur Zweit leider falsch ausgewertet (ist jetzt gefixt). Und die Auflösung war fix auf 72 dpi gesetzt. Dafür haben die folg. Funktionen jetzt einen zusätzlichen (optionalen) Parameter :

image::snapshot_page
image::snapshot_frame
image::snapshot_frames

24.03.2013

In bestimmten Konstellationen stürzt InDesign® bei linklist::collect_any() ab. Leider nicht immer, und ich kann auch nicht herausfinden, wo das Problem liegt.

Das ist gefixt, war eine Folge des Fixes von Bug 3188.

wenn ich eine Alternativ-Verbindung von Rahmen zu TopCenter mache, funktioniert alles, wie gewünscht. Ist das Ziel aber BottomCenter, funktioniert das nicht.

Ja, hatte ich nicht bedacht. Wir waren immer davon ausgegangen, dass die Rahmen untereinander liegen - und plötzlich gibt es negative Abstände. Und - ja klar - wenn die alternative Rahmen UNTER dem Ziel-Rahmen liegen, geht es auch nicht.

Das ist jetzt alles gefixt. Einzige Bedingung ist : Die Kanten, von denen die alternativen Magneten ausgehen, müssen alle auf der gleichen Seite der Zielkante liegen.

Die beiden Abbildungen zeigen die verschieden Möglichkeiten, alternative Magnenten für vertikale Anpassungen zu setzen.

Unter nicht sicher reproduzierbaren Bedingungen stürzt InDesign® Serverfbeim Beenden ab.

Der Fehler hängt mit jüngsten änderungen (R3530) zusammen, da wurde das Verhalten beim Beenden generell erstmal verbessert: es wird aufgeräumt, noch offene Templates etc. geschlossen und Zwischendateien gelöscht. Allerdings ist die Anwendung zu diesem Zeitpunkt nicht immer noch (aber manchmal schon) in einem Zustand, der Schließen von Dokumenten erlaubt, das wird jetzt geprüft und damit ist der Fehler behoben.

Gefixt

In bestimmten Konstellationen und insbesondere beim Verarbeiten größerer Dokumente bzw. Aufbau-Jobs stürzt InDesign® Serverfbei einigen cscript-Funktionen zur Tabellengestaltung (z.B. table::broaden_to_frame) ab.

Gefixt.

24.03.2013

Wenn Textrahmen, die Platzhalter enthalten, verkettet sind, erscheinen die Platzhalter mehrfach im Ergebnis von linklist::collect - und zwar einmal für jeden Rahmen in der Kette. Das passiert nur, wenn Rahmen der Kette (müssen nicht alle sein) gruppiert sind.

linklist::collect_any() scheint das gleiche zu tun.

Ist gefixt.

Die Werte, die textmodel::get_parastyle() für start und length zurückgibt, sind irgendwie abhängig davon, ob im Dokument ein Rahmen ausgewählt ist, obwohl gFrame gar nicht verwendet wird.

Im vorliegenden Fall wird das genutzt, um sprachabhängig Stile im Dokument zu tauschen. Sobald ein Rahmen ausgewählt ist, läuft das Script in eine Endlosschleife, sonst funktioniert's.

Irrtümlicherweise wurden die Textpositionen der Eingabe gegen das Textmodel des Skriptes geprüft und nicht, wie es richtig gewesen wäre, gegen das Textmodel des SkriptAUFRUFES. Der Fehler ist gefixt.

Der gleiche Fehler betraf auch die folg. Funktionen:

• textmodel::get_parastyle
• textmodel::set_parastyle
• textmodel::get_charstyle
• textmodel::set_charstyle
• textmodel::find_surrounding_word
• textmodel::find_surrounding_paragraph
• textmodel::set_hypenation
• textmodel::get_hypenation
• textmodel::get_cometgroup
• textmodel::select_cometgroup
• textmodel::create_cometgroup
• textmodel::resolve_cometgroup
• textmodel::change_cometgroup
• textmodel::select

Wenn der zu prüfende Text ein einfaches Hochkomma ' enthält, wird der Platzhalter in der Aufgabenpalette angezeigt. Im Infobereich unten steht dann "Beide Inhalte sind gleich". Ein typografisches Hochkomma ’ oder ‘ macht keine Probleme.

Ist gefixt.

In der Doku heißt es:

ClassID 51 // Bedingungen für Gestaltungsregeln von Textplatzhaltern
ClassID 52 // Gestaltungsregeln von Textplatzhaltern

Das ist aber genau umgekehrt implementiert.

Doku ist korrigiert.

Wenn man auf das Magnet-Tool in der Werkzeugleiste klickt, klappt das Untermenu nach links aus. Wenn man nur einen Bildschirm hat, ist das ziemlich blöd.

Und es ist auch ziemlich unpraktisch, dass der Text in einer Zeile steht, er nimmt bei mir die gesamte Breite des 1920 px breiten Bildschirms ein.

Beim Mac werden die Titel der Tools für die Menü-Namen nach dem ersten Return abgeschnitten, für die gelben Hilfetexte werden sie vollständig angezeigt. Offenbar ist das unter Windows anders. Aber das kommt von Adobe - wir können da nichts machen.

Ich habe deshalb die Tooltexte für Windows generell gekürzt. Die Menüs sehen jetzt aus wie im Screenshot. Die Hilfetexte sind dafür wesentlich kürzer. Anders gehts offenbar nicht. Alle Versuche mit anderen Zeilentrennern haben leider keine Veränderung gebracht.

Damit die Hilfe für die Werkzeuge nicht ganz verloren geht, befindet sie sich jetzt in dem gelben Zettel des ersten Buttons der Palette ().

Wir haben heute einen Fehler in den Comet-Plugins entdeckt, der unser aller Aufmerksamkeit seit Einführung der persistenten Cometgruppen in v3.2.1 R2356 (17. März 2011!) entgangen ist. Er bewirkt folgendes :

Ein Dokument enthalte 3 Produkte:

Seite 1 : Cometgruppe 100
          Cometgruppe 200
Seite 2 : Cometgruppe 300

Zwischen 100 und 200 wird jetzt das 400 Produkt eingefügt. Nach Reorganisation landet 200 mit neuem Template auf Seite 2 :

Seite 1 : Cometgruppe 100
          Cometgruppe 400
Seite 2 : Cometgruppe 200
          Cometgruppe 300

Soweit, so gut. Das Dokument wird gesichert und geschlossen. Nach Neuöffnen sehen die Cometgruppen aber so aus :

Seite 1 : Cometgruppe 100
          Cometgruppe 400
Seite 2 : Cometgruppe 2345
          Cometgruppe 300

Der Inhalt der Gruppe ist vollkommen richtig. Die Gruppennummer 2345 leider nicht.

Der Fehler ist gefixt.

Für die Verwaltung von Comet-Notes werden die UIDs von Seiten und Spreads benötigt.

Mit den neuen Funktionen

    page::get_spread
    document::get_pageref
    document::get_spreadref

geht das jetzt. Mehr dazu in der Doku. Hier ein Beispiel:

int main ()
{
	int		pg			= page::get (gFrame);
	int		indexInSpread;
	int		spread		= page::get_spread (0, pg, &indexInSpread);	
	ItemRef	pageRef		= item::alloc ();
	ItemRef	spreadRef	= item::alloc ();

	document::get_pageref (pageRef, 0, pg);
	document::get_spreadref (spreadRef, 0, spread);

	wlog ("", "Spread %d (%d), Seite %d (%d), %d. Seite im Spread\n",
			spread, item::getint (spreadRef),
			pg, item::getint (pageRef), indexInSpread);
	return 0;
}

In der Funktion frame::image sind ja Angaben für einen Alphakanal möglich. Das scheint nicht zu funktionieren.

Ja, immer dann, wenn die Alpha-Kanäle keine Namen haben (auch wenn man den Index verwdendet). Dabei haben A-Kanäle meist keinen Namen.

Das Problem ist gefixt. Die Angabe des A-Kanales erfolgt jetzt immer über den Index. Der Name des Kanales wird nicht mehr ausgewertet.

Das geht jetzt mit image::set_alpha_channel.

image::setclip wird jetzt von InDesign® Serverfausgeführt.

Die Anweisung

frame::image (frame, "bild.tiff", kPlaceCentered, kFitBigContentProp, 0);

soll eine Bild platzieren und den ersten Freistellpfad des Bildes anwenden. Macht sie auch. Aber nur in den Desktop-Plugins. Am Server nicht.

Ist gefixt. Die Anweisung wird jetzt auch bei InDesign® Server richtig ausgeführt.

Ich habe mit frame::image ein Bild platziert. Dabei habe ich einen Beschneidungspfad anwenden lassen. Später will ich das Bild ersetzen und KEINEN Beschneidungspfad mehr anwenden. Wie bekomme ich den denn wieder weg? Ist einmal ein Pfad gesetzt, hilft es leider nichts, die Funktion mit kIgnoreClipping aufzurufen.

Stimmt leider. Dafür gibt es jetzt die neue Konstante kResetClipping. Dann wird der Pfad auf alle Fälle zurück gesetzt.

z.B: bei Int kommt ja bei einem Vergleich zwischen 4<5 = 1 und 4> 5 = 0 raus jedoch bei FLOAT kommt hier 4.<5.0 = 1928658603321851904

Das ist gefixt. Der Rückgabe-Wert war 1.0. Die dabei angewendete IEEE-Norm-Darstellung sieht als INT genauso aus wie oben beschrieben :-)

Unter manchen Bedingungen schlagen int-Vergleiche fehl :

Aus den Vergleichen geht phase mit dem Wert -1 hervor. Wo man doich eigentlich 3 erwarten würde.

int		k = 26;
int		phase;

if (k == 21 || k == 34 || k == 35)		phase = 1;
else if (k == 23)						phase = 2;
else if (k == 22||k == 26||k == 36)	phase = 3;
else									phase = -1;

Mit der 3.3 Rev 3313 tritt das Problem nicht auf.

Das Problem ist gefixt. Es war eine weitere Folge von Bug 3168.

Ich glaube, ich bin grade über einen Fehler in den neuen PlugIns gestolpert. Offenbar funktioniert eine Abfrage à la

    if (list::get_pos(placedIDs,SGID,0)==-1)

nicht korrekt.

Ist gefixt. Das war eine Folge von Bug 3168.

Schön wäre es eine Methode zu haben, die die Zeilenhöhe so anpasst, dass keine Zelle mehr einen Übersatz hat. Analog zur Methode fit_col, die die Spaltenbreite entsprechend anpasst.

Habe mir so eine Methode selbst programmiert und die Laufzeit ist nicht so berauschend, vielleicht gibt die interne InDesign®-API da mehr her.

Ich passe die Zeilenhöhen schrittweise so lange an, bis die Zellen keinen Übersatz haben. Da nach dem Anpassen der Zellenhöhe ein Aufruf von textmodel::force_redraw() notwendig ist (siehe Bug #2957) dauert es bei einer kleinen Tabelle (27 Zeile, 3 Spalten) schon mal so 16-20min, bis die aufgebaut und angepasst ist. Durch eine Veränderung der Schrittweite komme ich immerhin schon auf 4min, aber das ist immer noch ganz schön lange für eine eher kleine Tabelle.

Die Laufzeiten stammen von einem PC auf einem Mac sind die, warum auch immer, bei gleichem Code und comet-Projekt deutlich geringer.

Ich hab dazu mit Andreas, der sich, wie ja jeder weiß, auskennt, gemailt :

• Er so: Sollte er nicht einfach mal ne Tabellenzeile mit einer Mindesthöhe in InDesign® definieren? Dann hat er auch keinen Übersatz mehr.
• Ich: Ja, das war eigentlich auch, was ich mir so gedacht hab. Ich konntes nur noch nicht prüfen. Das löst das Problem, oder?
• Er so :Also wenn wir ihn nicht komplett missverstehen, sollte das Problem damit erledigt sein. Ich nehme an, dass er eine fixe Höhe angegeben hat und so erst Übersatz entsteht. Mindesthöhe auf 1,058 mm und Attacke. Es könnte aber auch sein, dass er für die Zelle/Zeile eine zu geringe Maximalhöhe angegeben hat, die steht im Standard auf 211,irgendwas mm. Dann kann natürlich auch Übersatz in einer Zelle entstehen.

Laufen auf Windows mehrere InDesign® ServerfInstanzen parallel, kann es vereinzelt zu falschen Ergebnissen bei XML-Queries kommen. Der Fehler lässt sich vor allem im Autocomet / Batch Betrieb bei mehreren unterschiedlichen Konfigurationen (=config.xml's) beobachten, in anderen Szenarien ist das Auftreten extrem unwahrscheinlich und daher vermutlich kaum zu orten.

Ursache waren konfligierende (jetzt darf ich diesen Begriff endlich auch mal verwenden) temporäre Dateien des XML Parsers. Gelöst ab R3450

Nach einem Template-Tausch und anschliessendem Undo sind Cometgruppen mit itemlist::get_cometgroup_members nicht mehr auflösbar. Auch alle anderen Befehle (remove_cometgroup, resolve_cometgroup, ...) funktionieren nicht mehr.

Das Problem sind die Undos.

Hintergrund

Cometgruppen werden über die UIDs der Rahmen gebildet. (UIDs sind eindeutige Nummern der Objekte eines INDD-Dokumentes die immer weiter wachsen. Einmal verwendete Nummern werden nie wieder verwendet.) Beim Template-Tausch gehen diese UIDs verloren und die neuen Rahmen werden (mit neuen UIDs) neu gruppiert (ein scheusslich schwieriger Prozess, der noch dadurch erschwert wird, dass InDesign® nicht RahmenLISTEN kopiert, sondern immer nur einzelne Rahmen - das sieht nur nach aussen so aus, als wäre das ein Schritt). Wie auch immer, nachdem alle internen Verweise für die Cometgruppe aktualisiert wurden, hat die Cometgruppe natürlich eine neue ID.

Jetzt kommt DER KUNDE und sagt, naja, aber wir haben zu diesem Produkt eine Cometgruppen-ID irgendwo hinterlegt, die finden wir ja jetzt nicht mehr.

Und deshalb gibt es im Dokument eine Liste mit Wertepaaren "Erste ID - Aktuelle ID". Die wird nach jedem Copy/Paste, Neuanlegen, ... von Rahmen aktualisiert. Alles ist lieb und alles funktioniert.

Problem

Jetzt kommt ein Undo. Über dieses Ereignis informiert InDesign® nicht - und schon gar nicht darüber, was rückgängig gemacht. Die alten Rahmen (inkl. der alten) Cometgruppen-IDs sind wieder im Dokument. Aber leider auch noch der letzte Eintrag in der Liste mit den Wertepaaren. Wir bekommen ja gar nicht mit, dass die alten Rahmen wieder eingesetzt wurden. Sieht dann etwa so aus:

• Gruppe mit der ID 100
• Template-Tausch
• Es entsteht die neue Gruppe 200
• In die Wertepaareliste wird eingetragen : 100 - 200
• Die getauschte Gruppe bekommt nach aussen wieder die 100
• UNDO
• Der Rahmen 200 geht wieder verloren, der Rahmen 100 kommt zurück
• Der Rahmen 100 hat auch wieder die Cometgruppe 100
• ABER : In der Liste steht weiter : 100 - 200

Und wenn man jetzt nach der Gruppe 100 sucht, dann sagt unsere Liste : Na, dann schau mal in 200 nach - und das gibt es nicht mehr. Also bleibt die Cometgruppe leer.

DAS PROBLEM GELöST

Hofix von R3133-2 für DEN KUNDEN

ftp://ftp.werk-ii.com//WERKII/Comet/Partner_Downloads/Hotfixes/2013_02_22_R3313-2

11.2.2013

Wenn ich in einem Sync-Script xml::iattribute() oder xml::xattribute() verwende, setzt der Comet keinen Sync-Status mehr - zumindest bei einem Rahmenplatzhalter.

Jepp, ist gelöst.

Das Problem war der Aufruf einer InDesign®-API-Funktion mit deren Hilfe das XML-Element des aktuellen Skriptrahmens geholt wird (falls vorhanden). Die XML-Pfade in der o.g. genannten Funktion können ja auch lokal vom Rahmen ausgehen. Wie auch immer, diese Funktion hat die Rahmenreferenz als Eingabe benötigt - hat aber in diesen Parameter auch die Ergebnis-Referenz reingeschrieben. Das Skript hatte danach also eine leere Rahmenreferenz. Kein Wunder, dass dann nichts mehr geht.

Was passiert eigentlich, wenn ich einen float-Wert gegen ein int oder gar gegen einen char*-String teste? Der häufigste Fall ist sicher der :

float f = 12.3;
if (f == 0) ...

Das geht bereits seit langem. Im Beispiel würde "Falsch" herauskommen. Mit der Zuweisung f= 0.0 würde der Vergleich (f == 0) true ergeben.

Neu ist : Auch der Vergleich gegen Strings funktioniert :

if (f == "0")    // ⇒ true
if (f == "0.0")  // ⇒  true
if (f == "0.1")  // ⇒ false

int i = 0;

if (i = 0.0)		// ⇒ true
if (i == 0.6)		// ⇒ ebenfalls true
if (i == -0.6)		// ⇒ ebenfalls true

int i = 0;
i = i + 1;		// ⇒  Neuer Wert von i ist 2
i = i + 1.6;	// ⇒  Neuer Wert von i ist 2
i = i + -1.6;	// ⇒  Neuer Wert von i ist 0

Seit der 64-Bit-änderung für cScript (Bug 3168) funktionieren Bedingungen mit float-Vergleichen nicht mehr zuverlässig.

Im folgenden Beispielcode kann es (muss aber nicht) passieren, dass der if-Zweig der Bedingung besucht wird:

float 	x;
...

x = 1.5
if (x <= 0.0)
{
}
else
{
}

Schrecklich, aber wahr. Der Fehler ist gefixt.

Das sollte ein • (Bullet-Point) sein. Den hat der VisualStudio-Editor beim Editieren der C++-Datei kaputt gemacht. Ist gefixt - und zwar so, dass VS ihn nicht mehr kriegt.

Ich frage in meinem Batch-Job nach dem aktuellen Dateipfad des Dokumentes. Leider ist der immer leer.

Tja, dann ist das Original-Dokument (DMN_SCHEDULEDJOBS.TemplatePath) in einer älteren CS-Version. Dann wird zwar eine Kopie der Datei gezogen. Beim öffnen wird aber eine neues, konvertiertes Dokument gerzeugt - das natürlich keinen Dateipfad hat.

Für DMN_SCHEDULEDJOBS.ObjectPath = "/dev/null" ist das mit Bug 3173 gefixt. Für alle anderen Situationen muss die unter DMN_SCHEDULEDJOBS.TemplatePath angegebene Datei der aktuellen CS-Version entsprechen.

Wir führen Batch-Jobs mit der Ausgabe "/dev/null" aus. D.h., von der Original-Datei wird eine lokale Kopie gemacht, auf der dann der Job ausgeführt wird. Die Datei sollte danach wieder gelöscht werden. Wird sie aber nicht. Wenn man nur genügend Jobs ausführt, ist irgendwann die Festplatte voll.

Ja. Und zwar passiert das immer dann, wenn die Original-Datei aus einer älteren InDesign®-Version stammt. Dann wird die Datei in InDesign® als neues, konvertiertes Dokument geöffnet - und hat also keinen Dateiverweis mehr. Der Versuch, die Dokumentdatei am Ende zu schliessen, schlägt also fehl.

Der "Fehler" wird jetzt umgangen. Die Dateien werden gelöscht.

Workaround

Die Original-Datei in die CS-Version konvertieren, in der die Batch-Jobs ausgeführt werden.

Mir ist gerade das Gesicht auf die Tastatur gefallen, als ich einem Kunden jüngst dynamisch generierte QR-Codes versprach und er gerade eben meinte: "Das ist alles ganz prima, aber wir wollen die QR-Codes dann auch in unserer Hausfarbe "blau" andrucken..."

Ich ähhh... jedenfalls scheint image::barcode speziell beim "qrcode" den Schlüssel "barcolor" zu ignorieren, was Du ja auch dokumentiert hast und ja somit durchaus sein kann.

Siehst Du dennoch irgend ne Chance, wie ich das Ding "blau" bekomme? Nachträglich komme ich da ja auch nicht ran, weil das ja eingebettetes Postscript ist und das ganze aus Vektoren besteht. Da geht InDesign® ja nicht ran.

QRCodes können jetzt Farben (und Hintergrundfarben) bekommen.

R3405

Untersuchen mit Hilfe der Debug-Version von InDesign® haben ergeben, dass die interne Verwendung der Textplatzhalter zwar funktioniert, aber sicherer gestaltet werden kann.

Die entsprechende Umstellung hat über 500 Source-Files mit mehr als 2.500 Stellen betroffen. Die Plugins sollten jetzt sicherer laufen. Erste Tests ergaben zudem einen deutliche Geschwindigkeits-Gewinn. Ein Aufbau von 200 Seiten (!), der zuvor etwa 20 Minunten gebraucht hat, hat mit den neuen Plugins nur noch 13,5 Min. gebraucht. Ob der Gewinn von 30% Zeitersparnis allgemein gilt, werden weitere Tests ergeben.

R3405

InDesign® scheint bei der Arbeit ordentlich Speicher zu verlieren. Kann es sein, dass die Comet-Plugins das verursachen?

Wir haben das alles noch einmal sehr genau geprüft und haben einige Speicherlöcher, die durch die Plugins verursacht wurden, gefunden und geschlossen.

Der Leak-Bericht des Debug-Versuches meldet jetzt 0 (!!) Leaks, die durch die Comet-Plugins verursacht wurden.

Trotzdem können gepufferte Daten (wie z.B. die Platzhalteraktionen) einen Anstieg des benötigten Speicher bewirken. Auch fehlerhafte cScripte können zum Speicher-Verbrauch beitragen.

R3403

In einem Batch-Job werden 200-seitige Dokumente aufgebaut mit 200 Templates aufgebaut. Mit Mac und Windows XP funktioniert das. Server 2003 dagegen führt zum Absturz. In unserem Speichermess-Tool passiert das immer nach 600 MB, obwohl noch mind. 8GB frei wären.

Nach langer Suche hat Christoph herausgefunden, woran der Absturz lag : cScript verwendet zur Adressierung seiner Daten (Funktionen, Parameter, ...) Integer-Werte. Werden die Adressen zu groß, reichen die 31 Bit dieser Zahlen nicht mehr - und es kommen falsche Adressen heraus. Unglücklicherweise wird der Speicher unter Server 2003 offenbar so vergeben, dass man relativ schnell in diesen kritischen Bereich gerät.

Die gesamte Adressierung innerhalb von cScript wurde deshalb auf 64Bit umgestellt. Das Problem ist damit behoben.

Laut Doku kann ich Platzhalter von (und aus) einem Rahmen entfernen, indem ich placeholder::define() mit einer Placeholder-ID von -2 auf den Rahmen anwende.

Leider scheint das nicht so zu funktionieren, oder ich mache was falsch:

• der Rahmenplatzhalter verliert zwar sein Adornment, ist aber lt. Platzhalterwerte-Palette immer noch da und kann auch ausgeführt werden
• die Textplatzhalter im Rahmen sind auch noch alle da.

placeholder::define() gibt brav 0 zurück. Mache ich was falsch? Gibt es einen anderen Weg? Eine ID != 0 für das Produkt hilft auch nicht weiter.

Testscript:

int main()
{
	int err;

	err = placeholder::define(gFrame, -2, 0);
	wlog("", "err = %d (%s)\n", err, serror(err));

	return 0;
}

Die Textplatzhalter machst Du falsch. Du musst die Text-Indizees angeben :

placeholder::define (gFrame, -2, 0, 0, 0, "", 0, kEnd);

Die Rahmenplatzhalter mache ich falsch. Der Skriptbefehl entfernt lediglich das Adornment. Der Platzhalter bleibt. Das ist jetzt gefixt.

ACHTUNG : Ist der Rahmenplatzhalter mit einem Objekt verlinkt, bleibt dieses Objekt im Rahmen stehen. Will man das ebenfalls entfernen, muss VOR placeholder::define (gFrame, -2, 0); noch folg. Aufruf gemacht werden :

placeholder::link2 (gFrame, 0, 0 /* oder -2 */, 0, 0, "");

Der Comet ist ja seit längerer Zeit so schlau, ein im Dokument ausgewähltes Template auch in der Template-Palette zu markieren. Das ist auch extrem hilfreich.

Schön wäre, wenn das auch für gruppierte Templates ginge.

Wenn Du mit "gruppierte Templates" Templates meinst, die gruppierte Rahmen enthalten, dann geht das jetzt :-)

Dito Produktrecherche.

An dem gelben Hilfezettel der Produkte steht, dass beim Drag and Drop bei gehaltener Alt-Taste nur das Template eingefügt wird (und nicht geladen wird.) Das scheint nicht so zu sein. Die Produkte werden auch jedesmal geladen.

Gefixt.

Das war der Stand v3.3 R2851 am 11. 4. 2012.

Mit diesem Verhalten ist es leider nicht mehr möglich, Produkte mit Drag and Drop über Textplatzhaltern zu platzieren : Befindet sich die Maus über einem Textplatzhalter, wird beim Loslassen der Maus der Textplatzhalter neu verlinkt und geladen. Mit ALT wird das Template (ohne Link und Laden) eingesetzt.

Das ist natürlich nicht so schön. Man hätte ja schon auch gerne die Möglichkeit, das komplette Produkt zu platzieren.

Ich habe das Ganze folgendermaßen geändert:

Drag and Drop auf :

• Leerer Hintergrund und Bildrahmen: Platziere und lade das Produkt. Die Alt-Taste hat hier keine Bedeutung.
• Textplatzhalter :
  • Ohne Alt-Taste : Der Textplatzhalter wird mit dem Produkt neu verlinkt und geladen.
  • Mit Alt-Taste : Platziere und lade das Produkt.

Das Platzieren des reinen ungeladenen Templates ist damit aus der Produktrecherche heraus nicht mehr möglich. Aber das kann ja mit der Palette Templates gemacht werden - und ist dort auch besser aufgehoben.

Wir haben einen Produktaufbau mit einem Fortsetzungstemplate. In dem Fortsetzungsrahmen ist eine Tabelle vorhanden, die dann bei Bedarf umbrochen wird. In der Tabelle gibt es eine variable Anzahl von Kopfzeilen (abhängig von den Daten), die dann im neuen Rahmen wiederholt werden

Nach dem Aufbau der Tabelle müssen Bilder in der Tabelle nach einem bestimmten Regelwerk skaliert werden, dazu vergleiche ich die Position der Inline-Rahmen (Bilder) mit denen der Tabellenzellen um herauszufinden, welches Bild in welcher Zelle liegt.

Wenn ich im Fortsetzungsrahmen die Zellengeometrie abfrage, dann bekomme ich falsche Werte für "top" und "bottom", die anscheinend immer um die Höhe der vorhandenen Kopfzeilen verschoben sind. Die Bounding-Box frage ich seitenrelativ ab: table::cell::get_box(table, col, row, kPageRelative, &left, &top, &right, &bottom);

Der Testfall ist recht komplex, würde aber bei Bedarf versuchen den verfügbar zu machen. Gibt es vielleicht auch einen einfacheren Weg, die Bilder in einer Tabellenzelle zu ermitteln? Eingefügt werden die Bilder über table::insertimage()

Verstehe. Stimmt, stimmt nicht.

Den Fehler hab ich gefixt. Ist eine ziemliche Rechnerei mit den Kopfzeilen. Und wird nicht erleichtert dadurch durch die verschiedenen Regeln, ob und wann Kopfzeilen sichtbar sein sollen. Naja, jetzt gehts jedenfalls.

Was ich nicht verstehe ist, wie Du damit die Inline-Bilder einer Tabellenzelle holen willst. Ich würde das so machen:

#include "internal/types.h"
#include "internal/text.h"
#include "internal/table.h"

int main ()
{    
	Table		T   		= table::alloc ();
	ItemRef		frame 		= item::alloc();
	ItemRef		iframe    	= item::alloc();
	List		cols   		= list::alloc ();
	int			start, len, cl, ct, cr, cb;
	float		l, t, r, b;
	int			firstRow;
	ItemList	inlines;
	int			ilid        = 0;

	textmodel::selection (&start, &len, 
		frame, 0, 
		T, &cl, &ct, &cr, &cb);
	if (!table::is_valid (T))    return 0;

	table::cell::get_box (T, cl, ct, 
		kFrameRelative, &l, &t, &r, &b, 
		frame,
		&firstRow);

	// Hat die Zelle ein (oder mehrere Inlines?)
	table::cell::get_textpos (T, cl, ct, &start, &len);
	inlines = itemlist::inlines (frame, start, len);
	if (itemlist::length (inlines))
	{
		// Hier würde man in einer Schleife alle Bilder bearbeiten.
		// Ich hol hier nur mal das Erste.
		itemlist::get (inlines, iframe, 0);
		ilid    = item::getint (iframe);
	}

	showmessage ("Zelle [%d,%d] : %fx%f, %fx%f (Inline : %d)",
		cl, ct, l, t, r-l, b-t, 
		ilid);

	return 0;
}

Wir haben Rahmen mit Gestaltungsregeln, die nach Geometrie-änderungen gefeuert werden sollen. Miit dem Javascriptbefehl

    app.comet.framsformElement

wird die Grösse dieser Rahmen verändert. Dann müssten doch eigentlich die Gestaltungsregeln ausgeführt werden? Werden Sie aber nicht.

Das ist richtig, die Regeln werden (bisher) nicht ausgeführt. app.comet.transformElement verwendet die cScript-Befehle frame::scale und/oder frame::resize. Beide Skriptanweisungen unterdrücken das Ausführen von Gestaltungsregeln nach Geometrie-änderungen.

Das ist bewußt so gemacht, damit diese Regeln keine Seiteneffekte erzeugen können.

Folgende cScript-Befehle haben jetzt jeweils einen zusätzlichen optionalen Parameter, mit dem gesteuert werden kann, ob die Regeln (wie bisher) unterdrückt werden sollen oder ob sie (neu) ausgeführt werden sollen :

• frame::skew
• frame::rotate
• frame::scale
• frame::moveto
• frame::resize

• itemlist::skew
• itemlist::scale
• itemlist::rotate

Die Javascript-Anweisung app.comet.transformElement führt die Gestaltungsregeln "Nach Geometrie-änderung" jetzt ebenfalls aus.

Es kommt vor, dass Platzhalter des Dokumentes zwar in der Export-XML der Platzhalter erscheinen, aber die Rahmenliste (Element <frames>) leer ist. Woran kann das liegen? Ich beobachte dieses Verhalten bei einigen (aber nicht allen) gemergten Zellen.

Es liegt auch nicht daran, ob Tabellenzellen verbunden sind oder nicht. Immer der Platzhalter der ersten Textposition der ersten Zelle der ersten Tabelle eines Textes enthält keine Rahmenliste. Komisch, dass das so spät erst auffällt.

Der Fehler ist gefixt.

Hier ein Skriptcode zum Erzeugen der Placeholder-XML

tree1 = server::get_placeholders (
	0,
	kScopeSpread,
	1,
	"xmlversion:3.1;content:plain;layers:-'script';");
if (!tree1)		return 0;

xmlquery::write (tree1, "$DESKTOP/pp.xml");
xmlquery::close (tree1);

Die Rahmen meines Dokumentes zeigen plötzlich unten rechts große rote Zahlen. Groß heißt : Groß geschrieben und großer Wert. Wo kommen die denn her. Wenn ich die Ansicht für Nägel und Magnete abschalte, verschwinden die Zahlen.

Die großen roten Zahlen stellen die Lesereihehfolge der Rahmen bei Seitenrotationen dar (Palette priint.rotate). Mgwl. sind die Rahmen aus Templates entstanden, die älter als diese Erweiterung sind (v3.2 R2169, 8. Okt. 2010). In diesem Fall fehlen in den Rahmen die nötigen Angaben und InDesign® "denkt" sich was aus.

So bekommt man die Zahlen weg

• Palette "priint.adjust Rahmenliste" öffnen.
• Dann für jede Seite des Dokumentes
  • -Button unten in der Palette klicken
  • -Button unten in der Palette klicken
• Die Zahlen sollten jetzt weg sein.

Zusätzlich filtern die Plugins jetzt alle Sequenznummer die nicht im Bereich 0-4000 sind aus und setzen diese Werte automatisch auf 0. Das heisst dann aber auch : Bei Seiten mit mehr als 4.000 Rahmen können die Sequenznummern nicht mehr vollständig gesetzt werden (Aber: 1. ist priint:rotate bisher sowieso experimentell und 2. sind 4.000 Rahmen eigentlich ganz schön viele, oder?)

Ist die Palette priint.adjust geöffnet, kommt es hin und wieder vor, dass InDesign® abstürzt, wenn die aktuelle Rahmenauswahl gelöscht wird oder ein Dokument geschlossen wird.

Im Crash-Log steht dann als letzte Funktion redraw_nails.

Dieser Fehler ist jetzt hoffentlich gefixt.

InDesign® Serverfkann aus verschiedenen Gründen im Batch- oder CometServer Betrieb Speicher verlieren. Bei längerer Laufzeit kann es vorkommen, dass das Programm sich irgendwann unkontrolliert beendet. Es wäre schöner, das steuern zu können.

Dafür gibt es ab R3400 das neue Kommandozeilen-Argument shutdowntrigger mit den möglichen Parametern

    memory[=low] 
    time=hh:mm:ss
    uptime=1d | 24h | 1440m | 86400s
    documents=n
    jobs=n
    headroom=1G | 1000M | 1000000k

Das Argument kann mehrfach angegeben werden, z.B.

immer um Mitternacht runterfahren oder wenn 100 Dokumente verarbeitet wurden

-shutdowntrigger time=00:00:00 -shutdowntrigger documents=100

Bedeutung der Parameter:

memory[=low]: Beenden, wenn der InDesignMemoryManager kritischen Speicherzustand meldet

time=hh:mm:ss: zu bestimmter Tageszeit beenden

uptime=1d | 24h | 1440m | 86400s: nach bestimmter Laufzeit beenden

documents=n: Beenden, wenn n Dokumente bearbeitet (=mit Whiteboard / CometServer geöffnet)

jobs=n: Beenden, wenn n Batch-Jobs verarbeitet wurden

headroom=1G | 1000M | 1000000k: Beenden, wenn es nicht möglich ist, den gewünschten Speicher zu allokieren

memory[=low] prüft den Speicherzustand zur Idle-Zeit, da wird das meiste wieder freigegeben sein, tendentiell also keine ratsame Angabe

Beenden ist nur möglich, wenn aktuell keine Dokumente vom CometServer auf dieser Instanz geöffnet sind (damit könnte der CometServer derzeit gar nicht umgehen...). Andernfalls wird IDS bei nächster Gelegenheit beendet.

Du hast ja damals in broaden_to_frame eine Funktion eingebaut, dass auch eine umliegende Zelle als Referenz funktioniert. Das funktioniert auch tadellos, berücksichtigt auch Insets, aaaaber keine Konturen.

Leg mal nen Textrahmen an, mit einer einzelnen Zelle. Dieser Zelle gibst Du eine fette Kontur. In diese Zelle setzt Du dann die Tabelle und lässt broaden_to_frame ausführen. Die Tabelle läuft jetzt über die Kontur und zwar so weit, wie die Kontur stark ist.

Workaround, der aber nicht ganz richtig ist: Ich lege rechts ein Inset in Konturstärke an. Dann funktionierts.

Nebenfund:

Deine Standard-Table-Design-Method "Tabelle auf Rahmenbreite" kennt die neue Funktion (Anpassen von Untertabellen an die Breite der unschliessenden Tabellezelle seit v3.3 R2892, 8. Mai 2012) anscheinend noch gar nicht. Die tut nämlich noch wie früher. o_O

Das ist dann aber schon die volle Komfort-Funktion. Die Zell-Umrandung wird jetzt in die Berechnung eingeschlossen.

Der Nebenfund ist ebenfalls gefixt.

Ich habe die Doku so verstanden, dass ich die strtrim()-Funktion verwenden kann, um ein beliebiges Zeichen von Anfang und
Ende eines Strings zu entfernen:

strcpy(out, ",TESTTEXT,");
strtrim(out, ",");

sollte "TESTTEXT" ergeben. Tut es aber nicht - heraus kommt ",TESTTEXT,".

Der Fehler ist gefixt.

Workakround : strtoken

Das folg. Skript testet strtrim und strtoken.

char * cut (int fn, String str, char * s, int c)
{
	int 		tst 	= strtoken; // need an int to compare!

	strcpy (s, string::get (str));

	if (fn == tst)
	{
		int  	t 		= 0;
		int  	T 		= strtokencount (s, c);

		while (t < T)
		{
			if (strlen (strtoken (s, c, t)) > 0)
			{
				strcpy (s, strtoken (s, c, t));
				break;
			}
			++t;
		}
	}
	else 
	{
		fn (s, c);
	}

	return s;
}

int main ()
{
	String 		str 	= string::alloc ();
	char 		s 		[5000];

	textmodel::gettext (str);

	showmessage ("<%s>",  cut (strtrim,  str, s, ','));
	showmessage ("<%s>",  cut (strtoken,  str, s, ','));

	return 0; 

}

Hotfix

8.1.2013

könnte man implementieren, dass man per c-script Ereignisse an Rahmen senden kann? Hintergrund der Idee ist, dass man die Parameter "Zusatzinfo1/2" aktuell ja nur statisch befüllen kann und von c-script aus keinen Einfluss darauf hat.

Wenn das funktionieren würde, könnte man noch ganz andere "Schweinereien" im Template anstellen. :)

frame::apply_layout_rules hat nur ein paar weitere Parameter benötigt, damit das geht.

Jetzt kann man damit noch mehr machen, als über die Gestaltungsregeln möglich ist. In der Palette sind ja nur Rahmen der gleichen Cometgruppe adressierbar. Via Skript kann jeder beliebige Rahmen (im Prinzip auch in anderen Dokumenten) als Receiver möglich.

Ich habe zum Test folg. gemacht :

Ein Rahmen hat ein Gestaltungsregel, die einfach nur ein Showmessage macht :

Ein zweiter Rahmen hat folg. Skript :

int main ()
{
    ItemRef receiver = item::alloc ();

    item::define (receiver, gFrame, 222); // 222 ist die UID des ersten Rahmens
    frame::apply_layout_rules (receiver, 15, gFrame, "from script");

    return 0;
}

Führt man dieses Skript aus, wird die Nachricht "Das ist Rahmen 222!" gezeigt. Viel Spass damit :-)

Seit einiger Zeit fehlt in der Liste der Produkte des Dokumentes der Eintrag für das erste Seitentemplate. In R3300 begann die Liste noch mit einem Seitentemplate, jetzt (R3355) nicht mehr.

Das wäre nicht weiter schlimm. Ich verwende aber Gestaltungs-Ebenenm, die bisher auch in dem ersten Seitentemplate-Eintrag standen. Jetzt, wo dieser Eintrag fehlt, werden natürlich auch die Gestaltungsebenen ignoriert und meine Reorganisation geht schief. Ich kann den Seitentemplate-Eintrag manuell einfügen und die Gestaltungsebene dann festlegen, das funktioniert - aber das muss JEDES Mal gemacht werden.

So sollte die Liste eigentlich aussehen. Der grüne Eintrag für das Seitentemplate fehlt aber leider.

Der Fehler ist als Seiteneffekt des Fixes von Bug 3035 entstanden und besteht seit v3.3 R3170 (20.9.2012). Er ist jetzt gefixt.

Im Tabellenmodul können die Hotspot-Zellen den angelegten Zeilen/Spalten Gruppennamen zuordnen. Dabei kann zusätzlich zwischen ersten/inneren/letzten Zeilen/Spalten unterschieden werden.

Die Gestaltungsmethoden der Tabellen verwenden in der Regel diese Gruppennamen zu Unterscheidung der Zellen. Könnte man die Gruppennamen nicht automatisch als Zellstile interpretieren und nach dem Aufbau automatisch anwenden?

Das geht jetzt. Ganz unten in der Palette "Tabellenaufbau" befindet sich jetzt eine Checkbox mit dem Titel "Gruppennamen als Zellstile verwenden". Ist die aktiviert, werden die vergebenen Gruppennamen nach dem Aufbau als Zellstile angewendet. Die Einstellung gilt global für die gesamte Tabelle. Zellstile müssen aber nicht unbedingt existieren.           

ACHTUNG: Zusätzlich vergebene Gruppennamen für Zellen aus der Liste "Gruppen der Zelle" werden NICHT als Zellstile interpretiert. Diese Gruppennamen werden automatisch und unverändert an alle Geschwister-Zellen weitergereicht - da kann auch gleich ein Zellstil gesetzt werden - das hat die gleiche Wirkung.

Hotfix

19.12.2012

Dokumente, die mit installierten Comet-Plugins erzeugt wurde, führen an Arbeitsplätzen ohne Comet-Plugins mitunter zu dem Dialog "Missing plugins : EMBEDDEDLINK.PLN"

Der Fehler tritt nicht immer auf.

Nein, er sollte gar nicht auftreten. Alle Daten, die von den Comet-Plugins in Dokumente geschrieben werden, haben die Markierung "ignoreable", die genau diesen Dialog verhindern sollte.

Nach langer Suche war es dann doch einfach, den Fehler zu reproduzieren . Bei mir tritt er nur unter Windows auf. Hier genügt es, eine neue und völlig leere Datei zu erzeugen. Wird diese Datei ohne Comet-Plugins geöffnet, erscheint der Dialog.

Das Gleiche unter Mac - funktioniert.

Der Fehler ist gefixt.

Hotfix

12.12.12

Mein kleines Testscript (s.u.) liefert mir immer negative Werte, wenn das Bild verzerrt ist. Egal, ob ich 10º eingebe oder -10º, der Comet liefert immer -10.

int main()
{
	float    skew;

	frame::image_getskew (gFrame, &skew);
	showmessage("skew: %f", skew);

	return 0;
}

Ja stimmt. Die InDesign®-Funktion zum Ermitteln der Verzerrung ist leider entwas irritierend (und hat sich offenbar von CS2 bis jetzt auch geändert): Der absolute Wert ist richtig, das Vorzeichen ist falsch. Wenn man den erhaltenen Wert für die Verzerrung unverändert anwendet, wird die Verzerrung jedesmal genau umgedreht.

Wir ändern jetzt einfach das Vorzeichen nach dem Erfragen der Verzerrung und alles ist richtig.

Das Gleiche gilt auch für die Funktion frame::get_skew.

Der Fehler tritt nur bei InDesign® Server auf: Ich habe sog. befreundete Templates. Wenn die über einen Template-Tausch angewendet werden, werden die Inhalte der Templates trotzdem neu getauscht. Das sollte doch eigentlich nicht sein, oder?

Nein, das sollte nicht sein. Und ist es jetzt auch nicht mehr.

Ich bekomme immer 0 zurück.

Das geht jetzt.

Ich bekomme immer in einen Leestring als Antwort.

Das geht jetzt

Enthält ein Textrahmen nur eine einzige Tabelle, wird der Textrahmen durch fitframe max. 2000 Pt. groß, mehr nicht.

Die Tabellen dürfen jetzt grösser werden (etwa 3,5 km!).

Soll fitframe einen Rahmen anpassen, der dadurch über die untere Seitenkante hinausragen würde, wird die Funktion nicht ausgeführt. Oder genauer : nur teilweise. Der Rahmen wird so angepasst, dass er GENAU (also ohne einen kleinen Weißraum unter der aktuell letzten sichtbaren Zeile endet.

Das ist genau das Verhalten , das die InDesign®-Standardfunktion "Rahmen an Inhalt anpassen" macht. Aber eben nicht richtig.

Das Verhalten ist eine Folge des Fixes von Bug 3124 und jetzt wieder richtig.

Wir haben recht große Tabellen (500 x 10). Die Tabellen wurden mit dem Tabellenmodul aufgebaut. Das ist alles gut. Sollen bei diesen Tabellen alle Zellen ausgewählt werden (Menü oder Auswahl aufziehen), dauert das sehr lange. InDesign® zeigt dann für ungefähr 10 Sekunden, dass es beschäftigt ist (spinning wheel).

ICH KANN SO NICHT ARBEITEN!

Entfernt man die Comet-Plugins, geht die Auswahl schnell.

Nun, seien wir mal ehrlich - ohne die Comet-Plugins gäbe es auch diese großen Tabellen nicht. Jedenfalls nicht mit sinnvollem Inhalt.

Und genau das ist auch das Problem: Hinter den Zellen liegen die für den Tabellenaufbau nötigen Zelleninfos. Die sind in (fast) jeder Zelle anders. Die InDesign®-Tabelle enthält ja im Prinzip die Elemente des Kreuzprodukt irgendwelcher Eigenschaften. Z.B. zu den Eigenschaften Farbe (Zeile) und Größe (Spalte) die jeweiligen Preise:

Merkwürdigerweise befragt InDesign® bei der Zellenauswahl jede ausgewählte Zelle nach diesen Eigenschaften. Und, wenn der Wert einer Zelle anders ist als der der zuletzt befragten Zelle, dann wird die vorletzte Zelle angepasst. Und dann deren Vorgänger, und dann deren Vorgänger, usw usw. Das alles passiert natürlich nur im Speicher. Aber auch das dauert. Es ergibt sich ein sog. quadratischer Aufwand. Das ist immer seehr schlecht, dann es bedeutet, mit zunehmender Anzahl von Daten steigt der Aufwand nicht linear, sondern - na eben quadratisch.

In unserem Fall beträgt der Aufwand

    2*n*n + 2n +1

Für die Auswahl 500x10 Zellen werden also mehr als 50 Millionen Aufrufe benötigt! Ganz egal, wie flott die aufgerufene Funktion ist, das dauert.

Und nun die schlechte Nachricht : Das alles passiert hinter dem Vorhang und ist fest in InDesign® integriert und entzieht sich unserem Einfluss. Ich habe das Verhalten an Adobe gemeldet und nach vielem Aufwand diese Antwort bekommen:

The ReadWrite calls you're seeing when selecting table cells is due to attributes being copied into a focus cache. When anything in a story is selected attributes applied to the selection are copied into a cache to speed queries from observers and others concerning the selection.

We use the ReadWrite method on interfaces as a sort of copy constructor when copying interfaces. This is all done in memory. These ReadWrites are not happening to disk.

In addition the ReadWrite is used as an equality operator. We call ReadWrite to have the interface create an in-memory copy of its contents allowing comparison of attributes without explicit equality operators. This too is done in memory.

One of the reasons the ReadWrites increase exponentially is that, as we're building the focus cache we're comparing each attribute about to be added to the attributes already in the list. Each comparison involves a call to ReadWrite. As each cell adds its instance of your attribute to the list following cells have one more attribute with which they are compared.

So, although you are seeing many calls to ReadWrite, these are all in-memory reads and writes and shouldn't cause a significant performance hit. This is not a bug.

Ziehen Sie selbst Ihre Schlüsse.

Lösung

Leider bietet die Stelle, die da so unglaublich oft gerufen wird, nicht viele Möglichkeiten zu erkennen, woher der Aufruf kommt und ob man ihn umgehen kann. Ich habe trotzdem eine - wenn auch etwas artistische - Methode gefunden.

Der Aufwand ist jetzt nur noch linear, nämlich

    4*n + 2

Bei 500x10 Zellen sind das also nur noch 20.000. Oder 0,04% des ursprünglichen Aufwandes. Und - wir erinnern uns, bei grösseren Zellauswahlen wird der Unterschied noch gravierender. In Zeit umgerechnet bedeutet das:

• Vorher : 10 Sek.
• Jetzt : 0,04 Sek. Das ist wie beim Bobrennen, das bemerken Sie gar nicht.

Achtung

Wir können nur Vermutungen darüber anstellen, was InDesign® da im Hintergrund treibt. Das Ganze ist daher experimentell und Sie müssen die Option erst aktivieren. Verwenden Sie dazu das Menü

    Palette Tabellenaufbau > Schnelle Auswahl von Tabellenzellen

Sollte es zu irgendwelchen Auffälligkeiten/Fehlern beim Sichern von Tabellen mit Tabellen-Aufbau-Daten kommen, schalten Sie das Feature ab und wenden sich bitte an uns: paul@werk-ii.com. Testdatei und eine Beschreibung der Situation beschleunigen das Verfahren ungemein.

In den Server-Plugins ist das Feature natürlich nicht enthalten. Hier verhält sich alles völlig unverändert.

Für eine Reader-Version der Comet-Plugins werden inzwischen die folg. Plugins benötigt :

• CoreServlett
• Comet
• CoreSelection
• EmbeddedLink
• FrameLink
• NEU ToDoList[Model]
• NEU PageTemplates[Model]
• NEU PageAdapter-Reader[Model]
• NEU PageAdapter-Reader

ToDoList [Model] verlangt leider, dass das Plugin PlaceHolder (und damit letztlich der gesamte Comet) installiert ist.

Das ist ab v3.3 R3333 gefixt und ToDoList[Model] kann ohne PlaceHolder verwendet werden.

• Wir haben in der Datenquelle einen Text mit mehreren Absätzen, denen wir aber keinen expliziten Absatzstil zuweisen, d.h. als „Absatztrenner“ verwenden wir <0x000D> bzw. <nl:> (habe beide Varianten probiert).
• InDesign® stellt dann einen schönen Absatz dar und weist dem Absatz auch den richtigen Absatzstil zu
• Beim automatischen Sync werden aber anscheinend weder <0x000D> noch <nl:> als Absatztrenner verwendet, kann das sein?

Text, den ich aus dem Dokument auslese:

<ParaStyle:Produktbeschreibung><CharStyle:Hersteller>Schott Zwiesel<CharStyle:> 
<ParaStyle:Produktbeschreibung><CharStyle:Produktbezeichnung>Fachhandel Exklusiv<CharStyle:>
<ParaStyle:Produktbeschreibung><CharStyle:Produktbezeichnung>Serie: Classico<CharStyle:> 

Text, der aus den Daten kommt (die Variante mit <0x000D>, der Sync funktioniert aber auch bei <nl:> nicht):

%!TT<ParaStyle:Produktbeschreibung><CharStyle:Hersteller>SchottZwiesel<CharStyle:>
<0x000D><CharStyle:Produktbezeichnung>Fachhandel Exklusiv<CharStyle:>
<0x000D><CharStyle:Produktbezeichnung>Serie:Classico<CharStyle:> 

Die folgende Ersetzung im Skript-Code führt dazu, dass die Text gleich sind (<br/> wird zu <nl:>): name = strreplace(name, "<nl:>", "\n<ParaStyle:test>"); Schön wäre es, wenn die beiden Texte als gleich "erkannt" werden ohne die manuelle Korrektur.

Das ist gefixt.

Die Tabellen-Gestaltung "Gleiche Zellen verbinden" funktioniert nicht mehr. Bis R3030 ging das mit der gleichen Tabelle noch.

Das ist eine Folge von Bug 2904. Neben dem Parameter ckeckPgBreaks hat die neue Funktion table::merge_equals auch den Parameter cmpPlaceholders bekommen. Script-Funktion und Tabellengestaltung verweden die gleiche Implementierung. Aber leider war aus Versehen der Default für cmpPlaceholders bei den Tabellengedstaltungen auf true gesetzt. Das ist gefixt.

Zusätzlich hat der Meta-Daten-Dialog für "Gleiche Zellen verbinden" (Abb. 1) jetzt Einstellmöglichkeiten, mit denen diese Eigenschaften geändert werden können (Abb. 2).

    
    Abb. 1

    
    Abb. 2

In einem Skript werden per document::import_masterpage zuerst Musterseiten aus verschiedenen Dokumenten importiert. Danach werden Produkte aufgebaut. Das funktioniert mit InDesign® Desktop. Mit InDesign®-Server funktioniert es nicht. Die erste Musterseite wird richtig importiert. Alles andere fehlt im Dokument.

Das Problem ist gefixt. Es lag daran, dass beim öffnen der Originale der Musterseiten das aktuelle Frontdokument geändert wurde. Alle weiteren änderungen wurden dann leider in diesem Dokument gemacht - das zum Schluss mit ohne zu sichern geschlossen wurde.

Wie kann ich den einen Layer ganz in den Vordergrund bringen? Die Anweisungen layer::move_~ benötigen ja immer eine Angabe für die Ebene, HINTER die die Ebene verschoben werden soll.

Ja stimmt. Mit layer::move_ni und layer::move_ii geht das jetzt, wenn der Index der Ebene, hinter die verschoben werden soll, entweder -1 ist oder grösser als die Anzahl der Ebenen im Dokument.

Hotfix

29.11.2012

Enthält ein Produkt Multistate-Objekt, kann es unter seltenen Umstaänden vorkommen, dass bei der Reorganisation die Cometgruppen-ID des Produktes geändert wird. Das passiert auch dann, wenn das Produkt gar nicht verschoben oder gar mit einem Template geladen werden muss.

Weitere Reorganisationen ändern die Cometgruppen-ID dann nicht mehr.

Das ist gefixt.

Bei der Reorganisation von Dokumenten mit Multistate-Objekten treten Fehler auf. Es entstehen eine Vielzahl neuer "Produkte": Hatte die Produktrecherche vorher etwa drei Einträge, sind es nach der Reorganisation plötzlich 12.

Es sind aber keine neue Rahmen entstanden. Nur die Cometgruppen sehen komisch aus. Es scheint, als hätten die Multistates mehrere Cometgruppen-IDs.

Der Fehler tritt unter diesen Umständen auf:

1. Das Multistate-Objekt steht am weitesten links oben
2. Ein Status des Multistate-Objekts ist der Hauptrahmen der Cometgruppe

Der Fehler ist gefixt.

Im letzten Release (R3302) ging das noch schneller.

Das ist gefixt. War eine Folge von Bug 3111.

In den Skriptbefehlen productlist::get und datapool::get_get_products kann über ein Statement gesteuert werden, wie Einträge der Produktrecherche zu Produktlisten zusammengestellt werden sollen. Z.B.:

    "selected [id3=31 or id3=32]"

Dabei werden Produkte, die die Bedingung(en) in den eckigen Klammern nicht erfüllen, jeweils durch ihre Unterprodukte ersetzt.

Besonders im Textfluss-Aufbau hätte man es nun aber gerne, wenn die Oberprodukte dabei ebenfalls in der Liste bleiben würden (für Überschriften, Kapitel usw.). Was kann man denn da machen?

Das geht jetzt. Dazu müssen die Bedingungen einfach in geschweifte Klammern {} statt in eckige Klammern [] gesetzt werden. Es gibt ausserdem zwei neue neue Schlüssel"worte", mit denen gesteuert werden kann, ob die Listen Doppler enthalten dürfen oder nicht :

• with doubles allowed
• with no doubles

Das darf irgendwo (aber genau in dieser Schreibweise) im Statement stehen und gilt dann für alle gefundenen Einträge (ausser denen, die direkt aus der Produktrecherche kommen, also die, die direkt von "selected", "watch", "list" kommen.

Mehr dazu in der Doku.

Ich habe ein Dokument mit einer für das Tabellenmodul konfigurierten Tabelle. Wenn ich dieses Dokument öffne und z.B. die Gruppenzuweisung einer Hotspot-Zelle ändere, bleibt das Dokument im Status "Unverändert". Beim Schliessen erfolgt keine Nachfrage, ob gesichert werden soll. Nach dem Schliessen sind die änderungen verloren.

Das passiert nur dann, wenn ausschließlich änderungen an bereits konfigurierten Tabellenzellen gemacht werden. Sobald man noch IRGENDEINE ANDERE äNDERUNG am Dokument vornimmt, wird das Dokument ganz normal gesichert und die änderungen der Tabellenzellen werden zurückgeschrieben.

Ich habe das Verhalten, das seit v3.3 R3101 (21.7.2012) so ist, trotzdem wieder geändert. Es war eigentlich dazu gedacht, die Aufbaugeschwindigkeit von Tabellen zu erhöhen (hat es auch - so etwa um das 2-10 fache), aber dieser Seiteneffekt wiegt schwerer.

Wenn man über die Document Selection einen Text in die Preview Palette lädt und dann mehrfach nacheinander (manchmal 2 mal, manchmal aber auch bis zu 4 mal) den Text durch Klick auf den orangen Pfeil in das Dokument übernehmen will, kommt es zu einem InDesign® Absturz.

Das ist gefixt.

Wenn ich den Inhalt eines Platzhalters in einer Tabelle lösche über InDesign® und diesen anschließend über das Aufgabenmanagement aktualisieren möchte stürzt InDesign® ab. Ist der Platzhalter nur in einem Textrahmen dann funktioniert das ganze.

Wir haben die CometVersion 3.3 R 3144 aktuell im Einsatz ich habe aber auch mit Vorgängerversionen getestet da geht es genauso wenig.

Die Loadskripte der einzelnen Platzhalter sind einfach SQL-Aufrufe.

Das sind die lausigen Randfälle - in diesem Fall sogar wörtlich. Denn eigentlich ist der Platzhalter in diesen Fällen gar nicht mehr im Dokument. Nur der Zeichenstil an der Einfügestelle hat die Platzhalter-Info noch. Das verursacht das Problem.

Ist gefixt. Ich lasse das Dokument wie es ist und alles andere auch. Nur wenn beim Laden ein Platzhalter der Länge 0 gefunden wird, wird vorher automatisch ein Zero Space eingefügt.

Hotfix

25.11.2012

Das Holen der Produkte des Dokumentes dauert recht lange : GetItems (Produkte des Dokumentes) dauert ca 12 Sek., GetCometGroups dagegen nur ca. 1,5 Sek.. Die Gruppenliste ist fast die gleiche Liste wie ItemsListe. Vielleicht kann man noch da was optimieren?

Der kleine Unterschied zwischen GetItems und GetCometGroups ist : GetCometGroups holt einfach alles, was es im Dokument findet. GetItems sortiert zusätzlich nach den Seitenelementen. Und genau die Sortierung ist das, was die Zeit braucht. Aber die brauchen wir natürlich für die Reorganisation.

Die Sortierung konnte trotzdem optimiert werden und ist jetzt etwa 3-5 mal schneller.

Hotfix

23.11.2012

Nach einer Reorganisation im Whiteboard müssen alle Spreads des Dokumentes neu berechnet werden. Das ist leider sehr langsam. Woran könnte das denn liegen?

Das kann natürlich recht viele Ursachen haben. Eine davon lag definitiv in den Plugins und ist jetzt korrigiert. Die Plugins benötigen jetzt nur noch etwa 1/10 der Zeit zur Generierung der Spread-Previews.

FYI

Damit die Previews der Spreads richtig gerendete Schriften zeigen, müssen die Spread zuvor einmal im Print-Modus gezeichnet werden. Das wurde bisher im Fullresolution-Modus getan, der dafür gar nicht nötig ist. Im vorliegenden Fall enthalten die Dokumente eine große Anzahl Postscript-Bilder (hier sind es mit image::barcode erzeugte Strichcodes). Im Fullresolution-Modus müssen diese Bilder komplett berechnet werden. Das braucht natürlich eine gewisse Zeit. Im jetzt verwendeten sogenannten Proxy-Modus kann dagegen einfach das Preview der Postscript-Bilder verwendet werden - was durchaus reicht und eben viel schneller ist.

Hotfix

23.11.2012

Wir haben Problemen mit großen Dateien bei unserem Kunden und haben nach Tests folgendes herausgefunden:

Test 1: Wir haben ein neues InDesign® Dokument erstellt und dort 100 einfache, leere Bildrahmen platziert ohne Gestaltungsregeln, Platzhalter oder ähnliches zu verknüpfen. Nachdem wir dann das Dokument gespeichert haben und die Dateigröße überprüft haben, stellten wir fest dass dieses Dokument fast 10MB groß geworden ist.

Test 2: Wir haben nun die Comet Plugins aus InDesign® entfernt und Test 1 nochmals durchgeführt. Ergebnis war, dass dieses Dokument nach dem Abspeichern nur ca. 300 KB hatte!

Die Comet-Plugins benötigen für Platzhalter u.ä. eigene Daten. Die InDesign®-API von Adobe ist dabei so konstruiert, dass JEDER Rahmen diese Attribute bekommt - egal, ob der Rahmen diese Werte verwendet oder nicht. Jeder der 100 neu angelegten Rahmen bekommt also alle für Platzhalter, Nägel&Magnete, ... benötigten Datenfelder.

Genauere Tests ergaben folg. Platzbedarf für die einzelnen Erweiterungen:

Das Problem sind also die Nägel und Magneten.

Mit etwas Mühe ist es mir gelungen, den Speicherbedarf drastisch zu senken. Und das Charmanteste daran : Die änderung bedarf keiner Konvertierung bestehender Dokumente. Sie wirkt aber (s.o.) nur auf geänderte und neue Rahmen. Hier einige "bench marks"

Ein Rahmen benötigt also 1900 Bytes für Nägel und Magneten und für alle Comet-Daten zusammen etwa 5.000 Bytes statt wie bisher 99.000 Bytes, In Abhängigkeit von der Anzahl der Rahmen im Dokument kann die Dateigrösse also bis zu 95% heruntergehen (im Bespiel 13%).

Achtung: Auch wenn die Rahmen jetzt viel weniger ins Dokument schreiben (lassen) - alte Dokumente werden nicht wirklich kleiner. Das Verhalten ist InDesign®-immanent und kann von uns nicht geändert werden.

Neue Dokumente werden deutlich kleiner. Produkttemplates müssen dafür nicht geändert werden.

Workaround

Wenn Sie Nägel und Magnenten nicht verwenden, können Sie Plugins "PageAdapter" und "PageAdapter [Model]" einfach entfernen. NEUE Rahmen benötigen dann die genannten 96.000 Bytes weniger im Dokument. Alte Rahmen behalten ihre Grösse. Um Dokumente kleiner zu bekommen, müssen sie hier einmal in IDML exportiert und wieder importiert werden.

Hat man versehentlich ein falsches Passwort für den Login eingegeben, wird der Login-Dialog erneut geöffnet. Die Einstellung des Zeichensatzes wird dabei immer automatisch auf UTF-8 umgestellt. Egal, welche Einstellung man vorher hatte. Also ich übersehe solche änderungen - und dann wird mein Login wahrscheinlich falsch.

Das ist gefixt.

Die leeren, dimensionslosen InDesign®-Gruppen, die in Bug 3103 beschrieben wurden, führen ja zum Absturz der Reorganistion. Es gibt jetzt aber schon eine ganze Reihe Dokumente mit solchen Rahmen. Und diese Objekte sind recht schwer zu finden.

Kann man da was machen?

Diese Objekte werden jetzt beim Sammeln der Produkte des Dokumentes automatisch gelöscht. Im Logfile erscheinen Meldungen der Art

# Empty InDesign® group with uid 123 found at page 3
# Dimensionless frame with uid 126 found at page 3

Beim Templatetausch werden alle Rahme der alten Cometgruppe gelöscht. Sind die Rahmen dabei InDesign®-gruppiert, kann es passieren, dass ein leeres 0-dimensionales Gruppenobjekt auf der Seite zurückgleibt. Man kann das Objekt in der Ebenen-Palette sehen.

Bei Reorganisationen sdes Dokumentes führen diese Objekte zum Absturz von InDesign.

Ich weiss nicht, wie InDesign® das schafft, aber tatsächlich, es bleibt ein leeres Objekt ohne Dimension zurück, wenn die Rahmen gruppiert sind.

Ich kann dieses Verhalten umgehen. Die leeren Objekte entstehen jetzt nicht mehr.

So ist es. An gleicher Stelle in InDesign® Desktop verwendet, liefert die Funktion den richtigen Template-Namen.

Der Template-Name wird über das Plugin Pageitems berechnet, das es unter ID Server gar nicht gibt.

Aber man bekommt den Namen freilich auch anders heraus. Das machen die Plugins jetzt.

Enthält ein Textrahmen ausschließlich unsichtbare Zeichen, verhält sich InDesign® beim Anpassen der Rahmengrösse merkürdig:

• Ist der Rahmen höher als die Textzeile, wird gar nichts gemacht
• Ist der Rahmen niedriger als eine Textzeile, funktioniert es.

Zusätzlich wird im ersten Fall manchmal ein Overset erkannt, obwohl gar keiner da ist.

Ich habe die Funktion fitframe (frame::fit, Gestaltungsregel "Rahmen anpassen) an diese Situation angepasst und die Funktion arbeitet jetzt auch in diesen Spezialfällen richtig.

ACHTUNG : Die änderung der Funktion kann mglw. Aiswirkungen auf bestehende Anwendungen haben. Sollte es zu unerwartetem Verhalten von Rahmen bei Anwendung von fitframe kommen, bitte ich dringend um Nachricht (paul@werk-ii.com). Senden Sie mir bitte in diesem Fall auch die InDesign® mit dem beanstandetem Rahmen und einen Hinweis, um welchen Dokumentrahmen es sich handelt.

20.11.2012

(➚+fitempty)

Ein Rahmen meines Produktes fügt mit document::place_items weitere Rahmen ins Dokument ein :

li = document::place_items (
	0,
	"data","pageitems", 552,
	l, t-90.0, page::get(gFrame), "",
	gRecordID,
	gRecordID2,
	gRecordID3,
	"$DESKTOP/Bilder/buffer.jpg",
	1);

In der Liste der Produkte des Dokumentes erscheint das Produkt dann mit der String-ID, die in place_items angegeben wurde (hier "$DESKTOP/Bilder/buffer.jpg"). Das gibt natürlich beim Reorganisieren einigen ärger. Mir ist aufgefallen, dass der Fehler nicht auftritt, wenn die zusätzlichen Rahmen unter oder neben dem auslösenden Rahmen angelegt werden. Nur wenn einer der zusätzlichen Rahmen die neue linke obere Ecke aller Rahmen des Produktes bildet, tritt dieses Verhalten auf.

Dieser Fehler ist gefixt. Ein analoges Verhalten tritt auch in anderen Funktionen, die Dokumentrahmen anlegen, auf. Der Fehler ist in folgenden Funktionen gefixt wurden::

• document::place_items
• document::place_indesign
• document::insert_macro
• frame::create, frame::create2
• frame::create_textframe, frame::create_textframe_f

20.11.2012

(➚+builtByID)

Wenn ich mit dem weissen Pfeil Bildinhalte statt der eigentlichen Rahmen auswähle, wird die Liste "Produkte des Dokumentes" nicht angepasst.

Das wird jetzt ebenfalls gemacht.

20.11.2012

(➚+podimg)

Ich habe die Rahmen der Produkte mit InDesign®-Gruppen zusammengefasst. In der Liste "Produkte des Dokumentes" werden die Produkte auch richtig angezeigt. Wähle ich aber einen Produktrahmen (also einen Unterrahmen der InDesign®-Gruppe), wird das zugehörige Produkt leider nicht in der Liste "Produkte des Dokumentes" ausgewählt.

Das geht jetzt.

20.11.2012

(➚+podsub)

Sehr viele Cometfunktionen (Produktaufbau, Gestaltungsregeln, Seitenadaptionen, ...) schreiben bei Aktionen und Fehlern die UIDs der betroffenen Rahmen ins Logfile. Leider gibt es keine Standardfunktion, um einen Rahmen über seine UID auch im Dokument zu finden. Ich kann mir dafür zwar ein Skript schreiben, aber das muss ich dann in jedem Datenpool neu definieren. Könnte man diese Funktion nicht als Standard implementieren?

Ja, man kann. Es gibt dazu jetzt einen Menübefehl :

Produktrecherche -> Verschiedenes -> Rahmen auswählen

Und hier, der Vollständigkeit halber, noch ein Skript zur Rahmenauswahl (das nun gar nicht benötigt wird):

int main ()
{
	char		str		[50000];
	char		str1	[50000];
	int			p		= 0;
	int			len		= 0;
	ItemRef		fr		= item::alloc ();
	ItemList	frames	= itemlist::alloc ();
	
	if (gRun > 1)	return 0;
	if (!askstring (str, 
			"Text mit Rahmen-UIDs",
			"Auswahl von Dokumentrahmen",
			"", "", 0, 49999)) return 0;
	
	while (1)
	{
		p = strstrpos (str, "regexp:[1-9][0-9]*", p, &len);
		if (p < 0)	break;
		
		if (len > 0)
		{
			strcpy (str1, str, p, len);
			p = p + len;
			
			item::define (fr, 0, val (str1));
			if (frame::is_valid (fr))
			{
				itemlist::append (frames, fr);
			}
		}
		else p = p +1;
	}
	
	if (itemlist::length (frames)) itemlist::select (frames);
	
	return 0;
}

Mit Hilfe der Panelstatements 123 und 124 können ja jetzt schon Export und Import von InDesign®-Bibiothken unterstützt werden. Leider ist dazu doch einiges an Script-Know-how nötig - und eigentlich wird überall das Gleiche benötigt :

Export

• Schreibe die Bibliothek in eine Datenbanktabelle
• Schreibe die Assets in eine andere Datenbanktabelle

Import

• Stelle die Bibliothek aus diesen Datenbanktabellen wieder her

Sind die Panelstatements 123 und 124 nicht definiert oder zeigen auf leere Anweisungen, wird jetzt für ODBC- und OCI-Verbindungen ein Standardmechanismus zum Export und Import von Bibliotheken zur Verfügung gestellt.

Mehr dazu in der Online-Doku (Export, Import).

Hotfix

14.11.2012

Obwohl ich nur den Textcursor gesetzt habe (und keine weiteren Zeichen ausgewählt habe) löscht der Befehl Bearbeiten -> Einfügen ohne Formatierung ein ganzes Stück Text, bevor der Text aus der Zwischenablage eingefügt wird.

Sind nach hinten nicht mehr genügend Zeichen zum Löschen vorhanden, stürzt InDesign® ab.

Ah, auf den Tag GENAU vier Jahre alt, der Fehler. Am 9.11.2008 kam die erste Version der Plugins für CS4 raus - seitdem ist diese Funktion falsch.

Beim Ermitteln der aktuellen Auswahl wurden Start- und Endindex der Auswahl geholt. Der Endindex wurde dann fälschlicherweise als LäNGE interpretiert.

Der Fehler ist gefixt.

Bug oder Feature? Wenn man Tabellenzellen z.B. Absatzformate zugewiesen und über den Tabelleneditor die diversen Einstellungen für den tabellenaufbau eingegeben hat, wird bei den Absatzformaten in der Formatpalette ein "+" angezeigt, so als ob zusätzlich zum Format eine lokale Formatierung hinzugekommen wäre. Klickt man dann auf den Formateintrag mit gedrückter Alt-Taste (um die "lokale Formatierung" zu entfernen), dann verschwinden auch die Einstellungen des Tabelleneditors, und man muss alles neu eingeben.

Das Ganze passiert vor allem dann, wenn man Feintuning am Tabellenlayout betreibt, bevor man das Template dann endgültig speichert, und es ist ausgesprochen lästig! Muss das unbedingt sein, oder kann man es so machen, dass die Tabelleneinstellungen nicht durch die Formatierung beeinflusst werden? Unter Umständen kann durch dieses Verhalten ein Kunde, der nur die Gestaltung einer Tabelle anpassen will, das komplette Template "zerschießen"...

Das Problem ist ja ziemlich gemein. Bei Textattributen - wie z.B. den Textplatzhaltern - geht das. Leider enthält aber die sog. AttributeReport-Klasse für Tabellen- und Zellenattribute der InDesign®-API keine Möglichkeit, Attribute für den Plus-Entferner durchsichtig zu machen.

Ich glaube, wir können da leider gar nichts machen. Ich versuche trotzdem mal, den Adobe-Support zu befragen.

Ich habe einen Support-Case bei Adobe geöffnet - was gar nicht so einfach war. Ich habe einen isolierten Testfall gebaut - ein vollständiges Plugin, das NUR DIESES Problem enthält. Ich habe das Problem auf 10 verschiedene Arten beschrieben. Ich habe ungefähr 20 Mails an den Support geschrieben und ungefähr 20 bekommen. Hier exemplarisch ein Auszug aus einer der der letzten :

    It is working just how it should work.

Einige Monate später

In einem anderen Zusammenhang hab ich das Problem noch mal bei Adobe zur Sprache gebracht und einen - wenn auch kleinen - so doch hilfreichen Tipp bekommen. Und nachdem ich einen Tag wie wild auf die Tastatur eingehauen habe, konnte ich das Problem lösen :

Die Einstellungen des Tabellenmoduls sind ab jetzt nicht mehr Teil von Zellformaten. Ich filtere die alle raus - auf zwei Seiten Quelltext. Das Ausfiltern wird in folgenden Situationen gemacht:

• Anlegen neuer Zellstile
• Menü der Palette Tabellenaufbau -> Tabellenmodul-Eigenschaften aus Zellformaten entfernen

ACHTUNG!

änderungen an Formaten ändern automatisch auch alle Dokumentteile, die diese Formate verwenden.

Wenn ein Zellenformat geändert wird, das Informationen für das Tabellenmodul enthält, werden diese Informationen auch aus allen Tabellenzellen entfernt, die dieses Zellenformat verwenden. So geänderte Tabellen können danach nicht mehr ordnungsgemäß aufgebaut werden.

Aus Performance-Gründen wird das Ausfiltern nicht beim Anwenden eines Zellstiles gemacht.

Die Menübefehle für Tabellen

    Einfügen->Ausgewählte Zeilen/Spalten

können die aktuell ausgewählten Zeilen/Spalten einer Tabelle duplizieren. Das ist prima und wäre mit InDesign®-Bordmitteln nicht möglich. Leider werden bei den Aktionen nur die Zellen selbst kopiert. Inhalte werden nicht übernommen.

Das ist richtig. Ich habe mich hier an den Standardbefehlen Einfügen->Zeilen/Spalten orientiert, die ebenfalls keine Inhalte übertragen.

Als philanthropische Tat : Es gibt zwei weitere Menübefehle:

    Einfügen->Ausgewählte Zeilen/Spalten mit Inhalt

Die Menübefehle für Tabellen

    Einfügen->Ausgewählte Zeilen/Spalten

können die aktuell ausgewählten Zeilen/Spalten einer Tabelle duplizieren. Das ist prima und wäre mit InDesign®-Bordmitteln nicht möglich. Leider sind für ein Undo der Aktion, das ja trotzdem manchmal nötig ist, gaanz viele Einzelschritte nötig.

Das ist gefixt. Es ist nur noch ein Undo nötig, um den alten Zustand wiederherzustellen.

Hotfix

01.11.2012

Analog zu gNewValue (Wert für "Datenquelle" in der Aufgabenpalette) fände ich noch ein gOldValue (Wert für "Dokument") sinnvoll. Manchmal sollen Platzhalter ja vielleicht gar nicht vergleichen, was im Text steht, sondern andere Dinge prüfen.

Das gibt es jetzt. Der Wert kann an der selben Stelle im Skript gesetzt werden, wo auch gNewValue gesetzt wird.

ACHTUNG: Nicht in allen Situationen ist gOldValue definiert. Auch wenn gNewValue definiert ist, sollte eine Abfrage für gOldValue gemacht werden :

if (gOldValue)
{
    ...
}

Ist es tatsächlich so, dass ein setzen des parameters «alignment» in frame::stroke keinerlei auswirkungen hat!? egal ob ich den parameter auf -1, 0, 1 oder 2 setze, die kontur wird immer mittig gesetzt! könnt ihr das nachvollziehn?

Nein, das ist nicht so. Aber in der Doku fehlt in der Tabelle der Parameter gapOverprint. alignment muss also eins nach hinten rutschen, dann funktioniert es.

ACHTUNG : Wie ich gerade sehe, steht der Parameter miter zwar in der Doku. Aber der wird aktuell tatsächlich nicht ausgewertet. Das ist gefixt. (und die Doku natürlich auch.)

In den Trenntexten von Platzhaltern dürfen ja Skripte ausgeführt werden :

    # "Mein Trenntext" Script 123456

Das führt leider zum Absturz von InDesign.

Der Fehler ist gefixt.

Hotfix

26.10.2012

Über den Notizen-Label werden noch zwei kleine Icons (Rolle und Typ) und das Datum angezeigt. Diese Angaben sind rechtsbündig zum Notizen-Label. Ist das Label kurz (weil der Name der Notiz kurz ist oder fehlt und/oder weil der Zuständige für die Notiz fehlt oder einen kurzen Namen hat), dann ragt die Beschriftung recht weit nach links über die Notiz hinaus. Sieht nicht so schön aus. Könnte man das nicht linksbündig machen. Auf der rechten Seite ist ja einfach durch die Notiz selbst in der Regel mehr Platz.

Man kann - und man hat.

Ich habe in einem Textplatzhalter vier Tabellen eingefügt. Diese Tabellen sollen anschliessend der Reihe nach aufgebaut werden :

for (i = 0; i < 4; i++)
{	
	table::get(t, gFrame, i, gStart, gLen);	pos = table::get_anchorpos(t, &len);	
	if (pos < 0)
	{
		showmessage("Table not found in frame");
		break;
	}
	
	placeholder::link2(0, 3, gRecordID, 0, 0, strngid, pos, len);
	table::build (t);
}

Leider kommt nach dem Aufbau der ersten Tabelle die Meldung, dass keine weiteren Tabellen gefunden werden. Manchmal auch erst nach der zweiten Tabelle. die Tabellen sind aber definitiv im Dokument und gehören zum Platzhalter.

Das Gleiche gilt für table::reduce.

textmodel::restore hat einen Parameter, mit dem die Anzahl der eingefügten Zeichen ins Dokument zurück bekommt. Der liefert mitunter negative Werte :-(

Ja, und zwar immer dann, wenn das eingefügte Macro Tabellen enthält. Das ist gefixt. Die Längenangabe sollte jetzt richtig sein.

ACHTUNG:

Gleichzeitig mit diesem Fix ist das Verhalten der Funktion etwas geändert worden. Die Positionsangaben der Funktion sind ja textmodel-relativ und nicht wie sonst immer, platzhalter-relativ. Das ist natürlich weiter so. ABER : Wenn innerhalb des aktiven Platzhalters eingefügt wird, wird die Längenangabe platzhalter-relativ ausgewertet. kEnd ist in diesem Fall also das Ende des Platzhalters und nicht mehr, wie bisher, das Textende.

textmodel::insert_macro hat einen Parameter, mit dem die Anzahl der eingefügten Zeichen ins Dokument zurück bekommt. Der liefert mitunter negative Werte :-(

Ja, und zwar immer dann, wenn das eingefügte Macro Tabellen enthält. Das ist gefixt. Die Längenangabe sollte jetzt richtig sein.

ACHTUNG:

Gleichzeitig mit diesem Fix ist das Verhalten der Funktion etwas geändert worden. Die Positionsangaben der Funktion sind ja textmodel-relativ und nicht wie sonst immer, platzhalter-relativ. Das ist natürlich weiter so. ABER : Wenn innerhalb des aktiven Platzhalters eingefügt wird, wird die Längenangabe platzhalter-relativ ausgewertet. kEnd ist in diesem Fall also das Ende des Platzhalters und nicht mehr, wie bisher, das Textende.

Die mit einem roten Pfeil markierte Einstellung geht nicht mehr zu ändern. Bis R3170 ging das noch :

Das geht wieder.

In der Palette "Platzhalterwerte" sind seit v3.3 R3144 hinter den Editfeldern für die Prä- und Postfixe kleine Büroklammern, mit denen diese Texte konfiguriert werden können. In dem erscheinenden Dialog sollten unten alle Prefix/Postfix-Skripte (ClassID 50) gezeigt werden. Werden aber nicht. Das Popup ist leer.

Der Fehler tritt nur bei XML und SOAP auf. Bei Datenbankverbindungen werden die Skripte gezeigt.

Der Fehler ist gefixt.

In der Palette "Platzhalterwerte" sind seit v3.3 R3144 hinter den Editfeldern für die Prä- und Postfixe kleine Büroklammern, mit denen diese Texte konfiguriert werden können. Nur die erste Büroklammer öffnet den erwarteten Dialog. Die drei anderen Klammern tun nichts.

Das ist gefixt. Alle vier Büroklammern öffnen jetzt den Dialog und setzen dann das Ergebnis jeweils in das richtige Edit-Feld.

Ich vermisse die Funktion einen einzelnen Hyperlink direkt löschen zu können.

hyperlink::delete_ macht das jetzt. Mehr dazu in der Doku.

Mit frame::get_smart_item_data() kann die Kennung eines Rahmens ausgelesen werden. Wie kann diese Kennung per C-Skript gesetzt werden?

Dafür gibt es jetzt die neue Funktion frame::set_smart_item_data.

WORKAROUND

Mit placeholder::sget_value und placeholder::change_tags und dem Info-Slot "SmartInfo" kann man die Kennung ebenfalls ändern :

1. SmartInfo mit placeholder::sget_value holen
2. Das erste Zeichen des Strings ändern
3. SmartInfo mit placeholder::change_tags zurückschreiben

Unser Kunde ist auf ein Problem gestoßen, das beim Hinzufügen von Rahmen zu einer Comet-Gruppe auftritt. Im Anhang finden Sie ein Dokument, welches auf der linken und rechten Seite jeweils die selben Rahmen hat (sie wurden dupliziert). Der einzige Unterschied ist die Anordnung von links. Auf der ersten Seite liegt der hinzuzufügende Rahmen links von der Gruppe, auf der 2 Seite rechts davon.

Markiere ich nun beide Rahmen auf der linken Seite und führe den Contextmenü-Befehl "Rahmen zur Gruppe hinzufügen" aus, passiert gar nichts. Mache ich das selbe auf der rechten Seite funktioniert es. Unser Verdacht ist hier, dass Rahmen, die links von einer Comet-Gruppe liegen nicht zu dieser Gruppe hinzugefügt werden können.

Das Problem liegt natürlich nicht an der XY-Position des Rahmens. Es ist gefixt.

Analog zu get_font() hätte ich gern noch set_font(). Am liebsten so: textmodel::set_font(ItemRef frameRef, int startPos, int len, char* fontFamily, char* fontStyle), wobei fontFamily und fontStyle optional sein sollten (vielleicht will man ja nur eins davon setzen).

Warum will ich das und benutze keinen TaggedText? Weil InDesign® doof ist. Der Wert für cTypeface (also fontStyle) wird ignoriert, wenn direkt davor ein verschachteltes Format kommt. Dabei spielt die Reihenfolge der Tags keine Rolle, und andere Tricks auch nicht. Der Wert für cFont wird berücksichtigt.

Implementiert:

textmodel::set_font
textmodel::set_fontsize

Wir haben sehr viele Platzhalter (>300) und recht große Tabellen. Ist die Platzhalter-Palette geöffnet und sind dort alle Platzhalter geladen, passiert es immer wieder, dass InDesign® scheinbar steht. Die Wartezeiten können bis zu 30 Sek. (!) dauern. Dieses Verhalten tritt nur auf, wenn die Auswahl viele (>50) Platzhalter enthält (Tabellen, langer Text, viele Rahmen mit Platzhaltern).

Mit dem Fix von Bug 2786 beherrscht die Platzhalter-Palette Mehrfach-Auswahlen. Dazu müssen alle im Dokument ausgewählten Platzhalter in der Platzhalterliste gesucht und dann ausgewählt werden.

In meinem Test habe eine 62x10 große Tabelle und 777 Platzhalter - macht also knapp 1/2 Mio. Vergleiche. Das dauert - auch wenn der Rechner schnell ist. Erschwerend kommt hinzu, dass InDesign® den nötigen Observer für die Dokumentauswahl gleich 10 mal (!) aktiviert. Aus welchem Grund auch immer. Das sind dann also 5 Mio Vergleiche mit 6000 mal durch eine 777 Einträge lange Liste rennen. Ordentlich was zu tun.

Das meiste davon ist unnötig. Und den Rest konnte ich optimieren. Die Auswahl, die bei bis bisher 30 Sekunden gedauert hat, dauert jetzt noch etwa eine halbe Sekunde. Drunter geht nicht mehr.

In der Palette "Produkte des Dokumentes" kann man ja die Templates der Produkte tauschen. In der Liste wird dann das Template hinter dem Produkt unterstrichen dargestellt. Im Bild wurde das Template von "Flug der Engel" in "5. priint.day" geändert:

Wenn man dann reorganisiert, wird aber immer wieder das alte Template verwendet. Was mache ich falsch?

Gar nichts machst Du falsch. Die Plugins machen falsch. Das Problem ist gefixt. Templates lassen sich jetzt wieder tauschen.

Hotfix

12.10.2012

Wenn ich im Tabellenmodul in einer Table-Insert-Method den aktuellen Ebenen-Name auslesen will (layer::get_name(gFrame)), dann funktioniert das nicht zuverlässig.

Es verhält sich folgendermaßen:

Wenn ich Comet ganz neu mit der Datenbank verbinde und die Tabelle aufbauen lasse, ist das Ergebnis von layer::get_name(gFrame) leer. Bei einem erneuten Aufruf funktioniert es dann.

Es hat den Anschein, als wenn beim Erstaufruf "gFrame" noch gar nicht gefüllt ist und erst nach der Table-Insert-Method einen Wert bekommt. Beim nachfolgenden Aufruf verhält es sich dann genauso, bekomme aber den Wert, den ich beim Erstaufruf quasi zu spät erhalte. (Das kann man testen, in dem man zwischen dem ersten und zweite Aufruf den Ebenennamen wechselt.)

Das scheint mir ein Bug zu sein, oder wie komme ich an der Stelle zuverlässig an den Ebenen-Namen?

Nein, das Ergebnis ist eher zufällig. Die Skripte haben gFrame bisher überhaupt nicht gekannt. Jetzt sollten Sie es kennen.

Ich muss in einem Projekt die Hintergrundfarbe eines Rahmens setzen. Da die Farbe im Dokument definiert, aber durch Verwendung verschiedener Musterdokumente pro Dokument jeweils anders ist, mache ich das mit frame::color(gFrame, [Farbname]);

Leider habe ich dabei keine Möglichkeit, den Deckungsgrad (Tint) der Farbe zu setzen. Ich benötige 20% Deckungsgrad.

Ich hab schon versucht, das mit frame::opacity(gFrame,20.0,0,0); zu setzen, aber das bezieht sich ja auf die Transparenz des Rahmens und wirkt sich auch auf seinen Inhalt aus, ist also unbrauchbar.

Der Parameter hat bisher (niemandem) gefehlt. Jetzt hat die Funktion einen zusätzlichen Parameter. Angabe 0.0-100.0 (-1.0 für "Ignore").

Sind auf einer Seite mehrere Seitenelemente und werden Fortsetzungen verwendet, ist die Reihenfolge der Produkte des Dokumentes falsch.

Beispiel

Seitenelemente (E~) mit Produkten (P~)

E1 mit P1    E4 mit Fortsetzung von P3
E2 mit P2    E5 mit P4
E3 mit P3    E6 mit P5

ABER die Produktreihenfolge ist

P1
P3
P2
P4
P5
P6

P3 und P2 sind also vertauscht.

Zur Ermittlung der Reihenfolge werden die XY-Koordinaten der Cometgruppen der Produkte verwendet. Fälschlicherweise wurde dabei aber die gesamte Cometgruppe verwendet - es dürfen aber die einzelnen Teile (getrennt in Hauptgruppe und einzelne Fortsetzungen) verwendet werden - dann geht alles.

Der Fehler ist damit gefixt.

Produkte, die in normalen 1:1-Seitenelementen werden horizontal falsch platziert, wenn sie zentriert oder rechts ausgerichtet werden sollen. Links stimmt. Auch die vertikale Position stimmt.

Der Fehler ist gefixt.

Hallo,

mir ist da ein Fehler aufgefallen, der sich generell reproduzieren lässt (Version Windows 7): beim Drag & Drop aus der Produktrecherche mit gedrückter Strg-Taste in ein Seitentemplate wird dann nichts aufgebaut, wenn es eine ausgeblendete Ebene gibt (auch wenn diese nicht selektiert ist). Sobald man die Ebene einblendet, klappt alles normal.

Der Fehler ist gefixt.

Beim zweispaltigen Aufbau der Produkte in Kombination mit dem vertikalen Keil ist die Reihenfolge der Produkte in der Produktliste eine andere als in der Palette "Produkte des Dokumentes".

Für die Reihenfolge von Produkten in 1:N-Elemente werden deren XY-Koordinaten verwendet.

Bei spaltenweiser Sortierung gehören alle Produkte mit gleicher X-Koordinate zur gleichen Spalte. Leider ist die interne Maschinendarstellung etwas anders als das, was man nach "aussen" sieht : Zwei Rahmen, die nach aussen die gleiche X-Position (z.B. 294,803 Pt) haben, können intern die Positionen 294,803000001 Pt und 294,803000002 haben. Dadurch entstehen die beschriebenen Fehler.

Ich verwende daher für den Koordinatenvergleich jetzt nicht mehr die Werte selbst sondern deren Abstände. Ist der Abstand kleiner als 1 Pt sind die Werte gleich :

    ALT   if (x1 == x2)
    NEU   if (abs (x1-x2) < 1.0)

Damit ist das Problem gelöst.

Der vertikale Keil hat mit diesem Problem nichts zu tun. Er ändert die X-Koordinaten der Produkte nicht.

Hotfix

26.09.2012

Ich habe ein Seitenelement mit der Eigenschaft "Produkt darf im nächsten Element fortgesetzt werden". Wird dort ein Produkt platziert, das diese Eigenschaft brauchen könnte, funktioniert der Aufbau zwar, aber es wird mind. ein Seitenelement übersprungen. Für mich sieht das so aus, als würden die genau die Seitenelemente übersprungen, über denen die Rahmen lagen, die dann auf weitere Elemente verteilt werden sollten.

Das Problem ist gefixt.

Könnte man das Löschen in der Palette "Einstellugen" irgendwie erschweren? Ich würde das gerne nutzen, damit z.B. der Kunde selbst Bildpfade anpassen kann. Dabei habe ich (berechtigte) Angst, dass er sich die Konfiguration zerstört, in dem er aus Versehen auf das rote x klickt. Dann ist die Variable nämlich direkt unwiederbringlich verloren. Ohne Netz und doppelten Boden.

Es wäre cool, wenn man die Löschfunktion mit irgendeiner Tastenkombi (Strg-Alt o.ä.) schützen könnte, damit man sich da nicht direkt ins Unglück stürzen kann?

Zum Löschen der Einträge (Button UND Menü) muss jetzt die ALT-Taste gedrückt sein.

In der Palette Platzhalter kann man ja ziemlich viele Werte der Platzhalter sehen. Mit dem Befeh placeholder::change_tags kann man aber noch mehr setzen. Könnte man diese Werte auch in der Palette anzeigen?

Damit die Palette nicht unendlich groß wird, befindet sich jetzt ganz unten ein Editfeld mit der Beschriftung "Attribut". Dort kann man einen gültigen Slotnamen eintragen. Der jeweilge Wert des Platzhalters wird dann hinter diesem Feld angezeigt.

Wenn ein Fortsetzungstemplate angewendet wird, dann wird das nachfolgende Produkt immer auf einer neuen Seite platziert, obwohl das noch locker auf die vorherige Seite passen würde. D.h. auf der Seite mit dem Fortsetzungstemplate wird nichts mehr platziert.

Bei 3.3 R3000 gibt es diesen unnötigen Seitenumbruch nicht, hat sich da evtl. ein Fehler eingeschlichen?

Nachdem ich mir das jetzt genauer angesehen habe : Nein, es hat sich kein Fehler eingeschlichen. Du hast einen Fehler ausgenutzt, der inzwischen behoben ist (Bug 2952). Hier ist die Gestaltungsregel, die den Fehler ausnutzt:

gParam2 enthält die Kennung eines Rahmens der Hauptgruppe, gParam3 die Kennung eines Rahmen der Fortsetzung. Der Rahmen der Hauptgruppe wird in die Fortsetzung verschoben.

int main ()
{
	ItemRef		lastImage	= item::alloc ();
	ItemRef		leanOn	= item::alloc ();
	float		l, t, r, b;
	int			pageNum;
	
	frame::get_cometgroup_member (gFrame, gParam2, lastImage);
	frame::get_cometgroup_member (gFrame, gParam3, leanOn);
	
		if (!frame::is_valid (lastImage))	return 0;
		if (!frame::is_valid (leanOn))	return 0;
		
	frame::bbox (leanOn, &l, &t, &r, &b);
	pageNum		= page::get (leanOn);
	
	frame::moveto (lastImage, l, t, pageNum);
	return 0;
}

Ein Rahmen der Hautgruppe wird, zumindest von seiner Position her, von der Hauptgruppe in eine Fortsetzung verschoben. Es gibt nichts, woran der Aufbau das erkennen könnte (nicht mal die Seitennummer. Die Elemente könnten ja genauso gut auf der gleichen Seiten liegen.) Und prompt kommt der Aufbau auch durcheinander.

Ich habe eine ganze Weile darüber nachgedacht, ob ich was an dem Problem mache. Ich bin ziemlich sicher, dass das Ganze ein absoluter Einzelfall ist. Ich hab trotzdem was gemacht (s.u.).

Zur Lösung kann man zwei Dinge tun:

1. Im Fortsetzungstemplate an die Stelle, an die der Bildrahmen verschoben wird, einen durchsichtigen Rahmen der gleichen Grösse anlegen (gewissermaßen als "Platz"halter im Wortsinne). Damit kann das Dokument zwar nicht mehr aufgeräumt werden (weil der Bildrahmen ja weiterhin zum Haupttemplate gehört, das dadurch ziemlich groß wird), aber es wird immerhin richtig aufgebaut.
   
   
2. Hinter das frame::moveto diese Zeile einfügen :
   
       placeholder::change_tags (lastImage, 0, "Continue", -1);
   
   und auf das nächste Release (v3.3 R3175) warten. Da geht es dann richtig. ABER : Da kann zwar aufgeräumt werden, aber weil der Bildrahmen jetzt zur Fortsetzung gehört, wird er beim Aufräumen gelöscht - auch nicht so toll.

Eine richtige Lösung bekommt man mit dem Buildsupport-Skript hin : Nach dem Aufbau erzeugst Du deine Bildrahmen und platzierst Sie richtig. Vor dem (nächsten) Aufräumen löschst Du diese Rahmen alle. DamitDu die Rahmen wiedererkannt werden können, könnten sie mit einer einheitlichen Kennung versehen werden.

Ich habe in einem Seitentemplate ein Seitenelement für den Textaufbau eingefügt. Wenn ich in dieses Element Text importiere, erhalte ich immer einen Rahmen mit einem blau getönten Hintergrund.

Beim Textaufbau wird der Rahmen, in den importiert werden soll, direkt aus dem Seitentemplate geholt. So kann man den Textrahmen auch gestalten. Standardmässig werden neue Rahmen in Seitentemplate-Dokumente mit diesem blauen Hintergrund erzeugt. Das ist jetzt nicht mehr so.

Ich habe einen Rahmen mit der Gestaltungsregel "fitframe" nach Laden. In dem Rahmen ist ein Textplatzhalter. Nach dem Aufbau ist der Platzhalter geladen und der Rahmen hat die richtige Grösse.

Jetzt wird der Platzhalter-Inhalt im Datenbestand geändert. Nach Überprüfung mit der Aufgabenpalette erscheint der Platzhalter dann als "Zu aktualisieren" in der Liste. Wenn ich jetzt aktualisiere, wird der Platzhalter mit dem neuen Text geladen. Alles gut bis hierher. ABER : Die Gestaltungsregel wird NICHT ausgeführt. Der Rahme hat jetzt eine falsche Grösse.

Das ist völlig klar : Bei der Aktion wird der TEXT-Platzhalter neu geladen, nicht der Rahmenplatzhalter, den es ja gar nicht gibt. Aber die Regel wird nur beim Laden des RAHMENS ausgeführt - was wir ja hier gar nicht machen.

Trotzdem wäre es natürlich schön, wenn die Gestaltungregeln irgendwann gefeuert werden würden. Und das werden sie jetzt auch : nach dem Aktualisieren der Platzhalter einmal pro beteiligten Rahmen. Ist der Platzhalter Teil eines Textes, der über mehrere Rahmen läuft, werden die Gestaltungsregeln ALLER Rahmen der Textkette ausgeführt.

Hotfix

20.09.2012

Ich habe ein Seitentemplate mit einem Element. Dieses Element ist für Textfluß eingestellt. Das Produkt-Template enthält genau einen Textrahmen.

Baut man dann mehrere Produkte auf, wird zwar ein Textfluss erzeugt mit allen Rahmenverlinkungen und so - aber leider ist zwischen jeder Seite eine Leerseite.

Der Übersatz, den ein einzelnes Produkt erzeugt, erzeugt keine zusätzlichen Seiten. Nur bei Produktwechseln wird eine Zwischenseite angelegt.

Und auch das stimmt nur bedingt : Das passiert nur dann, wenn das Seitentemplate nur ein Element hat. Hat es mehrere, wird jeweils EIN Element übersprungen. Aber das ist ja auch nicht schön.

Der Fehler ist gefixt.

Ich habe ein aufgebautes Dokument, das reorganisiert werden soll. Dabei entsteht hinter dem ersten Produkt immer ein Seitenumruch. Auffällig ist, dass in der Palette "Prod. des Dok." hinter dem ersten Produkt ein Seitentemplate-Eintrag gezeigt wird - der ja tatsächklich dann den Seitenumbruch macht. Aber woher kommt dieser Seitentemplate-Eintrag in der Liste. Entferne ich ihn manuell, wird richtig und ohne zusätzlichen Seitenumbruch aufgeräumt. Das wäre soweit als Workaround okay. Ich muss das aber leider bei JEDER Reorganisation machen.

Der Fehler ist gefixt.

Templates (früher hießen die Pageitems) können ja vor dem Einsetzen das sog. PageitemID-Script ausführen, die unter XML im Element pageitems.pageitem.scriptid verwaltet wird.

Ich habe das Element in allen pageitem-Elementen angelegt und kann die SkriptId jetzt im Dialog zu den Pageitems (Templates) auch setzen. Wenn ich den Dialog erneut öffne, ist die Einstellung aber weg. Und beim Einsetzen des Templaets wird (nun erwartungsgemäß) das Skript auch nicht ausgeführt.

Alles ist richtig. Nur die Doku ist falsch. Hier fehl ein Wort. Das Element scriptid muss unter dem Element spread liegen. Also so :

    pageitems.pageitem.spread.scriptid

Hotfix

13.09.2012

Ist der Hauptrahmen einer Cometgruppe innerhalb einer InDesignGruppe, kann InDesign® abstürzen, wenn die Mitglieder der Cometgruppe ermittelt werden sollen.

Der Fehler ist gefixt.

Wenn man Notizen jetzt woeder auf ihre ursprüngliche Ebene zurücklegen kann, könnte man das dann vielleicht auch über den Namen machen. Das wäre von Vorteil, wen die Notizen in en anderes Dokument mit gleichen Ebenen-Namen importiert werden.

Das geht jetzt auch. ID und Name der Ebene werden pro Notiz hinterlegt. Wird eine Notiz wieder sichtbar gemacht, wird die Ebene zuerst über die ID gesucht. Wird diese Ebene nicht gefunden, wird über den Namen gesucht.

Nach dem Einblenden werden Notizen immer auf der obersten Ebene gezeigt - egal, auf welcher Ebene sie vor dem Ausblenden waren.

Notizen werden jetzt wieder auf ihrer ursprünglichen Ebene platziert. Die Ebenen können umbenannt werden, während Notizen ausgeblendet sind. Wird die Ursprungsebene gelöscht, während die Notiz unsichtbar ist, wird die Ebene auf der obersten Ebene platziert.

... und zusätzlich muss der Rahmen, der gelöscht werden soll, einen Platzhalter haben und mit einem Produkt verknüpft sein. Aber dabb stürzt InDesign® reproduzierbar ab, wenn man den Rahmen löschen will.

Huch. Stimmt. Das ist gefixt.

Beim Aufbau mit geöffneter Previewpalette stürzt InDesign® ab. Wenn die Previews vorab geladen werden ("alle Assets des Dokuments") sind sie gecached, und nix stürzt ab. Wenn die Previewpalette geschlossen ist, oder der Haken bei "an Dokumentauswahl anpassen" ist weg, stürzt auch nix ab.

Der Fehler ist gefixt.

Dafür war leider die große Keule nötog : JEDES Skript deaktiviert jetzt temporär das Neuladen der Preview-Liste. Wenn ALLES Skripte wieder beendet sind, wird die Liste neugeladen. Das Gleiche machen Produktaufbau und -reorganisation.

Ich habe ein kleines Probleme mit table::fit_col(). Du hast, laut der news_3.3 mit R3144 die Methode um einen Parameter erweitert damit die Zeilenhöhe nicht verändert wird bei einem fit_col(). Doch genau dies passiert leider.

Der Fehler ist gefixt.

Ich habe einen Platzhalter, der in einer Tabellenzelle steht. Dieser Platzhalter soll eine Tabelle einfügen. Dabei stürzt InDesign® ab. Es ist dabei egal, ob die die Tabelle mit TaggedText einfüge oder mit Skriptbefehlen zusammenbaue.

Steht der gleiche Platzhalter nicht in einer Tabellenzelle, funktioniert alles.

Beim Einfügen von Text müssen zwei Dinge getan werden :

1. Platzhalter im eingefügten Text laden
2. In der Schleife zum Bearbeiten der Platzhalter müssen Textposition und -länge angepasst werden.

Für beide Punkte muss die Länge des eingefügten minus die Länge des dabei gelöschten Textes ermittelt werden. Dazu hab ich ich Textlänge als Basis genommen. Das funktioniert - solange keine Tabellen eingefügt werden. Dann ist der Fall anders :

"Alter Text" : Länge = 10
"T1\rZelle1\rZelle2\rZelle2\rZelle4 : Länge = Länge (T1) + 28 >= 30

wobei T₁ eine Referenz auf die Tabelle hat. Die Länge ist variabel (so etwa zwischen 2 und 10).

Nach dem Einfügen der Tabelle ist folg. passiert :

1. Der Platzhalter, der dieTabelle einsetzt, wird über den neuen Text (mind. 0-30) gezogen. Dadurch bekommt u.a. jede Zelle der neuen Tabelle den Platzhalter.
2. Der neue Text wird geladen. Wobei dann mind. 5 neue Tabelle entstehen.
3. Und das in alle Ewigkeit für jede der neu eingefügten Tabellen ...

Das ist gefixt. Die Länge des neuen Textes wird jetzt richtig berechnet. Der Fehler in dieser Form bestand übrigens seit dem Fix von Bug 1274 am 2. Sept. 2008, also fast exakt vieer Jahre

Beide Menüs

    Comet > Platzhalter in/aus Taggedtext schreiben/lesen

sind aktiviert. Wenn ich mich einmal ein- und wieder auslogge, sind beide Menüs deaktiviert.

Workaround

Das Problem ist sehr einfach zu umgehen. Einfach im AfterLogin-Skript (Panelstatement 92) die folg. Zeilen einfügen :

    prefs::set_tags_readable (1);
    prefs::set_tags_writeable (1);

Lösung

Der Workaround funktioniert natürlich nicht, wenn Benutzer die Einstellung ändern. Die Einstellungen werden jetzt automatisch nach dem Logout zurückgesetzt.

Hotfix

09.09.2012

Ich habe zwei Platzhalter. Der erste zeigt einen Artikelnamen, der zweite eine Aufzählungsliste mit Eigenschaften. Diese Liste kann leer sein. Die Eigenschaften haben einen anderen Absatzstil als der Titel.

Im Template sieht das so aus

[Titel] [Eigenschaften]

Geladen so :

Produkt1
    • Eigenschaft1
    • Eigenschaft2
    • Eigenschaft3

Ich hätte gedacht, man kann jetzt in den Prefix so was reinschreiben wie !%TT<ParaStyle:Itemlist> und dann bekommt der neue Absatz mit den Eigenschaften den Stil "Itemlist". Bekommt er auch, aber der Titel auch.

Das geht mit den Prefixen bisher gar nicht. Der Text mit den Eigenschaften muss die Formatierung liefern :

%!TT<ParaStyle:><ParaStyle:Itemlist>Eigenschaft1<ParaStyle:Itemlist>Eigenschaft2...

Pre/Postfixe von Platzhaltern können jetzt (nach einem einleitenden #) Folgen von Anweisungen enthalten. Diese Anweisungen können verwendet werden :

1. Text für den Prefix
2. Absatz/Zeichenstil des Platzhaltertextes setzen
3. Skript für den Platzhalter ausführen (ClassID 50)

Damit kann man das gewünschte jetzt machen. Der Platzhalter für die Eigenschaften liefert das Ergebnis ohne Absatzstile einfach so hier :

%!TT<ParaStyle:>Eigenschaft1<ParaStyle:>Eigenschaft2

Im Prefix steht

# "/r" pStyle "Itemlist"

Damit ist alles gut. Mehr dazu hier.

Mit den Fixes von Bug 2986 und 3014 werden ja Tabellen, die aus Tabellenplatzhaltern entstanden sind, beim Neuverknüpfen mit einem anderen Produkt wieder richtig aufgebaut (was vorher gar nicht der Fall war, da wurden alle Platzhalter der Tabellenzellen mit dem neuen Produkt verknüpft - sehr strange).

Leider kann man das via cScript nicht nachstellen. Die Sequenz

    placeholder::link ...
    placeholder::load ...

erzeugt leider immer das alte Verhalten.

In der Tat. Das Problem kann jetzt durch zwei zusätzliche Parameter in placholder::link (und placeholder::link2) behoben werden : Dort kann man jetzt angeben, ob direkt nach dem Verknüpfen auch geladen werden soll. Macht man das so, ist alles gut - die Tabellen sind danach richtig. (Der zweite Parameter ist "applyRules" für das Laden.)

Ich habe einen Textrahmen, der nicht sehr hoch ist. Dieser Rahmen kann mglw. einen recht langen Text bekommen und soll sich dann an den Text anpassen. Meist klappt das. Wird der Text aber sehr lang, wird der Rahmen nicht groß genug.

Der Fehler ist mit Fix des Bugs 2961 in R3100 entstanden. Hintergrund war, dass Rahmen einen Text enthalten können, der niemals passt (schmaler Rahmen mit einem langen Wort, das nicht getrennt werden kann/darf). Dann muss man irgendwann aufgeben, den Overset zu beseitigen, in dem der Rahmen grösser gemacht wird. Das hatte ich bei 800 Punkten gemacht. (Aus Performance-Gründen soll der Rahmen auch nicht zu groß werden.) Ich habe den Stopp jetzt bei 2000 Punkten gemacht - das entspricht genau der Höhe der Arbeitsbereiche von zwei Spreads für Standard-Seiten (A4). Ich denke, das ist groß genug.

Sind Rahmen in InDesign®-Gruppen zusammengefasst, werden nicht alle Gestaltungsregeln der Rahmen ausgeführt. Die Regeln "Nach Laden" (<=) werden ausgeführt, alle anderen nicht.

Die Regeln werden jetzt auch für alle Rahmen in InDesign®-Gruppen ausgeführt.Regeln werden auch für die Gruppenrahmen selbst ausgeführt mit der Ausnahme : Die Regeln "Nach Laden" werden NICHT für Gruppenrahmen ausgeführt (dort gibts eh nichts zu Laden).

Ebenso werden jetzt auch alle Regeln von Rahmen in Multistates und Pushbuttons ausgeführt.

... die Tabellenzellen sind mit falschen IDs verknüpft.

Ausserdem fällt auf, dass im Logfile sehr viele Nachrichten der Art

# TABLE : Building table with UID ...

stehen. Das Template enthält aber nur eine Tabelle, die aufgebaut werden muss. Und entsprechend langsam ist das Ganze dann auch noch.

Bei Neuverlinken von Tabellen werden ab diesem Release aufgebaute Tabellen zurückgesetzt und danach neu aufgebaut (Bug 2986). Dabei ist ein kleiner aber wirksamer Fehler unterlaufen. Das ist jetzt gefixt.

Der Aufbau der Templates sollte jetzt wieder richtig funktionieren.

RELEASES R3121 - R3143 SOLLTEN NICHT VERWENDET WERDEN!

Habe gerade das Problem, dass ich nach dem Aufbau eines Produktes etwas machen muss und das hängt von der Vorlage des aktuellen und des nächsten Produkts ab. Daher wäre es Praktisch, wenn ich im Skript auf weitere Variablen zugreifen könnte:

1. Die Liste der aufzubauenden Produkte
2. Den Index (laufende Nummer) des aktuellen Produkts in der vorherigen Liste
3. Die IDs des aktuellen Produkts

Was schon geht, auch wenn es in der Doku nicht erwähnt ist, ist der der Zugriff auf gRecordStringID. Ist das so gewollt oder eher Zufall?

In diesen Skripten gibt es jetzt die folg. Variablen :

gProducts, gProduct, gProductCounter

Achtung :

• gProducts und dessen Inhalte dürfen nicht geändert oder gelöscht werden.
• gProduct darf geändert oder gelöscht werden.
• gProducts kann Seitentemplate-Einträge enthalten. Die Elemente sollten also mit product::get (..., kProductType) geprüft werden.
• gProducts kann "toDelete"-Einträge enthalten. Die Elemente sollten also mit product::get (..., kProductDoDelete) geprüft werden. kProductDoDelete ist neu in diesem Release.
• gProductCounter ist NICHT der Index von gProduct in gProducts. Es ist der 1-basierte Zähler, welches Produkt gerade aufgebaut wird. Den Index kann man mit productlist::get_pos (gProducts, gProduct) erhalten.

Bemerkung

gRecordStringID enthält die StringID des aktuellen Produktes. gRecordID, ~2 und ~3 enthalten die anderen Teile der ID des aktuellen Produktes. Das ist natürlich mit Absicht so. Punkt 3 von oben war also schon erfüllt.

ich hab das problem das keine Tabellen scripte nach einem Login gefeuert werden. Sobald man sich ein 2tes mal einloggt ist alles wieder i.o. Verwendet wird CS 5 R3100 und Mac 10.7/10.6

ich möchte den Fix dieses Bugs befördern,da ich diesen Bug bei drei Kunden habe. Es werden keine Spalten bzw. Zeilen Duplizierungsskripte ausgeführt. Das Logfile ist nicht aussagekräftig, da einfach das Logging der Spalten und Zeilenskripte fehlt und das Laden der Tabelle zeigt, dass sie leer ist.

Ein erneutes Einloggen bzw. mit Entwicklerlizenz ein aktives Leeren des Skriptcaches haben das Problem beseitigt, ein Zweimal-Einloggen-Workaround beim Kunden aber nicht verstanden werden wird.

Der Bug ist bei allen Releases nach R3000 vorhanden und auch noch in R3132.

(Comment 5) Ich habe weiterhin festgestellt, dass beim ersten Login das Suchen in der Template Palette nicht funktioniert (Sartorius) und im Logfile aber nichts passiert, wenn man auf die Lupe klickt.

Ich bin ziemlich sicher, dass du bei Comment 5 eine Comet-Revision < 3115 verwendet hast. Genau dieses Problem wurde nämlich in dieser Revision gelöst (Bug 2956). Kannst Du das bitte noch mal mit einem aktuellen Release prüfen?

Und was den Hinweis mit dem Logfile betrifft - wenn es sich um einen Plugin-Fehler handelt, wird dort auch nichts dazu stehen, oder? Ich kann ja nicht ins Logfile schreiben

    # Achtung, noch unbekannter Fehler in den Plugins ...

Der erste Fehler (das mit den Actions der ClassID 24 zum Aufbau der Zeilen und Spalten von Tabellen) stimmt leider und ist jetzt gefixt.

FYI

Der Fehler ist durch den Fix von Bug 2885 ("Shortcuts von Palettenskripten funktionieren nicht immer") in R3024 entstanden. Wie man schon aus dem Bug-Namen sieht - ein ganz anderes Thema. Ein unerwarteter Seiteneffekt hat dabei den komplizierten Prozess durcheinander gebracht, der sicherstellt, dass nach einem Login (der über das Plugin CoreService gemacht wird), alle anderen Plugins informiert werden und dort die nötigen Aktionen (wie z.B. eben das Laden der o.g. Actions) auslöst.

Wenn ich das folgende - sehr kurze - Skript ausführe, dann stürzt am Ende InDesign® immer ab. Unter MacOS tritt der Absturz nicht auf.

int main()
{
	IDTypeList entries = idtypelist::alloc(0);
	
	return 0;
}

Der Fehler ist gefixt.

Ich habe ein Template mit einem Textrahmen, dessen Grösse über die Gestaltungsregel "Rahmen anpassen" an den Textinhalt angepasst werden soll. Das funktioniert manchmal, manchmal aber nicht. Auffallend ist, dass der Textrahmen die Gestaltungsregel zwar ausführt (das sieht man im Logfile und ausserdem ist seine Höhe im Dokument anders als im Template), aber die Höhe ist nicht richtig. Wie kann das sein?

Wenn sich im Template Rahmen mit Konturführung befinden, passiert folgendes :

1. Der Produktaufbau platziert das Produkt an der Position (0, 0) der Seite. Irgendwo muss er es ja hin tun. Die Endposition können wir ja erst ermitteln, wenn das Produkt aufgebaut ist. Also ist (0, 0) eine gute Wahl - da fällt auch nichts von der Seite oder gar vom Arbeitsbereich.
2. Am Seitenanfang befindet sich aber ein bereits platziertes Produkt. Und der Rahmen mit der Konturführung verdrängt da den Text des neuen Produktes. und genau für diese Situation wird der Rahmen angepasst.
3. Das Produkt ist jetzt fertig aufgebaut und wird an die jetzt ermittelte Zielposition verschoben.
4. An der Zielposition ist KEIN Rahmen mit Konturführung. Dadurch braucht der Text natürlich weniger Platz im Rahmen. Und das ist das, was man dann sieht.

Doofe Situation das.

Ganz unten in der Trickkiste war noch was. Das Problem ist gefixt.

Es ist ein absoluter Sonderfall, der zu einem - eigentlich vorhersehbaren - Absturz führt : Eine InDesign®-Gruppe enthält einen Rahmen mit der Gestaltungsregel "Rahmen anpassen". Die Gruppe wird jetzt so verschoben, dass nur noch ein Teil ded obersten Rahmen im Arbeitsbereich liegt und der Rahmen mit der Gestaltungsregel ganz vom Arbeitsbereich fällt.

Führt man jetzt die Gestaltungsregel aus, stürzt InDesign® ab, oder besser gesagt - es warnt vor einem schwerwiegenden Fehler und hört dann auf.

Irgendwie ist klar, was passiert und dass das eigentlich nicht geht. Leider gibt es Kunden/Anwender, die Produktgruppen genau auf die oben beschriebene Art verschieben und dann die Platzhalter aktualisieren lassen. Und wenn die Gestaltungsregel dann nach dem Laden ausgeführt wird - peng.

Ja, irgendwie schon hart. Ist irgendwie so wie mit 180 bei Glatteis durch den Nebel und sich wundern, wenn man auf ein anderes Auto auffährt.

Wir verbreitern dafür kurzzeitig die Autobahn, so dass Problem nicht mehr auftritt.

ACHTUNG: DAS VERHALTEN WURDE NUR FÜR GESTALTUNGSREGELN ANGEPASST. ES IST RECHENINTENSIV.

Abgrenzung : Das gleiche Problem kann auch in beliebigen anderen Skripten auftreten (z.B. Laden-Skripte von Rahmen, die frame::fit, frame::duplicate, frame::move, ... ausführen). In diesen Fällen treten die InDesign®-Fehler nach wie vor auf. Aus Performance-Gründen werden wir für diese Fälle keine zusätzliche Behandlung implementieren.

Und noch ein weiteres ACHTUNG : Das ganze geht erst ab CS4. Für CS3 gibt es für dieses Problem keine Lösung!

Hotfix

29.08.2012

svn 3140

Gibt es das?

Jetzt ja :

    frame::get_corner
    frame::set_corner

Mit list::alloc kann man sich ja die (ausgewählten/markierten) Objekte der Comet-Paletten holen. Das klappt aber nur, wenn die jeweilige Palette auch sichtbar ist. Ansonsten ist die Ergebnisliste leer.

Beim Schliessen von Paletten entfernt InDesign® alle Listeneinträge der Listen der Palette. Deshalb ist das so. Wenn die Liste beim erneuten öffnen wieder den alten Inhalt zeigt,dann nur deshalb, weil wir sie sofort wieder mit den alten Daten füllen. Ein recht aufwendiger Prozess.

Da wir die Daten aber schon mal haben, können wir sie auch für list::alloc verwenden und hier Ergebnisse liefern, auch wenn die Palette unsichtbar ist.

ACHTUNG : Das geht natürlich nur für die Auswahltypen kAll und kEeyMarked. kSelected liefert weiterhin eine leere Liste - eine Auswahl haben unsichtbare Listen nach wie vor nicht!

Ich habe ein großes Dokument mit vielen Platzhaltern, die die SyncID -1 haben. Aufbau und Aktualisierung funktionieren fehlerlos. Aber beim Überprüfen des Dokumentes stürzt InDesign® immer und an verschiedenen Stellen ab. Die Laden-Skripte enthalten alle das für SyncID -1 nötige gNewValue und verlassen die Skripte vor Dokumentänderungen.

Ja, in dieser Situation sind große Speicherlöcher entstanden. Pro überprüftem Platzhalter gingen jeweils 2 MB Speicher verloren. Das geht natürlich nicht lange gut und der Speicher ist bald voll.

Der Fehler ist gefixt.

Die Edit-Felder zum schrittweisen Adaptieren des Frontdokumentes erlauben nur positive Schrittweiten.

Jetzt können auch negative Werte eingetragen werden.

Mit dem ersten Button der Palette priint.adjust kann man ja viele Adaptionen auf einmal machen. Die Adaptionen müssen dazu in einer XML-Datei beschrieben werden. In dieser Datei kann auch im Feld <basename> etwas eingetragen werden. Das Feld wird aber offenbar nicht genutzt - die Zieldateien haben jedenfalls keinen gemeinsamen Namensanfang -wie man vielleicht erwartet hätte.

Wir wollen ja keine Erwartungen enttäuschen. Ein gemeinsamer Namensanfang wäre zwar auch recht einfach in der XML-Datei selbst zu machen. Aber gut. Die Angabe in <basename> wird jetzt verwendet wie oben beschrieben.

Mit dem ersten Button der Palette priint.adjust kann man ja viele Adaptionen auf einmal machen. Die Adaptionen müssen dazu in einer XML-Datei beschrieben werden. Der hier angegebene Zielname wird automatisch mit der Endung ".indd" versehen. Das wird aber auch dann gemacht, wenn der Name in der XML-Datei diese Endung bereits hat.

Ist gefixt. Endet der gewünschte Name in der XML-Datei bereits auf '.indd' wird die Endung nicht mehr angefügt.

Mit dem ersten Button der Palette priint.adjust kann man ja viele Adaptionen auf einmal machen. Die Adaptionen müssen dazu in einer XML-Datei beschrieben werden. Das fängt auch gut an. Dann erscheint ein Progress-Balken und InDesign® hängt sich auf.

Stimmt in diesem Fall wirklich : Für den Fix von Bug 2631 wird hier gewartet, weil noch ein Dialog offen ist (der Progessbalken). Da kann er lange warten.

Der Fehler ist gefixt. In diesem Fall wird nicht mehr auf den Dialog gewartet.

Man kann die adjust-Regeln ja für Deutsch und Englisch lokalisieren. Für Französisch geht das leider nicht - obwohl wir eine französischen Variante der adjust Plugins haben.

Das sollte jetzt gehen. ("Sollte" meint : Ich kann es leider nicht testen, weil ich kein französisches InDesign® habe. Vor einem Einsatz bei Kunden muss das daher unbedingt mit einem französischen InDesign® überprüft werden! Mehr dazu hier.

Wenn ich das als Parameter eine Gestaltungsregel verwende, dann erhalte ich zwar eine Combobox, allerdings nur mit den Einträgen "Leer" und "@LOADLIST formlabels".

Wenn ich testweise, das "formlabels" durch "cellstyles" ersetze (um einen Syntaxfehler auszuschließen), dann wird die Auswahlbox richtig angezeigt.

Der Begriff heisst framelabels (nicht formlabels). Das hatte ich in der Doku falsch geschrieben (die offenbar doch jemand liest).

Könnte man nicht irgendeine Erweiterung der actions.xml machen, damit dort auch eine Doku für Parameter gemacht werden kann?

Die Parameter einer Adjust-Funktion können jetzt jeweils eine eigene Doku bekommen. Die Dokus werden im Feld inputdocumentation durch ## gertennt hinter der Funktionsbeschreibung angegeben und als gelbe Tooltips über den Parameternamen gezeigt.

Unused##0##Doku##Para1-Doku##Para2-Doku##Para3-Doku##Para4-Doku

Wie alle anderen Text(teile) für die Beschreibung von Adapter-Regeln werden auch die Parameter-Beschreibungen übersetzt (wenn verfügbar). Mehr dazu hier.

Man braucht schon eine sehr ruhige Hand, um einen Nagel oder einen Magneten zu setzen. Die Zielflächen dafür sind extrem klein. Kann man das nicht ein bisschen großzügiger gestalten?

Wir hatten die Flächen so stark verkleinert, damit auch an kleinen Rahmen die richtigen Punkte getroffen werden können.

Die aktiven Flächen für Nägel und Magnete sind jetzt deutlich grösser und werden nur bei Bedarf (also bei kleinen Rahmen) entsprechend verkleinert.

... oder jedenfalls anders als vorher. Ich hänge Dir mal zwei Dokumente an, in denen das gleiche Produkt mit dem gleichen Template aufgebaut wurde. So wie in Rev 2730 sollte es sein, so wie in Rev 3000 (und später) nicht. ...

Das Problem waren Rahmen, die mit document::place_items eingefügt wurden. In diesem Fall wurden die Gestaltungsregeln "Nach Laden" nicht mehr ausgeführt. Das ist gefixt.

Der Fehler ist als Seiteneffekt des Fixes von Bug 2791 aufgetreten (auch wenn diese Dinge auf den ersten Blick nichts miteinander zu tun haben.)

Wir wollen den RTF File importieren. Hier das Skript :

int main ()
{
	int			fi 		= file::open ("/Users/paul/Desktop/CLOB Kopie.txt", "r");
	char	*  	str 	= alloc (1000000);
	char		buf[512];
	int			len;

	*str = 0;
	while ((len = file::read (fi, buf, 511)) > 0)
	{
		buf[len] = 0;
		strcat (str, buf);
	}
	file::close (fi);

	textmodel::insert (str, 0, -1);
	release (str);
	
	return 0;
}

Bei den meisten Standardmethoden zur Tabellengestaltung ist in dem Popup zum Bereich nur der Eintrag "Spalte (ab)" (bzw. "Zeile (ab)") aktiv. Warum denn?

Ich hab das ein bisschen aufgelockert. Es sind jetzt einige Zielbereiche mehr aktiviert. Ausserdem wird bei der Auswahl einer Methode die Auswahl des Popup-Menüs mit den Zielen nicht mehr automatisch geändert.

Mit der Tabellen-Gestaltungsmethode "Übersatz vermeiden" können Spalten so verbreitert werden, dass keine Zelle mehr einen Übersatz hat. Kann man Spalten auch verkleinern?

"Übersatz vermeiden" heisst jetzt "Spaltenbreite anpassen" und kann mit der Büroklammer konfiguriert werden. Dort kann man auch einstellen, dass die Spalte kleiner wird.

Über der Liste "Gestaltung -> Methoden" befindet sich ein Button mit einer kleinen Büroklammer. Was macht das denn, es ist nie aktiv?

Mit dem Button kann ein Fenster geöffnet werden, in dem Parameter für die jeweils ausgewählte Methode eingestellt werden können. Es war natürlich ein Fehler, dass es nie aktiviert wurde. es ist jetzt bei Auswahl einer Standardmethode aktiviert.

Für folg. Standard-Methoden gibt es zusätzliche Parameter :

• Gleiche Zellen verbinden
• Spaltenbreite anpassen

Die anderen Methoden zeigen bei Klick auf die Büroklammer eine Meldung, dass keine weiteren Einstellungen verfügbar sind (und wenn sich alle dran gewöhnt haben, dass das Button ja doch aktiv werden kann, wird es in diesen Fällen wieder deaktiviert.)

... versteh ich ja - aber kann man nicht irgend etwas machen?

Doch, man kann. Die Funktion geht jetzt auch für Tabellen im Übersatz. Der Rahmen macht dafür zuerst ein fitframe (das am Ende wieder rückgängig gemacht wird).

Im Anhang 1 zu Bug 2988 befindet sich ein Comet-Gruppen-XML, welches unserer Ansicht nach nicht korrekt ist. Es beinhaltet 4 Elemente, 3 davon auf der linken, eines auf der rechten Seite eines Dokuments. Die Werte für size-relative der einzelnen Elemente lauten

    1.00%
    5.14%
    2.34%
    2.34%

Der Wert des Group-Knotens für size-relative lautet

    2.34%

Was ja rein von der Logik eigentlich nicht sein kann. Auch die anderen Größen sind anscheinend falsch berechnet. Das XML wurde über

app.comet.getCometGroups(
	"[FILEPATH]",
	Scope.COMETGROUP,
	Number([ID]),
	[TEMPFILEPATH],
	app.comet.ping() + ';-1; calc-sizes:true; size-checkmargins:true; size-useclips:false;');

abgefragt.

Die Gesamtfläche der Cometgruppe sollte natürlich jeweils die Summe der Angaben aus den Rahmen sein, also 10.82% und 88266324188 pt2 (und nicht nur die Rahmen der zweiten Seite des Spreads). Das ist gefixt (v3.3 R3121).

Die anderen Angaben sind richtig :

Scope.COMETGROUP bedeutet, als Gesamtfläche wird der Spread ohne Margins verwendet. Z.B. sind die 8161,993775 pt2 für den Rahmen 56106 genau 1,000214948091523% davon - und das steht ja auch so in der XML.

Die Funktion table::fit_col kann Tabellenspalten ja auch schmaler machen. Weil in den Zellen dann meist neu umbrochen werden kann, werden in diesem Fall meist die Tabellenzeilen höher. Kann man das unterbinden?

Die Funktion hat jetzt einen neuen Parameter (keepLineHeight) mit dem das gesteuert werden kann. Ist keepLineHeight = 1, werden Zeilenhöhen nicht verändert.

Vorher

Mit veränderlichen Zeilenhöhen

Mit festen Zeilenhöhen

Schritt 1

Ein Template mit einem Tabellenplatzhalter wird im Dokument platziert :

Schritt 2

Der Rahmen wird einem Produkt verknüpft (Shift-Klick in  des Produktes). Der Platzhalter wird durch seine Tabelle ersetzt und ordentlich aufgebaut :

Schritt 3

Jetzt wird der gleiche Rahmen mit einem anderen Produkt verlinkt. Dann sieht das so aus (und wahrscheinlich keiner ist überrascht)

Schritt 4

Jetzt wird der gleiche Rahmen wieder mit dem ursprünglichen Produkt verknüpft. Nein - dadurch entsteht nicht wieder die Tabelle aus Schritt 2. Die Tabelle sieht immer noch gleich aus.

Erläuterung

Was passiert da? Zunächst mal . Das ist kein Fehler im Showcase und kein Fehler in den Plugins - sondern eigentlich völlig richtig. Was dann.

Nehmen wir mal an, das erste Produkt hatte die ID (1,0,0). Damit wird die Tabelle aufgebaut. Die enthält irgendwelche Merkmale von (1,0,0). Die haben, sagen wir mal die IDs

    1,1,1		1,1,2		1,1,3		...
    1,2,1		1,2,2		1,2,3		...
    ...		...		...		...

Verknüpft man das jetzt mit dem Produkt (2,0,0) erhält man plötzlich das hier:

    2,0,0 2,0,0 2,0,0 ...
    2,0,0 2,0,0 2,0,0 ...
    ... ... ... ...

Das ist das dritte Bild. Verknüpft man wieder mit (1, 0, 0) erhält man

    1,0,0 1,0,0 1,0,0 ...
    1,0,0 1,0,0 1,0,0 ...
    ... ... ... ...

Genau das, was das Verknüpfen-Button machen soll - aber eben leider nicht mehr die Ursprungstabelle.

Lösung

Klar, das gefällt nicht. Deshalb ist das Verknüpfen-Button jetzt schlau geworden (und alle anderen Situationen in denen Textteile mit Tabellen aus Tabellenplatzhaltern enthalten sind ebenfalls. Jetzt sieht es (JUHU!) so aus : 

Ursprüngliche Tabelle

Mit einem anderen Produkt verknüpft

Und noch eins

Und wieder nach Hause

Der (nicht ganz einfache Trick) ist - die Tabellen werden automatisch neu aufgebaut.

Hotfix

15.08.2012

Im build-Skript eines Multiplatzhalters werden per frame::duplicate Rahmen angelegt. Leider gehören die aber nach dem Aufbau des Templates nicht zur Cometgruppe des Produktes. Oder jedenfalls nicht immer : Beim Produktaufbau klappt es, bei Drag and Drop nicht.

Wiederholende Elemente die via cScript angelegt wurden, wurden beim Einfügen des Templates nicht bemerkt. Das funktioniert jetzt.

Darf ich im Reorganisationsprozess eigentlich keine "wiederholenden Elemente" benutzen?

Folgendes Szenario:

Es gibt bei einigen Produkten nicht nur ein Produktbild, sondern noch weitere Varianten bzw. Detailbilder. Diese werden via wiederholenden Elemente über das das eigentliche Produktbild gestapelt.

Das ganze ist auch reorganisationsicher, wenn sich die Reorganisation auf eine Seite beschränkt. Sobald das Produkt mit den wiederh. Elementen auf die nächste Seite reorganisiert wird, funktioniert das nicht mehr.

Dann sind zwar noch alle Rahmen da, der Platzhalter wird aber nicht korrekt geladen bzw. alle Rahmen zeigen das gleiche Bild, nämlich von dem wiederh. Element, was zuletzt geladen wurde - auf dem Stapel ganz vorne liegt.

Ich bin mir jetzt nicht sicher, ob ich die "relativ alte" Funktion der wiederh. Elemente mit dem "relativ neuen" Reorganisieren mischen darf/kann.

Du hast recht. Aber es liegt an dir :-)

Wiederholender Rahmen und Elemente haben die gleiche Kennung. Wenn jetzt reorganisiert wird, holen sich die Rahmen die Inhalte vom Original mit passenden Kennung - und da wird halt immer das gleiche Original gefunden. Du musst also einfach die Kennung im Element entfernen.

Und ich überleg mir mal:

1. Ob bei Reorganisationen nicht auch die Einstellung "Bei Templatetausch laden" aus dem Templateverhalten berücksichtigt werden soll.
2. Ob wiederholte Rahmen überhaupt automatisch Inhalte übernehmen können sollen dürfen müssen.

zu 1/ Bei Reorganisationen sollen die Einstellungen zum Template-Tausch (vierte Spalte in den Optionen zum Template-Verhalten) natürlich berücksichtigt werden. Aber die Implementierung war ein bisschen falsch. Das ist jetzt gefixt. Wenn für den Rahmen also eingestellt ist, dass dessen Inhalt bei Reorganisationen neu geladen werden soll, dann wird er das auch (und Inhalte aus einem befreundeten Rahmen werden nicht übertragen).

zu 2/ Zusätzlich wird jetzt beim Übertragen der Inhalte befreundeter Rahmen geprüft, ob der Zielrahmen ein wiederholtes Element ist. In wiederholte Elemente werden ab jetzt keine Inhalte mehr übertragen - wiederholende Elemente werden sowieso neu geladen.

Ein Rahmen einer Seite hat soll vor der Adaption seinen Übersatz beseitigen und dann die Höhe der Seite so ändern, dass der untere Abstand des Rahmens zur Seite wieder gleich ist. Dazu wird also erst ein frame::fit ausgeführt. Danach wird in einer zweiten Regel die Seitenhöhe angepasst. Hier das Skript:

int main ()
{
	float 	   l, t, r, b;
	float 	   pl, pt, pr, pb;

	frame::bbox (gFrame, &l, &t, &r, &b);
	page::get_size (1, &pl, &pt, &pr, &pb);

	document::resize (
		pr-pl,
		  (pb - pt) 									// old height of page
		+ ((b -t) - (gOrgFrameBottom - gOrgFrameTop)) 	// + height difference of frame
		- (gPageHeightNew - gPageHeightOrg) 			// - height difference of adapter call
		);

	return 0;
}

behavior::change_action_data setzt falschen Zoomfaktor.

Es war richtig. Aber die Doku war falsch. Das ist jetzt korrigiert.

Kann man auch Hyperlinks mit URLS, Seiten, E-Mail, ... suchen? Bisher sind solche Hyperlinks nicht in den Ergebnislisten von hyperlink::find enthalten.

Diese Hyperlinks werden jetzt auch gefunden. Mit der Funktion

    link::crossref::type

kann der Zieltyp erfragt werden.

    link::crossref::info

enthält die nötigen Infos für URLs, Mails und Files.

Mit hyperlink::find können die Verweise eines Dokumentes ermittelt werden. Kann man auch nach Textankern suchen (insbesondere nach unbenutzten)?

Das geht jetzt. In hyperlink::find wird dazu der crossrefName "ANCHORS#" (in genau dieser Schreibweise) angegeben. Dann wird nach Ankern gesucht.

Kann man diese Infos auch irgendwie bekommen?

Mit den neuen Funktionen :

• link::crossref::src_frame
• link::crossref::src_textpos
• link::crossref::src_textlen

geht das jetzt.

Die Funktionen link::crossref::frame und link::crossref::pos geben irgendwie was falsches zurück. Acu crossref::left, lop, right, bottom, x und y sind falsch (leer).

Das ist gefixt.

Wird ein Textanker von mehreren Hyperlinks verwendet - was ja durchaus normal ist - findet hyperlink::find immer nur EINEN Hyperlink.

Das ist gefixt.

Obwohl ich den Namen des Links in hyperlink::find leer lasse (also nach beliebigen Namen suche), bleibt meine Ergebnisliste leer. Was mache ich denn falsch.

Der VERWEIS-Name wurde richtig ausgewertet. Aber der ANKER-Name nicht. Da wurde angenommen, dass er aus einer Comet-Objekt-ID gebildet sein muss. Was natürlich nicht sein muss.

Wird hyperlink::find jetzt mit classID 0 gerufen, wird diese Annahme für den Ankernamen nicht mehr gemacht. In diesem Fall wird der Wert der StringID direkt gegen den Ankernamen geprüft.

Sind also crossrefName UND sid des Aufrufes leer, werden ALLE Hyperlinks gefunden.

Ich kann ja mit hyperlink::find eine Liste aller Hyperlink eines Dokumentes erstellen lassen. Aus dieser Liste kann ich dann Quelle und Ziel des Verweises ermitteln. Kann man auch die UID des Verweiszeiles ermitteln. Hintergrund ist, dass Buttons definiert werden sollen, die ebenfalls an diesen Anker springen.

Also etwa so hier:

:
:

behavior::add_action (btn, 2, 1, action);
behavior::change_action_data (btn, action, "",???, 2);

Ja, eine entsprechende Funktion hat gefehlt. Es gibt jetzt zwei neue Funktionen, eine für die UID des Hyperlinkes, eine für die UID des Ankers :

• link::crossref::hyperlink_ref
• link::crossref::anchor_ref

Der obige Aufruf würde also so aussehen, vorausgesetzt lk ist ein gültiges Hyperlink-Objekt. Achten Sie auf das item::getint! Hier wird nur die Zahl benötigt, nicht die gesamte Referenz.

behavior::add_action (btn, 2, 1, action);
behavior::change_action_data (btn, action,
	"", 
	item::getint (link::crossref::anchor_ref (lk)),
	2);

Liegen Rahmen ganz im Arbeitsbereich, also auf keiner Seite, ist die Rahmenposition, die frame::bbox berechnet, falsch. Man würde erwarten, dass die Position zur nächstliegenden Seite bestimmt wird. Die Rahmengrösse word richtig berechnet.

Der Fehler ist gefixt.

Liegen Rahmen einer Liste ganz im Arbeitsbereich, also auf keiner Seite, werden bei itemlist::duplicate die neuen Rahmen manchmal falsch positioniert. Der Fehler tritt aber nicht immer auf.

Ja, der Fehler tritt nur dann auf, wenn der erste Rahmen der Liste ganz im Arbeitsbereich liegt.

Der Fehler ist gefixt.

Liegen Rahmen einer Liste ganz im Arbeitsbereich, ist itemlist::move_to mitunter fasch. Der Fehler tritt nicht immer auf, manchmal klappt es auch.

Ja, der Fehler tritt immer dann auf, wenn der erste Rahmen der Liste ganz im Arbeitsbereich, also auf keiner Seite liegt.

Der Fehler ist gefixt.

Rahmen, die vollständig im Arbeitsbereich liegen, also zu keiner Seite gehören, werden von frame::moveto falsch verschoben.

Der Fehler ist gefixt.

Template-ID-Skripte haben die globale Variable gPage. Die sollte eigentlich die Seitennummer der Seite einhalten, auf der das Template gerade platziert werden soll. Leider steht dort immer -1 drin.

Der Fehler ist gefixt.

Liegt ein Rahmen ganz im Arbeitsbereich, also ausserhalb jeder Seite, liefert page::get die Seitennummer -1. Das ist eigentlich okay. Kann man nicht, vielleicht mit einer extra Option, die am nächsten liegende Seite liefern?

Die Funktion hat jetzt den weiteren Parameter "queryNearest", mit dem das gesteuert werden kann. Default ist "off" (also nicht nach der nächstliegenden Seite suchen).

Liegt ein Rahmen ganz ausserhalb der Seite, also vollständig im Arbeitsbereich, stürzt InDesign® bei frame::duplicate ab.

Der Fehler ist gefixt.

Wir laden ein TIF-Bild per frame::image() in einen Rahmen und geben dabei nur die ersten beiden Parameter (Rahmen und Bildpfad) mit an. Das Bild müsste dann eigentlich in den Rahmen eingepasst werden, es wird allerdings unter Berücksichtigung des vorhandenen Pfades in Rahmen eingepasst.

Nur wenn wir beim Setzen des Bildes sagen, dass ein Pfad mit einem bestimmten Namen berücksichtigt werden soll und wir dann einen Pfadnamen angeben der nicht existiert, dann wird das Bild wie gewünscht in den Rahmen platziert.

Auch die Angabe der Parameter bis einschließlich kIgnoreClipping bringt keine Abhilfe.

Beispiele

So wird das Bild unter Berücksichtigung des Pfades skaliert:

frame::image(gFrame, picturePath, kMiddle, kFitBigContentProp, kIgnoreClipping);

So wird das Bild wie gewünscht skaliert:

frame::image (gFrame, picturePath, kMiddle, kFitBigContentProp, kClipPathByName, "huhu");

Der Befehl verwendet die Einstellungen der Importoptionen für Bilder. Mit den folg. Schritten kann man das Verhalten abschalten :

1. Cmd-D
2. "Importoptionen anzeigen" aktivieren
3. Bild auswählen
4. "Photoshop-Beschneidungspfad anwenden" deaktivieren
5. Okay klicken

Danach macht der Befehl frame::image auch mit kIgnoreClipping das Richtige.

Ab v3.3 R3116 wird die Einstellung in den Importoptionen bei kIgnoreClipping automatisch zurückgesetzt (und nach dem Import wieder zurück). Damit ist frame::image bei kIgnoreClipping jetzt unabhängig von den Pfad-Einstellungen in den Importoptionen.

Hotfix

08.08.2012

Skriptsprachenbefehl:

frames = itemlist::pageframes(pg, 1, 0, "--active--", 0, 0, 0);

produziert Absturz von InDesign® Server, owohl in Optionen ist die aktive Ebene gesetzt. Ich weiß, dass wir keine aktive Ebene auf der ID Server Seite haben- Trotzden die Ebene soll von API Optionen gelesen werden.

Das ist gefixt.

Ich möchte die in der Platzhalterpalette selektierten Einträge in einem Skript abfragen. Laut Doku müsste das mit List placeholderIds = list::alloc(kPanelPlaceholder); funktionieren, ich erhalte aber immer eine leere Liste.

Habe auch schon kEyeMarked ausprobiert, aber auch da ist die Liste leer. Die Palette der Platzhalter war während der Ausführung sichtbar und es gab Einträge, die mit einem Auge markiert waren.

Mache ich etwas falsch oder ist das ein Bug?

Das hat offenbar noch nie jemand benötigt. Die entsprechenden Zeilen für die Platzhalter-Palette haben im Code gefehlt. das ist jetzt gefixt. Und das Gleiche auch für die Aufgaben-Palette.

Einige Textrahmen führen beim Anpassen ihrer Grösse an den Inhalt zu einer Endlosschleife. Mit den InDesign®-Bordmitteln können diese Rahmen Rahmen gar nicht angepasst werden. Die Comet-Plugins vergrössern den Rahmen bis auf eine Höhe von 16 Millarden (!) Punkten und versuchen dann, die Breite zu ändern. Dabei bleibt InDesign® stehen.

Es handelt sich um Textrahmen mit einem einzeiligen Text, der nicht getrennt werden kann, z.B. "123456". Ausserdem ist der Rahmen rund.

Wie eklig. Die Rahmen müssen zuerst so verändert werden, dass Sie keinen Übersatz mehr haben. Bei einzeiligen Texten wird das jetzt auf 5000 Punkte beschränkt. Dann funktioniert alles.

Achtung : Im vorliegenden Fall mit dem Kreis verändert sich der Rahmen bei wiederholtem Anpassen. Comet führt das Anpassen daher solange aus, bis keine Veränderung mehr auftritt. Das ist ein recht aufwendiger Prozess der einige Zeit dauern kann. Bei rechteckigen Rahmen tritt dieses Problem nicht auf - und die Anpassung geht entsprechend zügig.

Im abgebildeten Fall dauert die Rahmenanpassung dann doch leider 3 Sekunden:

Ich habe ein InDesign® CS 4 Dokument erstellt, in dem zwei Kreis-Elemente integriert sind die Text beherbergen. Im Rahmen und im Text ist die Gestaltungsregel Bedingung: Textübersatz und Regel: Text anpassen bei Übersatz hinterlegt.

Je nachdem was im XML gepflegt ist, soll also im Rahmen dementsprechend verkleinert werden. Das klappt soweit ganz gut, aber nur wenn der Inhalt 4
Zeichen nicht überschreitet. Z.B. Wenn der Inhalt 1234 ist, passt sich die Schriftgröße optimal an. Ist der Inhalt 12345 zeigt der Textrahmen nur noch das Übersatztextzeichen - das rote plus an :

InDesign®-Tabellen können wegen der Zell-Insets, Zellrahmen, ... nicht beliebig klein werden. Die Skalierung wird daher nach einer bestimmten Anzahl von Schritten abgebrochen. Mit der bisherigen Grenze waren damit Textverkleinerungen auf minimal 65% der Ursprungsgrösse möglich. Die Grenze ist jetzt verschoben. Textverkleinerungen sind bis etwa 1% der Ursprungsgrösse möglich. Damit ist das Problem gelöst.

Nach dem Login (das Login-Fenster ist noch offen) erscheint die Fehlermeldung

    SQLExec [select error from placeholder where ID = ?] ...

Was könnte denn da falsch laufen?

Der Fehler entsteht so : Für jede Palette werden die Paletten-Aktionen geladen. Das wird in zwei Schritten gemacht :

• Schritt 1 : Sammeln aller nötigen Action-IDs.
• Schritt 2 : Danach werden die einzelnen Aktionen geladen.

Der Fehler kann nur auftreten, wenn zwischen Schritt 1 und Schritt 2 eine der gefundenen Aktionen gelöscht wird. Also eigentlich nie.

Ich habe die Situation trotzdem entschärft. Die in diesem Fall sowieso unnötige Anweisung "select ... from placeholder ..." wird nicht mehr ausgeführt. Dafür erscheint im Fly-out-Menü der Palette ein Eintrag "Undefinierte Aktion NNN".

In einem Produktaufbau wird ein Bild platziert. Das Bild hat oben einen Nagel und wird unten durch einen Magneten festgehalten. Gestaltungsregeln skalieren das Bild und positionieren es oben in der Mitte.

Nach dem Aufbau des Produktes steht das Bild aber an UNTEREN Rahmenkante.

Ja, das ist leider richtig. Der Fehler wird durch ein Implemtierungsdetail der Adaption verursacht : Der Rahmen wird erst so verschoben, dass der Magnet richtig ist. Danach "sieht" die Adaption den Nagel und vergrössert den Rahmen von unten aus. Dabei bleibt das Bild natürlich unten stehen. In der Abbildung ist die Situation dargestellt : Links ist der Rahmen VOR der Adaption. Er soll an der roten Linie ausgerichtet werden. Im mittleren Bild sehen Sie das. Im dritten Bild ist dann auch der Nagel wieder richtig - aber das Bild steht jetzt unten.

Das Problem ist gelöst. Die Bildposition bleibt jetzt erhalten.

Erst nach erneutem Logout/Login werden die Popup-Menüs der Palette richtig geladen.

Stimmt, aber es liegt an etwas ganz anderem : Alles funktioniert richtig, wenn ein gültiger XML-Ordner gesetzt ist, mit dem sich InDesign® beim Start automatisch verbinden kann. Stellt man dann eine SOAP-Verbindung her, werden in der Publikationspalette alle Popup-Menüs sofort richtig geladen.

Das gleichen Problem treten auch in den folgenden Paletten auf :

• Gestaltungsregeln
• Seitenraster
• Templates
• Platzhalter
• Previews
• Aufgaben

Der Fehler ist in allen Paletten gefixt.

Bei zwei-spaltigen Tabellen funktioniert die Funktion broaden_to_frame nur bei der ersten Tabelle. Meine letzte Version in der das noch richtig funktioniert hat war die R 2840. Die letzte Version mit der ich getestet habe war die R 3044.

Der Fehler ist beim Fix von Bug 2731 entstanden und jetzt gefixt.

Schön wäre es, wenn man beim Markieren der Platzhalter im Dokument einen zusätzliches Modus hätte, bei dem der Name des Platzhalters mit angezeigt wird. So könnte man sich schnell einen Überblick verschaffen, welche Platzhalter in einer Vorlage verwendet werden.

Ich habe das etwas anders umgesetzt : Die Platzhalter-Palette beherrscht jetzt Mehrfach-Auswahl. Werden im Dokument jetzt mehrere Platzhalter ausgewählt, werden auch in der Palette mehrere Platzhalter selektiert. Bei Rahmenauswahlen werden auch die Textplatzhalter innerhalb der Rahmen selektiert.

Ausnahme: Damit man weiterhin schnell sehen kann, ob und mit welchem Platzhalter ein Rahmen verknüpft ist, wird bei der Auswahl EINES Rahmen nicht nach Platzhaltern im Text dieses Rahmens gesucht.

Achtung I: Zum manuellen ändern der Listenselektion können jetzt die Zeilenteile außerhalb des Platzhalternamens verwendet werden. Um Platzhalter ins Dokument zu setzen, muss der Name des Platzhalters angeklickt werden. Damit das jeder erfährt, wird beim Klick außerhalb des Namens eine DontShowAgain-Nachricht mit einem entsprechenden Hinweis gezeigt.

Achtung II: Bei großen Dokumentauswahlen kann das Sammeln der Platzhalter etwas dauern. Es empfiehlt sich daher generell, die Platzhalter-Palette nur dann anzuzeigen, wenn man sie auch benötigt.

Ich wähle einen Rahmen einer Fortsetzung aus (Das sind die Rahmen, bei denen in der Platzhalterdarstellung links oben ein kleines graues Dreick gezeigt wird.). dann wird reorganisiert.

Das Produkt beginnt jetzt auf der Seite des Fortsetzungsrahmens. Alle Nachfolgeprodukte verschieben sich. Zwischen altem und neuem Produktbeginn sind alle Seiten leer.

Das ist ja ganz offensichtlich, was da passiert : Ab dem mit der Wahl des Fortsetzungsrahmen ausgesuchten Produkt wird das Dokument aufgeräumt. Nur leider beginnt dieser Prozess nicht auf der Seite, auf der das Produkt tatsächlich beginnt, sonder auf der Seite des Fortsetzungsrahmens.

Vor der Reoragnisation muss noch die Startseite des Produktes ermittelt werden. Die kann manchmal ziemlich weit weg sein. Das wird jetzt gemacht. damit ist der Fehler gefixt.

Im Vorher-Bild wurde der lila hinterlegte Rahmen ausgewählt. Dann wurde reorganisiert. Dabei wird der grüne Rahmen richtig an die linke obere Ecke des Seitenelementes verschoben. Im Nachher-Bild ist er nicht mehr zu sehen, weil - und jetzt kommt der Fehler - auch der lila Rahmen an diese Position verschoben wird.

Das Problem ist gelöst. Der lila Rahmen wird jetzt richtig positioniert.

FYI: Für die Rahmen der Seite wird jeweils ermittelt, auf welchem Seitenelement sie liegen. Das wurde richtig gemacht. Leider wurde dann der Index (in diesem Fall 1) weitergegeben. Die Reorganisation erwartet aber Sequenz-Nummern. Das wäre hier die 2 gewesen. Sequ.-nr. 1 ist der der kleine blaue Streifen oben auf den Seiten. Dort passt der lila Rahmen nicht rein. Also geht es beim nächsten Seitenelement weiter - und dort liegt schon der grüne Rahmen. Das war der Fehler.

Die Funktion textmodel::find_surrounding_paragraphliefert im Fehlerfall eine Fehlercode und nicht, wie in der Doku beschrieben, -1. Das wäre nicht weiter schlimm. Aber die Fehlercodes sind meist grösser als 0 und daher nicht von einem gültigen Ergebnis unterscheidbar.

Der Fehler ist gefixt. Due Funktion gibt jetzt im Fehlerfall immer -1 zurück.

Die Funktion textmodel::find_surrounding_word liefert im Fehlerfall eine Fehlercode und nicht, wie in der Doku beschrieben, -1. Das wäre nicht weiter schlimm. Aber die Fehlercodes sind meist grösser als 0 und daher nicht von einem gültigen Ergebnis unterscheidbar.

Huch. Der Fehler ist gefixt. Due Funktion gibt jetzt im Fehlerfall immer -1 zurück.

Seit einiger Zeit können Comet-Notizen ja mit ausgedruck werden. Das funktioniert auch. Un die Notizen sind jetzt auch im Vorschau-Modus von InDesign® sichtbar. Dort fehlt aber das Label oben links.

Das Label ist jetzt auch in der Vorschau sichtbar. Gedruckt wurde es sowieso schon.

Das XML der Comet-Notizen, das man beim Export der Notizen erhält, enthält für jede Notiz eine Liste von Kommentaren.

<notes>
	<note id="1" ...>
	...
	<comments>
		<comment num="1" ...>
		</comment>
  </comments>
  ...
</notes>

Hat es damit etwas auf sich? Fügt man in das XML weitere comment-Elemente ein, werden diese eingefügten Kommentare beim Import der Notizen jedenfalls ignoriert. Nur der erste Kommentar wird im Dokument gezeigt.

Richtig bemerkt. Die Struktur ist bereits zur Unterstützung mehrerer Kommentare pro Notiz vorbereitet. Bisher wird dieses Feature von den Plugins aber nicht unterstützt.

Achtung :Zusätzlich eingefügte Kommentare in der XML-Datei gehen beim erneuten Import verloren!

Lösung

=== Import ===

Die Kommentarliste wird ab v3.3 R3101 unterstützt. Jedes <comment>-Element erzeugt einen eigenen Textblock in der Notiz. Die Textblöcke werden jeweils durch einen leeren Absatz getrennt. Die Attribute "on" und "user" des Kommentares werden mit einem einleitenden "> " dem Kommentartext vorangestellt :

> 26.07.2012 12:09, paul
Kommentartext

Hier ein Ausschnitt aus einer Notizen-XML:

<comment num="1" user="comet-bugs@werk-ii.com" role="proof_reader" on="20120724160100">
	<plain>Schau mal nach Bug 2948.</plain>
	...
</comment>
<comment num="2" user="paul" role="proof_reader" on="20120726103100">
	<plain>Das ist jetzt erledigt.</plain>
	...
</comment>

Das ergibt folgenden Text in der Notiz:

=== Export ===

Umgekehrt werden Textteile der Notiz, die durch mind. einen leeren Absatz getrennt sind, jeweils als neuer Kommentar exportiert. Als Zeitangabe wird dann die aktuelle Zeit verwendet, "user" bekommt den aktuellen Loginnamen am Rechner.

Absätze, die mit ">" beginnen, leiten ebenfalls einen neuen Kommentar ein. Diese Absätze dürfen nur eine Zeile lang sein und müssen mind. ein sichtbares Zeichen haben. Hier eine Zusammenstellung der mögl. Angaben

• > user // Als Zeit wird die aktuelle Systemzeit verwendet
• > zeit, // Das Komma ist wichtig! Als user wird der aktuelle Loginname am Rechner verwendet
• > zeit, user

"user" ist ein beliebiger Text ohne Komma und ohne Absatztrenner. "zeit" ist eine beliebige Zeitangabe mit oder ohne Uhrzeit Whitspaces vor und nach den Angaben werden entfernt.

Leere Kommentare werden nicht exportiert. Der Text

> paul
> clara
Kommentartext

erzeugt also keinen Kommentar für "paul".

Ich werd noch wahnsinnig.

Einer unserer Kunden hätte generell gerne die Spracheinstellung der Texte auf "English: USA". Das habe ich in den Templates und im Musterdokument auch gemacht, und zwar für alle Absatzformate und für das Dokument ("Wörterbuch" und "Autokorrektur").

Wenn ich ein Template auf das Dokument ziehe, springen die Spracheinstellungen in den Rahmen (siehe Palette "Zeichen") wieder auf Deutsch zurück. Das passiert aber nur in den Musterdokumenten; in neuen (mit deutschem InDesign® angelegten) Dokumenten hingegen nicht.

Wenn ich ein neues Dokument verwende, passiert das nicht, trotz deutschem InDesign. Auch nach dem Importieren der Stilvorlagen aus dem alten Dokument funktioniert es noch.

Wenn ich hingegen von dem Ursprungsdokument ein idml exportiere und öffne, springt die Spracheinstellung auf Deutsch.

Der Fehler lässt sich leicht reproduzieren: aus den Rahmen eines Dokumentes ein Template erstellen und wieder auf die Seite ziehen. Wie gesagt, ich werd noch wahnsinnig.

Um die richtige Sprach-Einstellung für neue Rahmen zu erhalten, muss die Default-Einstellung in InDesign® geändert werden. (Neustartvon InDesign® OHNE Dokument, Textwerkzeug, gewünschte Spracheinstellung wählen, Neustart von InDesign)

Hotfix

20.07.2012

Publikationen haben ja wie andere Objekte auch IDs, die aus drei Zahlen und einer StrinID bestehen. In den Panelstatements für die Palette "Publikations-Infos" (100, 101, 103, 104, 105) wird aber immer nur die erste Zahl weitergegeben.

In den Panelstatements 100, 101, 103, 104, 105 können jetzt die Tags <ID>, <ID2>, <ID3> und <STRINGID> verwendet werden, die jeweils durch die IDs der aktuellen Publikation ersetzt werden

Kann man Musterseiten aus anderen Dokumenten in ein Dokument importieren?

Mit dem neuen Befehl document::import_masterpage geht das jetzt. Um zu bestimmen, welche Musterseiten in einem Dokument enthalten sind, kann die Funktion document::get_masterpages verwendet werden.

... wenn ich die Combobox auswähle

    select id, name from pageitems where id > 0 order by name; 
    Database execution error : 
    200047 : ORA-24338: statement handle not executed

Der Grund ist wohl, dass bei Auswahl des Popupmenüs automatisch die Einträge fürs zweite (unsichtbare) Popup geladen werden. Aber die zugehörige Anweisung leer ist. Der Fehler ist gefixt.

Enthält ein Absatz- oder Zeichenstilname eines %!TT-Textes Unicodezeichen grösser 128 (z.B. der Zeichenstil "Straßenname") wird gar nichts mehr ins Dokument importiert.

Der Fehler ist gefixt.

Enthält ein w2-Tag Unicode-Zeichen grösser 128, wird der Platzhalter falsch im Dokument angelegt. Solche Zeichen können aber in den StringIDs durchaus vorkommen.

WORKAROUND : Abschalten der Option "Zusatzmodule > Comet > Platzhalter aus TaggedText anlegen"

Der Fehler ist gefixt.

Enthält ein %!TT-Text mehrere w2-Tags, die jeweils <CharStyle:>-Angaben enthalten, schlägt der Import fehl. Der erste Platzhalter wird richtig angelegt. Alle weiteren enden jeweils beim <CharStyle:>.

WORKAROUND : Abschalten der Option "Zusatzmodule > Comet > Platzhalter aus TaggedText anlegen"

Der Fehler ist gefixt.

Enthält ein w2-Tag mehrere CharStyles wird zwar ein Platzhalter angelegt - aber der geht nur bis vor das zweite CharStyle (analog ParaStyle).

Bei dem Text

    %!TT<w2:77780, 500, 10, 1, ''><CharStyle:Price>Preis<CharStyle:> €</w2>

gehört das " €" nicht mehr zum Platzhalter.

WORKAROUND : Abschalten der Option "Zusatzmodule > Comet > Platzhalter aus TaggedText anlegen"

Der Fehler ist gefixt.

Ich hab das (bestimmt alltägliche) Problem, dass ich ein fit_col() auf eine Tabelle mache, bei der die erste Zeile nur aus einer Spalte besteht. Leider passt fit:col dann nur die erste Spalte an. Gibt's da irgendeinen Trick, oder muss ich wirklich die Textkoordinaten aller Zellen durchgehen?

Nein, es gibt keinen Trick. Es war ein kleiner Fehler in den Plugins, der jetzt gefixt ist.

Vorher

Nachher

Man beachte inbesondere die erste Spalte, die auf den ersten Blick breiter als nötig erscheint. Die Breite ist aber nötig, damit der Text der ersten Zeile vollständig sichtbar ist. Der Trick dabei : Die Spalten werden von rechts beginnend bearbeitet.

Werden mit dem Javascript-Befehl placeTemplate Produkte platziert, werden die Gestaltungsregeln "Nach Einfügen" (+) der Templates nicht ausgeführt.

Mit Bug Bug 2845 wurde zwar gefixt, dass die Gestaltungsregeln nach dem Laden (<-) getriggert werden. Leider waren aber auch die Regeln nach dem Anlegen (+) abgeschaltet. Die werden jetzt auch ausgeführt.

Achtung : Die Regeln nach Aufbau (Bausteine) werden hier NICHT ausgeführt - es wird ja kein Seitenaufbau durchgeführt.

Gestaltungsregeln können ja in verschiedenen Situationen ausgeführt werden. Dazu gibt es in der Liste der Gedstaltungsregeln in jeder Zeile ein Feld mit mehreren Buttons, die aktiviert werden können. Die Reihenfolge dieser Buttons ist zwar eigentlich egal. Aber irgendwie nimmt man ja an, dass die Regeln dann auch in dieser Reihenfolge ausgeführt werden.

Das stimmt. Momentan ist z.B. die Situation + (Nach Neuanlage) vor der Situation <- (Nach Laden). Das + feuert aber erst, wenn das Laden schon beendet ist. Das steht zwar auch so im gelben Hilfe-Zettel - aber schöner wäre es schon, wenn die Button-Reihenfolge anders wäre.

Die Reihenfolge der Buttons ist jetzt wie im Bild gezeigt:

Ein Aufbau von Produkten mit zwei Skriptläufen führt zu "kein Seitenelement gefunden, dass groß genug ist für das Produkt".

Beim Einfügen wird jedesmal ein Produkt eingefügt, das per Aufbauregel" eine neue Seite erzwingt. Beim zweiten Mal scheint das dann nicht mehr zu klappen.

Wer macht denn so was?! Aufbauregeln sind Teil des Rasteraufbaus. Nur aus Gründen der Rückwärts-Kompatibilität werden sie auch vom Seitenaufbau weitestgehend unterstützt. Das Erzwingen von Seitenwechseln wird im Seitenaufbau durch Seitentemplate-Einträge in der Produktliste gemacht. Das sind Produkte mit folg. Eigenschaften :

    kProductType = 4
    kProductPageType = 0 (linke Seite), 1(neue Seite), 2(rechte Seite)

Ein vollständiges Beipiel finden Sie hier.

Der Fehler ist trotzdem gefixt.

FYI : Der Fehler lag daran, dass der Seitenaufbau generell lieber bestehende Seite befüllt als neue anzulegen. Die Aufbauregel "Neue Seite" hat also die nächste Seite des Dokumentes verwendet - die in diesem speziellen Fall noch Inhalte hatte - und dann konnte dort natürlich kein Platz mehr gefunden werden.

Produkte werden spaltenweise in ein Seitenelement importiert. Das funktioniert richtig. Schaut man sich die Produkte in der Palette "Produkte des Dokumentes" an, stimmt dort aber die Reihenfolge nicht - was natürlich beim Reorganisieren zu Fehler führt.

So wurde aufgebaut :

    P1    P4
    P2    P5
    P3    P6

So sieht die Liste aus

    P4
    P1
    P2
    P3
    P5
    P6

Sehr misslich das. Ich habe lange nach dem Fehler gesucht, der letztlich an der Maschinen-Genauigkeit für Floating lag : P1 und P4 hatten beide den gleichen y-Wert. Jedenfalls sah das nach aussen (und auch im Debugger) so aus. In Wirklichkeit lag P4 ein winziges Stück höher - und lag damit VOR dem Seitenelement.

Wir können den Fehler zwar nicht beheben, aber wir haben ihn unschädlich gemacht.

Ein Skript fügt mit productlist::establish Produkte in ein Dokument ein. Danach ist natürlich die Liste der Prod. des Dokumentes nicht mehr aktuell. Häufig vergessen Benutzer aber, die Liste neu zu laden - und wundern sich dann, was beim nächsten Reorganisieren passiert. Kann man die Liste vielleicht automatisch aktualisieren?

Aus Preformance-Gründen habe ich die Aktualisierung nicht in den Befehl productlist::establish eingebaut. Es gibt aber einen eigenen Befehl dafür, den man vorzugsweise am Ende des Skripte ausführen lassen kann :

    productlist::reload_products_of_document

Wir haben eine Menge Dokumente, bei denen leider einige Textplatzhalter so aufgebaut sind :

    [Text Tabelle]

D.h., die Tabelle ist direkter Teil des Platzhalters. Inzwischen werden die Tabellen mit einem Tabellenplatzhalter angelegt. Leider gehen jetzt beim Aktualisieren der alten Platzhalter die Tabellen verloren. Wenn man den Platzhalter um die Tabellen entfernen könnte, wären die alten Dokumente gerettet. Leider arbeitet textmodel::clear_placeholder aber nur auf dem aktuellen Skripttext. Kann man da was machen?

textmodel::clear_placeholders hat jetzt einen zusätzlichen optionalen Parameter, in dem der gewünschte Textrahmen angegeben werden kann. Dann kann man das Problem mit folg. Skript leicht lösen :

int main ()
{
	ItemList       frames	= itemlist::allframes (1);
	ItemRef        fr 		= item::alloc ();
	Table          T   		= table::alloc ();
	int            f, t;
	int            a, b;

	for (f = 0; f < itemlist::length (frames); f++)
	{
		itemlist::get (frames, fr, f);
		for (t = 0; t < table::count (fr); t++)
		{
			table::get (T, fr, t);
			a = table::get_anchorpos (T, &b);
			if (a >= 0)
			{
				textmodel::clear_placeholders (a, b, fr);
			}
		}
	}
	return 0;
}

In der Produktrecherche kann man einstellen, ob sich die Listenauswahl an die Dokumentauswahl anpassen soll oder nicht. (Menü Palette->Listenauswahl->Stabile Listenauswahl oder das Button "Stabile Listenauswahl" unten in der Palette).

Hat man KEINE stabile Listenauswahl, wird die Auswahl in der Liste immer der Auswahl im Dokument angepasst. Ist die Dokumentauswahl leer wird in der Liste der Eintrag [Kein Objekt] ausgewählt. Könnte man das so ändern, dass in diesem Fall die Listenauswahl erhalten bleibt?

Das Button hat jetzt drei Einstellmöglichkeiten :

• : Auswahl anpassen
• : Auswahl anpassen, aber leere Auswahl ignorieren
• : Auswahl nicht verändern

Buttonklick (oder das Menü Palette->Listenauswahl->StabileListenauswahl) kreisen durch diese Möglichkeiten. Das oben beschriebene Verhalten erhält man, wenn "Rot-Blau" eingestellt ist.

Hotfix

04.07.2012

In der Palette "priint:adjust" können die verbotenen Ränder eines Bildes eingestellt werden. Das funktioniert auch - aber nicht für den Wert "oben".

Das geht jetzt.

In der Palette "priint:adjust" wurde bisher immer ein Preview des aktuell ausgewählten Rahmens gezeigt. Seit CS5 ist dort immer nur ein weisses Rechteck zu sehen.

Der Fehler ist gefixt. Das Preview ist jetzt auch unter CS5 und höher zu sehen.

Wenn ich die Regel "Bildgröße anpassen" auswähle, dann skaliert das Bild knallhart auf die Rahmengröße. Dummerweise stört es ihn hierbei nicht, ein Bild z.B. mit 250% zu Lasten der Qualität einzubauen.

Gab es nicht mal die (sinnvolle) Einschränkung, dass Bilder niemals vergrößert eingebaut werden, sondern maximal verkleinert werden?

Die Option gibts jetzt. Zusätzlich gibts als dritte Option "Vektorformate". Dort kann eine Liste von Dateiendungen angegeben werden für alle Formate, die trotzdem beliebig vergrössert werden dürfen (z.B. "ps eps"). "alle" ist der Short cut für "ai ps eps pdf".

InDesign® kann es gar nicht, fit::frame aber schon - das Anpassen von Rahmen mehrspaltiger Texte. Aber leider ist auch fit::frame nicht sehr genau in der Anpassung. Die Rahmen sind immer irgendwie zu hoch.

Ja, das ist wahr. Es muss ein Kompromiss zwischen Genauigkeit der Rahmenhöhe und Geschwindigkeit der Anpassung gefunden werden. Der war ein bisschen sehr einseitig zugunsten der Geschwindigkeit ausgefallen. Jetzt ist die Berechnung genauer - dafür ein bisschen langsamer.

Hotfix

01.07.2012

svn 3073

In einem 1:N-Seitenelement mit spaltenweisem Aufbau sollen Produkte aufgebaut werden. Leider wird aber keine neue Spalte begonnen und das letzte Produkt ragt nach unten über das Seitenelement hinaus.

Der Fehler tritt nur dann auf, wenn das Produkttemplate vor dem Laden noch ins Element passt, nach dem Laden aber höher geworden ist.

Das gleiche Problem tritt auch im zeilenweisen Aufbau auf, wenn dort das Produkt beim Laden breiter wird. Dann ragt es halt rechts über das Seitenelement hinaus.

Gar nicht so einfach, dafür Testfälle zu bauen. Der Fehler ist gefixt.

Winziger Schönheitsfehler: Wenn eine Cometgruppe bei der Reorganisation neu aufgebaut werden muss (z.B. bei Seitenwechsel) zeigen die Rahmenplatzhalter an, dass sie nicht synchron wären (roter Haken). (Sync-Scripte sind vorhanden!)

Einmal mit der Aufgabenpalette gesucht und alles ist wieder grün.

Die Textplatzhalter zeigen das Verhalten nicht.

Rahmen gleicher Kennung befreundeter Templates (also die Rahmen, die bei Reorganisationen Inhalte übernehmen können) übernehmen jetzt auch SyncState und Modified-Date aus dem Original.

Das Freistellen von Musterseiten-Elementen hört immer auf, wenn eine Seite keine Musterseite hat. Alle Seiten hinter dieser Seite wurde nicht mehr bearbeitet.

Dieser Fehler ist gefixt.

Hotfix

28.06.2012

Wir haben ein großes Problem beim Arbeiten mit mehreren Dokumenten auf dem Comer Server (Rev. 3.3 3044). Im Anhang finden Sie ein Paket, welches das Problem reproduzierbar macht.

Wenn file2 vor dem Platzieren geöffnet wird, dann geht das Auslesen der Gruppe nach dem Platzieren im ersten Dokument mit "Cometgroup not found" schief, da das Produkt im zweiten Dokument platziert wird.

Wenn man file2 nach dem Platzieren öffnet, dann kann mit zwei parallelen Dokumenten gearbeitet werden :

    app.comet.documentOpen(file1, true, options1);
    app.comet.documentOpen(file2, true, options2);

    app.comet.placeTemplate(file1, ...);

Bug 2725 (R2808, 21.02.2012). Der Fehler ist gefixt.

Achtung : Alle Serverversionen seit R2808, 21.02.2012 bis R3069 können jeweils nur mit einer einzigen geöffneten Datei pro Skript arbeiten und müssen diese am Skriptende auch wieder schliessen.

Die Drag and Drop - Option "Shift-Taste halten" zum Unterdrücken des PageItemID-Skriptes für Produkte wird nicht mehr unterstützt. Das Skript wird jetzt immer ausgeführt.

Es wird gewünscht, dass Produkte bei Drag and Drop automatisch an der linken oberen Ecke des Seitenelementes platziert werden, über dem sie fallengelassen werden.

Dabei soll keine Prüfung gegen bereits bestehende Seiteninhalte und/oder Seitengrössen gemacht werden. Auch die in den Seitenelementen eingestellten Ausrichtungen sollen ignoriert werden.

Drag and Drop mit den gehaltenen Tasten

    Shift + Command

macht das Gewünschte jetzt. Der Cursor bekommt dann dieses Aussehen :

Die Sache mit den Musterseitenelementen ist anscheinend noch nicht ganz ausgestanden:

Man nehme einen Standard-Produktaufbau (Mauer) über mehrere Seiten, beginnend mit einer rechten Seite. (Standard)

Wenn ich anschließend "page::masteritems_load(-1, 0);" ausführe, werden alle Musterseitenelemente gelöst und geladen, bis auf den Rahmen auf der ersten, rechten Seite. Den ignoriert er quasi.

Mit der neuen Option "Musterseiteneinträge freistellen und laden" ergibt sich übrigens der gleiche Fehler.

Das ist gefixt

In der Datenbank hat Platzhalter die syncID -1. Bei der Verlinkung von Text/Rahmen mit diesem Platzhalter erhält der Platzhalter aber immer die Sync-ID 0. Der Fehler tritt nur bei ODBC-Verbindungen auf. XML und SOAP funktionieren.

Der Fehler ist gefixt.

Hotfix

21.06.2012

Besser wäre es sicher, dann den freigestellten Rahmen zurückzugeben, oder?

Das wird jetzt gemacht.

Wenn ich einen Rahmen mit kRefPointBottomRight an seinen Inhalt anpassen will, ändert der zwar seine Höhe - aber nicht auf das erwünschte Minimum. Der Rahmen wird viel zu hoch. Das Gleiche passiert auch mit anderen Referenzpunkten unterhalb der oberen Rahmenkante.

Auffällig an dem Fehler ist : Wenn ich das Template, in dem der Rahmen enthalten ist, genügend weit unten auf einer Seite platziere, funktioniert es, nur im oberen Seitenbereich nicht.

Damit frame::fit richtig funktioniert, muss der Rahmen zunächst so groß gemacht werden, dass kein Übersatz mehr besteht (In 90% der Fälle funktioniert frame::fit zwar auch ohne diesen Schritt, aber zumindest durch den Filter der API ist nicht zu erkennen, woran das liegt - also machen wir es immer.) Wird der Rahmen jetzt unten festgehalten, wächst er natürlich nach oben. Und weil wir aus Performance-Gründen großzügig vergrößern, landet die obere Rahmenkante ausserhalb des Arbeitsbereiches.

Und dann passiert folgendes : InDesign® verkleinert den Rahmen zwar. Aber nicht auf das gewünschte Minimum, sondern nur soweit, dass er nicht ganz von der Arbeitsfläche fällt - irgendwie auch verständlich.

Diese Verhalten wird jetzt dadurch gelöst, dass VOR dem eigentlichen Anpassen des Rahmens die Arbeitsfläche vergrössert wird. Und zwar so, dass der Rahmen in keinem Fall von der Arbeitsfläche fallen kann. Dann wird der Rahmen angepasst. Danach kann die Arbeitsfläche wieder auf ihre alte Grösse gebracht werden.

Damit ist der Fehler gefixt.

Hotfix

20.06.2012

Wendet man die Gestaltungsregel "Bildplatzierung anpassen" auf Bildrahmen an, die einen Beschneidungspfad verwenden, kommt nicht das erwartete Ergebnis raus. Das Bild wird so platziert, als würde der Beschneidungspfad gar nicht verwendet.

Die Gestaltungsregel funktioniert jetzt auch bei Bildern mit aktivem Beschneidungspfad.

Fragt man mit frame::image_getpath_bbox nach der BoundingBox um den verwendeten Biidpfad, erhält man zwar ein richtiges Ergebnis. Aber der linke obere Punkt ist immer (0.0, 0.0). Schöner (und brauchbarer) wäre natürlich, wenn dieser Punkt die Abstände zur linken oberen Ecke des gesamten Bildes liefern würde.

Das wird jetzt gemacht.

Wenn ich den Standardproduktaufbau mache (Mauer), dann wird spätestens ab der zweiten Seite die Musterseitenelemente gelöst, die einen leeren Rahmenplatzhalter haben, obwohl an keiner Stelle masteritems_load ausgeführt wird.

Beginnt man den Produktaufbau auf einer linken Seite, landen die Musterseitenelementen der linken UND rechten Seite gelöst auf der Folgeseite. Das führt dann bei einem Produktaufbau inkl. masteritems_load im Panelscript, dass die Rahmen doppet und dreifach auf der Seite stehen.

Normalweise sollte doch kein Musterseitenelement gelöst werden, wenn nicht masteritems_load aufgerufen wird, oder?

Für Bug 2903 musste ich einige änderungen machen. Dabei verwende ich eine InDesign®-API-Funktion zum Ermitteln der Musterseiteneinträge. Die Funktion will die UID einer Musterseite und gibt dann eine Liste von Musterseiten-Rahmen zurück. Eigentlich ganz okay - was nicht so okay ist. Die Funktion gibt viel mehr zurück  Nämlich auch alle Musterseiten-Rahmen der Seiten, die links der gewünschten Seite im Masterspread liegen.

Diese Rahmen werden jetzt (ziemlich aufwendig) ausgefiltert und der Bug damit gelöst.

Zu den Musterseitenelementen siehe auch Bug 2903, Bug 2910, Bug 2911, Bug 2912 und Bug 2913,

Es gibt bisher kein Verfahren, nach Seiten-Reorganisationen die Musterseiteneinträge  automatisch freizustellen und/oder neu zu laden. Man muss dazu immer den Befehl

    Produktrecherche > Verschiedenes > Musterseiteneinträge aktualisieren

Mit der neuen Aufbau-Option "Musterseiteneinträge freistellen und laden" geht das jetzt automatisch : War beim letzten Produktaufbau die Option gesetzt, werden nach jedem Aufräumen die Musterseiteneinträge aktualisiert, sonst nicht.

Darüber hinaus wertet auch der Skriptbefehl productlist::reorganize das Flag aus : Ist hier das Flag gesetzt, werden in jedem Fall nach dem Aufräumen die Musterseiteneinträge aktualisiert. Ist das Flag nicht gesetzt, wird die Einstellung des letzten Produktaufbaus verwendet.

Da man vielleicht nicht immer gleich Produkte einfügen will, um die automatische Musterseitenrahmen-Aktualisierung ein- oder auszuschalten gibt es zusätzlich ein neues Menü zum ändern der Einstellung :

    Produktrecherche > Verschiedenes > Nach Reorganisationen Musterseiteneinträge aktualisieren

Der Produktaufbau lädt ja offenbar die Musterseiten-Rahmen aller Seiten, die neu angelegt werden müssen. Aber der Zeitpunkt ist natürlich ein bisschen doof : Nämlich dann, wenn die Seite noch leer ist.

Irgendwie inkonsequent ist ausserdem, die Musterelemente bestehender Seiten völlig unberührt zu lassen.

Der Produktaufbau hat jetzt eine weitere Option : Musterseiteneinträge freistellen und laden (in Skripten das Flag kLoadMasteritems). Ist diese Option aktiviert, werden nach dem Aufbau der Produkte die Musterseiteneinträge (mit Platzhalter) ALLER Dokumentseiten freigestellt und/oder neu geladen.

FYI : Es ist nötig, das mit allen Seiten zu machen, da Musterseiteneinträge beim Laden ihrer Inhalte auch auf Inhalte anderer Seiten zugreifen können und sich daher auch Musterseiten-Rahmen auf Seiten ändern können, die der aktuellen Aufbau gar nicht verändert hat.

Das geht bisher nur mit dem Befehl page::masteritems_load. Einen Menübefehl gibt es dazu nicht, oder? Über den Befehl

    Produktrecherche > Verschiedenes > Musterseiteneinträge aktualisieren

kann ja immer nur die aktuelle Seite bearbeitet werden.

Das geht mit gleichzeitig gehaltener Shift-Taste.

Weil es aber eigentlich ziemlich blöd ist, Menüs mit Modifier-Taste zu versehen (die ALT-Taste zum Editieren von Skripten reicht) hab ich ein weiteres Menü eingefügt, mit dem alle Seiten bearbeitet werden können :

    Produktrecherche > Verschiedenes > Musterseiteneinträge der Seite aktualisieren
    Produktrecherche > Verschiedenes > Alle Musterseiteneinträge des Dokumentes aktualisieren

In der neuesten Version R3030 werden Musterseiten-Rahmen nicht mehrt vollständig aktualisiert. Ich verwende den Befehl

    Produktrecherche > Verschiedenes > Musterseiteneinträge aktualisieren

Auch page::masteritems_load funktioniert nicht mehr richtig.

In beiden Fällen werden zwar alle noch nicht freigestellten Musterseitenrahmen (die einen Platzhalter haben) freigestellt und geladen. ABER : Rahmen, die bereits freigestellt waren, werden nicht neu geladen.

Das ist eine Folge des Fixes von Bug 2903 und funktioniert jetzt wieder.

Die Release für CS5.5 R2575 und latest Release R3024 sind beide nicht fehlerfrei auf dem CS5.5 Server.

Der Fehler ist gefixt

1:N-Seitenelemente, die ihren Inhalt spaltenweise anordnen sollen, machen das auch sehr schön und richtig. Leider werden die aufgebauten Produkte aber in der Palette "Produkte des Dokumentes" in falscher Reihenfolge gezeigt (nämlich zeilenweise). Was dann natürlich zu Fehlern bei der Reorganisation führt.

Der Fehler war leider noch nicht vollständig gefixt. Aber jetzt ist alles okay.

Hotfix

15.06.2012

svn 3041

In einer mit dem Tabellenmodul aufgebauten Tabelle verwende ich die Methode "Gleiche Zellen verbinden". Dadurch entstehen zum Teil recht hohe Zellen über viele Zeilen. In diesen Zeilen kann InDesign® keine Rahmenumbrüche machen - und mein Produktaufbau schlägt fehl oder erzeugt unnötig viel Weißraum.

Ich habe einen neuen Skriptbefehl gemacht :

    table::merge_equal

Der hat einen Parameter, mit dem man steuern kann, ob Merges über Rahmenumbrüche gehen können oder nicht.

Hotfix

14.06.2012

svn 3034

Kann app.comet.placeTemplate so erweitert werden, dass das Template nach dem Platzieren NICHT automatisch geladen wird?

Mit der Option "auto-load:false" kann das Laden jetzt unterdrückt werden :

var gDocument 	= "/Users/paul/Desktop/place_template.indd";
var gOptions 	= app.comet.ping() + ";-1;";

app.comet.placeTemplate (
		gDocument,
		Scope.SPREAD,
		0, 486,
		"500, 10, 0, \"\"",
		10.0, 10.0,
		ReorganizeLevel.NONE,
		gOptions+"auto-load:true;");

Durch den Menüfehl

    Produktrecherche > Verschiedenes > Musterseiteneinträge aktualisieren

werden zwar die Musterseiten-Einträge der Seite aktualisiert. Leider erscheint aber auch ein Musterrahmen der Folgeseite auf meiner Seite. Das gleiche passiert mit dem Skriptbefehl

    page::masteritems_load(seitennummer, 3);

Das stimmt so nicht ganz. Man hat zwei Musterseiten :

• Musterseite A : Mit den Rahmen m_a1 und m_a2
• Musterseite B : (von A abgeleitet) mit dem Rahmen m_b1. Zusätzlich wurde auf dieser Musterseite der Rahmen m_a2 freigestellt und entfernt. Auf der Seite sind also m_a1 und m_b1 zu sehen.

Aktualisiert man jetzt die Musterseiten-Rahmen einer Dokumentseite, die B als Musterseite verwendet, dann erhält man DREI freigestellte Rahmen : m_a1', m_a2' und m_b1'. Klar, m_a2' sollte hier nicht erscheinen.

Knifflig, knifflig - aber gelöst. Beides, Menü und Skriptbefehl machen jetzt das Richtige : m_a1 und m_b1 werden freigestellt und aktualisiert, m_a2 erscheint nicht auf der Seite.

Leider erfordern manche Projekte sehr sehr ausführliche StringIDs. In der Platzhalterwerte-Palette kann ich die, wenn sie zu lang zum Anzeigen sind, per Mouseover ansehen. Schön wäre, wenn das auch in der Tabellenaufbau-Palette ginge.

Phantastisch wäre, wenn ich die Werte per Kontextmenü rauskopieren könnte - aber ich weiss nicht, ob die API das problemlos hergibt.

In der Tabellenmodul-Palette und in Platzhalterwerte sind die einzelnen ID-Felder jetzt ersetzt durch jeweils ein Multiline-Edit, das die IDs anzeigt.

In Platzhalterwerte werden zusätzlich noch die zwei Infos-Felder angefügt.

Die Edits sind scrollbar und man kann die Text rauskopieren. (Man kann die Werte auch ändern, aber das zieht natürlich keine Dokument-änderiungen nach sich. Aber wenn die Felder disabled sind, sind sie so grau und unleserlich. Kopieren könnte man trotzdem.)

Alle Produkte verwende das gleiche seitenabhängige Template. Alle Rahmenkennungen sind richtig gesetzt. Trotzdem werden einige, aber nicht alle Produkte, beim Aufräumen neu geladen, wenn sie auf eine neue Seite verschoben werden müssen (also das Template getauscht werden muss).

Produkte werden vor und nach dem Füllen mit Daten auf ihre Grösse geprüft - klar. Wenn sie zu groß sind, führt das zu einem Wechsel des Seitenelementes (und mglw. zu einem Seitenwechsel).

Wenn das Produkt schon der ersten Prüfung nicht standgehalten hat, war alles okay. Wenn die erste Prüfung okay war, aber die zweite nicht, dann wurde das Produkt neu geladen. Ein klarer Fehler - der jetzt gefixt ist. Sie sollten das an einem schnelleren Produkt-Aufräumen auch deutlich merken.

Obwohl ein Produkt noch auf eine Seite passen würde, wird es beim Reorganisieren auf eine neue Seite verschoben. Woran könnte das liegen?

Hat das Produkt Fortsetzungen? Wenn ja - prüfen Sie mal die Gestaltungsregeln der Rahmen, die fortgesetzt werden sollen : Gibt es da bei den Regeln für Reorga ein Fitframe oder andere Methoden, die die Rahmenhöhe ändern?

Dann ist das das Problem. Die Höhe der Rahmen mit Textfortsetzung wird vom Produktaufbau gesteuert! Wenn Sie die Rahmen hinterrücks wieder höher machen, kann das natürlich nicht funktionieren.

Höhenänderungen an Rahmen mit Fortsetzungen in den Reorg-Regeln werden jetzt automatisch wieder zurückgesetzt.

Ein Produkt, das auf eine Seite gepasst hat, wird nach dem Aufräumen auf einer neuen Seite platziert. Auf der alten Seite bleibt ein großer weisser Fleck.

Gibt es Fortsertzungen und legt das Template im BuildSupportScript in der Situation kBeforeCreateContinue zusätzliche Rahmen im Dokument an? Dann könnte das Problem dadurch entstehen : Im BuildSupportSkript angelegte Rahmen werden automatisch als Fortsetzungsrahmen gekennzeichnet und bei Reorganisationen weggeschmissen. Fortsetzungen werden von 1 beginnend gezählt. Aber leider ist der Zähler beim ersten kBeforeCreateContinue-Call noch 0 - diese Rahmen werden also gar keine Fortsetzung.

Der abgebildete Rahmen müsste an der linke Seite eigentlich ein kleines graues Dreieck zeigen - die Markerierung, dass der eine Fortsetzung ist :

Das ist jetzt gefixt. Die Rahmen werden automatisch der ersten Fortsetzungsgruppe zugeordnet.

Erklärung

Und wieso entstand dadurch Weiss-Raum? Ganz einfach - vor dem Aufräumen werden Rahmen, die eine Fortsetzung haben, wieder auf ihre Grösse, wie sie im Template definiert ist, zurückgesetzt. Das funktioniert auch. Aber die Position des zusätzlichen Rahmens ändert sich natürlich dadurch nicht. Das Produkt wird also gar nicht kleiner - und der Zielplatz im Seitenelement muss nur geringfügig kleiner sein, damit das Produkt nicht passt.

server::get_placeholders erzeugt einen XML-Export der Platzhalter eines Dokumentes. Für Textplatzhalter wird dabei deren Position und Fläche ausgegeben :

• node psc:placeholderlist.placeholders.placeholder.frames.frame.bbox.rect
• node psc:placeholderlist.placeholders.placeholder.frames.frame.area.polygon

Platzhalter, die in den Initialen eines Absatzes beginnen, bekommen dabei falsche Y-Koordinaten. Die Y-Positionen liegen immer bei der vorletzten Zeile der Höhe der Initialen.

Mit so was kann mal sich mal locker einen Tag beschäftigen. Die Höhe stimmt jetzt auch in Initialen.

server::get_placeholders erzeugt einen XML-Export der Platzhalter eines Dokumentes. Für Textplatzhalter wird dabei deren Position und Fläche ausgegeben :

• node psc:placeholderlist.placeholders.placeholder.frames.frame.bbox.rect
• node psc:placeholderlist.placeholders.placeholder.frames.frame.area.polygon

Platzhalter, die teilweise im Übersatz liegen, enthalten dabei widersprüchliche Angaben : In bbox steht der umgebende Textrahmen aber mit Breite 0.000. Im Polygon steht die Beschreibung der sichtbaren Fläche.

In bbox steht jetzt die Bounding-Box der sichtbaren Fläche des Platzhalters.

server::get_placeholders erzeugt einen XML-Export der Platzhalter eines Dokumentes. Für Textplatzhalter wird dabei deren Position und Fläche ausgegeben :

• node psc:placeholderlist.placeholders.placeholder.frames.frame.bbox.rect
• node psc:placeholderlist.placeholders.placeholder.frames.frame.area.polygon

Liegt der Platzhalter vollständig im Übersatz, hat er ja eigentlich keine Fläche mehr. Trotzdem stehen in den Exporten Werte drin.

Ich habe das geändert. In den Koordinaten-Angaben von Platzhaltern, die VOLLSTäNDIG im Übersatz liegen, stehen jetzt überall Nullen (0.0000).

Seitennummern werden zwar jetzt richtig ersetzt. Die eingestellten Nummerierungs- und Abschnittsoptionen werden dabei aber leider ignoriert.

Auch das geht jetzt.

Bewegt man eine Cometgruppe mit app.comet.cometGroupMoveTo von einem Spread auf einen anderen, werden dabei die Cometgruppen zerstört bzw. verändert.

Der Fehler ist gefixt.

Für Bilder, die komplexere Freistellpfade haben, dauert die Berechnung der Fläche mit frame::get_visible_area sehr lange. Wir haben hier ein Bild, bei dem dauert die Berechnung etwa 3 1/2 Minuten.

Lässt man sich mit dem Javascript-Befehl app.comet.getCometGroups die Cometgruppen eines Dokumentes ausgeben und verwendet dabei die Option size-useclips:true dauert dann natürlich auch dieser Befehl entsprechend länger.

Testscript :

var gOptions 	= app.comet.ping() + ";-1;";
var gDocument 	= "/Users/paul/Desktop/testCS55.indd"

app.comet.documentOpen(gDocument, true, gOptions);
var groupXml = new XML(app.comet.getCometGroups(
	gDocument,
	Scope.PAGE,
	1,
	'',
	gOptions +
	"calc-sizes:true;size-checkmargins:true;"));

var xmlGroups = groupXml.descendants('group');
// app.comet.documentClose(gDocument, gOptions);

var pt2mm = 1.0;

function rnd (str)
{
return parseFloat (str)*pt2mm*pt2mm;
}

for(var i = 0; i < xmlGroups.length(); i++)
{
	var xmlGroup = xmlGroups.length() == 1 
			? xmlGroups
			: xmlGroups.child(i);

	alert('Fläche (sichtbar / gesamt)\t: '
			+ rnd (xmlGroup.attribute('visible-size-absolute'))
			+ "\t\t/ " + rnd (xmlGroup.attribute('size-absolute')));
}

Der Freistellpfad des Bildes im Testdokument besteht aus 125 Einzelpfaden mit jeweils bis zu 1740 Stützpunkten. Die Flächenberechnung wird (mal ganz grob gesprochen) in drei Schritten gemacht :

1. Jeder der Einzelpfade des Freistellpfades muss in ein genügend nahes Polygon umgewandelt werden. Es ergeben sich die Polygone p₁, ..., p_n.
2. Bestimmen der Schnittmenge ps der Polygone p₁, ..., p_n. Das ist natürlich keine zusammenhängende Fläche, sondern ein Gebilde, das wieder aus vielen Polygonen p_s1, ..., p_sm besteht.
3. Berechnen der Flächen von p_s1, ..., p_sm. Die Summe dieser Flächen ergibt dann die Bildfläche.

Das sind genügend komplexe und insbesondere viele Rechenschritte, um selbst einen sehr schnellen Prozessor eine ganze Weile zu beschäftigen.

Ich habe das Ganze mal etwas näher untersucht und festgestellt, dass die Hauptrechenzeit für Schritt zwei benötigt wird. Und dass man diese Rechenzeit extrem verkürzen kann, wenn man die Polygone in Schritt 1 etwas großzügiger annähert. Und unter der Annahme, dass genügend komplexe Flächen (mehr als 20 Stützpunkte) im Durchschnitt gleich viele konvexe und konkave Randstücke haben, heben sich die Fehler bei der Annäherung durch Polygone nahezu auf.

Damit konnte ich die Rechenzeit von 220 Sekunden auf etwa 1 Sekunde drücken.

ACHTUNG : Rahmenüberdeckungen führen zu einem exponentiellen Anwachsen des Rechenaufwandes. Linearer Aufwandsanstieg wäre möglich, aber aufwendig zu realisieren. Wir würden das als Feature-Request (erste Schätzung 5 Tage) ansehen.

Alle & in der Produktrecherche werden verschluckt. Wenn ich die im Panelstatement verdopple: SELECT a.ID, ... REPLACE(a.Name, '&', '&&'), ... geht's. Alles andere (&amp;, <0x0026>, auch ein CAST zu varchar(max)) bringt nix.

Comet 3.3, CS5, Rev 3000 auf nem Mac. Verbindet sich mit SQL Server 2005, über OpenLink-Teriber, Unicode, login Unicode. Datentyp der Spalte nvarchar.

Bis einschliesslich CS3 hat Adobe das &-Zeichen in Textfeldern als Unterstreichungs-Markierung verwendet (die aber offenbar auch nicht funktioniert hat). Ab CS4 ist dieses etwas merkwürdige Verhalten geändert worden. Bei den dazu nötigen fast 200 Anpassungen im Comet-Quelltext habe ich an einer Stelle (nämlich der ersten Spalte der Produktrecherche) einen kleinen Fehler gemacht.

Das Problem ist gefixt.

Nach einer Weile Arbeit mit der Aufgaben-Palette friert InDesign® beim öffnen eines neuen Dokumentes ein.

1. Aufgabenpalette öffnen in den Vordergrund holen, und die Optionen=> Platzhalter, Liste anpassen, Übersatz prüfen und Gesperrte Ebene überprüfen aktivieren
2. Seite öffnen(dadurch das die Aufgabenpalette aktiv ist werden die Überlauf-Fehler auch gleich angezeigt)
3. Doppelklick auf einen Eintrag in der Aufgabenpalette damit ins Dokument zu den Platzhalter gesprungen wird
4. Seite schliessen
5. Seite wieder öffnen(Ich bin immer über den InDesign® Menü-Punkt "Zuletzt verwendete Datei öffnen" gegangen)

Nach der 6-ten Wiederholung habe ich dann unser altes Problem wieder das InDesign® einfriert und ein Prozessor auf 100% läuft. Das ganze habe ich auf 2 Rechnern bei uns im Haus getestet mit den Versionen 3.3 R2840 und R3000.

Wenn ich allerdings den Schritt 3 überspringe und die Überlauf-Fehler ignoriere tritt das Problem nicht auf dann kann ich die Seite auch ohne Probleme öfters öffnen(nach den 50 mal abgebrochen).

Der Fehler ist gefixt.

FYI : Das Problem ist immer dann aufgetreten, wenn man zu Textplatzhaltern springen wollte und der Text hat Tabellen enthalten. Springen zu Rahmen und springen zu Textplatzhaltern in Texten ohne Tabelle(n) war okay.

Bei einem Produktaufbau werden bei einigen Produkte nicht alle Rahmen des Produktes zu einer Cometgruppe zusammengefügt. In "Produkte des Dokumentes" erscheinen dann mehrere Einträge des Produktes (und spätestens beim Aufräumen passieren dann böse Dinge).

Ich habe versucht, die Produktrahmen manuell zu einer Cometgruppe zusammenzufügen. Das geht auch nicht. Der Rahmen, der vorher nicht in der Cometgruppe war, geht auch manuell nicht hinzuzufügen.

Auffällig daran ist : Das passiert immer dann, wenn man Rahmenketten hat, bei denen einige Rahmen keinen Text anzeigen können (weil sie zu klein für die Schrift oder das Wort sind oder so flach, dass ein Tabellenheader gleich in den nächsten Rahmen geschoben wird (siehe Anlage 1) : Immer nur der erste Rahmen, der den Text anzeigen KöNNTE (wenn er nicht zu klein wäre), kann zur Cometgruppe hinzugefügt werden, die folgenden Rahmen bis einschlisslich dem Rahmen, in dem der Text oder die Tabelle dann erscheinen, können nicht zur Cometgruppe hinzugefügt werden.

Und hier die Erklärung : Beim Erzeugen/Erweitern von Cometgruppen müssen immer erst alle Rahmenhierarchien aufgelöst werden (Weil InDesign®-Gruppen nicht Mitglieder von Cometgruppen sein können.) Dazu wird rekursiv in die Rahmenstruktur eingetaucht. Unglücklicherweise trifft man dabei aber auf ähnlich ungeeignete Objekte wie die InDesign®-Gruppen, z.B. auf Textspalten. Interessiert ist man am Textrahmen, nicht an der Spalte. Deshalb wird die Spalte nach der ersten Textposition gefragt, die sie anzeigt - dann kann man sich den dazugehörigen Textrahmen holen. Könnte man - in dem oben beschriebenen Fall wären das aber mind. ZWEI Rahmen und den zweiten erhält man also nie.

Viele Wege führen nach Rom. Und mind. zwei von der Textspalte zum Textrahmen. Der Fehler ist gefixt.

Hotfix

25.05.2012

Muss der Produktaufbau von einer linken auf eine rechte Seite wechseln, wird er mit dem Fehler -11100 abgebrochen :

#    Die Seite 3 konnte nicht erzeugt oder neu eingefügt werden.
#    
#    Unbekannter Fehler -111000
#    
#    9. Produkt, ID = [1, 108, 2, '182|11453']
#    
#    Das Template ist zu groß für das Seitenelement gewesen.
#    Es wurde aber kein weiteres Seitenelement mehr gefunden.

Das Problem ist wieder behoben.

Man nehme 3 Produkte, lasse sie aufbauen und zwar so, dass das zweite Produkt aufgetrennt und auf der nächsten Seite fortgesetzt wird.

    A
    B-B
    C

Man schiebe Produkt C über Produkt B und reorganisiere. B landet dann auf der zweiten Seite, aber der Tabellenplatzhalter wird nicht mehr geladen!?

Dass Problem tritt nur dann auf, wenn der Rahmen, der fortgesetzt wird, direkt mit einer Tabelle beginnt, die (will man ja so) in der Fortsetzung weiter geht. Die InDesign®-API-Funktion, die berechnet, welcher Rahmen einer Textkette welche Textposition enthält, gibt hier die (falsche) Antwort, es sei der Rahmen der Fortsetzung.

In textmodel::get_frame_containing hatte ich das bemerkt und extra behandelt. Beim Produktaufbau nicht. Jetzt gehts.

Palettenskripten können bei ihrer Definition in actions Shortcuts zugewiesen werden. Manchmal funktionieren die aber nicht auf Anhieb. Wenn man das Menü, das die Einträge enthält, einmal aufklappt, funktionieren die Shortcuts.

Das Problem ist sehr einfach zu beschreiben :

1. Die Shortcuts benötigen die Menüs
2. Die Menüs benötigen die Datenverbindung
3. Die Datenverbindung benötigt die Menüs

Aber ärgerlich ist es trotzdem irgendwie. Ich hab deshalb ein bisschen in die C++-Trickkiste gegriffen (also eigentlich ziemlich tief) und konnte das Problem entscheidend verbessern : Ist beim Start von InDesign® mindestens eine der Paletten Produktrecherche oder Front Row geöffnet (nicht unbedingt sichtbar), funktioniert alles auf Anhieb. Ist keine dieser Paletten offen, funktioniert es, nachdem eine der Palette geöffnet wurde.

ACHTUNG : Das geht aktuell nur für Palettenskripte der Produktrecherche (classid 3). Aber wer benutzt schon andere?

Welche Shortcuts können nicht verwendet werden?

• Bereits von InDesign® belegte Shortcuts können nicht überschrieben werden.
• Viele der Funktionstasten sind vom Betriebssystem belegt.
• Shift+Ctrl+Buchstabe u.ä. funktionieren natürlich nicht, wenn eine Texteingabe aktiv ist (InDesign®-Dokument oder Paletten-Controls)
• Der Modifier Opt (die Alt-Taste) wird i.d.R. verwendet, um Skripte zu editieren. Wenn Sie diesen Modifier verweden, werden Sie also immer der Skripteditior sehen (oder eine Warnung, dass Sie zum Editieren der Skripte eine Partner-Lizenz benötigen.)

Alle anderen Seiten des Dokumentes bekommen die gleiche Grösse wie die erste Seite. Könnte man das nicht auch so machen, dass man eine andere Seite als Basis nehmen kann?

Die Funktion page::crop hat jetzt einen weiteren Parameter : die Seite.

Bis CS4 kann man natürlich nur einheitliche Seitengrössen verwenden. Die wird aber jetzt aus den Rahmen der angegebenen Seite ermittelt und gesetzt.

Ab CS5 wird AUSSCHIESSLICH die Grösse der angegebenen Seite verändert. Alle anderen Seiten bleiben (bis auf die in Bug 2883 beschriebene Ausnahme mit dem Anschnitt) unverändert. Mit der Angabe von -1 werden alle Dokumentseiten, die mind. einen Rahmen haben, an ihren Inhalt angepasst.

Zusätzlich hat die Funktion noch den weiteren Parameter keepMargins (Default 1). Ist der 0, werden bei allen Seiten, die angepasst werden, die Anschnitte auf (0, 0, 0, 0) gesetzt - und die Seiten dann entsprechend kleiner.entes bekommen die gleiche Grösse wie die erste Seite. Könnte man das nicht auch so machen, dass man eine andere Seite als Basis nehmen kann?

page::crop soll ja die erste Dokumentseite so verkleinern, dass sie genau um die Seitenrahmen passt. Das klappt auch sehr gut.

Leider meldet InDesign® ab sehr kleinen Rahmen den Fehler, dass die gewünschte Seitengrösse im Bereich 1-15552 Punkte sein muss - was sie ja eigentlich wäre.

Der Fehler tritt dann auf, wenn der Seitenanschnitt kleiner als der Seitenanschnitt der zugehörigen Musterseite ist.

Beispiel

Die Seite hat oben und unten einen Beschnitt von 10 mm und einen Rahmen von 4 mm, müsste dann also 24 mm hoch werden. ABER die zugehörige Musterseite hat einen Beschnitt von jeweils 12,7 mm. Die Musterseite erlaubt der Seite also als Minimalhöhe 25,4 mm (plus 1 Punkt). Und so gesehen ist die Fehlermeldung richtig, die eigentliche Seitehhöhe wäre dann kleiner als 1 Punkt.

Lösung

Missliches Problem. Es wird jetzt dadurch gelöst, dass, wenn nötig, der Musterseitenanschnitt auf (0, 0, 0, 0) gesetzt wird. Dann geht natürlich alles wieder (mit der kleinen Einschränkung, dass alle Seiten, die ihren Anschnitt aus der Musterseite nehmen, dann auch keinen Anschnitt mehr haben. Das kann man verhindern, indem zuvor auf alle Seiten ein page::set_margins gemacht wird.)

Öffne ich ein Dokument so, klappt die Abfrage auf die Anzahl der Seiten :

    doc = document::open(BaseFile, doc, 1.0, 0, 0, 0, 0, 1, 1, kSuppressUI);

öffne ich es ohne die zusätzlichen Parameter, funktioniert alles :

    doc = document::open(BaseFile, doc); 

Dummerweise ist die lange Parameterliste oben jedoch laut Doku der default und sollte somit das gleiche bewirken?

Ja, ein kleiner Fehler in den Plugins. Es wird nur geprüft, ob die Default-Parameter da sind oder nicht, aber nicht deren Wert. Die vier Nullen (0, 0, 0, 0) geben aber die Grösse das Dokument-Fensters an - in diesem Fall also eine unsinnige Grösse.

Der gleiche Fehler tritt auch bei document::open_copy und document::create auf.

Die Angaben zur Fenstergrösse werden jetzt nur verwendet, wenn das Fenster eine Höhe und Breite grösser 0 hat. Damit ist der Fehler gefixt.

Hat man ein Dokument mit verschiedenem Anschnitt für links und rechts gibt page::get_margins bei linken Seiten die Werte für linken und rechten Beschnitt falsch zurück : Die Variable für den linken Beschnitt gibt den rechten Beschnitt zurück und umgekehrt.

Analog verhält sich page::set_margins : Der Wert des neuen linken Beschnitts wird rechts gesetzt und umgekehrt.

Das Ganze passiert nur linken Seiten. Rechte Seiten, innere Seiten und Seiten von Spreads mit nur einer Seite werden richtig behandelt.

Das Verhalten ist einfach erklärt : Bei doppelseitigen Spreads sind die Beschnittangaben nicht der Abstand von der linken/rechten Seitenkante sondern der Abstand von der inneren bzw. äußeren Seitenkante. Ich habe das in der Doku korrigiert.

Zusätzlich haben beide Funktionen einen neuen optionalen Parameter, mit dem gesteuert werden kann, ob man das alte Verhalten (innen bzw. links und rechts bzw. außen) haben will, oder ob man tatsächlich den Abstand von der linken bzw. rechten Seitenkante meint.

Hotfix

25.05.2012

Kann man in der Preview-Palette für lange Texte nicht solche gelben Hilfezettel mit dem vollständigen Text machen?

Man kann. Die Texte der Previewpalette haben jetzt gelbe Zettel mit dem vollständigen Text (oder jeweils soviel Text, wie die gelben Zettel anzeigen können).

Könnten wir nicht die Zeichensatz-Einstellung "UTF-8" zum Default des Login-Dialoges machen (statt Systemzeichensatz)?

Das ist jetzt so.

Wenn ich den InDesign®-Server mit sudo starte, kommt eine Fehlermeldung über die Rechte des iorfiles:

    Wed Jul 20 07:11:33 2011 WARN    [server] WARNING!
        Please check file permissions for '/var/comet/ids1.ior'.
        Most probably you cannot use this file as a corba communication endpoint.

Auch wenn ich die Datei lösche, wird sie vom Cometen mit anscheinend seltsamen Rechten wieder angelegt.

Funktioniert trotzdem, könnte aber Hasenherzige verunsichern...

Startparameter:

    sudo ./InDesignServer
        -iorfile /var/comet/ids1.ior
        -cometlog /var/comet/log/comet1.log
        -cometcache /var/comet/cache1/
        -cometapilog /var/comet/log/api1.log
        -previews

Das Problem scheinen nicht die Permissions der Datei zu sein sondern die eines Ordners des angegebenen Pfades. Wie auch immer, ich habe die Fehlermeldung jetzt anders gestaltet : Ich schreibe (irgend)etwas in die Datei. Wenn das gut geht, kommt keine Meldung, geht das schief, wird die Meldung gezeigt.

Etwas später überschreibt das Plugin "Corba Support" die Datei mit den aktuellen Werten und gibt darüber Auskunft im Terminal-Fenster :

• erfolgreich : Writing IOR to 'your ior'
• Fehler : Cannot open IOR file 'your ior' for writing, check permissions. Und erst bei diesem Fehler muss man was tun.

Wenn man PDFs platziert, so hat man im InDesign® ja die Wahl, welche PDF-Box als Beschnittrahmen herangezogen wird. (Objekt-Box, Medien-Box, Trim-Box etc.).Soweit schon mal nichts schlimmes. Problematisch ist, dass InDesign® sich die zuletzt ausgewählte Import-Methode merkt und von nun an immer wieder auf die gleiche Art importiert. (Leider merkt ID sich das als Programmvorgabe und nicht als Einstellung im Musterdokument.)

Jetzt führt das zu sehr netten Sideeffekts:

1. Am Montag mache ich eine Comet-Ausleitung -> alles ist gut.
2. Am Dienstag platziere ich irgend ein PDF mit anderen Importoptionen manuell für irgend was anderes -> auch gut.
3. Am Mittwoch leite ich den Kram vom Montag nochmal aus und alle PDFs stehen anders in den Frames.

Was ist passiert? Montag hatte ich noch die Importoption zum Beschnitt auf das Objekt stehen und ab Dienstag steht die Voreinstellung auf "Beschnittrahmen".

Das ist natürlich tödlich und man sucht sich schon mal den Wolf, um den Fehler zu finden.

Kann man irgendeine Möglichkeit schaffen, die PDF-Importoptionen in C-Script direkt beim Import als Parameter festzunageln, damit ein PDF immer gleich platziert wird?

Es gibt einen neuen Befehl :

    frame::place_pdf_with_crop

Dort kann die Art des Beschnitts angegeben werden. Der Befehl ist exakt wir frame::place_pdf mit dem neuen sechsten Parameter cropTo. (Ein neuer Befehl war nötig, weil frame::place_pdf eine beliebige Anzahl von Parameter hat und die Parameter-Liste deshalb nicht erweitern werden kann.)

Bei einem XML-Projekt dauert es neuerdings recht lange, wenn man von einer beliebigen Palette in die Produktrecherche wechselt. Während der Wartezeit (können durchaus bus zu 5s sein) ist die CPU-Last bei 100%.

Es lag nicht an einer neueren Version der Plugins, es lag an der großen Anzahl von Templates : Wenn die Palette sichtbar wird, muss das Popup mit den Templates neu aufgebaut werden. Das ist etwas aufwendig (z.B. werden bei Templates mit gleichem Namen die IDs an den Namen angefügt.) aber geht nach ein bisschen Optimierung jetzt ganz schnell.

In manchen Produkten wird in der productlist die preRule auf kNewPage gesetzt. Wenn die Liste mti pageTemplates aufgebaut wird dann auch eine neue Seite erzeugt, wenn das Produkt aber so groß ist, das es durch den Umbruch sowieso auf eine neue Seite gesetzt wird, wird nochmal eine Seite erzeugt. Das heisst ich habe eine leere Seite zwischen den Produkten.

Statt der preRuleID, die Comet 2.1 ist, sollte in die Produktliste ein weiterer Eintrag eingefügt werden, der vom Produkt-Typ Pagetemplate (=4) ist, dann wird das funktionieren.

Hier ein kleines Beispiel :

int  	stPageTemplateID	= ?;
int  	stNewPageType		= ?;        // 0 links, 1 beliebig, 2 rechts

int main ()
{
	ProductList            pl        = productlist::get ("selected");
	int                    result;
	Product                p;
	Product                q;
	int                    i;

	for (i = 0; i < productlist::length (pl); i++)
	{
		p = productlist::get (pl, i);
		if (Hier Bedingung einfügen)
		{
			q = product::alloc (kScriptStack);

			product::set (q, kProductType, 		4);
			product::set (q, kID,				stPageTemplateID);
			product::set (q, kProductPageType,	stNewPageType); 

			productlist::insert (pl, q, i, 1);
			i = i + 1;
		}
	}

	result = productlist::establish (
		pl,
		0,                		// front document
		-1,                		// current page
		"",        				// front layer
		stPageTemplateID,    	// page template
		0,         				// default page item
		kShowProgress,         	// + kPreferDefaultPageItem
		0,           			// pre script
		0,         				// no single sequences
		"",      				// sequence name not used
		0                		// errmess
		);

		productlist::release (pl, 1);
		
		return 0;
}

Meine Liste der Produkte des Dokumentes enthält Seitentemplate-Einträge mit der ID 0. Damit geht dann natürlich die Reorganisation nicht.

Der Fehler ist gefixt. In diesem Fall wird, wenn verfügbar, das aktuell in der Seite gesetzte Seitentemplate verwendet (und nicht das in den Produkten hinterlegte).

FYI : Das war gar kein Fehler. Das Ding hat nur genau gemacht, was es sollte : Nämlich die Produkte des Dokumentes und die in den Produkten hinterlegten Seitentemplates sammeln. Die Produkte hatten aber überhaupt keine Info über ein Seitentemplate. Das ist immer dann so, wenn Produkte manuell (also nicht über den Seitenaufbau) platziert werden - also eigentlich ziemlich häufig.

Dass trotzdem oft ein gültiges Seitentemplate in der Liste auftauchte, lag an einem - und jetzt wirklich - Fehler in den Plugins : Spätestens, wenn ein Template eingesetzt wird, sollten dort die Seitentemplate-Infos entfernt werden. Das wurde bisher nicht gemacht. Und da man meist mit den gleichen Seitentemplates arbeitet, sah alles irgendwie richtig aus, war es aber nicht.

Die Reihenfolge, in der eine Tabellenzelle neue Spalten und Zeilen anlegt, scheint intern festgelegt zu sein : Zuerst werden die Spalten aufgebaut, dann die Zeilen. Leider kann es passieren, dass man mit dieser Reihenfolge nicht zurecht kommt. Dann müssen erst die Zeilen und danach die Spalten generiert werden, weil erst aus den Zeilen hervorgeht, welche Spalten benötigt werden.

Im ersten Block der Palette "Tabellenmodul" (das ist der Block "Spalte kopieren") ist jetzt ein kleiner blauer Pfeil. Damit können die Blöcke "Spalte kopieren" und "Zeile kopieren" vertauscht werden. Diese Reihenfolge wird dann beim Aufbau der Tabelle verwendet.

Kleines Achtung : Der blaue Pfeil ist nicht sichtbar, wenn einer der Blöcke geschlossen ist.

Produkte sollen in der Reihenfolge

    1 | 2
    3 | 4

auf einem Spread platziert werden. Geht das mit Seitentemplates?

Ja, das geht mit Einschränkungen. Dazu steht jetzt folg. in der Doku :

Seitentemplates können über einen ganzen Spread gehen. Wählen Sie dazu den Seitentyp Druckbogen in der Seitenelemente-Palette.

Für Spread-Templates gelten folgende Einschränkungen :

• Es werden nur zweiseitige Spreads unterstützt.
• Der Seitenaufbau muss auf einer linken Seite beginnen.
• Elemente mit mehreren Produkten (1:N-Elemente) werden nicht unterstützt.
• Zur Zeit können keine Fortsetzungstemplates verwendet werden.

Hat mein ein Seitentemplate vom Typ "Doppelseite", werden in Seiten, die mit diesem Seitentemplate verknüpft sind, keine Elemente im Hintergrund gezeigt (Menü "Seitentemplate zeigen").

Das ist gefixt. Die Elemente werden jetzt gezeigt.

Wenn man (aus Versehen) eine Gruppe statt eines Bildes in der Gruppe selektiert hat und dann auf den orangenen Pfeil der Previewpalette klickt, um das Bild zuzuweisen, stürzt InDesign® ab. Es sollte statt dessen eine Fehlermeldung oder ein Hinweis kommen.

Bei dem Versuch, einer InDesign®-Gruppe ein Bild zuzuweisen, erscheint jetzt eine Warnung.

Ich habe ein Produkt als InDesign®-Gruppe aufgebaut. Wähle ich diese Gruppe aus, um sie mit Shift-Klick in ein Produkt mit einem anderen Produkt zu verlinken, werden nicht alle Unterrahmen neu verlinkt.

Man sieht den Effekt auch daran, dass in der Produktrecherche danach ZWEI Einträge ausgewählt sind, das alte UND das neue Produkt.

Merkwürdig daran ist, dass trotzdem alle Inhalte und Bilder richtig verknüpft und geladen werden.

Ja, das "Problem" tritt nur bei Rahmen auf, die keinen Platzhalter gesetzt haben. Wird so ein Rahmen ausgewählt, kann die Produktrecherche meist trotzdem das zugehörige Produkt auswählen - es wird einfach statt der Platzhalter-Info des Rahmens dessen Aufbau-Info ausgewertet. Und genau diese Info wurde bei Unterrahmen von InDesign®-Gruppen bisher nicht aktualisiert, wenn das Produkt neu verlinkt wurde.

Der Fehler wäre ein reines Anzeige-Problem, wenn diese Info nicht auch bei Seitenreorganisationen verwendet werden würde.

Das Problem ist jetzt gefixt.

1:N-Seitenelemente, die ihren Inhalt spaltenweise anordnen sollen, machen das auch sehr schön und richtig. Leider werden die aufgebauten Produkte aber in der Palette "Produkte des Dokumentes" in falscher Reihenfolge gezeigt (nämlich zeilenweise). Was dann natürlich zu Fehlern bei der Reorganisation führt.

Der Fehler ist gefixt.

Wenn durch den merge-Aufruf eine Zelle aus dem Tabellenkopf mit einer aus dem Tabellenkörper verbunden werden soll, dann stürzt InDesign® einfach ab.

Wäre schön, wenn das geprüft werden könnte und die Methode dann einen Fehlercode zurückgibt.

table::merge testet jetzt, ob die Bereiche ganz innerhalb der Kopf-, Körper-, oder Fusszeilen der Tabelle liegen. Ist das nicht der Fall wird der Fehler tableTextModelErr (= 3) zurückgegeben.

Rahmen die mit frame::duplicate erzeugt werden, bilden merkwürdige Comet-Untergruppen wenn der Originalrahmen einer Cometgruppe angehört hat.

Die Funktion hat jetzt einen weiteren Parameter mit dem gesteuert werden kann, ob der neue Rahmen automatisch der gleichen Cometgruppe zugewiesen werden soll, zu der auch das Original gehört oder nicht. Wird der Rahmen in ein anderes Dokument dupliziert, geht die Cometgruppen-Zugehörigkeit unabhängig von dieser Einstellung verloren.

Beim Auflösen von Cometgruppen über das Kontextmenü werden nur die Hauptgruppen aufgelöst. Untergruppen bleiben erhalten.

Das Menü

    Kontextmenü > Comet-Gruppen > Auflösen

löst jetzt auch alle Untergruppen auf. Das neue Menü

    Kontextmenü > Comet-Gruppen > Auflösen der Hauptgruppe

löst nur die Hauptgruppe auf.

Das ist in der Doku falsch beschrieben : Nicht die 0 als Seitennummer, sondern die -1 bewirkt, dass der Rahmen auf die gleiche Seite dupliziert wird.

Ich habe zusätzlich geändert, dass ab v3.3 R3005 alle Seitennummern <= 0 den Rahmen auf die gleiche Seite wie das Original duplizieren.

Im gelben Zettel des Reorg-Buttons steht

    ALT : Reorganize the complete document

Das wird aber nicht getan. Es wird offenbar nur die erste Seite aufgeräumt.

Der gelbe Zettel der englischen Version ist leider falsch. Richtig muss es heissen :

• ALT : Reorganize current page only
• SHIFT : Reorganize complete document
• CTRL : (Press key right before releasing the mouse!) Load contents of close friends too
• CMD : Use the page templates stored in the products resp. document pages

Das ist jetzt gefixt.

Wenn ich mit gehaltener Alt-Taste das Aufräumen-Button drücke, werden Produkte verdoppelt.

Ja, das passiert immer dann, wenn auf der aktuellen Seite noch Platz für Produkte ist. Wenn für diese Verschiebung das Template getauscht werden muss, entsteht eine zweite Produktgruppe. Dieses Produkt hat, weil Cometgruppen-IDs aufräum-resistent sein müssen, zudem die gleiche Cometgruppen-ID wie die Originale. Die Originale bleiben im Dokument erhalten, weil deren Seiten gar nicht aufgeräumt werden sollen.

Ein doofes Verhalten. Ich habe das geändert : Jetzt werden beim Aufräumen einer Seite nur noch Produkte aufgeräumt, die auch vorher schon auf dieser Seite lagen.

Nur ne Kleinigkeit, die man aber so nicht erwartet: Wenn ich einen Button für ein Palettenscript in FrontRow anlege, setzt der Befehl "Aktionen und Palettenscripte zurücksetzen" den Cache zwar für das Palettenscript zurück. Ein Klick auf FrontRow führt aber noch immer den alten Stand des Palettenscriptes aus, während der Aufruf über die Produktrecherche den neuen Stand ausführt.

Geht jetzt. Umgedreht hat es schon funktioniert. Das Zurücksetzen-Button muss man dabei nicht anwenden. Die änderung wird direkt beim Sichern im Editor-Fenster gemacht.

Leider funktioniert das Ersetzen von Variablen im Text nicht für Seitennummern und Abschnittsmarken, die mit dem Menü

    Schrift > Sonderzeichen einfügen > Marken

eingefügt werden.

Das geht jetzt. Auch Fussnoten-Nummern werden jetzt richtig weitergegeben.

Final

11.05.2012

Die Dokumentation der Funktion frame::size scheint zu fehlen?

Ist gemacht : frame::size

Fügt man (z.B. mit textmodel::replace) einen TaggedText in Dokument ein, der ausschlieeslich aus Inlines besteht und keinen direkten Text enthält, stürzt InDesign® ab.

Der Fehler ist gefixt.

WORKAROUND : Abschalten der Option "Zusatzmodule > Comet > Platzhalter aus TaggedText anlegen" verhindert den Absturz.

Hotfix

08.05.2012

table::broaden_to_frame verbreitert Tabellen so, dass sie genau die Breite des umgebenden Textrahmens bekommen. Ist die Tabelle aber Untertabelle einer anderen Tabelle, ist das ja nicht richtig. In diesem Fall sollte die Tabelle eigentlich auf die Breite der umgebenden Zelle gebraicht werden, oder?

Eine Funktion table::broaden_to_cell oder so ist dafür nicht nötig. table::broaden_to_frame schaut jetzt, ob die Tabelle eine Untertabelle einer anderen Tabelle ist. Ist das so, wird statt des Textrahmens die Tabellenzelle (minus den Zell-Inset) als Begrenzung verwendet. Damit ist das Problem gelöst.

Hier ein Beispielskript. Die Schleife über die Tabellen funktioniert, weil die Tabellen für table::get nach ihren Textpositionen sortiert sind :

int main ()
{
	Table		T		= table::alloc ();
	int			t		= 0;
	
	for (t = 0; t < table::count (gFrame); t++)
	{
		table::get (T, gFrame, t);
		table::broaden_to_frame (T, -1);
	}
	
	return 0;
}

Bug 2849 - frame:: remove_masteritem_override führt zum Absturz

Der Fehler ist gefix, Beschreibung siehe Kommentar 42 von Bug 2733 (oder hier eine Zeile weiter unten).

Der Aufbau stürzt immer noch in dem Moment ab, in dem eine neue Seite generiert werden soll.

Ja, leider. Ich kann es reproduzieren. Der Unterschied zwischen meinem bisherigen Test und dem aktuellen Test ist : Bisher hatte ich auf Seite 1 mit dem Aufbau begonnen. Das funktioniert. Beginnt man den Aufbau auf Seite 2 - Crash.

Ich hab den Fehler gefunden!

Es ist das gleiche Problem wie in Bug 2829 : Ein Funktion der InDesign®-API benötigt eine Rahmenreferenz. Aber der Aufruf der Funktion will eine LISTE von Rahmenreferenzen - und von der dann die ADRESSE. Ist ja machbar :

    api_function (&UIDList (frameRef));

Das wirklich Hinterhältige ist : Adobe löscht die übergebene Liste am Ende der Funktion. Das ist natürlich mit dem obigen Aufruf fatal. Er muss so lauten :

    api_function (new UIDList (frameRef));

Bei Bug 2829 war (zwar versteckt, aber vorhanden) ein Hinweis in den API-Headern. Bei der hier verwendeten Funktion ist noch nicht mal beschrieben, welche Daten der interne Aufruf überhaupt braucht. Na gut, jetzt gehts jedenfalls.

Ich hab das "Critical" gestellt, weil die fehlerhafte Stelle bei jeder neuen Seite des Produktaufbaus aufgerufen wird, also ziemlich häufig. Ein Wunder, dass der Fehler nicht häufiger zugeschlagen hat. So ist das halt mit Fehler, die den Arbeitsspeicher kaputt schreiben.

Es ist sicher nicht schwer, ein Skript zu machen, das Textübersatz durch anlegen weiterer Rahmen auf neuen Seiten beseitigt. Schwieriger wird es aber, wenn ich dafür die Textrahmen des definierten Seitentemplates verwenden will.

Dafür gibt es jetzt die Funktion textmodel::solve_overset. Sie beseitigt den Übersatz jeweils durch Anlegen weiterer Textrahmen und (mglw.) neuen Seiten. Drei Methoden sind verfügbar :

1. Kopiere den letzten Rahmen der Textkette seitenfüllend auf eine neue Seite und verlinke den neuen Rahmen mit der Textkette.
2. Kopiere den letzten Rahmen der Textkette mit gleicher Grösse und Position auf eine neue Seite und verlinke den neuen Rahmen mit der Textkette.
3. Lege neue Textrahmen gemäss dem definierten Seitentemplate an Enthält das Seitentemplate keine Textelemente, bricht die Funktion mit Fehler pageTemplateEmptyErr (= 1271) ab. Ist kein Seitentemplate definiert, wird der Text mit Kopienen des letzten Rahmens der Textkette forgesetzt.

Hotfix

03.05.2012

Offenbar enthält die Skriptvariable gLen einen falschen Wert. gLen hat immer den Wert von gStart.

Der Fehler ist seit Hotfix R2856 (13.04.2012) in den Plugins. Merkwürdig, dass das noch keiner gemerkt hat. Der Fehler ist jetzt gefixt.

Fügt ein Buildhelper-Skript bei Reorganisationen zusätzliche Rahmen ins Dokument ein, werden diese Rahmen von den nachfolgenden Produkten nicht "gesehen" und überlagert. Das tritt nur innerhalb von 1:N-Elementen auf.

Der Fehler ist gefixt.

Mir ist gerade aufgefallen, dass man Platzhalter, die in einem MSO sitzen nur dann aktualisieren kann (Aufgaben-Palette), wenn der entsprechende Status ausgewählt ist. Nehmen wir an, wir haben eine kleine Montageanleitung, also eine MSO mit drei Anleitungsschritten. (Bildplatzhalter + Textplatzhalter)

Wenn sich jetzt im 2. und 3. Objektstatus etwas gegenüber der Datenquelle ändern würde und der Rahmen aktuell nur den 1. Objektstatus aktiv hat, so sieht der Comet die änderung nicht. Das Plugin kennt wahrscheinlich so erstmal keine MSOs und zieht nur den aktiven Status heran.

Gerade noch mal ausprobiert und es funktioniert doch schon! Comet verhält sich genau so, wie ich es mir gewünscht habe.

Allerdings nur bei den klassischen Multistateobjekten. Bei Schaltflächen - die ja durchaus auch per Platzhalter befüllt werden könnten - funktioniert es leider nicht. Zugegeben: Jetzt ist der FeatureRequest um einiges spezieller geworden, aber immer noch nicht abwägig. :-)

Das funktioniert jetzt auch.

Werden mit dem Javascript-Befehl placeTemplate Produkte platziert, werden die Gestaltungsregeln der Templates nicht ausgeführt.

Das war bis R2856 (13.04.2012) okay und ist beim Fix von Bug 2791 passiert. Der Fehler ist korrigiert.

Liegen die Rahmen eines Produktes auf mehreren Seiten eines Spreads, funktioniert der Template-Tausch (Shift-Alt-Klick in das Link-Button der Produktrecherche) nicht. Das Produkt verschwindet einfach.

Auch wenn das Produkt ganz ausserhalb aller Seiten im Arbeitsbereich liegt, kann das Template nicht getauscht werden.

Im Logfile sollte dazu eigentlich eine Nachricht der Form

    # Pageitem 523 will leave the page and cannot insert into the document : 
    # --> Page (left, top, right, bottom) = 0.000000, 0.000000, 595.275574, 841.889771
    # --> Pageitem (left, top) = -68.976379, 337.072845

stehen. Hintergrund ist, dass der Template-Tausch als Unterfunktion des Seitenaufbaus testet, ob ein Produkt (noch) auf die aktuelle Seite passt. Schneidet die Cometgruppe zwei Seiten eines Spreads oder liegt ganz ausserhalb der Seiten, tut sie das nicht.

Das ist natürlich nicht das Verhalten, das man vom Template-Tausch erwartet. Ich habe das deshalb so geändert, dass in diesem Fall die Prüfung gegen die aktuelle Seite entfällt. Damit sollte der Template-Tausch auch in den Grauzonen funktionieren.

ACHTUNG : Als Einfügepunkt wird immer die linke obere Ecke der BoundingBox um die Rahmen der gesamten Cometgruppe verwendet.

Mit der Javascript-Anweisung

    app.comet.getCometGroups

sollen die Cometgruppen der Spreads eines Dokumentes geholt werden. Das klapptin den meisten Fällen, bei einigen Spreads bleibt das Skript aber stehen.

Das sind die Spreads, mit vielen Inhalten. Hier wird ein Ergebis, das grösser als 32kB ist.

Leider ist es so, dass InDesign® abstürzen kann, wenn Funkionen, die über die CORBA-Schnittstelle gerufen werden können, lange Ergebnisse liefern. Wir können da so nichts machen und haben die Ergebnis-Länge deshalb auf 32 kB beschränkt. Sie benutzen die CORBA-Schnittstelle gar nicht? Bei Ihnen könnte der Fehler also gar nicht auftreten? Leider ist es aber zweitens so, dass wir innerhalb der Plugins gar nicht mehr sehen können, woher der Aufruf kam - so dass die Einschränkung also leider für alle InDesign® Server gelten muss.

Lösung

1. Wenn Sie statt Scope.SPREAD Scope.PAGE verwenden, werden die Ausgaben natürlich kleiner. Aber das hilft wahrscheinlich nicht lange.
2. Funktionen wie getCometGroups haben alle den Parameter tmpPath. Der Parameter ist genau für diese Situation gedacht. Sie können hier den Pfad einer temporären Datei angegeben. Ist das Ergebnis länger als 32kB, wird es automatisch in diese Datei geschrieben. Ist das Ergebnis des Aufrufes undefined, muss die XML aus der angegebenen temporären Datei gelesen werden. So machen wir das innerhalb unserer Komponenten.

Zusätzlich kann jetzt die Threashold-Grösse beeinflusst werden.

ACHTUNG : Das sollte nur dann gemacht werden, wenn sichergestellt ist, dass die Aufrufe nicht per CORBA-Schnittstelle weitergegeben werden (wie das z.B. im CometServer gemacht werden muss.).

1. Statt eines Pfades auf eine temp. Datei kann der Parameter tmpPath auch die Angabe threshold=your_local_threshold enthalten. (-1 für beliebige Länge).
2. InDesign® Server kann mit der Option -cometthreshold your_global_threshold (-1 für beliebig) gestartet werden.

Enthält ein Text InDesign®-Variablen, werden diese nicht mit exportiert, wenn man den reinen Text (z.B. mit kExportPlain) exportiert. Statt dessen enthält der exportierte String an der Stelle der Variable ein komisches unsichtbares Zeichen.

Das ist so gesehen auch völlig richtig. Die Variablen werden ja erst zur Render-Zeit berechnet und dann angezeigt. Ihre aktuellen Werte sind NICHT Teil des Textes.

Damit die aktuellen Werte trotzdem mit exportiert werden können, gibt es eine Reihe neuer Exportformate :

kExportPlusPlain
kExportPlusUnitext
kExportPlusXUnitext
kExportPlusXMLUnitext
kExportPlusPlainNoTypografics
kExportPlusHTML

Die ~Plus~-Formate ersetzen Variablen im Text automatisch durch deren aktuelle Werte.

Die Paletten Front row und Produkte des Dokuments zeigen kein Palettenmenü; wenn oben rechts auf das Icon geklickt wird, passiert nichts. Es sollte doch zumindest der About... -Eintrag angezeigt werden, oder?

Die Paletten haben auch keine zuätzlichen Menüs, die hier gezeigt werden müssten. Und das About ist auch nicht InDesign®-Standard. Ich habs trotzdem reingemacht.

Sind das Tage? Dann wären wir in der Tat sehr großzügig. Das sind mehr als 460.000 Jahre.

Ist gefixt.

R2882

Hotfix

25.04.2012

Mit Begeisterung habe ich festgestellt, dass es mit dem Befehl "table::build(T,0,1)" auch möglich ist, selektiv Teile einer Tabelle neu aufzubauen, z.B. nur die Artikel, oder nur die dynamischen Attribute, oder nur die Staffelspalten. Leider scheint in dieser Funktion noch ein Bug zu stecken: beim Neuzeichnen werden die IDs zwar an die Zellen geschrieben, aber nicht an die Platzhalter, so dass die einzelnen neuen Zeilen/Spalten nur den kopierten Inhalt der ersten Zeile/Spalte enthalten.

Ist gefixt.

Aber Achtung

Wie beim vollständigen Aufbau werden auch hier die von der Zelle eingefügten Zeilen u/o Spalten gelöscht und danach neu eingefügt. Danach werden die Cell-IDs neuberechnet und ALLE Zellen der neuen Zeilen/Spalten neu geladen.

Wird bspw. die Zelle [Zeile 2, Spalte 4] neu aufgebaut, werden auch die Zellen [Zeile 2, Spalte 1], [Zeile 2, Spalte 2] und [Zeile 2, Spalte 3] neu geladen.

TIPP

Man kan den teilweisen Aufbau auch in der Palette testen. Dazu die Zelle auswählen, die aufgebaut werden und dann das Aufbau-Button mit gehaltener ALT-Taste drücken.

Beim Aufbau großer Tabellen oder allgemein beim Laden vieler Platzhalt scheint Arbeitsspeicher verloren zu gehen.

Durch die Dokumentänderungen verbraucht InDesign® natürlich selbst schon mal etwas mehr Speicher. Weiterer Speicher wird für die Undos benötigt - alle änderungen können ja wieder rückgängig gemacht werden.

Auffällig ist aber, dass der Speicherverbrauch auch dann nicht wieder (vollständig) zurückgeht, wenn das geänderte Dokument geschlossen wird.

Nach einigen änderungen im Quellcode konnten wir den Speicherverbrauch jetzt drastisch senken.

Die Reorganisation eines Dokumentes wird immer mit der Fehlermeldung :

    Es wurde kein Seitenelement gefunden, dass groß genug für das Produkt ist.

abgebrochen. Die Produkte konnten aber einwandfrei aufgebaut werden. Was geht da schief?

Dieser Fehler tritt immer dann auf, wenn die den Gestaltungsregeln zur Reorganisation eines Textrahmens mit Fortsetzung der Rahmen zu groß gemacht wird - z.B. mit dem allseits beliebten frame::fit. Dann wird dieser Textrahmen mglw. seehr hoch - und passt dann natürlich tatsächlich nicht.

Lösung (projektseitig)

Die entsprechende Regel entfernen. Oder, wenn das nicht möglich ist, die Grössenänderung entfernen. Oder, wenn auch das nicht möglich ist, die Grössenänderung rückgängig machen.

Fakt ist jedenfalls, mit dem Setzen der Eigenschaft "Rahmen fortsetzen" wird die Aufsicht über die Rahmenhöhe an die Reorganistaion übergeben.

Beim Produktaufbau darf die Rahmenhöhe geändert werden. Hier muss sie das u.U. auch - wenn nämlich das Produkt mit Drag and Drop einfach platziert wird (ohne Produktaufbau oder gehaltener Cmd-Taste). In diesem Fall gibt es ja gar keineFortsetzung - und Übersatz soll es auch nicht geben. (Beim ProduktAUFBAU werden Höhenänderungen durch Ladenskripte und/oder Gestaltungsreglen automatisch wieder zurückgesetzt auf die Höhe des Rahmens wie sie im Template definiert ist.)

Lösung (Plug-In-seitig)

Auch bei Reorganisationen werden änderungen der Rahmenhöhe, die in Ladenskripten u/o Gestaltungsregeln gemacht werden, wieder zurückgesetzt auf die im Template definierte Rahmenhöhe.

Nicht alle Rahmen von Fortsetzungstemplates werden beim Produktaufbau geladen. Alle Rahmen, zu denen ein Rahmen gleicher Kennung im Haupttemplate existiert, werden mit einer Meldung wie

    # Suppress loading frame 325, got a promise by label 'B'.

vom Laden ausgeschlossen.

Bis R2842 hat das funktioniert. Releases danach funktionieren nicht mehr richtig.

Ooh Schreck. Das Problem ist behoben.

Die Reorganisation stürzt ab nach der Zeile "# Executing layout rule 'Apply magnets'". Die Meldung mit "... done" kommt nicht mehr.

Der Fehler konnte bei der automatischen Reparatur von Magnetverweisen entstehen und jetzt gefixt.

Unter Windows ist die Hintergrundfarbe der aktuellen Auswahl meist dunkelblau. Den schwarzen Text in der Palette "Gestaltungsregeln" kann man dann praktisch nicht mehr lesen.

Unter Windows wird für die ausgewählten Einträge der Palette "Gestaltungsregeln" jetzt weisse Schrift verwendet.

Unter Windows ist die Hintergrundfarbe der aktuellen Auswahl meist dunkelblau. Den schwarzen Text in der Palette "Template-Verhalten" kann man dann praktisch nicht mehr lesen.

Unter Windows wird für die ausgewählten Einträge der Palette "Template-Verhalten" jetzt weisse Schrift verwendet.

Fügt man (z.B. durch Drag and Drop) neue Produkte in ein 1:N-Seitenelement ein, wird, obwohl man sich ziemlich weit hinten im Dokument befindent, unter Umständen das gesamte Dokument reorganisert. Was geht da vor?

Das Problem besteht darin, dass das Seitenelement mit der Fortsetzung eines Produktes beginnen kann. Diese Rahmen müssen natürlich auch mit aufgeräumt werden. In diesem Fall wird dann rückwärts im nächsten Seitenelement gesucht, ob dieses Element vielleicht mit einem Produkt BEGINNT. Usw., und schnell ist man am Anfang des Dokumentes. Das passiert da.

Natürlich ist das ein bisschen viel Aufwand. Die Rahmen der Fortsetzung können auch ohne Neuladen richtig platziert werden. Für uns ein bisschen aufwendig - für alle anderen jetzt weniger.

ACHTUNG

Das ist eine grössere änderung. Die Fortsetzungsrahmen, mit denen ein Element beginnt, werden jetzt lediglich neu positioniert. Danach wird das Element wie bisher weiter gefüllt bis es voll ist. Danach werden die Produktrahmen im Element justiert, wie es das Element will (linksbündig, zentriert, Keil, ...).

Hier eine kurze Erläuterung von altem und neuem Verfahren :

Grüne Rahmen sind Haupttemplates. Der orange Rahmen ist eine Fortsetzung.

Wird jetzt zwischen beide Produkte ein neues Produkt platziert, geschieht folgendes :

1. (ALT) : Gehe zurück bis einem Seitenelement, das mit einem Produkt beginnt. Im ungünstigsten Fall ist das das erste Seitenelement der ersten Seite. Ab hier wird aufgeräumt. Für Fortsetzungen heisst das : Diese Rahmen werden gelöscht und die Fortsetzungen neu erzeugt.
2. (NEU) :
   1. Platziere den orangen Rahmen links oben im Seitenelement. 
   2. Füge das neue Produkt (mit dem im Seitenelement festgelegten Minimalabstand) ein.
   3. Passt der grüne Rahmen der rechten Seite noch ins Element?
   • Nein : Produktrahmen des Elementes justieren (Hier zentrieren)
   • Ja : Produkt verschieben bis Minimalabstand.
   1. WEITER MIT DER REORGANISATION

Das neue Verfahren ist also mit viel weniger Aufwand zum Laden der Produkte verbunden.

Der Fix von Bug 2733 (2012-02-21 08:16:24) führt jetzt leider unter Windows zum Absturz.

Das ist gefixt.

Macht man einen Produktaufbau der neue Seiten anlegen soll und hat dabei die Option "Bestehende Seiten und Seitentemplates bevorzugen", wird ein falsches Seitentemplate gewählt, wenn

1. der Aufbau einen Seitentemplate-Wechsel enthält
2. und die neue Seite noch kein Seitentemplate hat.

Dann wird für die erste Seite nach dem Seitentemplate-Wechsel immer noch das alte Seitentemplate verwendet. Erst ab der zweiten Seite nach dem Wechsel wird dann das richtige Seitentemplate verwendet.

Alles klar? Wie auch immer, wenn mans braucht ist der Fehler natürlich misslich. Er ist behoben.

Soll die Funktion frame::get_visible_area den Seitenanschnitt ignorieren (das Flag kCheckMargins ist nicht gesetzt), wird bei Rahmen, die über mehrere Seiten eines Spread gehen, eine falsche Fläche berechnet. Es werde immer die Flächenteile der Seite des Rahmens verwendet.

Der Fehler betrifft auch die folg. Funktionen :

    document::get_visible_areas
    frame::get_fill_level
    Die Werte der Elemente size-absolute und size_relative der Placeholder-XML

Der Fehler ist gefixt.

Dokumentreorganisationen stürzen häufig ab. Die letzte Meldung im Logfile :

# Fullfill promise : Copy image of frame x into frame y

Der Fehler tritt nur unter Windows auf. Auf dem Mac wird das selbe Dokument fehlerfrei reorganisiert.

Der Fehler ist gefixt.

FYI

Das Problem wurde durch den fehlerhaften Aufruf einer Funktion der InDesign®-API verursacht. Intern werden dort letztlich alle Dokument-änderungen durch sogenannte Commands ausgeführt. Diese Commands müssen natürlich vorher mit den nötigen Eingaben versorgt werden. Und dabei ist Adobe ziemlich inkonsequent. Rahmen müssen meist, aber nicht immer, über eine Rahmenliste übergeben werden. Die Liste kann manchmal direkt übergeben werden. Manchmal wird aber auch ein Zeiger auf eine Liste gefordert. Und in einigen Fällen (aber wiederum nicht in allen), löscht das Command nach der Ausführung dann diesen Zeiger. Dann ist es natürlich doof, wenn man die ADRESSE einer Liste übergeben hat. Man muss an dieser schon erstmal ein neues Listenobjekt allokieren, das dann weitergegeben wird. Aber das muss man erst mal rausfinden. In der "Doku" zur API steht das selbstverständlich nicht.

R2856

Hotfix

13.04.2012

Der Export von Text im RTF-Format (kExportRTF) funktioniert unter Windows leider nicht.

Der Fehler ist gefixt.

Egal, wie lang der Abschnitt in der Größe auch sein mag: der Parameter liefert immer 1.

Der Fehler ist gefixt.

Ein Palettenskript öffnet ein Dokument und fügt dort einige Rahmen ein. Danach wird das Dokument gesichert und wieder geschlossen. Aber leider sind die änderungen danach nicht im Dokument enthalten.

Das Problem wurde durch den Fix von Bug 2510 ausgelöst und ist jetzt behoben. Das Problem bestand seit v3.3 R2636 (6. Sep 2011) und hat nichts mit der CS-Version zu tun. Es tritt in allen CS-Versionen auf.

FYI

Für Bug 2510 wurden die Aktionen, die ein Palettenskript auslöst in eine sog. CommandSequence eingeschlossen. Die ist dann beim Sichern innerhalb des Skriptes offen und verhindert das Sichern des Dokumentes. Der gleiche Fehler trat auch bei document::close mit automatischem Sichern auf.

Kann ich Rahmenlisten skalieren, drehen und verzerren. Das mit den einzelnen Rahmen ist sehr aufwendig.

Das glaub ich, dass das aufwendig ist. Mit den Befehlen

   itemlist::scale
   itemlist::rotate
   itemlist::skew

dagegen ist es ganz einfach.

Ja, das geht jetzt:

    itemlist::duplicate

Eine Reihe von Funktionen erwarten Parameter, die eine Dokumentreferenz enthalten. Wie bekomme ich denn so eine ohne document::front oder document::current?

Mit

    document::alloc (path)

kann jetzt zu jedem geöffneten Dokument dessen Referenz geholt werden.

Kann man irgendwie rauskriegen, welche Dokumente gerade geöffnet sind?

Mit den neuen Skriptbefehlen

    document::count
    document::get_nth

geht das jetzt.

Es gibt Funktionen zum Drehen, Verschieben, Zerren von Rahmen. Aber zum Skalieren gibt es keine?

Doch gibt es. Nur die Doku hat gefehlt. Ist jetzt gemacht.

Schön wäre es ja, wenn auch Hexzahlen gingen, z.B. val ("0xFF").

Das geht jetzt. Es werden Hex- und Oktalzahlen unterstützt. Hexzahlen werden am führenden "0x" erkannt, Oktalzahlen beginnen mit einer 0. Die Aufrufe

    val ("255");
    val ("0xff");
    val ("0xFF");
    val ("0xFFpaul");
    val ("0377");

geben allesamt den int-Wert 255 zurück.

Lässt man ein Produkt mit Drag and Drop in ein Dokument fallen, werden danach die neu angelegten Produktrahmen ausgewählt. Das funktioniert. Aber wenn das Prudukt Multistate-Objekte enthält, sind statt des Multistates die einzelnen Stati ausgewählt. Wenn man jetzt die Rahmen noch ein wenig verschieben will, schlägt InDesign® Krach.

Der Fehler ist gefixt.

An dem gelben Hilfezettel der Produkte steht, dass beim Drag and Drop bei gehaltener Alt-Taste nur das Template eingefügt wird (und nicht geladen wird.) Das scheint nicht so zu sein. Die Produkte werden auch jedesmal geladen.

Ist gefixt.

Mit den Reader-Plugins kann leider die Sichtbarkeit von Platzhaltern nicht geändert werden - die entsprechenden Menüs fehlen (Kontextmenü, Menü "Ansicht").

Platzhalter sind prinzipiell aber sichtbar. Sie müssen nur vorher in einer Vollversion sichtbar gemacht worden sein, dann sind sie auch im Reader sichtbar.

Der Fehler ist gefixt.

Bei der Action zum Laden der Objekte eines Multiframe-Platzhalters kann man anscheinend nicht die Tags mit dem Hinweis "Nur in Platzhalteraktionen", z.B. "placeholderID" und "modified" verwenden.

Du hast Recht, unter ODBC/SOAP ging es nicht. Das ist gefixt. Ein Hotfix kommt demnächst.

Beim Export der Platzhalter eines Dokumentes mit server::get_placeholders werden die Platzhalter des Dokumentes in eine XML-Struktur geschrieben. In dieser Struktur ist leider keine Information enthalten aus der ersichtlich ist, ob der Platzhalter (ganz oder teilweise) im Übersatz liegt. Diese Information wäre für das Whiteboard aber wichtig.

Die XML-Struktur enthält dazu jetzt das neue Attribut

    psc:placeholderlist.placeholders.placeholder.overset

Das Attribut kann folgende Werte haben

    no
    partiell
    yes

Achtung : Das Attribut ist auch bei Rahmenplatzhaltern definiert und kann auch dort die Werte yes/no haben. Rahmen mit overset="yes" sind auf alle Fälle Inlines (entweder direkt im Text oder in einer Tabellenzelle).

Werden Platzhalter mit server::get_placeholders exportiert, bekommen alle Text-Platzhalter in Rahmen mit einem Textinset falsche X-Koordinaten. Die Koordinaten werden exakt um den Betrag des linken Insets nach links verschoben. Merkwürdigerweise werden die Y-Koordinaten aber nicht ebenfalls um den entsprechenden oberen Inset verschoben.

Es waren sowohl die Boundingboxes als auch die SVG-Koordinaten der Polygone um die Textplatzhalter verschoben. Der Fehler ist gefixt.

Auf (bisher noch) ungeklärte Weise haben Rahmen des Dokumentes Magnete bekommen, die auf den gleichen Rahmen zeigen. Wenn jetzt Magnetabstände aktualisiert werden sollen, stürzt InDesign® ab. Im Logfile erscheinen ganz viele

    # Changing paste board size for move
    #    Frame bbox        (56.694047, 736180.57, 566.93027, 736292.32)
    #    Old paste board bbox    (-1247.2441, -733808.27, 1247.2441, 736078.82)
    #    New paste board size    (2494, 1.47e+06)
    #    New paste board (R)    (-1247.2441, -734031.77, 1247.2441, 736302.32)

Der Fehler ist gefixt.

ACHTUNG : Mglw. handelt es sich bei den fehlerhaften Magneten nicht um zusätzliche Verbindungen sondern um falsch restaurierte bestehende Verbindungen. Die originalen Verbindungen können aus den verfügbaren Daten der Magneten nicht wiederhergestellt werden. Im reparierten Dokument können also Magnetverbindungen fehlen.

ACHTUNG II : Das Problem der fehlerhaften Verbindungen (wenn es denn daran liegt) ist nur zeitaufwendig zu finden und kann erst im nächsten Release (3.3.1) gelöst werden.

Im Whiteboard werden Platzhalter doppelt angezeigt : Einmal an der richtigen Position und einmal um eine Seitenbreite verschoben. Die Platzhalter werden bei der Anzeige mit server::get_placeholders aus dem InDesign®-Dokument exportiert.

Das passiert immer dann, wenn die Rahmen einer Textverkettung über verscheidene Seiten eines Spreads verteilt sind. Dann werden die Platzhalter jeweils einmal pro Seite des Spreads exporiert - und dann im Whiteboard mehrfach angezeigt.

Der Fehler ist gefixt.

Wenn ich eine oder mehrere Aufgaben in der Aufgabenpalette mit einem Auge versehe und dann neu sortiere, bleiben die Augen an ihrem Platz (statt an ihrer Aufgabe).

Lustig. Ist gefixt.

Seit der indesign version 7.0.4 (bei 7.0 war das anders) wird beim aufruf eines absatzformats anstelle der korrekten zuweisung des bereits im dokument vorhandenen formats ein zusätzliches, gleichen namens mit dem zusatz -1 angelegt und zugewiesen. Das maskieren von sonderzeichen in den formatpfaden hat nichts gebracht.

Platzhalter liegt auf textrahmen, "%!TT<Parastyle:ABC><w2...>dummy</w2>..."

Nein, es ist alles okay, Du hast nur zeitgleich an den Importoptionen für Tagged-Text rumgespielt. Mach doch sowas nicht :-)

Wie kann man das wieder retten :

1. Exportiere ein Stück Text als TaggedText in (z.B.) aaa.txt
2. Apfel-D
3. Im Dialog "Importoptionen zeigen" klicken
4. aaa.txt auswählen
5. ! Jetzt kommt der Dialog mit den Import-Optionen. Dort
       Textformatkonflikte lösen mit : Satzdateidefinition
       (Und NICHT : Tag-Dateidefinition)
6. Okay
7. ! Wichtig ! Nochmal Apfel-D
8. Im Dialog "Importoptionen zeigen" wieder ausschalten
9. Auswahl aaa.txt
10. Okay
11. Zweimal Undo
12. Mir Einen ausgeben

Liegt ein Produkt zu nah am rechten und/oder unteren Seitenrand funktioniert leider der Template-Tausch (z.B. mit Shift-Alt-Klick in die ersten Spalte eines Produktes) nicht. Man erhält stattdessen die Fehlermeldung

    # Pageitem N will leave the page and cannot insert into the document

Der Fehler ist gefixt.

Über das Kontext-Menü "Nägel und Magneten" kann man die Option "Rahmennummern anzeigen" einschalten. Fein. Aber wenn ich später mal Undo mache, werden auch diese Rahmennummern wieder ausgeblendet. Ist okay - aber dann wäre es schön, wenn das in EINEM Schritt geschehen würde.

Ist gefixt. Die Anzeige der Rahmennummern kann jetzt in einem Schritt rückgängig gemacht werden.

Ich habe einen Text, der aus vier Inlines besteht, die jeweils durch ein Leerzeichen getrennt sind. Beim Erstellen der Elemente-XML (server::get_elements) stürzt InDesign® wiederholbar und sofort ab. Wenn der Rahmen aus dem Dokument entfernt wird, klappt alles.

Der Fehler ist behoben. (Ein kleiner aber wirkungsvoller Schreibfehler (Achtung Quelltext)) :

    skip = ownedList[i].fAt + ++numFrames;

Hier muss statt des '+' ein Semikolon stehen, schon gehts.

Nach Reorganisationen werden die Notizen des Dokumentes neu zugeordnet. Dabei gilt :

• Gruppennotizen werden an die (mglw.) neue Gruppe gesetzt
• Rahmennotizen, wenn nötig und möglich an den befreundeten Rahmen (Rahmen gleicher Kennung im neuen Template) angehangen

Das funktioniert mit sichtbaren Notizen. In Notizen, die bei der Reorganisation unsichtbar waren, stehen aber falsche Verweise auf Seiten und Spread, wenn sich die zugehörigen Rahmen oder Gruppen verschoben haben oder ausgetauscht wurden.

Nach der Reorganisation werden jetzt für alle Notizen des Dokumentes die RahmenUIDs, Seiten-, und Spread-Angaben aktualisiert. Der Fehler ist damit behoben.

... und zwar einmal als sichtbare Notizen und einmal als unsichtbare Notizen. Versucht man dann, eine der unsichtbaren Notizen sichtbar zu machen, wird dieser Eintrag gelöscht.

Das ist immer dann passiert, wenn das Dokument vor der Reorganisation keine unsichtbaren Notizen enthielt und ist jetzt gefixt.

Wenn ich ein Dokument reorganisiere und ein Produkt muss dabei auf einer neuen Seite platziert werden und benötigt dafür ein anderes Template, können ja die Inhalte befreundeter Rahmen (Rahmen gleicher Kennung in altem und neuem Template) direkt übernommen werden. Das wird aber irgendwie nicht gemacht. Jedenfalls nicht immer.

Ja, und zwar immer dann nicht, wenn man die Palette "Templates" noch nie geöffnet hatte. Hat man die Palette einmal in den Vordergrund geholt, funktioniert alles.

Auch unter InDesign® Server hat es nicht mehr funktioniert, wenn man die Datenbankverbindung geändert hat.

Der Fehler ist gefixt. Die Palette muss jetzt nicht mehr extra geöffnet werden und unter InDesign® Server darf selbstverständlich die Verbindung geändert werden.

Ein Funktion zur Auswahl einer Vorlage wäre schön. Wie haben eine Gestaltungsregel, die so lange neue Seiten platziert wie ein Rahmen einen Übersatz hat. Der Regel muss man mitgeben, welche Vorlage auf den neuen Seiten platziert werden soll und im Moment geben wir dort die ID ein, schön wäre eine grafische Auswahl.

    @LOADLIST templates

Das gibt es jetzt. Alle aktivierten und in der Produktrecherche sichtbaren Templates werden ins Popup eingetragen. Die Einträge haben jeweils die folgende Form :

    ID  | Name

ID und '|' sind dabei durch einen Tabulator getrennt.

Werden die Platzhalter eines Rahmens aktualisiert werden dabei auch die nötigen Magnete ausgeführt. Das ist nötig, weil Ladenskripte und/oder Gestaltungsregeln Rahmengrössen verändern können.

Leider passiert dabei aber etwas Merkwürdiges : Die Magnetabstände werden auf die im Template eingestellten Werte zurückgesetzt. Manuelle Rahmenverschiebungen gehen verloren.

Beispiel

• Rahmen A und B sind mit einem Magneten verbunden und haben de Abstand 10. So wird das dann auch ins Dokument geladen.
• Jetzt wird der Rahmen B (manuell) so verschoben, dass der Abstand zu B 50 beträgt.
• Dann wird A aktualisiert. Dadurch wird leider jetzt auch B wieder auf den Abstand 10 an A gezogen.

Um Magnetabstände wiederherstellen zu können, müssen sie natürlich irgendwo im Rahmen hinterlegt sein. Aus Performance-Gründen werden diese Abstände aber bisher nur in einigen (seltenen) Fällen gesichert (z.B. beim Sichern eines Templates). Manuelle änderungen an den Rahmen "sieht" die Magnet-Wiederherstellung nicht.

Es ist möglich, die Plugins so zu gestalten, dass Geometrie-änderungen automatisch zum Sichern der Magnetabstände führen. Das führt freilich zu neuen Problemen wie folg. Beispiel illustriert :

Template X

• besteht aus den Rahmen A und B
• A und B sind durch einen Magneten verbunden

Einfügen eines Produktes mit Template X

• A wird geladen und macht ein frame::fit
• Dder Magnetabstand zwischen A und B neu berechnet
• Ein nachfolgendes Wiederherstellen des Abstandes zwischen A und B macht nichts mehr. Der Abstand ist ja bereits okay.

Das Einzige, was man machen kann, ist, JEDE Stelle, die den Rahmen durch ein Skript verändern kann (Laden, Aufbau, Gestaltungsregeln, frame::move, ...) zu markieren und die änderungen der Abstände in diesen Fällen nicht zu machen. Das sind ungefähr 50 Stellen. Mit dem automatischen Aktualisieren und den nötigen Notifiern sind das ungefähr 100 Stellen im Quellcode, die angepasst werden müssen.

Lösung

Das ist jetzt gemacht. Manuelle änderungen an Rahmen-Geometrien führen jetzt automatisch zum Sichern der Magnetabstände in den Rahmen. Alle anderen Rahmenänderungen werden an dieser Stelle übergangen.

ACHTUNG

Das betrifft auch Funktionen wie frame::move, frame::resize, ... . Diese änderungen führen nach wie vor NICHT zum Neuberechnen der Magnetabstände. Hintergrund ist folgender :

Produkt P bestehend aus den Rahmen A und B

• Zwischen A und B gibt es einen Magneten

Ein Paletten-Skript macht folg.

• Verschieben von A
• Wiederherstellen der Magnetabstände

In diesem Fall soll natürlich der alte Abstand vor der Rahmenverschiebung verwendet werden.

Damit Rahmenänderungen von Skripten dauerhaft gesichert werden, muss in solchen Situationen einer der neuen Skriptbefehle

    itemlist::store_magnet_distances
    frame::store_magnet_distances

hinterhergeschickt werden.

Hat man in der Produktrecherche oder der Platzhalterpalette einige Augen gesetzt, werden beim Aktualisieren von Platzhaltern im Dokument nur die betroffenen Rahmen- und Textplatzhalter neu geladen.

Danach werden auch die Gestaltungsregeln und Magnete der betroffenen Rahmen ausgeführt. Leider werden aber auch die Gestaltungsregeln und Magnete aller anderen Rahmen ausgeführt.

Es ist ein enormer Rechenaufwand, für jeden Rahmen zu testen, ob er ein mit einem Auge markiertes Objekt (Platzhalter oder Produkt) enthält. Beim Fix von Bug 2177 wurde diese Berechnung deshalb nur für einige Spezialfälle gemacht. Diese Prüfung wird jetzt bei JEDEM Aktualisieren von Platzhaltern gemacht. Einzige Bedingung ist, dass mind. ein Auge (Platzhalter od. Produkt) gesetzt ist.

Die Magnete wurden ausserdem unabhängig von der o.g. Prüfung tatsächlich für alle Rahmen ausgeführt. Das war natürlich nicht richtig. Deshalb wird hier jetzt nur gehandelt, wenn der Platzhalter des Rahmens zu einer der Augen-Listen passt oder wenn der Rahmen solch einen Textplatzhalter enthält.

Im Kundenprojekt liegen haufenweise generierte Dokumente vor, die blöderweise Gestaltungsregeln auf diversen Rahmen hatten, die beim Aktualisieren der Platzhalter gefeuert werden. Das führt beim Aktualisieren der Preisplatzhalter zum Verspringen vieler, vieler Rahmen.

1. Ja, ich habe das Event in den Templates entfernt, das hilft nur den bereits fertig gefinishten Dokumenten nichts, in die nur noch die neuen Preise geladen werden sollen.
2. Ich habe system::suppress_layout_rules gefunden und zu Testzwecken Palettenskripte gebaut, die system::suppress_layout_rules(0) und system::wakeup_layout_rules(0) ausführen.

Dies hat leider im Gegensatz zu Ticket Bug 2177 bei mir nicht funktioniert, da die Rahmen gruppiert sind. Aber auch wenn man die Rahmen vorher entgruppiert, scheint es nicht zuverlässig zu gehen. Ich habe eine Handvoll kleiner Screencasts gemacht, die das Thema veranschaulichen. Das Dokument zum Spielen liegt ebenfalls bei. Hänge ich gleich ans Ticket an.

Verstehe ich suppress_layout_rules falsch? Meine Erwartung wäre, dass es global *alle* per Parameter spezifizierten Gestaltungsregeln scharf- oder abschaltet. Das scheint nicht der Fall zu sein. Der Versuch, per Parameter (2) nur das spezifische Event abzuschalten (Platzhalteraktualisierung), hat zu identischen Ergebnissen geführt.

Derzeit müssen die User alle Rahmen von Hand anfassen, entgruppieren und die Gestaltungsregeln anfassen. Das Projekt ist aber schon prekär in Verzug, so dass wir eine schnelle Lösung bräuchten, daher auf "critical" gesetzt.

Die Probleme mit dem Aktualisieren der Magnet-Abstände sind mit Bug 2799 gelöst.

Die Probleme mit den falschen Magnetabständen sind mit Bug 2800 gelöst.

suppress_layout_rules hat nichts damit zu tun, ob Rahmen gruppiert sind oder nicht. Falsch war es trotzdem. Zumindest dann, wenn man einen Wert ungleich 0 angegeben hat. Das ist jetzt gefixt.

Ansonsten hat suppress_layout_rules funktioniert - nur leider im gegebenen Fall nichts geholfen, weil die Magnetabstände automatisch nach dem Laden aktualisiert wurden.

Lösungsvorschläge

Für die Aktualisierung der bereits erstellten Dokumente gibt es zwei Möglichkeiten :

1. Die Plugins PageAdapterModel und PageAdapterUI entfernen und InDesign® neu starten. Danach können Magnetabstände nicht mehr verändert werden (weil das diese beiden Plugins tun.).
2. Ab v3.3 R2850 gibt es den Befehl itemlist::store_magnet_distances. Mit dem können VOR dem Aktualisieren der Preise die Magnetabstände gesichert werden. Hier ein Skript (das pro Dokument einmal ausgeführt werden muss.)

int main ()
{
	int            pg        = document::pages ();
	int            p;
	ItemList       frames    = 0;

	for (p = 1; p <= pg; p++)
	{
		frames    = itemlist::pageframes (p, 1);
		itemlist::store_magnet_distances (frames);
		itemlist::release (frames);
		frames    = 0;
	}

	return 0;
}

... und das völlig zu Recht. Eine Anfrage an

    textmodel::available

hätte das bestätigt. Es gibt kein Textmodel. Gestaltungsregeln werden nicht mit einem Textmodel sondern mit einem Rahmen gerufen. Auch wenn der Rahmen ein Textrahmen ist - das Skript lehnt das ab (wie übrigens fast alle textmodel-Funktionen, die nicht noch zusätzlich den Rahmen übergeben.

Es wäre ein leichtes, das so zu ändern, dass das Textmodel automatisch aus dem Rahmen geholt wird - ich bin bloss nicht sicher, was das für Seiteneffekte haben könnte.

Ist auch nicht schlimm. Mit

    textmodel::get_frame_containing

kann man einen Rahmen übergeben und alles ist gut.

ACHTUNG : Auch hier gilt : Ist die Textstelle im Overset, wird der erste Rahmen zurückgegeben.

.. was blöd ist, weil die zumindest in der actions.xml für priint:adjust gebraucht werden (siehe Bug 1999)

Zumindest für die Parameter-Listen (Popup-Menüs) von Gestaltungsregeln bieten die Plugins jetzt einen Workaround : Statt der Zeilentrenner dürfen die einzelnen Werte auch mit :I: getrennt werden (Der Strich ist ein großes i.)

Mit der Angabe

   Vergleich:I:kleiner:I:gleich:I:größer

wird ein Popup mit dem Titel Vergleich und den Einträgen kleiner, gleich und größer erzeugt.

Ein Funktion zur Auswahl einer Vorlage wäre schön. Wie haben eine Gestaltungsregel, die so lange neue Seiten platziert wie ein Rahmen einen Übersatz hat. Der Regel muss man mitgeben, welche Vorlage auf den neuen Seiten platziert werden soll und im Moment geben wir dort die ID ein, schön wäre eine grafische Auswahl.

    z.B.: @LOADLIST templates

Genauso heisst die Formel jetzt auch.

    @LOADLIST templates

Alle aktivierten und in der Produktrecherche sichtbaren Templates. Die Einträge haben jeweils die folgende Form :

    1  | Name

ID und '|' sind dabei durch einen Tabulator getrennt.

Bereits in R2840 umgesetzt!

Mit dem Skriptbefehl tabel::resize_rows kann ja die Höhe von Tabellenzeilen geändert werden. Die Höhenänderungen funtionieren. Es wird aber immer die Einstellung "Minimal" gewählt. Kann man die Zeilenhöhe auch auf "Genau" stellen?

Das Feature ist umgesetzt : Sind min- und maxHeight gleich (und grösser 0.0) wird die Zeilenhöhe auf "Genau" gestellt (und die Angabe der aktuellen Höhe im ersten Höhenparameter ignoriert). Fehlen die Angaben oder sind ungleich, wird die Einstellung "Mindestens" gesetzt.

ACHTUNG : Es ist (auch mit Bordmitteln) nicht möglich, eine aktuelle Zeilenhöhe zu setzen, ohne dabei die Minimal-Höhe zu ändern. Die Funktion könnte so gesehen auf eine der Höhenangaben (Höhe, minimale Höhe, maximale Höhe) verzichten. Aus Gründen der Rückwärtskompatibilität ändere ich aber an den Parametern nichts.

Mit dem ersten Button in den Produkten kann man ja zum ersten/nächsten Dokumentobjekt (Platzhalter, Rahmen, Cometgruppe) springen, das mit dem Produkt verknüpft ist. Das klappt prima - man muss aber bereits irgendwas im Dokument ausgewählt haben. Ist die Dokumentauswahl leer, ertönt lediglich ein Piep.

Das ist jetzt gefixt. Die Dokumentauswahl darf jetzt auch leer sein, um ein Produkt im Dokument zu finden.

Workaround

Einfach irgendeinen Rahmen oder Text wählen, und dann suchen.

Die Anbindung von Comet über SOAP macht in einigen Umgebungen Probleme (namentlich .Net / WFC WebServices). Grund sind geringe Unterschiede in den HTTP Headern, vor allem bei multipart/related Nachrichten, die je nach Implementierung mehr oder weniger von den W3C Recommendations abweichen bzw. mehr oder weniger großzügig interpretiert werden. Theoretisch sind die PlugIns mit nahezu jeder SOAP Implementierung interoperabel, in der Praxis sind oft Anpassungen auf WebService-Seite notwendig.

Ab R2842 ist Folgendes geändert:

• (Bugfix) multipart/related Nachrichten werden nur noch bei Bedarf generiert, also bei putBinaryFile. Die meisten SOAP Services können beides verarbeiten, bei .Net machen multipart Nachrichten bei "normalen" Requests Probleme
• SOAP Version und Header lassen sich über eine Konfigurationsdatei anpassen.

Bei getBinaryFile allokierter Speicher wird nicht wieder freigegeben.

In R2842 gefixt.

Die panelstatements.xml Datei wird unter SOAP / XML unter Umständen sehr häufig angefordert. Ursache ist, dass diese Datei beim Einlesen der Dokument-Event Statements nicht gepuffert wird.

Der Fehler ist in R2842 behoben. In SOAP Projekten, die per system:set_docwatch () die Dokumentbeobachtung EINgeschaltet haben, dürfte das einen deutlichen Performance-Gewinn bringen.

Beim Einfügen von TaggedText in Tabelle sind mir folgende Phänomene aufgefallen:

1. Wenn ich direkt nach dem w2-Tag mit einem ParaStyle das Absatzformat setze, dann erhalte ich immer einen Umbruch bevor der Inhalt kommt. Da wird anscheinend ein "leerer" Absatz für das w2-Tag erstellt und dann kommt der eigentliche Inhalt. Beispiel:
   
   %!TT<w2:100, 500, 10, 1, '><ParaStyle:XXX>1</w2>
2. Wenn ich den Parastyle vor dem w2-Tag habe, dann ist die Leerzeile weg. Ist das das definierte Verhalten oder ein Bug?

In beiden Fällen bekomme ich in der Tabelle keine Platzhalter (ist evtl. Bug #2715 doch noch nicht final korrigiert?) Mit der vorherigen Hotfix-Version waren die Platzhalter vorhanden, es wurde nur manchmal ein leerer Platzhalter erstellt und der Inhalt stand dann hinter dem per w2-Tag definierten Platzhalter.

Das Verhalten ist jetzt in beiden Fällen gleich und die Platzhalter werden richtig angelegt. Der Fehler ist entstanden beim Fix von Bug Bug 2782, sorry.

R2842

svn 2838

22.03.2012

Die panelstatements.xml Datei wird unter SOAP / XML unter Umständen sehr häufig angefordert. Ursache ist, dass diese Datei beim Einlesen der Dokument-Event Statements nicht gepuffert wird.

Der Fehler ist in R2842 behoben. In SOAP Projekten, die per system:set_docwatch () die Dokumentbeobachtung EINgeschaltet haben, dürfte das einen deutlichen Performance-Gewinn bringen.

Bei getBinaryFile allokierter Speicher wird nicht wieder freigegeben. Der Fehler ist in R2842 gefixt.

Die Anbindung von Comet über SOAP macht in einigen Umgebungen Probleme (namentlich .Net / WFC WebServices). Grund sind geringe Unterschiede in den HTTP Headern, vor allem bei multipart/related Nachrichten, die je nach Implementierung mehr oder weniger von den W3C Recommendations abweichen bzw. mehr oder weniger großzügig interpretiert werden. Theoretisch sind die PlugIns mit nahezu jeder SOAP Implementierung interoperabel, in der Praxis sind oft Anpassungen auf WebService-Seite notwendig.

Ab R2842 ist Folgendes geändert:

• (Bugfix) multipart/related Nachrichten werden nur noch bei Bedarf generiert, also bei putBinaryFile. Die meisten SOAP Services können beides verarbeiten, bei .Net machen multipart Nachrichten bei "normalen" Requests Probleme
• SOAP Version und Header lassen sich über eine Konfigurationsdatei anpassen, Beispiel siehe unten. Die Datei muss im PlugIns Verzeichnis liegen und wird vor dem Login eingelesen. Empfohlene Einstellung: leer
• das href Attribut des Xop:include Element wird nun auch nach dem cid: Schema erzeugt, auch das konnte für Interoperabilitätsprobleme sorgen.

Hier farblich hervorgehoben der Zusammenhang zwischen HTTP Headern und Einstellungen in der soapflags.ini-Datei:

1. Request:

POST /soap/ HTTP/1.1
Host: localhost:81
User-Agent: gSOAP/2.7
Content-Type: application/xop+xml; charset=utf-8
Content-Length: 934
Connection: keep-alive
SOAPAction: "login"

soapflags.ini:
http-type=application/xop+xml; charset=utf-8

2. Multipart-Request

POST /soap/ HTTP/1.1
Host: localhost:81
User-Agent: gSOAP/2.7
Content-Type: multipart/related; boundary="==rHFpLm5WNXWc7RWYzqkrFbwSAf+VegOxrBJEkEcsnn4zEcmeVdHqMB4ekxvR=="; type="application/xop+xml"; start="<SOAP-ENV:Envelope>"; start-info="application/soop+xml; charset=utf-8"
Content-Length: 4487
Connection: keep-alive
SOAPAction: "putBinaryFile"

--==rHFpLm5WNXWc7RWYzqkrFbwSAf+VegOxrBJEkEcsnn4zEcmeVdHqMB4ekxvR==
Content-Type: application/xop+xml; charset=utf-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <SOAP-ENV:Envelope>

soapflags.ini:
http-multipart-type=application/xop+xml; charset=utf-8
http-multipart-start-info=application/soop+xml; charset=utf-8
soap-multipart-type=application/xop+xml; charset=utf-8; type="application/soap+xml"
http-type=application/xop+xml; charset=utf-8
soap-type=application/soap+xml; charset=utf-8

Eine vollständige Konfigurationsdatei mit allen möglichen Einstellungen findet sich hier

svn 2837

Hotfix

20.03.2012

Zum Erzwingen von Seitenwechseln kann die Produktliste für productlist::establish auch Seitentemplates enthalten. Wird establish aber mit dem Flag kSkipEmptyTemplates aufgerufen, werden diese Seitentemplates leider übergangen.

Der Fehler ist gefixt.

Wir haben Dokumente mit sehr vielen kleinen Rahmen. Wenn der Seiteadapter installiert ist, wird das Verschieben von Rahmen sehr langsam.

Das Problem wird dadurch verursacht, dass InDesign® versucht, die Nägel und Magneten zu zeichnen. Oder genauer, die Nägel und Magneten werden nicht gezeichnet, aber es wird ausgerechnet, wie groß die Fläche ist, die gezeichnet werden soll. Das dauert natürlich seine Zeit, alle Magneten zu prüfen.

Das berechnen der nötigen Fläche wird jetzt nicht mehr gemacht, wenn sowieso keine Nägel und Magneten gezeichnet werden sollen.

Wenn das Zeichnen aktiviert ist, muss das natürlich trotzdem gemacht werden - und das Arbeiten wird etwas langsamer. Aber mit ein paar kleinen Tricks konnten wir auch hier einiges rausholen, so dass auch in diesem Fall die Verzögerung kaum mehr spürbar ist.

Habe das gerade mal mit 3.3 R2829 aus dem Hotfix-Ordner des FTP-Servers ausprobiert und anscheinend wird bei einer SOAP-Verbindung die Datei nicht erneut vom Server geladen.

Habe das ganze mit den Parametern (0, -1, 0) und (1, -1, 1) probiert.

Hast recht, in diesem Fall müsste der interne XML-Baum zuvor weggeschmissen werden.

Die Datei findstaments.xml wird jetzt neu geladen, wenn reloadStatements = 1 ist.

Die Inlines, die ein %!TT-Text mit in-Tags anlegen soll, erscheinen an falschen Textpositionen oder gar nicht. Bis v3.2.3 hat der gleiche TaggedText funktioniert, seit v3.3 funktioniert es nicht mehr.

Das liegt an der mit Fix von Bug 2506 geänderten Verarbeitung der Comet-Tags zusammen. Comet-Tags müssen jetzt bei Importen nicht mehr extra behandelt werden. Sie sind jetzt integraler Bestandteil des Import/Exportmechanismus für TaggedText.

Leider benötigen die in-Tags trotzdem eine sorgfältige (und aufwendige) Extrabehandlung. (Das liegt daran, dass TaggedText eigentlich überhaupt keine Inline-Rahmen enthalten kann.) Dabei wurde an einer Stelle des neuen Verfahrens ein Zähler falsch behandelt.

WORKAROUND

Das alte Verfahren kann mit den Menüs

Zusatzmodule > Comet > Platzhalter in Taggedtext schreiben
Zusatzmodule > Comet > Platzhalter aus Taggedtext lesen

wieder hergestellt werden. Dazu das Häkchen aus diesen Menüs entfernen.

Wenn das nicht an allen Arbeitsplätzen manuell gemacht werden kann oder soll, können diese Eigenschaften alternativ z.B. im Loginskript (Panelstatement 92) gesetzt werden :

    prefs::set_tags_readable
    prefs::set_tags_writeable

Ab v3.3 R2830 ist der Fehler gefixt. Sowohl altes als auch neues Verfahren für die Comet-Tags behandeln Inlines jetzt richtig.

Leider liefern Typecasts der Form (int)99.9 oder (float)123 nicht die richtigen Ergebnisse.

Typecasts von int in float und umgekehrt sollten immer mit den neuen Funktionen

    toint
    tofloat

gemacht werden.

Allerdings liefert toint(99.9) nicht die erwarteten 100, sondern 99. Sollten wir dafür nicht ne eigene Funktion haben ("trunc" oder "floor"?)

Es gibt dazu auch eine Forums-Diskussion : Rounding floating point numbers in cscript.

Und ss gibt jetzt die neue Funktion

    round

Ein Funktionsparameter steuert, ob Sie unverzerrtes (mathematiches) oder kaufmännisches Runden verwenden wollen. Hier einige Ergebnisse :

So also machts der Kaufmann. Jetzt wissen wirs.

In der Aufgabenpalette werden unten aktueller und Datenbankwert der Platzhalter gezeigt. Häufig kann man die Unterschiede beider Strings gar nicht so gut sehen.

Unter den beiden Werten steht jetzt eine weitere Angabe mit dem ersten Unterschied beider Strings (Textposition und, wenn verfügbar, der Text, der sich unterscheidet).

Durch den Fix von Bug 2498 ist ein weiterer Fehler in der Aufgabenpalette zutage getreten, der zum Absturz von InDesign® geführt hat, wenn Dokumente mehrfach geschlossen und wieder geöffnet wurden.

Dieser Fehler ist ebenfalls gefixt.

In der Aufgabenpalette werden ja für jede Aufgabe die Vergleichswerte für "Dokument" und "Datenquelle" angezeigt. Die bleiben auch stehen, wenn in der Aufgabenpalette nichts selektiert ist - so weit, so gut.

Aber auch nach dem Erledigen aller Aufgaben und sogar nach dem Neuladen der Palette bleiben die Werte des zuletzt ausgewählten Eintrags stehen - wenn die Palette leer ist, bleiben die da ewig.

Das ist jetzt gefixt.

Ach ja, könnt ich ja noch hinschreiben : Die Angaben werden jetzt sogar dann neu geschrieben, wenn man im Dokument einen Textplatzhalter ändert.

Obwohl nach dem Aktualisieren der Platzhalter kein Übersatz im Text besteht, werden einige Platzhalter mit einem roten + (im Overset) markiert. Irgendwas scheint da falsch zu sein.

Das rote + gibt ja an, ob der gesamte TEXT oder die TABELLENZELLE, in der der Platzhalter liegt, einen Übersatz haben. Das rote + gibt NICHT an, ob der Platzhalter oder Teile davon im Übersatz liegen. Das macht das weisse +. Dazu habe ich mal den gelben Hilfezettel für das Statusfeld ein bisschen besser beschriftet.

Trotzdem bleibt das Problem bestehen : Der Text hat keinen Übersatz, aber einige Platzhalter haben nach dem Aktualisieren ein rotes Plus.Schaut man genauer hin, sieht man, dass "einige" immer nur Textplatzhalter in normalem Text sind. Platzhalter in Tabellenzellen zeigen den richtigen Status.

Und hier die Erklärung : Die Platzhalter werden der Reihe nach aktualisiert und ihr Status neu berechnet. Entsteht nun durch die Aktualisierung eines Platzhalters ein Übersatz, bekommt dieser Platzhalter eine rotes Plus. Dann kommt der nächste Platzhalter, der lädt sich so, dass der Übersatz jetzt wieder weg, er bekommt einen grünen Haken. Davon geht aber das rote Plus des vorigen Platzhalters nicht mehr weg.

Der Übersatz-Status des roten Plus' wird jetzt in einer weiteren Schleife NACH dem Aktualisieren ALLER Platzhalter gemacht. Dann stimmt alles.

Enthält die Dokumentauswahl einen Rahmen oder Textplatzhalter eines Produktes, wird dieses Produkt in der Produktrecherche ausgewählt (wenn es dort gerade angezeigt wird). Das klappt für Rahmen aber nur, wenn die einen Platzhalter haben.

Häufig ist es aber so, dass die Cometgruppen von Produkten auch Rahmen ohne Platzhalter enthalten. Eigentlich sollten diese Rahmen doch aus zu einer Auswahl in der Produktrecherche führen, oder?

Das geht jetzt. Zusätzlich wird Mehrfachselektion unterstützt.

Mit dem Button der ersten Spalte der Produktrecherche kann man zu den Platzhaltern im Dokument springen, die mit diesem Produkt verknüpft sind. Dabei werden immer nur einzelne Platzhalter ausgewählt. Kann man auch die gesamte Cometgruppe eines Produktes auswählen?

Über dieser ersten Spalte gibt es jetzt ein kleines Button. Mit diesem Button kann eingestellt werden, ob (wie bisher) die einzelnen Platzhalter ausgewählt werden oder (neu) gesamte Cometgruppen. Platzhalter, die nicht Teil einer Cometgruppe sind, werden wie bisher einzeln ausgewählt.

Mit dem Button der ersten Spalte der Produktrecherche kann man zu den Platzhaltern im Dokument springen, die mit diesem Produkt verknüpft sind. Ist bereits ein Platzhalter ausgewählt, wird zum nächsten Platzhalter gesprungen. In geschachtelten Inline-Rahmen funktioniert das nicht - hier werden Platzhalter übersprungen.

Wer macht denn so was? Egal, ist gefixt.

Hotfix

08.03.2012

Verwendet man den Aufbau mit einem BuildSupportSkript und legt dort in der Situation kAfterBuild zusätzliche Rahmen an, werden diese Rahmen vom nachfolgenden Produkt überdeckt.

Das ist gefixt, siehe auch hier.

Wir verwenden für einen Produktaufbau das BuildSupportSkript. Das Skript legt einen zusätzlichen Rahmen mit dem Text "Fortsetzung auf Seite ..." an. Bei der Reorganisation wird dieser Rahmen in der BuildSupportScript-Situation kCheckSizeBefore zuerst gelöscht. Das funktioniert alles.

Leider kann jetzt unter bestimmten Umständen das Produkt gar nicht mehr platziert werden. Der Aufbau generiert den Fehler 1219 (Seite konnte nicht gefunden werden). In unserem Fall wäre das die Seite 4. Diese Seite wird kurz vorher angelegt - steht zumindest im Logfile.

Es passiert folg.:

Im BuildSupport können natürlich Rahmen gelöscht und/oder angelegt werden. Vor dem BuildSupport merkt sich der Produktaufbau deshalb alle Rahmen der Seite und vergleicht diese Liste mit den Rahmen, die NACH dem Skript vorhanden sind. Damit wird die interne Rahmenliste des aktuellen Produktes angepasst.

Leider war die Reorganisation aber bereits einige Seiten weiter - dort hat sich gar nichts verändert, hier auf Seite 4, der Rahmen mit dem Text "Fortsetzung auf Seite ..." liegt aber noch auf Seite 2.

Naja, der Rest ist klar : Der BuildSupport löscht den Rahmen, der Aufbau merkt das nicht. Und etwas später will der Aufbau/die Reorganisation die Rahmen des Produktes dann endlich auf Seite 4 verschieben. Und das geht mit dem Rahmen "Fortsetzung auf Seite ..." nicht, weil es den ja nicht mehr gibt. Fehler 1219 (Seite nicht gefunden) wird generiert, weil vor dem Verschieben auf eine neue Seite erst die alte Seite gefunden werden muss - und die gibts ja dann auch wirklich nicht.

Nach dem BuildSupport wird jetzt zusätzlich für jeden Rahmen des Produktes getestet, ob er auch wirklich noch im Dokument existiert. Wenn nicht, wird er aus der Liste entfernt - und kann dann auch nicht mehr falsch behandelt werden.

Damit ist der Bug gefixt.

In der Palette Platzhalterwerte wird ja unter Gruppen-ID die Cometgruppe eines Rahmens gezeigt. Diese Anzeige stimmt häufig nicht mit dem überein, was im Dokument angezeigt wird (und wie sich das Dokument verhält).

Der Rahmen 300 sei Mitglied der Cometgruppe 197. (Die 197 wird jedenfalls in dem schrägen Label der Cometgruppen-Darstellung angezeigt.) Bewegt man den Rahmen, ändert sich die Grösse der Cometgruppe (die farbige Hinterlegung im Dokument). Bei

Kontextmenu Comet-Gruppen > Auswählen

werden auch richtig alle anderen Rahmen der Cometgruppe ausgewählt. Usw.. Aber in Platzhalterwerte steht unter Gruppen-ID nicht, wie man erwartet hätte, eine 197, sondern 250. Da ist doch was nicht richtig?

Doch, doch, alles stimmt. Nur in Platzhalterwerte wird etwas angezeigt, das nicht ganz richtig ist :

Reorganisationen können ja Templatewechsel erfordern. Dann werden alle Rahmen eines Produktes ausgetauscht und eine neue Cometgruppe erzeugt. Als Cometgruppen-ID wird die UID (irgend)eines Rahmens der Gruppe verwendet. Die sieht man zur Zeit in Platzhalterwerte.

Da Cometgruppen sich aber (zumindest nach aussen) bei Reorganisationen nicht ändern dürfen, führt das Dokument eine Übersetzungstabelle "Neue -> Alte Gruppen-ID". Diese Liste wird jedesmal befragt, wenn mit Cometgruppen-IDs umgegangen wird. So wird eben auch für die Anzeige im Dokument diese Liste befragt und der neue Wert in seinen alten (Original)wert umgerechnet.

Im obigen Beispiel die Übersetzungstabellen also einen Eintrag 250 -> 197.

Das wird jetzt auch in der Palette Platzhalterwerte gemacht. Damit ist der Fehler gefixt.

Bei einer SOAP-Anbindung wollen wir verschiedene Datenquellen (die vom SOAP-Server verwaltet werden) über die Auswahl eines Findstatements ansprechen, d.h. für jede Datenquelle gibt es ein Findstatement. Die Datei findstatements.xml wird dafür dynamisch vom Server generiert.

Wenn jetzt eine neue Datenquelle hinzugefügt wird, dann muss sich der InDesign®-Benutzer komplett abmelden und neue anmelden, damit die neue Datenquelle sichtbar wird. Schön wäre ein Skript-Befehl zum Aktualisieren der Auswahlbox mit den Findstatements. Habe in der Doku gesucht, aber nichts gefunden ... intern müsste es sowas ähnliches ja schon geben, da man die Auswahlbox ja über die Oberfläche erweitern kann.

Ziel wäre es ein Panelstatement (Action) zu schreiben über das der Benutzer dann ohne erneutes Login die aktuellen Datenquelle zur Auswahl hat.

Ist implementiert :

    productlist::update_findstatements (
        int reloadStatements = 0, 
        int selectThis = -1,
        int reloadList = 0);

z.B.

    productlist::update_findstatements (1, 300, 1);

Die Liste der Produkte des Dokumentes wird falsch berechnet. In der Palette "Produkte des Dokumentes" werden falsche Produkte angezeigt. Beim Reorganisieren werden falsche Produkte ins Dokument eingefügt.

Der Fehler ist als Seiteneffekt des Fixes von Bug 2746 entstanden und gefixt.

Der Fehler ist in allen Releases

    R2775 - R2818

aller Comet-Plugins enthalten.

Erklärung

Das Problem ist, aus den Rahmen der Cometgruppe eines Produktes die ID herauszufinden, mit der das Produkt aufgebaut wurde. Das ist nicht ganz einfach:

1. Wiederholende Elemente haben mglw. andere Produkt-IDs.
2. Beim Aufbau können zusätzliche Rahmen angelegt worden sein, die ebenfalls andere Produkt-IDs haben.

Die Produkt-IDs müssen also keineswegs eindeutig sein.

Der erste Fall konnte dadurch gelöst, dass Rahmen, die durch wiederholende Elemente entstanden sind, eine eigene Markierung erhalten. Rahmen mit dieser Markierung werden beim Ermitteln der Produkt-ID ignoriert.

Der zweite Fall wurde wie folgt gelöst : Alle Rahmen der Cometgruppe werden zuvor nach ihrer Kennung sortiert. Rahmen ohne Kennung landen am Ende der Liste. Der erste Rahmen der Liste, der kein wiederholendes Element ist und eine Produkt-ID hat (ID1 > 0), liefert die (jetzt eindeutige) Produkt-ID. Um Mehrdeutigkeiten auszuschliessen, sollten also mind. ein Rahmen des Templates eine kleinere Kennung haben als alle Rahmen, die sonst noch (z.B. mit place_items) in Laden- oder anderen -skripten angelegt werden.

Für die Sortierung der Kennung wird der Unicode-Wert der Kennung verwendet. Also

    ... 0 < 1 < 2 < ...< 9 < ...< A < B < ...< Z < ...< a < b < ...< z < ...

05.03.2012

Die Javascript-Funktion app.comet.getCometGroups

    visible-size-absolute
    visible-size-relative
    size-absolute
    size-relative

Was enthalten denn diese Werte? In den Werten ohne visible steht immer der gleiche Wert wie im Element mit visible drin. Was mach ich falsch?

Die Werte hängen von den folgenden (weiteren) Optionen des Aufrufes ab :

size-checktrans

Der Rahmenhintergrund von Bildern kann selbst undurchsichtig sein. Nicht-transparente Bildhintergründe werden im Normalfall ignoriert und nicht zur Rahmenfläche hinzugerechnet. Soll bei nicht-transparenten Bildhintergründen der gesamte Rahmen als Fläche verwendet werden, setzen Sie dieses Flag. Rahmenhintergründe sind transparent, wenn eine der folgenden Eigenschaften gesetzt ist :

• Keine Hintergrundfarbe
• Effekte : Füllmethode ungleich "Normal"
• Effekte : Deckkraft < 100.0

size-checkmargins

Soll die Seitengrösse jeweils auf den Beschnitt verringert werden anstatt auf die gesamte Seite?

size-allowholes

Löcher im Bild werden normalerweise zur Bildfläche hinzugerechnet. Mit dieser Option werden Löcher im Bild nicht zur Bildfläche hinzugerechnet. Die Option ist nur aktiv, wenn kUseClippath (size_useclips) verwendet wird.

size-useclips

Verwende bei Bildern den Bildinhalt. Wird das Bild mit einem Beschneidungspfad angezeigt, wird dieser Pfad verwendet. Der Pfad darf beliebig komplex sein und wird immer mit der Form des Rahmens geschnitten.

Elementwerte

In den Werten mit und ohne visible stand bisher tatsächlich immer der gleiche Wert drin. Das ist gefixt. Folgende Werte werden jetzt in die Elemente eingetragen:

Beispiel. Der Ordner gExampleBasePath muss eine gültige connections.xml Datei mit Ihren Verbindungsdaten (hier "yourConnection") und eine Testdatei (hier temp:cs55.indd) enthalten

var gExampleBasepath = "/Users/paul/Desktop/brutto/";

// Connect
app.comet.setEnvironment (gExampleBasepath + "CometEnvironment", 0,,"", "");
app.comet.use ("yourConnection", "", "", false, "");

// set document and options
var gOptions = app.comet.ping() + ";-1;";
var gDocument = gExampleBasepath + 'temp_cs55.indd';

// open document
app.comet.documentOpen(gDocument, true, gOptions);

// retrieve groups xml from document
var groupXml = new XML(app.comet.getCometGroups(gDocument, Scope.PAGE, 0, '', gOptions + "calc-sizes:true;"));

var xmlGroups = groupXml.descendants('group');

// close document as it is not needed any more
app.comet.documentClose(gDocument, gOptions);

function rnd (str)
{
	return eval (Math.round (parseFloat (str)));	
}

// iterate through the contained groups and alert the size values
for(var i = 0; i < xmlGroups.length(); i++)
{
	alert('-------------  '+ eval (i+1) + '  ------------');
	
	alert('Fläche (sichtbar / gesamt)\t: ' 
		+ rnd (xmlGroup.attribute('visible-size-absolute')) 
		+ "\t\t/ "
		+ rnd (xmlGroup.attribute('size-absolute')));
	
	alert('Fläche in % zur Seite\t\t: '
		+ xmlGroup.attribute('visible-size-relative')
		+ "\t\t/ "
		+ xmlGroup.attribute('size-relative'));

	alert('Verdeckte Fläche\t\t: '
		+ rnd (eval (parseFloat (xmlGroup.attribute('size-absolute'))
		- parseFloat (xmlGroup.attribute('visible-size-absolute')))));
	alert('');
}

Kann man die Comet-Notizen eines Dokumentes auch unter InDesign® Server drucken (bzw. in PDFs exportieren)?

In der Desktop-Variante kann man das machen, in dem man ein Preset (für Druck bzw, PDF-Export) mit der Einstellung "Unsichtbare Elemente drucken" erstellt und dieses Preset für die Ausgabe verwendet.

Das geht unter InDesign® Server deshalb nicht, weil Notizen dort beim öffnen eines Dokumentes immer automatisch unsichtbar gemacht werden. Ebenso werden neue Notitzen (document::import_notes) automatisch unsichtbar gemacht.

Mit document::show_notes können Notizen jetzt auch unter InDesign® Server sichtbar gemacht werden. Ausserdem werden die für Notizen nötigen Adornments (Notizenbeschriftung, Pfeile, ...) auch bei InDesign® Server dargestellt.

Hier ein Skript :

#include "internal/types.h"

int main ()
{
	document::import_notes (0, "$DESKTOP/foo.xml",);
	document::show_notes ();
	document::pdf_export(0, 0, "Druckbare Notizen");
	document::hide_notes ();

	return 0;
}

Das Skript setzt voraus, dass Sie in InDesign® das PDF-Preset "Druckbare Notizen" mit der Einstellung "Unsichtbare Elemente drucken" angelegt haben.

ACHTUNG : Nach dem Export der Datei sollten die Notizen unbedingt wieder unsichtbar gemacht werden. Notizen (oder Teile von Notizen) werden sonst in allen Anwendungen (z.B. Whiteboard) sichtbar, die das Dokument (oder Teile davon) extern anzeigen.

TIPP : Mit Hilfe der Funktion document::set_notes_printable können Notizen auch ohne spezielles Preset gedruckt und in PDFs exportiert werden.

Die Aufgabenpalette (ToDos) bringen InDesign® mit folg. Szenario leicht in eine Endlosschleife :

1. Seite öffnen
2. Aufgabenmanagement ausführen
3. Aufgaben ausführen lassen durch das Aufgabenmanagement
4. Seite schliessen ohne sichern
5. Seite wieder öffnen

Wiederholt man diese Schritte 3-4 mal, bleibt InDesign® beim nächsten öffnen hängen.

Das passiert jetzt nicht mehr. Ich kann diese Schritte mit einer Datei, die vorher reproduzierbar beim vierten Mal zur Endlosschleife führte, jetzt über 30 Mal machen.

Habe gerade mal den aktuellen Hotfix getestet (R2808 MAC CS5.5). Mit den neuen Plugins stürzt mir InDesign® beim Produktaufbau mit Seitentemplates aus irgendwelchen Gründen ab. Mit älteren Plugins ist alles Bueno.

Ja, beim Fix von Bug 2733 ist ein kleiner Fehler unterlaufen - ist gefixt.

Im InDesign® wird ein Bild platziert. Danach wird der Rahmen mit dem Objektwerkzeug kopiert und in einen anderen Rahmen eingefügt(Kontext-Menü=> Bild einfügen). Bei diesen Objekten bekomme ich über die Funktion frame::image_getpath keinen Pfad!

Getestet mit Comet 3.2.3 und 3.3 unter CS 5.5

Unter unserer alten Version Comet 3.1 und CS 3 funktioniert das vorgehen noch!

Ich schreib mal auf, wie ich das verstanden hab :

1. Es gibt einen Bildrahmen mit einem Bild. Bei diesem Rahmen funktioniert frame::image_getpath.
2. Mit Cmd-Copy wird dieser Rahmen (nicht das Bild!) in die Zwischenablage kopiert. Das ist wichtig : Der schwarze Auswahl-Pfeil ist aktiv und der BLAUE Rahmen ist ausgewählt, nicht der braune Rahmen des eigentlichen Bildes.
3. Jetzt wird ein anderer Bildrahmen ausgewählt (auch wieder der blaue) und mit dem Kontext-Menü "Bild einfügen" die Zwischenablage in den Rahmen eingesetzt.

InDesign® macht dann Folgendes : In den blauen Rahmen wird ein weiterer blauer Rahmen eingesetzt, der dann das Bild enthält.

Leider hat Adobe mit CS5 die interne Verwaltung der Bildlinks im InDesign-eigenen SDK geändert und Konstrukte wie oben werden dort gar nicht mehr unterstützt.

Die Funktion

    frame::image_getpath

hat deshalb jetzt den (optionalen) Parameter deepDive. In diesem Fall wird die gesamte Rahmenhierarchy rekursiv nach einem Bild durchsucht.

Abgrenzung

In InDesign®-Gruppen und Textrahmen wird natürlich nicht eingetaucht.

Der "Bug“fix betrifft darüber hinaus LEDIGLICH das Verhalten der o.g. Funktion frame::image_getpath. Andere intern verwendete Comet-Funktionen und insbesondere die Funktionen zum Sammeln von Platzhaltern, Aufgaben (ToDos), Export von Dokumentstrukturen (placeholders.xml, elements.xml, groups.xml, ...) können abweichende Pfadangaben ermitteln.

Das gleiche Problem tritt auf, wenn innerhalb von w2-Tags ParaStyle-Tags stehen.

Das ist jetzt auch behoben.

Sieht man nach aussen nicht, ist aber so : Für %!TT-Texte wird der für TaggedText nötige Vorspann mit den verwendeten Stilen automatisch erzeugt :

Ein

    <ParaStyle:Textfahne>

im %!TT-Text ergibt ein

    <DefineParaStyle:Textfahne=>

im intern erzeugten Vorspann. Leider gibt ein zweites "<ParaStyle:Textfahne>" auch einen zweites "<DefineParaStyle:Textfahne=>".

Intern ist das egal, ausser dass beim Import des TaggedText für jede (leere) Stilinformation einmal in der entsprechenden Stiltabelle nachgeschaut werden muss. Diese Zeit kann man ja eigentlich sparen.

Die Stil-Definitionen werden jetzt jeweils nur einmal gemacht.

Der Fehler tritt immer dann auf, wenn das Seitenelement die Rahmen in der Mitte oder unten platzieren soll. Dann passiert folgendes :

Die Rahmen werden platziert und justiert. Danach werden die Fortsetzungen erzeugt - aber dazu sollten die Rahmen wieder oben im Element stehen.

Dr Fehler ist gefixt.

Beim Platzieren von defekten TIFF-Bildern per frame::image() stürzt der Comet ab. Anscheinend nicht direkt beim frame::image(), weil ich das in einem Palettenscript nicht reproduzieren kann. Dort liefert's nur "unbekannter Fehler -6" zurück. Im Platzhalter stürzt es ab.

Das Problem ist leider ein bisschen anders : Bei defekten TIFFs zeigt InDesign® eine fest eingebaute Warnung, dass das TIFF kaputt oder inkompatibel ist. Diese Meldung muss man wegklicken. Kann man aber gar nicht, wenn man in zwei Rahmen gleichzeitig ein falsches Bild einsetzen will. Und wenn InDesign® dann vor dem zweiten Bild waren will, stellt es sich selbst ein Bein.

Nun gibt es einige Möglichkeiten, Dialoge und Warnungen zu unterdrücken. Die helfen nur leider alle nichts : Die Warnung wird offenbar zeitversetzt gezeigt. Da hab ich das Zeigen von Warnungen längst wieder an - kann ich ja nicht einfach mal global abschalten.

Ich hab jetzt ewig gesucht - und eine andere Möglichkeit gefunden. Das ganze funktioniert jetzt - ich meine, die fehlerhaften Bilder können zwar nicht importiert werden - aber es stürzt auch nicht.

Zusätzlich wird ins Logfile folg. Meldung geschrieben :

# Error while reading the TIFF image : 
  The image may damaged or incompatible.
  Save the image using different settings, and try again.
# Error -6 while importing image
  '/Users/paul/Desktop/Defekte Bilder/12026350.tif'

Hat man für ein Template einen Textflowprefix eingestellt, wird dieser Prefix zwischen die einzlenen Texte/Inlines der Rahmen des Templates eingefügt. Ich hätte ja eher gedacht, dass der Text verwendet wird, um EINMAL vor dem Template eingefügt zu werden, oder?

Stimmt, das war etwas übereifrig. Der Prefix wird jetzt nur noch EINMAL am Beginn des Textes, der durch das Template erzeugt wird, eingefügt.

In der Palette zur Einstellung der Template-Eigenschaften (Button der Palette "Templates") gibt es Einstellungen zum Textfluß-Präfix des Templates. Die dort eingestellten Werte werden beim erneuten öffnen des Templates nicht mehr angezeigt.

Das tritt nur unter XML und SOAP auf. Mit SQL funktioniert es.

Das ist gefixt. (Es wurde ein fehlerhaftes select zum Abfragen der Daten für den Dialog gesendet.)

In der Palette zur Einstellung der Template-Eigenschaften (Button der Palette "Templates") gibt es Einstellungen zum Textfluß-Präfix des Templates. Diese Felder sind immer deaktiviert.

In der Doku (extensions.html) steht, dass diese Eigenschaft aktivert wird, wenn man in pageitems die Felder textflowPrefix1, ... anlegt. Hab ich gemacht, geht trotzdem nicht.

In den Plugins wird beim Login die aktuelle Konfiguration geprüft. Da wird auch gefragt, ob die o.g. Felder verfügbar sind. Leider mit einem Rechtschreibefehler : Es wird nach textflowPrefix (ohne 1) gesucht anstatt nach textflowPrefix1. Das ist jetzt gefixt.

Workaround : Das Attribut textflowPrefix (Typ int) anlegen. Dann wird das Feature freigeschaltet.

Hotrelease

svn 2805

21212

Immer wieder kommt es vor, dass InDesign® bzw. InDesign® Server plötzlich abstürzen. Der gleiche Aufbau kann heute oder 10 mal funktionieren aber morgen abstürzen oder gleich beim ersten mal.

Immer wieder kommt es vor, dass InDesign® bzw. InDesign® Server plötzlich abstürzen. Der gleiche Aufbau kann heute oder 10 mal funktionieren aber morgen abstürzen oder gleich beim ersten mal. Inzwischen ist es uns gelungen, einen reproduzierbaren Testfall zu erhalten, der etwa bei jedem

    2. - 10.

mal zum Absturz geführt hat. 

Mit viel Debug-Aufwand konnte ich in den Fehler in der Maschine finden, die für das Ersetzen der <Tags> (z.B. <ID>, <document>, <path>) in Panelstatements und Actions zuständig ist. Diese Maschine basiert auf einer gebräuchlichen, öffentlich verfügbaren Implementierung - und dort war auch der Fehler. Klar, es handelt sich um nicht selbst allokierten Speicher - das ist es ja letztlich immer. In diesem Fall sollten Speicheradressen geladen werden. 

Im günstigen Fall hat die gelesene Adresse nur Mist enthalten. Das war meist nicht schlimm. In jedem Text gibt es unglaublich viele Versuche, ob ein Eingabetext ein gewünschtes Zeichen enthält :

    ... if (a<b) ...

Da geht die Aufmerksamkeit mal hoch, wenn das '<' gelesen wird. Aber spätestens beim ')' ist das auch wieder vorüber - das kann kein gültiges Tag mehr geben. Wenn jetzt bei ')' eine falsche Adresse für den Anfang gefunden wurde, ist das völlig egal.

Im schlechten Fall aber hat der gefragte Speicher eine Adresse rausgerückt, die es gar nicht mehr gibt. Man hat z.B. 8GB (= 8589934592 Bytes) und jetzt soll das Programm an der Stelle 10.000.000.000 nachschauen. Da fällt es um, es kann nicht nachschauen an einer Stelle, die es nicht gibt, da gibt es auf.

Nachdem das gefixt war (mein Test läuft jetzt 10.000 mal), trat ein weiteres Problem auf - die gleiche Stelle hat auch noch unglaublich Speicher verbraucht (600 MB in 1.000 Runden, also etwa 64 kB pro Durchlauf). Das ist jetzt auch gefixt. Der Speicherverbrauch (an dieser Stelle) beträgt jetzt : 0 Byte und mein Test ist 

    150.000

mal gelaufen.

Abhängig von der Installationsumgebung (namentlich "mit InDesignServer" und "ohne InDesignServer") müssen im Desktop beim Einbuchen unterschiedlich detaillierte Metainformationen generiert werden:

• mit InDesignServer: es werden nur Notizen benötigt, alles andere wird auf dem Server bei Bedarf berechnet
• ohne InDesignServer: wir benötigen auch Previews, CometGruppen, Elemente, Platzhalter etc.

Bislang ist es nicht möglich, die Art der Metadatengenerierung an die Umgebung anzupassen.

Zur Erinnerung: was beim Einbuchen geschieht, wird durch das Panelstatement 115 festgelegt. Üblicherweise steht da dann irgendwo

    priint::checkin (gDocumentID, gDocumentPath);

Der Befehl kann durch zwei weitere Parameter an die Umgebung angepasst werden:

1. (schon lange)
   char * options: Feinanpassung der XML Formate an Anforderungen bzw. Feinsteuerung der Bildgenerierung. Siehe Abschnitt "options" in der Server Development Dokumentation.
2. (ab R2793)
   int type: kWithInDesignServer oder kNoInDesignServer (internal/types.h muss eingebunden werden), Metadaten für die typischen Fälle mit bzw. ohne InDesignServer.

Der vollständige Aufruf also:

priint::checkin (
	char 	* 	documentID, 
	char 	* 	documentPath, 
	char 	* 	options = 0,
	int 		type = kWithInDesignServer);

! ACHTUNG ACHTUNG ACHTUNG ACHTUNG ACHTUNG !

Für Installationen OHNE InDesign® Server muss also ab R2793 Panelstatement 115 angepasst werden und da als 4. Parameter kNoInDesignServer angegeben werden.

Wir haben in der Publikations-Palette festgestellt, dass die Breite der Baumstruktur wohl hardcoded ist und sich nicht breiter ziehen lässt. Das hat zur Folge, dass man ab einer bestimmten Tiefe den Baum nicht mehr weiter aufklappen kann bzw. nicht mehr sieht, was man da für ein Dokument hat:

Was schlagen Sie hier vor um das Problem zu umgehen?

Bisher war die letzte Spalte der Palette die Spalte, die sich der Fensterbreite angepasst hat. Diese Spalte hat jetzt eine fixe Breite. Dafür ist die Namensspalte variabel und passt sich der Gesamtbreite der Palette an.

Die Palette kann darüberhinaus fast beliebig groß gezogen werden.

Damit dürfte das Problem erledigt sein.

Enthalten Panelstatements oder Actions SQL-Kommentare, kann dies zu Problemen führen. Die sind schwer eingrenzbar, i.d.R. äußet es sich so, dass es mal geht, mal nicht und meistens nicht oft hintereinander.

Problematisch sind vor allem Kommentare am Ende des Statements, z.B

    [ ... ] ORDER BY sort -- nach SORT sortieren

Das ist ab R2793 behoben, gleichzeitig ist der Parser auch etwas robuster bzgl. falscher Syntax (nicht geschlossene Quotes, nicht geschlossene C-Kommentare etc.)

Ein Platzhalter wird in der Liste der Aufgaben (ToDoList) als zu aktualisieren angezeigt. Wird dieser Platzhalter im Dokument gelöscht und dann in der Palette angeklickt (auf das Symbol der ersten Spalte), soll der Status in ein x (gelöscht) geändert werden. Das klappt - aber nur wenn der Text keine Tabellen hat. Dann wird ein grüner Haken angezeigt und die letzte Tabelle im Dokument ausgewählt.

Das ist gefixt. Der Platzhalter bekommt jetzt das erwartete X.

Macht man folgendes mehrfach, stürzt InDesign® irgendwann ab :

1. Datei öffnen
2. Aufgaben laden
3. Schliessen ohne Sichern

Die Dokumente sollten viele Platzhalter und viele nicht aktuelle Platzhalter haben. Der Absturz kommt dann nach etwa 5-15 Wiederholungen.

Über die Einträge der Aufgabenliste können die Platzhalter im Dokument ausgewählt werden. Dafür müssen die Platzhalter natürlich Angaben über Zielrahmen/text und Textpositionen haben. Textverweise sind eine komplexe interne Struktur der InDesign®-API von Adobe, die einen sehr - nun sagen wir - feinfühligen Umgang benötigen. Sonst kann es passieren, dass diese Objekte irgendwann einmal nach ihrem Dokument fragen, das vielleicht schon längst (wie hier) geschlossen ist. Leider ist, entgegen der geforderten Feinfühligkeit in der Anwendung, der Umgang innerhalb der API eher rau. Dort wird nicht lange gefackelt, Prüfungen auf NULL oder so was werden da offenbar nie gemacht. Tja, und dann Absturz.

Der Fehler ist gefixt. Ich kann die oben beschriebenen Schritte jetzt über 100 mal machen.

Die Einstellung, dass Fehler beim Seitenaufbau ignoriert werden sollen, wird zumindest dann ignoriert, wenn man das Aufbau-Button klickt. Treten dann Fehler auf, werden die zwar erstmal übergangen und mit dem Aufbau fortgesetzt. Ganz am Ende wird das Dokument aber wieder in seinen Ausgangszustand versetzt. Schön wäre ja eigentlich, wenn man den (zwar fehlerhaften) Aufbau trotzdem bekommen würde - wo man ja auch schon die ganze Zeit gewartet hat.

Das wird jetzt so gemacht. das Dokument wird dann nicht mehr "zurückgespielt".

Werden mehrere Seiten über den Seitentemplate-Aufbau erzeugt, so werden immer die evtl. vorhandenen Musterseitenelement, die mit Platzhalter versehen sind, auf die Satzseiten übernommen. Dieses Verhalten war mir schon früher aufgefallen, ich fans es etwas lästig,aber nicht wirklich störend.

Kritisch wird es dann, wenn man beim Seitenaufbau mit einem Seitentemplate beginnt und in diesem ST einen Nachfolger bestimmt hat. In diesem Fall werden interessanterweise die Musterseitenelemente von der ersten Seite auf die Nachfolgerseite übernommen, dort gibt es dann eine Fehlermeldung, dass der Aufbau nicht ausgeführt werden konnte, weil das Element nicht passt (obwohl das eigentlich nicht stimmt).

Der Fehler ist gefixt.

Enthält die StringID eines Produktes ein Anführungszeichen ("), kann das Doppelklick-Skript nicht ausgeführt werden. Es erscheint der Fehler -9 ("; missing"). Das passiert auch schon bei dem einfachsten Skript :

int main ()
{
    return 0;
}

Der Fehler betrifft verschiedene Arten von Skripten (z.B. Doppelklick in der Produktpalette, verschiedene Unterstützungsskripte für den Seitenaufbau und der Publikationspalette und der Aufbau wiederholender Elemente). An allen Fällen wurden Anführungszeichen im String nicht cScript-konform maskiert.

Der Fehler ist gefixt.

Internal mark : #sid""

Enthält eine Cometgruppe interaktive Elemente (Objektstati, Buttons, ...) werden über das Kontextmenü Comet-Gruppen > Auswählen nicht die interaktiven Elemente, sondern deren Unterelemente ausgewählt.

Der Fehler ist gefixt.

Internal mark : #group_sel

Alt-Click des Löschen-Buttons der Palette Produkte des Dokumentes führt zu Fehlern, wenn in den zugehörigen Cometgruppen Objektstati und Buttons enthalten sind. In diesem Fall werden statt der Hauptobjekte die Unterrahmen gelöscht. Die Hauptobjekte bleiben als (unsichtbare) Objekte im Dokument erhalten. Das Dokument kann danach nicht mehr benutzt werden.

Der Fehler ist gefixt.

Internal mark : #pod_del

In der Palette Produkte des Dokumentes werden bei aktiviertem "Auswahl synchronisieren" automatisch die zu einem Listeneintrag gehörenden Dokumentrahmen selektiert. Das funktioniert. Enthält die Cometgruppe Objektstati oder Buttons, werden aber statt dessen deren einzelne Stati (also die Unterobjekte) ausgewählt. Das macht mal so weit nichts. Will man die Rahmenauswahl jetzt aber löschen oder verschieben, stürzt InDesign® ab. Es sollten wohl besser die jeweilgen Hauotobjekte ausgewählt werden.

Das wird jetzt so gemacht. Der Fehler ist gefixt.

Internal mark : #pod_sel

Enthält eine Cometgruppe Rahmen, die von wiederholenden Elementen angelegt wurde, werden in der Palette Produkte des Dokumentes falsche IDs angezeigt - nämlich die ID eines dieser Rahmen.

Ja, das passiert immer dann, wenn diese Rahmen die am weitesten links oben in der Cometgruppe liegenden Rahmen sind. Der Fehler ist gefixt.

Internal mark : #pod_rep

Enthält eine Cometgruppe Objektstatus-Objekte oder Buttons, werden in der Palette Produkte des Dokumentes die Cometgruppen als "Manuell angelegte Cometgruppe" erkannt - und werden falsch reorganisiert.

Ja, das passiert immer dann, wenn das Objektstatus der am weitesten links oben liegende Rahmen der Cometgruppe liegt. Der Fehler ist gefixt.

Internal mark : #pod_mso

Kann man, wie für Notizen möglich, auch die Druckbarkeit einzelner Rahmen ermitteln und ändern?

Ja, dazu gibt es die neuen Funktionen

    frame::get_printable
    frame::set_printable

Nichtdruckbare Rahmen werden im Dokument mit einem roten Dreick rechts oben am Rahmen markiert. Dazu muss die Ansicht "Nägel und Magneten : Zeigen" aktiviert sein.

Comet-Kommentare sind standardmässig nicht druckbar. Diese Rahmen bekommen daher keine spezielle Markierung, wenn sie nicht druckbar sind. Comet-Kommentare bekommen eine Markierung (blaues Dreick rechts oben) wenn sie druckbar sind.

Im Bild sehen Sie einen nicht druckbaren normalen Dokumentrahmen (orange) und einen druckbaren Comet-Kommentar.

Kann man die Druckbarkeit von Comet-Notizen auch mit Hilfe der Skriptsprache setzen?

Ja klar :

    document::get_notes_printable
    document::set_notes_printable

Comet-Notizen werden ja nicht gedruckt und nicht in PDF-Exporte übernommen. Das ist ja prinzipiell auch gut so. Kann man Notizen vielleicht trotzdem in der Druckausgabe sichtbar machen?

Mit folgenden Menüpunkten geht das jetzt :

Palette Kommentare : Druckbare Kommentare

Zusatzmodule > Aufgaben > Druckbare Kommentare

Die Menüs ändern jeweils die Druckbarkeit aller Notizen des gesamten Dokumentes.

Sichtbar gemachte versteckte Notizen und neue Notizen bekommen die aktuelle Notizen-Druckbarkeit des Dokumentes. Die Druckfähigkeit der Notizen eines Dokumentes wird in der Palette Kommentare angezeigt :

Laut Doku können die Einträge der Palette Previews auch aus eigenen Tabellen/Ordnern geladen werden. Dazu werden die letzten beiden Parameter der Objekt-Statements der Previews/Snippets verwendet. Leider klappt das nicht.

Das funktioniert jetzt.

Unter XML und SOAP kann der zweite Zusatzparameter zudem eine Angabe über das Format des einzufügenden Snippets enthalten (INDD, INDS, IDMS).

Unter SQL muss die Tabelle über das int-Attribut

    format

verfügen, in dem das Format des jeweiligen BLOBs eingetragen wird.

Mehr dazu in der Online-Doku.

In der Template-Palette kann man auswählen, ob man alle oder nur die "normalen" oder nur die Tabellentemplates sehen will. Sehr schön. Kann man das auch so machen, dass sich InDesign® diese Einstellung "merkt"?

Ja klar, geht jetzt.

Mit itemlist::create_snippet können ja Comet-Snippets in der Tabelle pageitems angelegt werden (Einträge mit kindID = 2). Diese Snippets werden wir "normale" Templates in der Templateliste angezeigt. Könnte man die vielleicht aus der Liste ausfiltern?

Neben den beiden Buttons zum Ausfiltern der normalen und der Tabellen-Templates gibt es jetzt einen weiteren Knopf, mit dem die Snippets aus der Anzeigeliste ausgefiltert werden können.

In den Anweisungen zum Laden der Listeneinträge kann in den Spalten 4 und 5 die Grösse des Eintrages angegeben werden. In der Preview-Palette wird aber trotzdem die Grösse 0 x 0 Pixel angezeigt.

Ja, und zwar immer dann, wenn der Eintrag keine Formatangabe (Spalte 3) und kein gültiges Preview hat. Hat ein Eintrag keine Formatangabe, wird nämlich versucht, Format, Bildgrösse und Auflösung aus dem Bild zu ermitteln. Ist kein Bild da, geht das schief.

Der Fehler ist gefixt.

Wenn ich die Doku richtig verstehe, sollte die Funktion folgendes machen :

• 3 Parameter : Erzeuge ein InDesign®-Snippet
• 5 Parameter : Erzeuge ein Comet-Snippet. Die Meta-Daten des Snippets werden über den Template-Dialog erfragt.
• mehr als 5 Parameter : Erzeuge ein Comet-Snippet. Die Meta-Daten werden aus den
  Parametern des Aufrufes genommen.

Dazu einige Fragen :

1. Kann man InDesign®-Snippets auch direkt in die Datenbank exportieren?
   
   Nein, das ist bisher nicht vorgesehen, kann aber sehr einfach selbst
   implementiert werden. In der Doku von itemlist::create_snippet findet sich ein Beispiel, wies geht.
   
   
2. Bei 5 (und mehr) Parametern werde ich angemeckert, dass die Attribute recordid, ... in pageitems fehlen. Was ist denn das?
   
   Comet-Snippets sind Objekte, die in der Palette Previews geladen werden können.
   Die dort gezeigten Einträge stellen Alternnativen eines Produktes dar. Dazu
   muss man natürlich erst mal ein Produkt haben - das wird in der Tabelle
   pageitems in den Feldern
   
       recordid, recordid2, recordid3, recordstringid
   
   hinterlegt. Die Felder müssen bei Bedarf in der Datenbank angelegt werden.
   
   
3. Mit 5 und mehr Parametern funktioniert der Aufruf offenbar nicht. Auffällig ist, dass im Logfile bei "... data = [binfile ] " gar keine Datei angegeben ist.
   
   Stimmt. Ab CS5 funktionierte der Befehl nicht mehr. Das ist jetzt gefixt.
   
   
4. Was für ein Format hat das Comet-Snippet eigentlich?
   
   InDesign®-Snippets haben das Format IDMS.
   
   Comet-Snippets haben das Format INDD und werden im Attribut pageitems.KindID
   mit 2 markiert.

In einem meiner Projekte werden Inline-Platzhalter-Rahmen mit Markenlogos generiert. Dabei werden den einzelnen Rahmen ID1-3 des Produktes zugewiesen, in die String-ID schreiben wir den Namen der Marke (zur Weiterverarbeitung im Platzhalter des generierten Inline-Rahmens). Dabei werden die String IDs offenbar in Tagged Text gewandelt.

Beispiel

Generierter Inline-Rahmen:

   <in: 56.6929, 56.6929,177,17,10002,247435,'Röhm'></in>

Das Auslesen der gRecordStringID im Platzhalter 177 ergibt dann aber nicht "Röhm", sondern "R<0x00F6>hm", so daß folgender Code:

    query::send(qu,"select datei from comet_marken_logos where marke = ?");
    query::input(qu,kString,gRecordStringID);
    query::output(qu, kString, name);
    query::exec(qu);
    query::fetch(qu);

zu folgendem Query führt:

    select datei from comet_marken_logos where marke = 'R<0x00F6>hm';

Ich habe das jetzt umgangen, indem ich das Ganze per tagged_to_utf8 umgewandelt habe, aber die Erwartung wäre, dass wenn ich "äöü" in die StringID schreibe, dass ich dann auch genau das wieder rausbekomme, wenn ich es auslese. ;-)

Das Problem war trat beim Lesen der in-Tags auf und ist jetzt gefixt.

In Workflows werden Notizen in InDesign®-Dokumente importiert, bearbeitet und wieder exportiert. Leider ist nach dem Export nicht mehr erkennbar, welche alte Notiz zu welcher neuen Notiz gehört. Gibt es dafür eine Lösung?

Die XML-Struktur der Notizen kann jetzt eine Reihe von Attributen enthalten, die Comet-seitig nicht verändert werden :

<note
	id="4" 
	type="hint"
	customerID="10"
	customerID2="11"
	customerID3="12"
	customerStringID="sttring1"
	customerData1="data11"
	customerData2="data12"
>

Die Werte der Customer-Attribute können ausserhalb von InDesign® definiert werden und werden von den Comet-Plugins einfach durchgereicht. Es gilt :

• note.customerID, note.customerID2, note.customerID3 müssen integer-Strings sein
• note.customerStringID, note.customerData1, note.customerData2 können beliebige String-Werte sein.
• Die Werte werden Comet-seitig nicht geändert.
• Haben die Attribute in der Import-Datei gefehlt, bekommen sie beim Export die Werte, 0, 0, 0, "", "", "". (Die Attribute werden also beim Export automatisch angelegt, egal, ob sie vorher existiert haben oder nicht.)
• Die Werte werden in der Palette 'Kommentare' angezeigt (können dort aber nicht editiert werden) :
  
  
  
  Auf Kundenwunsch wurden die beiden Felder Info 1 und Info 2 wieder ausgeblendet. Sie sind in der aktuellen Version nicht mehr sichtbar.
• Die Werte noteCustomerData1 und note.CustomerData2 werden beim Duplizieren von Notizen-Rahmen in InDesign® ebenfalls dupliziert. Die Felder note.customerID, note.customerID2, note.customerID3 und note.customerStringID werden, wenn eine Notiz mit gleicher CustomerID im Dokument existiert (sichtbar oder unsichtbar) auf [0, 0, 0, ""] gesetzt.
• Die Werte werden in die Exportformate IDML, IDMS, ... übernommen (als CustomerID, CustomerID2, CustomerID3, CustomerStringID, CustomerData1, CustomerData2) und beim Import wiederhergestellt. Existiert im Dokument bereits eine Notiz mit gleicher CustomerID, wird die ID des neuen Rahmens auf [0, 0, 0, ""] gesetzt.

(siehe auch hier)

Jetzt ist aber so, das nur 8 bit PNGs transparent angezeigt werden, 16 und 24 bit nicht.

Der Fehler ist gefixt.

FYI

Das Problem bestand darin, dass die von Adobe bereitgestellte Funktion zum Berechnen von Previews mit den Alpha-Pfaden der PNGs nicht umgehen kann. (Genauso wie sie mit EPS-Bildern nicht umgehen kann.) Für die EPS-Bilder haben wir einen Workaround. Der wird jetzt auch für PNGs verwendet.

Das in der Tabelle placeholdergroups verwendete Attribut user führt unter MSSQL zu einem Konflikt mit dem dort definierten Schlüsselwort user.

Sie können statt user jetzt irgendeinen anderen (erlaubten) Bezeichner verwenden. Der verwendete Bezeichner muss in diesem Fall zusätzlich in der Tabelle keywords unter dem Schlüssel USER eingetragen werden :

    insert into keywords (ID, keyword, value) values (nextID, 'USER', 'Ihr_Bezeichner');

Wird der Standard-Bezeichner placeholdergroups.user verwendet, können Sie den Eintrag in keywords weglassen.

In der Doku steht, dass die Tabelle placeholdergroupsXplaceholders kein ID-Attribut benötigt. Trotzdem wird es beim Login erfragt - und dann können die Platzhaltergruppen nicht geladen werden.

Legt man das Attribut an, gibt es einen Fehler beim Anlegen eines neuen Eintrages, weil dann kein Wert für ID übergeben wird.

Als m:n-Tabelle benötigt die Tabelle tatsächlich kein ID-Feld. Das Laden nach dem Login war falsch. Dort mussten eigentlich die placeholderIDs für jede Gruppe erfragt werden.

Das ist jetzt gefixt.

Unter bestimmten Umständen führt app.comet.getCometGroups zum Absturz von InDesign. Das passiert immer dann, wenn (wie auch immer das passieren kann) das Dokument InDesign®-Gruppen enthält, die sich selbst als Unterlemente enthalten.

Problem

Comet-Gruppen können durch InDesign®-Gruppen hindurchgehen. Für die Berechnung der Cometgruppen ist es daher nötig, die Unterelemente der InDesign®-Gruppen zu sammeln. Da InDesign®-Gruppen wieder InDesign®-Gruppen enthalten können, ist das natürlich rekursiv. Naja, der Rest ist klar - nach relativ kurzer Zeit kommt ein Stack-Overflow.

Testskript

var gDocumentPath = "/Users/paul/Desktop/aaa.indd";
var gXML = "/Users/paul/Desktop/xml1.xml";

app.comet.documentOpen (gDocumentPath,  true,  "");
alert (app.comet.getCometGroups (gDocumentPath,Scope.SPREAD,0,gXML,""));
app.comet.documentClose (gDocumentPath, "");

Lösung

Den Fehler in der InDesign®-API können wir natürlich nicht beheben. Wir überprüfen deshalb jetzt, ob eine InDesign®-Gruppe sich selbst enthält und beenden die Suche nach Unterobjekten in diesem Fall. Der Fehler ist damit behoben (ab v3.3 R2791).

Workaround

Das folgende Skript löscht diese Rahmen auch automatisch :

int main ()
{
	ItemList 	frames 		= itemlist::allframes ();
	ItemRef 	frame 		= item::alloc ();
	ItemList 	subframes;
	ItemRef 	subframe 	= item::alloc ();
	int 		i;

	for (i=0; i< itemlist::length (frames); i++)
	{
		itemlist::get (frames, frame, i);
		if (frame::is_group (frame))
		{
			subframes = itemlist::subframes (frame);
			if (itemlist::length (subframes) == 0)
			{
				wlog ("", "# Removing frame %d.\n", item::getint (frame));
				frame::remove (frame);
			}
			itemlist::release (subframes);
		}
	}
	return 0;
}

Das folgende JavaSkript kann genau einmal ausgeführt werden. Es öffnet ein Dokument und schliesst es sofort wieder :

var gDocumentPath = "/Users/paul/Desktop/aaa.indd";

app.comet.documentOpen (gDocumentPath, true, "");
app.comet.documentClose (gDocumentPath, "");

Beim zweiten Aufruf stürzt InDesign® ab. Unter IDServer funktioniert das Ganze.

Der Fehler ist gefixt.

TaggedText mit w2-Platzhaltern legt keine Platzhalter an, wenn der Platzhalter-Text <CharStyle:>-Tags enthält :

    %!TT<w2: 30, ....><CharStyle:Preis>12,99<CharStyle:></w2>

Das Problem besteht darin, dass die Tags im in TaggedText kontext-sensitiv sind. Das Tag <CharStyle:> hat eine Sonderbedeutung und beendet automatisch alle anderen offenen Zeichenstil-Tags (von denen das w2-Tag eines ist). Auch der folgende w2-Tag-freie TaggedText ist falsch : 

    %!TT<cStrikethru:1><CharStyle:Preis>12,99<CharStyle:><cStrikethru:>

In beiden Fällen wird gemeldet, dass die jeweilige Abschlussmarke keine Anfangsmarke hat. Das ist richtig, <CharStyle:> hat das Tag ja bereits geschlossen. Da gewöhnlich die Option "Fehlerhafte Tags vor Import zeigen" abgeschaltet ist, sehen wir diese Fehlermeldung aber nicht. Die Wirkung ist "nur", dass der Platzhalter (oder die Durchstreichung) im Text fehlen.

Lösung 1

Mit den Menüs

• Zusatzmodule > Comet > Platzhalter aus TaggedText anlegen
• Zusatzmodule > Comet > Platzhalter in TaggedText schreiben

kann das neue Verhalten abgeschaltet werden. Die Plugins behandeln TaggedText dann wieder wie in Versionen vor Comet 3.3.

Lösung 2

Umformatieren des TaggedTextes so, dass die w2-Tags jeweils innerhalb der CharStyles stehen. Das obige Beispiel würde also so aussehen:

    %!TT<CharStyle:Preis><w2: 30, ....>12,99</w2><CharStyle:>

Man muss darauf achten, dass jedes CharStyle ausserhalb der w2-Tags steht. Bei Bedarf müssen dabei zusätzliche (gleiche) w2-Tags eingefügt werden. Hier ein Beispiel :

    %!TT<w2: 30, ....><CharStyle:Preis>12<CharStyle:><CharStyle:PreisOben>,99<CharStyle:></w2>

wird zu :

    %!TT<CharStyle:Preis><w2: 30 ... >12<w2:><CharStyle:>
          <CharStyle:PreisOben><w2: 30 ... >,99<w2:><CharStyle:>

Lösung 3

Mit dem Fix von Bug 2715 wird TaggedText mit w2-Platzhaltern, die <CharStyles> enthalten, automatisch umformatiert. Die änderungen werden ab Comet 3.3 R2791 in den Pluigns enthalten sein.

Unter schwer reproduzierbaren Voraussetzungen werden in einer Tabelle bei table::compress_colwise und table::woodoo in den neuen Zellen der Tabelle leere Platzhalter gesetzt.

Der Fehler ist behoben.

In einem Dokument wird eine Tabelle mit table::compress_colwise() komprimiert (Ver. 3.2.3 R 2621 CS5.5). Mit einer neuen Version (3.3 R 2717) lässt sich die Tabelle nicht mit decompress_colwise entkomprimieren. Der Rückgabewert ist zwar 0 = okay, aber es passiert nichts. Wenn die Tabelle mit 3.3 komprimiert wird, funktioniert auch das Entpacken einwandfrei.

Der Fehler ist gefixt. Tabellen, die in 3.2.3 komprimiert wurden, können jetzt auch mit 3.3 wieder vergrössert werden.

26.01.2012

Comet kann keinen Fließtext!

Naja, nicht ganz: Enthält der dem einen Platzhalter umgebenden Absatz zugewiesene Absatz- oder Zeichenstilname Sonderzeichen (Beispiel "Fließtext") so wird beim Ersetzen des Platzhalters mit TaggedText

• erstens ein neuer Stil mit (falsch) als System-Zeichen interpretierten UTF8 Zeichen angelegt
• zweitens der ursprüngliche Absatz bzw. Zeichenstil nicht richtig angewendet

Gelöst in Version 3.3, R2786

In certain circumstances the comment panel gets in an illegal state: comments created with any of the "Note" tools or the "Plus" button in the panel don't appear in the comment list, these notes will also appear in the whiteboard as normal frames.

Steps to reproduce:

• activate the comment panel (i.e. bring it to front)
• open a document with at least one comment, delete ALL comments
• close the document, activate any panel (e.g. "Publications")
• open another document, create comments with the "Note" tool or "Plus" button
• optionally checkin the document and open it in priint:suite to see the effect in the Whiteboard

This bug has been fixed in R2782

Beim Einbuchen über die Publikationspalette werden jetzt ja immer alle Metadaten mitgeschickt. Die sind derzeit etwas ausführlich und enthalten eine Menge Informationen, die i.d.R. gar nicht benötigt werden. Das kostet Rechenzeit im Desktop, Übertragungszeit im Netz und wieder Rechenzeit und Speicher auf dem Server.

Ab R2790 ist das Standardformat wesentlich gestrafft:

• Element und Platzhalterinhalte werden nicht mehr exportiert
• Koordinaten werden nur als einfache BBoxes ausgegeben

Wenn ausführlichere Informationen benötigt werden, kann dies durch Anpassung des Einbuchen-Panelstatement (115) und Aufruf des Befehls

priint::checkin_document

gesteuert werden. Dieser Befehl erlaubt im Parameter "options" alle Angaben, die in der CometServer Entwicklerdoku (Abschnitt "Options") aufgeführt sind.

Mit dem neuen Skriptbefehl

priint::create_metadata (ItemRef docRef, char * destPath, char * options)

können Metadaten-Zips auch lokal und unabhängig von der Publikationspalette generiert werden.

Vor allem für die direkte Nutzung der Skripting Schnittstelle von InDesign® Server(bzw. der Comet-Erweiterungen) wäre es praktisch, wenn man bestimmte Eigenschaften (CometGruppe, Produkt-ID...) direkt von einem Rahmen abfragen könnte.

Einfach gesagt, aber schon die CometGruppen-ID muss ja berechnet werden (persistent vs. UID im Dokument), also gelöst durch eine neue Methode des PageItem Objekts:

getCometProperty (String propertyName)

liefert bestimmte Eigenschaften. Als propertyName werden derzeit ausgewertet:

• COMETGROUP
• RECORDID
• PLACEHOLDERID
• GROUPMEMBERS

Ergebnistyp ist jeweils ein String, Beispielaufruf (in JavaScript):

var frame = doc.rectangles[frameIndex];
var groupID = frame.getCometProperty ("CometGroup");

Und dann gibt es neu auch die Methode

placeholderStore

des Application.comet Objekts. Die ruft einfach das Speichern-Skript des / der Platzhalter auf, ohne Werte im Dokument neu zu setzen etc. Aufruf genau wie placeholderLoad und placeholderSync

In der Publikationspalette sollen neben Dokumenten auch Musterdokumente bearbeitet werden können. Die Suche über conditions und conditionmenues ist dafür nicht intuitiv.

Das ist jetzt als aktivierbarer Palettenmenü-Eintrag realisiert.

Der Menübefehl ist aktiv, wenn eine Datenverbindung besteht un

• Panelstatement 130 (Musterdokumente Liste) ode
• Panelstatement 131 (Musterdokumente Objekte) definiert sind

(im Fall von SOAP-Verbindungen ist nur Panelstatement 130 relevant).

Sonstige Verwendung genau wie Panelstatement 36 und 37.

Globale Variablen werden im Desktop ja gerne dafür verwendet, um sitzungsspezifische Umgebungsvariablen festzulegen. Wie kann ich die mit InDesign® Server/ Whiteboard verwenden?

Hierzu war zunächst eine Erweiterung des CometServers notwendig, mehr dazu in der Entwicklerdokumentation für CometServer.

PlugIn-seitig gibt es

1. zwei neue Panelstatements für

• Wechsel der Session: 13
• Nutzung einer Session: 134

Es wird jeweils ein cscript erwartet, als einzige globale Variable ist der String gSessionID definiert.

2. den neuen Skript-Befehl

• server::get_sessionproperty (char * propertyName, char * out = 0): static const char *

3. zwei Skriptbefehle zum vereinfachten Zugriff auf globale Variablen

• system::set_global (char * name, char * value) : int
• system::get_global (char * name, char * out = 0) : static const char *

Mehr dazu in der cscript-Dokumentation.

Ein einfaches Session-Wechsel Skript kann z.B. so aussehen:

int main ()  
{     
    char * lang = server::get_sessionproperty ("language");
    
    system::set_global ("gUserLanguage", lang);
    return 0; // ! 
}

In beliebigen cscripten kann dann auf die globale Variable "gUserLanguage" zugegriffen werden und die ist abhängig von der jeweiligen Sitzung.

InDesign® SERVER

Die Desktop PlugIns unterstützen ja die Features

• Template tauschen unter Beibehaltung der (eventuell bereits editierten) Produktdaten
• Produkt tauschen unter Beibehaltung des (eventuell bereits nachbearbeiteten) Templates

Beides lässt sich mit InDesign® Serverfbislang nicht aufrufen.

Dabei ist die Lösung so einfach: Die Methode "cometGroupReplaceGroup" platziert anstelle einer bereits vorhandenen CometGruppe eine andere, für die Platzierung können Template-ID und Record-ID angegeben werden.

Wird als templateID -1 übergeben, werden nur die bestehenden Platzhalter neu verknüpft und geladen (= Produkttausch)

• eine leere RecordID (= "0,0,0,\"\"") übergeben, wird ein neues Template eingesetzt und die Produktdaten (sofern entsprechend gelabelt) bevorzugt aus dem Dokument übernommmen (= Templatetausch)
• In allen anderen Fällen verhält sich die Methode wie gewohnt (= die alte Gruppe wird gelöscht und an der Position im Dokument eine neue eingesetzt).

Realisiert ist das ab R2780

In der Doku steht:

static int cell::get_fillcolor_cmyk (Table T, int col, int row, ...usw

Der Befehl braucht aber zuerst die Zeile und dann die Spalte!

col, row -> row, col

Andersrum ist es nämlich ein 1A InDesign®-Killer.

Vielen Dank für den Hinweis!

Sinngemäß gilt das auch für

• get_stroke
• get_strokecolor_rgb/lab/cmyk

Die Dokumentation ist ab R2774 korrigiert.

Achtung! Bei einer ganzen Reihe weiterer Tabellen- und Zellenfunktionen (get_rotate, get_text, get_textpos etc.) ist die Parameter-Reihenfolge aber tatsächlich wie angegeben 1. Spalte, 2. Zeile.

Nur relevant für InDesign® SERVER

Die Methoden placeholderLoad / Sync / Store etc. der Scripting-Schnittstelle liefern falsche Fehlercodes. Bei leeren Seiten oder Spreads sowie ungültigen Rahmen-IDs wird 538644 (kDataPanelFatalUnrecoverableErrorCode) geliefert, obwohl 538639 (kDataPanelPlaceholderNotFoundErrorCode) bzw. 538638 (kDataPanelElementNotFoundErrorCode) richtig wäre. Alle anderen Fälle (ungültige Spreads, Seiten, Gruppen etc.) liefern richtige Fehlercodes.

Nun ja, man könnte sagen: die Eingabe ist schon Müll, dass ein Fehler zurückgegeben wird ist ja erstmal positiv. Andererseits erlaubt uns die genauere Fehlerbehandlung an dieser Stelle auch, Operationen früher abzubrechen und somit für einen allgemein stabileren Betrieb zu sorgen. Ab R2790 verhalten sich diese Methoden (und viele andere mehr) korrekter.

In conditionmenues.xml und conditions.xml definierte Suchparameter werden in SOAP / XML nicht oder nicht richtig ersetzt.

Die Ersetzung von Suchparametern funktioniert nur unter ganz bestimmten Bedingungen: Die ID des condition Eintrags stimmt mit der ID des conditionmenues überein, sind mehrere conditions für ein Menü definiert wird immer die erste Ersetzung angewendet. Zudem werden bei Verbindungsaufbau die Default-Einträge (Element defaultselection) nicht vorausgewählt.

Gelöst in R2790

Besteht eine CometGruppe nur aus genau einer InDesign®-Gruppe ist das Verhalten in einigen Punkten inkonsistent:

SERVER

Bei Platzierung einer solchen Gruppe (placeTemplate, replaceCometGroup etc.) wird keine Gruppen-ID zurückgegeben.

DESKTOP

Bei Auswahl der CometGruppe (in diesem Fall also: der InDesign®-Gruppe) gehen die sonst für CometGruppen zur Verfügung stehenden Kontext-Menü Funktionen (wie z.B. Hinzufügen zur Gruppe) nicht.

DESKTOP und SERVER

Bei Templatetausch geht die (persistente) Gruppen ID verloren

Das ist alles gefixt in R2786

Fehlerbeschreibung:

Wenn in der Preview-Palette die Option "Aktuelle Bildeinstellungen bevorzugen" aktiviert ist, dann werden bei kopierten Bildrahmen die Verknüpfungen nicht sauber gesetzt.Das Problem taucht auch auf, wenn ein Bild mit frame::image(fr, path, kPlaceLikeExisting) platziert wird. Seit CS5 bildet InDesign® in der Verknüpfungspalette ja hierarchische "Gruppen" identischer Bilder. Anscheinend wird bei PlaceLikeExisting die "Gruppen"-Zugehörigkeit mit übernommen.

Was passiert:

Mit kPlaceLikeExisting wurde nicht die Verknüpfung aktualisiert, sondern die Resource, auf die die Verknüpfung zeigt. Bildrahmen, die auf die gleiche Resource zeigen, werden gleich mitgeändert.

Die Gestaltungsregel "Gleiche Zellen verbinden" verbindet gleiche Zellen nicht.

Grund war der neue TaggedText Export, der die kompletten w2 Angaben enthält, also auch die RecordID. Die ist bei sonst gleichem Zellinhalt in der Regel doch verschieden, daher wurden die Zellen nicht mehr verbunden.

Gefixt in R2786, zur abschließenden Prüfung sollte sich das Paul nochmal ansehen.

R2764

14.12.11

Der Befehl document::import_notes macht scheinbar nichts.

Achtung, abweichend von der cscript-Dokumentation: Dokument::export_notes und Dokument::import_notes zeigen keinen Dateidialog, folgende Aufrufe sind möglich:

// Export in String
String xml = string::alloc ();
document::export_notes (0, 0, xml);
showmessage ("Notes: %s.", string::get (xml));

// Export in Datei
document::export_notes (0, "$DESKTOP/notes.xml");

// Export in Default-Datei (= Dokument-Pfad + Name * _notes.xml)
document::export_notes ();

// Import aus String
char * notes = "<notes/>";
int res = document::import_notes (0, 0, notes);

// Import aus Datei
document::import_notes (0, "$DESKTOP/notes.xml");

// Import aus Default-Datei (= Dokument-Pfad + Name * _notes.xml)
document::import_notes ();

Soll die Import / Export-Datei über Dialog festgelegt werden, kann in cscript dafür die Funktion file::select_file verwendet werden.
Die minimal erforderlichen Informationen im Notizen-XML sind wie folgt:

<notes>
  <note id="21069" type="todo">
    <title>Titel</title>
    <comments>
      <comment num="1" user="" role="" on="">
        <plain>comment</plain>
      </comment>
    </comments>
    <reference type="pageindex" uid="0" id="" x=".." y=".." start="0" end="-1" >
      <bbox x="1.0" y="1.0" width="120.0" height="80.0" />
    </reference>
  </note>
</notes>

Wenn es schon document::set_modified gibt, würden wir gerne auch den änderungszustand eines Dokuments abfragen können.

Das geht ab R2764 mit dem Skriptbefehl document::get_modified ()

Können im Produkte-Panel auch Icons von einem WebServer angezeigt werden?

Das geht jetzt, analog zu ImagePath und IconPath kann als "gridelement" jetzt auch ImageUrl und IconUrl verwnedet werden, Beispiel: ImageUrl : "http://mein.server.com/bilder/produkt.png" Zu beachten: die Leerzeichen VOR und NACH dem Doppelpunkt! Bilder werden bis zum nächsten Login gecached.

Nach dem Ausbuchen eines Dokuments über die Publikationspalette und damit verbundenem Import von Notizen - waren teilweise alle importierten Notizen ausgewählt - konnte der Import von Notizen durch Undo rückgängig gemacht werden Beides nicht intuitiv.

Ab R2764 ist kein Undo mehr möglich, das Selektions-Verhalten sollte auch behoben sein.

Ein im Desktop exportiertes Elemente XML enthält auch die Notiz-Rahmen. Das ist problematisch, wenn diese Informationen mit dem CometServer weiterverarbeitet werden sollen.

Und falsch ist es außerdem, daher behoben in R2764, Version 3.3

Unter Windows XP stürzt InDesign® ziemlich zuverlässig beim Einbuchen von Dokumenten über die Publikationspalette ab.

Ursache ist ein Fehler in der von uns für Windows verwendeten Zip-Bibliothek - oder eher Inkonsistenten bei den für die interne Darstellung von Zeichen verwendeten Typen bzw. Macros (TCHAR vs. wchar_t vs. char), die zu einem fehlerhaften Aufruf von memcpy geführt haben. Warum das unter anderen Windows-Versionen funktionierte ist ein wenig schleierhaft, jetzt geht es auch mit Windows XP.

Behoben in R2764, Version 3.3. Der Fehler betraf alle Zip-Routinen, also auch Aufruf der cscript Funktionen file::zip etc.

05.12.11

Siehe Bug 2676, die Aufräumroutinen waren dann doch noch nicht ganz korrekt, teilweise wurde Speicher doppelt freigegeben mit unabsehbaren Effekten.

Das ist in R2755 behoben.

Projekte mit SOAP Datenverbindung oder Checkin / Checkout Support in der Publikationspalette, die R2750 installiert haben, müssen umgehend auf R2755 aktualisieren.

Auf Windows werden Notizen mit Umlauten nicht korrekt importiert. Im Dokument erscheinen die zwar richtig, im Kommentare-Panel stehen statt der Umlaute aber InDesign®-Tags, beim erneuten Export werden daraus XML umschlüsselte Tags, die dann im Whiteboard als <0x1234> ... angezeigt werden.

Der Bug lag mal wieder auf tiefster Ebene im Windows XML Parser (bzw. unserer Adapterklasse). Aus der ära VOR der UTF8 Unterstützung in den PlugIns (also 1er und 2er Versionen der PlugIns) stehen da noch Konvertierungsroutinen drin, die großteils in der weiteren Verarbeitung wieder zurückgewandelt werden, aber - soweit irgendwie absehbar - gar nicht mehr benötigt werden.

Achtung! Wenn ab R2755 in Windows XML Projekten oder allgemein bei der Verarbeitung von XML Daten unter Windows Absonderlichkeiten auftreten: bitte gleich melden und notfalls wieder eine Version zurückgehen (=> R2750)

Achtung II für die korrekte Verarbeitung von Notizen muß der CometServer ebenfalls aktualisiert werden auf mindestens R8795

Schließlich: der Befehl document::import_notes hat nicht funktioniert, er hat im Gegenteil Notizen exportiert. Auch das ist behoben.

Wenn Dokumente über die Publikationspalette ausgebucht werden, hängt InDesign® neuerdings erstmal ein ganzes Weilchen, bevor irgendetwas passiert.

Das sieht nur so aus, im Hintergrund werden solange die Metadaten (Notizen etc.) vom Server angefordert, der diese eventuell überhaupt erst erstellt und dafür das Dokument mit InDesign® Serveröffnen muß Das dauert schon etwas.

Um Irritationen zu vermeiden erscheint der Fortschrittsbalken jetzt aber sofort nach Klick auf den Download Pfeil, also wenigstens sofortige Rückmeldung, dass der Klick registriert wurde und irgendwas passiert.

23.11.11

Die Funktion frame::image_scale kann bei Bildern mit Freistellpfaden zu einem "protective shutdown" führen.

Ja, das ist die gleiche Situation wie bei Bug 2681.

Das Problem tritt bei Bildern mit einem Photoshop-Freistellpfad auf, wenn

1. das Bild von seinen Dimensionen recht groß ist
2. der Freistellpfad klein und recht weit unten ist
3. der Zielrahmen im Verhältnis zum Bild sehr klein ist
4. und der Zielrahmen recht weit oben auf der Seite liegt

Zur Skalierung wird als Fixpunkt die linke obere Ecke des Bildrahmens verwendet - und das Bild fällt mglw. von der Montagefläche. Was dann den "protective shutdown" auslöst.

(Eigentlich eher ein InDesign®, oder? Denn das Bild ist ja ein Unterobjekt des Grafikrahmens und kann als solches gar nicht von der Montagefläche fallen.)

Aus Gründen der Rückwärtskompatibilität will ich das bisherige Verhalten der Funktion erhalten. Um das Problem mit den Freistellpfaden zu lösen, hat die Funktion den neuen (optionalen) Parameter

    frameRelativeRefPoint

bekommen. Ist der ungleich 0, werden die Angaben zum Referenzpunkt relativ zum Grafikrahmen ausgewertet. Der Punkt (10.0, 10.0) ist dann also der Punkt (frame.Left+10, frame.Right+10).

Damit ist das Problem gelöst.

Einige Bilder führen beim Einsetzen ins Dokument mit

    frame::image (frame, path, kBestSide);

zu einem "Protective shutdown" mit der Begründung, dass durch dies Aktion ein Objekt von der Monatgefläche verdrängt werden würde.

Das Problem tritt bei Bildern mit einem Photoshop-Freistellpfad auf, wenn

1. das Bild von seinen Dimensionen recht groß ist
2. der Freistellpfad klein und recht weit unten ist
3. der Zielrahmen im Verhältnis zum Bild sehr klein ist
4. und der Zielrahmen recht weit oben auf der Seite liegt

Dann passiert folgendes :

Das Bild wird importiert und von InDesign® automatisch so platziert, dass die linke obere Ecke des Freistellpfades links oben im Rahmen liegt.

Für kBestSide muss das Bild jetzt deutlich verkleinert werden. Dazu wird als Fixpunkt die linke obere Ecke des Bildrahmens verwendet - und das Bild fällt von der Montagefläche. Was dann den "protective shutdown" auslöst.

(Eigentlich eher ein InDesign®, oder? Denn das Bild ist ja ein Unterobjekt des Grafikrahmens und kann als solches gar nicht von der Montagefläche fallen.)

Lösung

Wir verwenden als Fixpunkt der Skalierung bei kBestSide... jetzt nicht mehr die linke obere Ecke des Bildes sondern den Bildpunkt, der an der linken oberen
Ecke des RAHMENS liegt. Damit kann das Problem nicht mehr auftreten.

Beachten Sie aber bitte, dass kBestSide... aus Gründen der Rückwärtskompatibilität weiterin die Grösse des gesamten Bildes (und nicht die Grösse des Freistellpfades) zur Bildskalierung verwendet. Soll das freigestellte auf Rahmengrösse gebracht werden, können Sie das mit

    frame::fit_image (gFrame, 1);