Ich verwende in einer Gestaltungs-Bedingung die globale Variable gIsInBuild. Leider führt das zu einem Skriptfehler beim Aufbau von Produkten, die diese Bedingung verwenden.

Ja, fälschlicherweise werden da noch Regeln der Situation "Template eingefügt" (==16) ausgeführt. Die werden seit 3.3 gar nicht mehr unterstützt. Ich hab das jetzt entfernt.

Workaround

Als Workaround kann folg. Skript verwenden werden (Der Aufruf über die Funktion is_in_build ist wichtig);

int is_in_build ()
{
	return gIsInBuild;
}

int main ()
{
	int 	retval 	= 0;

	if (gWhen == 16) 	retval = 1;
	else 				retval = is_in_build ();

	return retval;
}

Unter bestimmten Umständen wird in der Änderungshistorie der Notizen ein falscher Benutzer (und zwar der aktuell eingeloggte statt aus notes.xml übernommene) angezeigt.

Diese bestimmten Umstände sind ganz einfach: der Benutzeraccount ist rein numerisch, also sowas wie "17", "32", "60" …

Im Zeitalter der zunehmenden Digitalisierung wird es sicher immer verbreiteter, einander auf diese Weise anzureden (warum dann aber nicht gleich 00010001, 00100000 oder 00111100?), daher sollten wir das auch verarbeiten können.

Gefixt.

Bereiche anwenden -> anpassen -> center lässt sich nicht dauerhaft einstellen.

Ich vermute mal, für den Test wird der der priint-Adjust-Ordner verwendet (adjust_config_r026 beta z.B.). Dieser Ordner hat keine Lokalisierungen, alles ist in Englisch. Wir mussten aber aber für die Gestaltungsregeln einige Begriffe übersetzen. "center" ist einer davon - das gibt jetzt einen Konflikt mit dem nicht übersetzten "center" aus adjust.

Ich habe das so gelöst, dass in adjust jetzt zusätzlich die nicht übersetzten Begriffe erlaubt sind.

WORKAROUND

Umbennenen des Begriffes "center" z.B. in "centered". Dazu muss dann auch die Regel selbst angepasst werden (zwei Stellen!):

ALT : else if (strcmp(f, "center") == 0)    *method
NEU : else if (strncmp(f, "center", 6) == 0)    *method

ACHTUNG

Die geänderte Regel muß den Rahmen neu zugewiesen werden!

In ganz seltenen Fällen werden die Gestaltungsregeln "Nach Laden" nicht ausgeführt. Man kann das im Comic-Shocase sehen, dass manchmal die Bilder nicht richtig ausgerichtet sind.

Der Fehler ist gefixt.

Ich habe einen Platzhalter, der ein Bild platzieren soll. Das schlägt fehl und wird im Logfile vermerkt. Trotzdem steht eine Zeile weiter drunter, dass das Skript fehlerfrei ausgeführt wurde:

# Error -6 while importing image '/aa/bb/image.png'
# Load frame action 20048 done with no errors.

Das ist auch völlig in Ordnung so. Die Fehlerprüfung der einzelnen Skriptbefehle ist natülich Anwendersache und muss ggf. mit einem entsprechenden return geahndet werden. Wenn ein Skript aber 0 zurückgibt, geht die Skriptbearbeitung in aller regel davon aus, dass alles zur Zufriedenheit erledigt wurde.

Zur Verdeutlichung habe ich die etwas missverständliche Meldung "... done with no errors" geändert in "... successfully finished". Das beschreibt die Situation glaube ich besser. Ausserdem kann man so im Logfile auch erfolgreicher nach dem Wort "error" suchen (was ja bisher kaum ging :-) )

Beim Platzieren von PDFs mit frame::place_pdf erhalte ich die Meldung, dass die PDF-Datei nicht geöffnet werden kann. In Acrobat (oder einem anderen PDF-Viewer) kann ich das PDF aber problemlos öffnen.

Werden bei einer Bearbeitung mehrere PDs platziert, wird die Fehlermeldung mehrfach angezeigt - das führt dann zum Absturz von InDesign®.

Das Problem ist, dass entgegen der Doku eine Seitennummer benötigt wird. Mit Angabe einer Seitennummer tritt das Problem nicht mehr auf. Ab R7901 kann, wie in der Doku beschrieben, die Seite 1 als Default verwendet werden.

Obwohl das DocWatch aktiviert wird, wird mein Skript "BeforeDocClosed" von InDesign® Server nicht ausgeführt. Der Fehler betrifft nur dieses Skript, andere Skripte des DocWatch (z.B. AfterOpen) werden ausgeführt. Mit InDesign®- Desktop funktioniert alles, nur eben mit dem Server nicht.

Gefixt.

Seit R7234 (9.1.2015) funktioniert die Skriptfunktion table::fit_col nicht mehr. Auch die Tabellengestaltungsmethode "Spaltenbreiten anpassen" geht nicht mehr.

Der Fehler ist in v3.4, v4.0 und v4.0.4 enthalten.

Ooops, da hat uns wohl svn einen Streich gespielt. Die Funktionen gehen jetzt wieder. Was für ein Schreck. Gefixt!

Bei Auswahl des Tools "Placeholder tools working on text selection" werden trotzdem ALLE Platzhalter des aktuellen Textes bearbeitet, wenn ich z.B. auf das Tool-Button zum Aktualisieren der Platzhalter drücke. Ich hätte erwartet, dass dann nur die Platzhalter der aktuellen Textauswahl neugeladen werden. Wie kann denn erreichen, dass nur ein bestimmter Platzhalter neu geladen wird?

Die englische Übersetzung der Tool-Auswahl ist hier etwas mißverständlich. Im Deutschen heißt die gleiche Auswahl: "Platzhalter-Werkzeuge bearbeiten den Rahmen der Textauswahl" - und das macht es ja dann auch.

In der englischen Version heißt die Auswahl jetzt "Placeholder tools working on frame frame of text selection".

Im Grunde ist die Auswahl identisch mit "Platzhalter-Werkzeuge bearbeiten die ausgewählten Rahmen", wenn nur ein einziger Rahmen ausgewählt ist. Wir werden dieses Verhalten mglw. in einem der nächsten Releases anpassen.

Wenn tatsächlich nur die Platzhalter der Textauswahl bearbeitet werden sollen kann dafür das Fly-Out-Menü "Aktualisiere die Produkte der Textauswahl" der Produktrecherche verwendet werden.

Wendet man die Funktion textmodel::scale_font auf Text an, der automatische Zeilenabstände, sind die Zeilenabstände danach negativ. Im normalen InDesign® bemerkt man den Fehler gar nicht. Es werden weiter automatische Zeilenabstände generiert. Nur InDesign® Server kann die so geänderte Datei nicht mehr öffnen. Und beim Export in TaggedText sieht man, dass dort ein cLeading kleiner 0.0 steht.

Gar nicht gut. Der Fehler ist gefixt.

Die Funktion textmodel::justify bearbeitet nicht immer alle Rahmen oder die falschen Rahmen von Textketten. Der Fehler tritt insbesondere auf, erste/letzte Zeichenpositionen in Textrahmen als Index für die Funktion verwendet werden.

Der Fehler ist gefixt. Er betrifft auch die Gestaltungregel "Vertikale Textausrichtung -> Absatzkeil".

Unter Windows sind die Umrechnungen von Datum-Uhrzeit (z.B. 7. Okt. 2015) in interne Datenstrukturen falsch. Es wird immer die aktuelle Zeit verwendet. Lediglich das Eingabeformat yyyymmddhhmmss funktioniert richtig.

Dieser Fehler besteht seit Vesion 1 der Plugins (also seit fast 12 Jahren!).

Gefixt.

Das Problem wird durch folgende seltene und unglückliche Kombination von Anweisungen verursacht:

1. Im Laden-Skript des Platzhalters wird das Bild richtig importiert. Danach
   kommen zwei weitere Anweisungen
   
       frame::fit_image (frame, 4);
       frame::fit_image (frame, 0);
   
   Die erste skaliert das Bild so, dass der Bildrahmen vollständig ausgefüllt wird. Dadurch können schmale Bilder sehr hoch werden. In der zweiten Anweisung wird das so skalierte Bild im Rahmen zentriert. Dadurch kann die linke obere Ecke Bildecke sehr weit nach oben rutschen.
   
   

2. Jetzt wird die Gestaltungsregel fitimage ausgeführt. Die skaliert das Bild an seiner linken oberen Ecke so, dass es genau in den Rahmen passt. Dadurch kann es von der Montagefläche fallen. Das ärgert InDesign® so, dass es abstürzt.

Workaround

Beide fit_image entfernen. Die Ergebnisse dieser Aktionen werden durch fitframe sowieso wieder verändert.

Nach der Gestaltungsregel fitframe wird jetzt noch die Gestaltungsregel "Bild platzieren" ausgeführt. Die zentriert das Bild noch.

Lösung

Die Regel fitframe skaliert jetzt nicht mehr am Fixpunkt oben/links sondern in der Bildmitte. Dadurch kann der oben beschriebene Fehler gar nicht mehr auftreten. Damit ist das Problem gelöst.

Beim Einloggen in meine lokale Datenbank stürzt InDesign® reproduzier immer dann ab, wenn mein Rechner weder eine Ethernet- noch eine WLAN-Verbindung hat. Hat der Rechner eine aktivierte Verbindung, klappt alles. Es ist dabei unerheblich, ob die Verbindung auch hergestellt werden konnte, es reicht, dass sie aktiviert ist.

Im vorliegenden Fall wird der Fehler durch den cScript-Aufruf priint::set_pref im Loginskript ausgelöst. Auch system::tcpip führt in der beschriebenen Situation zum Absturz.

Der Fehler ist gefixt. Wir haben das Fehlen einer TCP/IP-Adresse mit einer Funktion der Mac-Entwicklungumgebung abgefangen, die bisher eine Warnung geschrieben und dann ein Return veranlasst hat. Jetzt bricht diese Funktion das gesamte Programm ab - natürlich nicht so gut.

Genau. Das ist nämlich nicht ganz so einfach. Deshalb gibt es jetzt dafür die Funktion system::font_info.

Ich verwende ID Server Windows und habe bisher keine Lizenz. Leider fehlen in der Ausgabe aber auch alle Angaben, die zum Erstellen der Lizenz nötig sind. Auffällig ist auch, dass das große pc-Logo fehlt.

Der Fehler lag an einer erweiterten internen Verwendung von Strings. Diese Erweiterung war auf Grund der langen Texte für die Tabellen des serverbasierten Tabellenmodules leider nötig.

Das ist gefixt.

Logausgaben der Plugins von einer Länge >= 32000 Zeichen führen zeimlich zuverlässig zum Absturz von InDesign®.

Und wieder wurde eines der beliebten Features zum Beenden von InDesign® entfernt: nicht genug, dass der Absturz nun ausbleibt, die maximale Länge der Logausgaben wird ab R7684 3.4 / 4.0.3 / 4.0.4 auch nur noch durch den zur Verfügung stehenden Arbeits- bzw. Festplattenspeicher begrenzt.

Bei fehlenden Platzhalter-Definitionen in in-Tags sollten die Dummy-Texte eingesetzt werden

Gefixt.

Der Fehler tritt nur bei XML-Offline und SOAP auf: Enthält ein TaggedText ein w2-Tag mit einem unbekannten Platzhalter, bekommt dieser Platzhalter im Dokument zufällige Werte für alle seine Daten wie LoadID, SyncID, Prefix, Postfix, ... .

Der Fehler ist gefixt. Die Platzhalterwerte werden sämtlich mit 0 bzw. "" initialisiert.

Die Hilfslinien-Angaben im spreads-XML enthalten folgende Fehler:

• auf der Musterseite definierte horizontale Hilfslinien über das gesamte Pasteboard erscheinen nicht, wenn die tatsächliche Seite nicht die erste Seite des Musterseiten-Spreads enthält (typischerweise der Fall bei rechter Seite als erste Dokument-Seite)
• in diesem Fall sind auch die Koordinaten auf der Musterseite definierter vertikaler Hilfslinien um die Breite der "fehlenden" Seite verschoben

Gefixt.

Mit Plugin-Revision 7202 und 7373 kommt beim Prüfen der Platzhalter in der Aufgabenliste eine Fehlermeldung "Fehler bei der Skriptausführung". Der Fehler tritt angeblich in der Sync-Aktion des Platzhalters "Fit Frame" (1071) auf. Mit Plugin-Revision 5252 passiert das nicht.

Jetzt kommt das seltsame: ich habe zu Testzwecken sowohl die Sync- als auch die Load-Aktion des Platzhalters durch einen Dummy ersetzt:

int main()
{
	return 0;
}

Und zwar ohne irgendwelche Includes oder sonst was. Ich habe auch alle anderen Platzhalter aus dem Dokument entfernt. Trotzdem die Fehlermeldung, dass ein ';' vermiß werden würde.

Der Rahmen enthielt den Text :

Wir nannten ihn "DICK", aber das war er nicht.

Der böse Bube war der "DICK". In Rahmenplatzhaltern wird dem Script in der globalen Variable gLink der Bildpfad mitgegeben. In Textrahmen ist kein Bildpfad da, also wird der Text verwendet Die Variable ist recht neu. Früher wurde Pfad und Name getrennt geliefert - und in beiden Pfadteilen die Anführungszeichen escaped (oder wie das heißt). In gLink wurde das bisher nicht getan, das ergab dann mit "DICK" :

char gLink [] = "Wir nannten ihn "DICK", aber das war er nicht.";

Was ja jetzt nicht so 100%ig richtig ist.

Das ist gefixt.

Mit den aktuellen Mitteln des Seitenadapters ist es nicht möglich, ein Bild immer so platzieren, dass ein bestimmter Bildpunkt relativ zur Seite immer an der gleichen Stelle liegt.

Hier ein Beispiel: Kennen Sie Bad Frankenhausen? Es hat den schiefsten Kirchturm Europas, schiefa als Pisa, gewissermaßen. 5 m ist die Spitze des Turmes aus dem Lot. Das soll man auf den Bildern auch sehen - bei Formatadaptionen soll daher die Kirchturmspitze immer im Zentrum des Bildes stehen. Das obige Bild eignet sich zur Demonstartion leider nicht. Es wird auf alle Fälle Platz um das "Zentrum" benötigt. Das müssen Sie Ihrem Fotografen vorher sagen. Ich verwende daher ein Handy-Foto von mir:

Das ist einfach, wenn die Seiten immer proportional skaliert werden. Dann ergibt sich das einfach, wenn das Bild genauso wie die Seite skaliert wird. Bei nicht-proportionalen Größenänderungen wird es komplizierter. Mit ein wenig Mühe wäre es aber möglich, ein entsprechendes Skript zu schreiben, das diese Aufgabe erledigt.

Besser ist aber diese Lösung : Die bisherigen Bildmagnete können ja einen Rahmen mit einem Bildpunkt "mitziehen". Was wir hier wollen, ist der umgekehrte Fall : Ein Bildpunkt soll mit einem Rahmen mitgezogen werden. Der Rahmen selbst bewegt sich relativ zu den Änderungen der Seitengrößen. Das kann jetzt mit dem Werkzeug "Roter Magnet" () und SHIFT-Klick für das Magnetziel definiert werden.

Beispiel

Als erstes legen Sie einen Hilfsrahmen an. Im Bild oben ist das der rote Pfeil. Der zeigt mit seiner linken, oberen Ecke genau auf die Kirchturmspitze (oder wo auch immer Sie das Bild festhalten wollen.). Dieser Rahmen bekommt oben und links jeweils einen ROTEN Nagel. Damit wird sich die linke, obere Ecke immer relativ im gleichen Abstand zum Seitenrand befinden.

Unter der Pfeilspitze soll jetzt immer der gleiche Bildteil liegen.

1. Wählen Sie das Werkzeug "Roter Magnet" ().
2. Klicken Sie die linke Seite des großen Bildes.
3. SHIFT-Klicken Sie die linke Seite des roten Pfeiles
4. Wiederholen Sie das jeweils mit den oberen Kanten

Damit ist das schon erledigt.

Die Skalierung des großen Bildes machen Sie wie immer:

1. Fügen Sie die Aktion "nach Größenänderungen Bild skalieren" an
2. Legen Sie den bevorzugten Bildausschnitt fest. Klicken Sie dazu einfach auf den blauen Knopf von "Minimalansicht innerhalb" :
3. Fügen Sie die Aktion "nach Größenänderungen Bereiche anwenden" an. Konfigurieren Sie diese Regl so, dass die "Muß"-Bereiche bevorzugt werden.

Zum Schluß können Sie den Hilfsrahmen mit dem roten Pfeil unsichtbar machen (Standardpalette "Ebenen").

Adaptionen

Hier sehen zwei nicht-proportionale Adaptionen:

Ich habe für den Produktaufbau ein Seitenelement in Seitengröße. Dort können beliebig viele Produkte platziert werden. Wenn jetzt

1. ein Produkt das Seitenelement mit einer Fortsetzung betritt
2. diese Fortsetzung deutlich schmaler als das Seitenelement ist
3. die Fortsetzung durch eine Gestaltungsregel verbreitert wird

ja, dann wird das nächste nicht mehr in diesem Seitenelement platziert sondern es wird leider ein neues Seitenelement verwendet und das Produkt dort platziert. Und das auch noch mit dem Y-Offset aus dem ersten Seitentemplate.

Sehr schön, wir sind in der Fehlerkategorie : DREI Bedingungen müssen erfüllt sein, um den Fehler zu provozieren.

Das ist jetzt gefixt.

Ich habe ein Comet4-PublishingHub-Projekt. Leider haben dort die Fortsetzungsrahmen nie die richtige Größe. Es sieht so aus, als hätten die Rahmen mit der Fortsetzung immer die Größe aus dem Template. Meine Gestaltungsregel "Fit Frame" scheint auch ignoriert zu werden.

Ja, das stimmt leider. Und als Folge des gleichen Fehlers wird auch immer nur eine Fortsetzung angelegt. Der Fehler lag nicht in den Plugins. Der Comet4-PublishingServer liefert aber leider Fortsetzungstemplates ohne Fortsetzung, so dass der Produktaufbau davon ausgehen mußte, dass der Aufbau des Produktes an dieser Stelle beendet ist. Diese fehlenden Angaben können sich die Plugins aber auch "denken". Damit ist der Fehler gefixt.

Dass das "Fit frame" nicht wirkt ist klar. Mit der Einstellung "Rahmen fortsetzen" gibt man Kontrolle der RahmenHÖHE an den Produktaufbau ab.

Werden via soap.getBinaryFile ungültige (d.h. auf dem Server nicht existierende / auswertbare) fileIDs abgefragt, stürzt InDesign® ab.

Nicht generell, nur unter bestimmten Bedingungen, die aber unglücklicherweise im Zusammenhang mit PubServer / CometBridge Verbindungen auftreten können:

1. der WebService liefert trotzdem resultCode 0
2. das in der SOAP Antwort mitgelieferte CometBinary Element ist NULL

Gefixt.

Die About-Fenster der Comet-Plgins zeigen jetzt den Lizenzcode, der die Freischaltung der Plugins ermöglichte.

Wird nicht-wohlgeformtes XML mit dem Fast-Parser eingelesen, hängt InDesign® in einer Endlosschleife. Einfach nachvollziehbar in cscript bspw. mit dem Aufruf

document::import_notes (gDocument, 0, "malformed-XML");

Gefixt in

• 3.4 R7540
• 4.0.3 R7540
• 4.0.4 R7540

In der Spreads XML Datei sollen auch Angaben zu Hilfslinien, Grundlinien- und Dokumentraster stehen. Ausführliche Beschreibung siehe http://fogbugz.werk-ii.com/default.asp?12698.

Unterstützt ab

• 3.4 R7540
• 4.0.3 R7540
• 4.0.4 R7540

Oder in anderen Worten: Eine unter Windows angelegte und ausgeblendete Notiz wird beim Öffnen und Wieder-Einblenden auf dem Mac nicht richtig angezeigt. Umgekehrt funktioniert das auch nicht.

Nun ist das glücklicherweise nicht unser regulärer Ablauf, in aller Regel werden Notizen aus einer extern mitgeführten XML-Datei gelesen und das funktioniert plattformübergreifend völlig richtig.

Beim Einlesen aus dem InDesign® Dokument verwenden wir eine von Adobe freundlicherweise bereitgestellte Hilfsklasse zum Übersetzen von Unicode nach UTF-8 - und die verhält sich auf Windows und Mac unterschiedlich. Ja was soll man denn damit anfangen?

Lösung:

Ab 4.0.4 7540 verwenden wir zum Schreiben und Lesen eine eigene UTF8 zu Unicode Konvertierung. Damit die im Dokument gespeicherten Daten von alten Versionen unterschieden werden können, schreiben wir außerdem eine führende "0".

Das heißt, dass in 4.0.4 gespeicherte Notizen mit älteren Plug-In Versionen (3.4 und 4.0.3) nicht mehr gelesen werden können?

Im Prinzip ja, aber
    3.4 ab R7540
    4.0.3 ab R7540
enthalten ein Kompatibilitäts-Update, das Lesen von 4.0.4 Notizen erlaubt. Gespeichert wird in diesen Versionen aber nach wie vor im "alten" Format.

bei einem Test der Funktionen unter dem namespace "behavior" sind 2 Probleme aufgetaucht. Die Funktion behavior::image() führt nicht zum gewünschten/erwarteten Ergebnis. Stattdessen verhält sie sich, wie wenn der Overlay "Hyperlink" gewählt wurde. Daher habe ich die Funktion behavior::hyperlink() probiert. Diese existiert jedoch gar nicht!

Zwei Schreibfehler haben

1. behavior::hyperlink zu behavior::hyerlink gemacht
2. In behavior::image die Eingenschaft Hyperlink aktiviert

Beide Fehler sind gefixt.

Werden beim Mergen von Tabellenzellen ganze Zeilen und/oder Spalten zusammengefügt, hat die Tabelle danach weniger Zeilen/Spalten. (Diese Bereiche können übrigens nicht wieder auseinander genommen werden.) Beim Zusammenfügen von Zellen gleichen Inhaltes entstehen dadurch Fehler, weil sich die Zellenindexe ändern.

Gefixt.

Der Seitenaufbau lässt bei Produkten mit Fortsetzungen mitunter viel freien Platz in den Seitenelementen. sehen Sie selbst:

IST

Die roten Rahmen sind Fortsetzungen. Die erste Fortsetzung (3.2) wird richtig platziert. Danach muß eine neue Seite angelegt werden und 3.3 wird platziert. Auch richtig. Die Platzierung von 4 aber ist falsch : Neben 3.3 wäre ja noch Platz gewesen. So wird ohne Not eine neue Seite angelegt.

SOLL

Hier wird der freie Platz neben 3.3 richtig ausgefüllt. Danach ist für die beiden Produkte mit der 5 immer noch genügend Platz auf der Seite.

Das ist gefixt.

Bei XML mit Kommentaren kann es zu Fehlern beim Einlesen kommen. Daten hinter Kommentaren können 'unsichtbar' werden.

Gefixt.

Im Whiteboard angelegte Notizen mit leeren Absätzen werden beim Ausbuchen eines Dokuments als mehrere Kommentare interpretiert.

Spätestens beim Einbuchen wird aus dem (ursprünglich) einem Kommentar mehrere, die - bis auf den ersten - alle als Erzeuger den lokalen InDesign®- Benutzer angegeben haben.

Das Standardverhalten wird NICHT geändert, ab R7274 kann aber (z.B. im Loginskript) das Verhalten gesteuert werden. Die Funktion

prefs::show_note_history(int showNotes)

wird um einen Parameter erweitert:

prefs::show_note_history(int showNotes, int importMode)

importMode kann einen der folgenden Werte annehmen (definiert in types.h):

kNotifyIgnoreEmptyParagraphs	// Standardverhalten wie bisher
kNotifyFilterEmptyParagraphs	// leere Absätze entfernen
kNotifyConvertEmptyParagraphs	// leere Absätze in einzelne Kommentare konvertieren

Zusätzlich kann mit dem Flag kNotifyAutoFitNotes erreicht werden, dass Notizrahmen beim Import und Einblenden automatisch an den Textinhalt angepasst werden. Im Zusammenspiel mit Whiteboard-Notizen scheint mir das ein sinnvolles Feature zu sein.

Beispiel Login-Skript:

int main() 
{
    prefs::show_note_history(1,
        kNotifyConvertEmptyParagraphs
        + kNotifyAutoFitNotes);

    return 0;
}

bewirkt, dass leere Absätze in Kommentare konvertiert und die Notizrahmen an den Text angepasst werden.

Im Whiteboard angelegte Notizen mit leeren Absätzen werden beim Ausbuchen eines Dokuments als mehrere Kommentare interpretiert.

Spätestens beim Einbuchen wird aus dem (ursprünglich) einem Kommentar mehrere, die - bis auf den ersten - alle als Erzeuger den lokalen InDesign®- Benutzer angegeben haben.

Das Standardverhalten wird NICHT geändert, ab R7274 kann aber (z.B. im Loginskript) das Verhalten gesteuert werden. Die Funktion

prefs::show_note_history(int showNotes)

wird um einen Parameter erweitert:

prefs::show_note_history(int showNotes, int importMode)

importMode kann einen der folgenden Werte annehmen (definiert in types.h):

kNotifyIgnoreEmptyParagraphs	// Standardverhalten wie bisher
kNotifyFilterEmptyParagraphs	// = leere Absätze entfernen
kNotifyConvertEmptyParagraphs	// = leere Absätze in einzelne Kommentare konvertieren

Zusätzlich kann mit dem Flag kNotifyAutoFitNotes erreicht werden, dass Notizrahmen beim Import und Einblenden automatisch an den Textinhalt angepasst werden. Im Zusammenspiel mit Whiteboard-Notizen scheint mir das ein sinnvolles Feature zu sein.

Beispiel Login-Skript:

int main() 
{
    prefs::show_note_history(1,
        kNotifyConvertEmptyParagraphs
        + kNotifyAutoFitNotes);

    return 0;
}

bewirkt, dass leere Absätze in Kommentare konvertiert und die Notizrahmen an den Text angepasst werden.

Mit dem Parameter justifyRows der Funktion table::break_ kann man steuern, ob die Neuverteilung der Zellen möglichst gleichmäßig erfolgen soll (oder ob einfach von oben gefüllt werden soll):

Wenn man z.B die folgende Tabelle hat:

Header1 Header2 C1 C2 C3 C4 C5 C6 C7 C8

Und C7 ist die erste Zelle, die über den Rahmen hinausragt, dann würde ich so so umbrechen, wenn es möglichst gleichmässig sein soll:

Header1 Header2 C1 C2 C3 C4
Header1 Header2 C5 C6 C7 C8

Tatsächlich umbrochen wird mit justifyRows=1 aber so:

Header1 Header2 C1 C2 C3 C4 C5
Header1 Header2 C6 C7 C8

Und mit justifyRows=0 so (Was okay ist):

Header1 Header2 C1 C2 C3 C4 C5 C6
Header1 Header2 C7 C8

Ja ja, schon recht. Jetzt wird das richtig gemacht.

Der Fehler ist gefixt.

Das "type" Element wird nicht ausgewertet, daher ist es nicht möglich, in die Produktliste Seitentemplates aufzunehmen.

Gefixt.

Werden mit der Funktion document::move_pageitems Seiteninhalte verschoben, sind danach die Cometgruppen aller verschobenen Rahmen weg. Das Gleiche gilt für Magnete zwischen den Rahmen.

Ja, im Prinzip ist das Verschieben auf einen anderen Spread nichts anderes als Löschen und Neuanlage der Rahmen. Dabei gehen, wie ja hoffentlich inzwischen allseits bekannt, die Cometgruppen verloren.

Da in diesem speziellen Fall immer innerhalb ein und des selben Dokumentes gearbeitet wird und Cometgruppen sich gar nicht ändern können, werden daher hier jetzt die Cometgruppen erhalten.

Magnete bleiben, soweit möglich, erhalten. Magnete zwischen verschiedenen Seiten eines Spreads werden gelöscht, wenn durch die Verschiebungen die Rahmen nicht mehr im selben Spread liegen.

Die Buch-Funktion book::export_ mit PDF unter R7100 ist noch nicht 100% perfekt. Wenn man versucht auf ein share zB. //FileServer/public/xxxxx.pdf zu verweisen bricht die Funktion mit -1 Unbekannter Fehler ab.

Gefixt.

Ich habe in meiner Template-Palette einige Templates, die nicht richtig gesichert werden konnten : Templat-Datei und Preview sind leer. Ich weiß, ich kann mit diesen Einträgen sowieso nichts anfangen und kann sie einfach löschen. Wenn man aber auf die Idee kommt, solche Einträge ohne Bild vielleicht vor dem Löschen noch mal zu prüfen und sie in der Palette doppelklickt, dann stürzt InDesign® ab.

Adobe lässt in der InDesign®- API (der Grundlage für unsere Plugins) so gut wie keine Eingabedaten prüfen. So ziemlich alle der 10.000enden Funktionen kann man nur nutzen, wenn man vorher alle Daten z.B. gegen 0 (NULL) usw. testet. Das geschieht angeblich aus Performance-Gründen. So führt offenbar auch der Versuch, eine leere Datei zu öffnen, zum Absturz von InDesign® und jeder, der diese Funktion nutzen will, sollte also vorher prüfen, dass die Datei nicht leer ist. Das machen wir jetzt. Damit ist dieser Fehler behoben.

Ich habe ein Template mit mehreren Bildrahmen. Alle haben den gleichen Platzhalter. Über eine globale Variable (die Bildnummer) wird gesteuert, welches Bild in welchen Rahmen kommt. Die Bildnummer wird dabei bei jedem Laden um eins erhöht. Es ergeben sich also die Bilder 1, 2, 3, 4, ... .

Nur leider nicht in der erwarteten Reihenfolge - obwohl ich die Sequenznummern in "Template-Verhalten" gesetzt habe.

Ja, das sollte eigentlich funktionieren. In zwei Fällen hat es bisher nicht funktioniert :

1. Aufbau mit document::place_items (und nicht der normale Produktaufbau)
2. InDesign®- Gruppierte Rahmen

Das ist jetzt gefixt.

Generell gilt aber: Textplatzhalter werden VOR Rahmenplatzhaltern ausgeführt. Weitere Infos finden Sie hier.

Gibt es in cScript eine Möglichkeit, einen ganzen Speicherbereich zu initialisieren?

Ab jetzt : memset

Seltsames Phänomen: Ich habe einen einfachen Textplatzhalter, der einen kleinen InlineFrame in den Text ankern soll:

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

int main()
{
	int 		out_pos, out_type;
	ItemRef 	fr 	= item::alloc();

	textmodel::replace("%!TT<in:100., 100.></in>");
	textmodel::get_anchor(
		textmodel::start (),
		textmodel::length (),
		&out_pos, &out_type, fr);
	frame::color_cmyk(fr, 100., 0., 0., 0.);

	return 0;
}

Wenn ich diesen Platzhalter in einem Textrahmen lade, passiert das Erwartete. Er macht einen cyanfarbenen Inline-Rahmen in 100x100pt, der an Position 0 ankert. Diesen kann ich neu Laden und auch "machen und tun". Da ist nichts kaputt zu bekommen.

Mache ich das jedoch in einer Tabellenzelle, funktioniert das nicht immer. Irgendwas läuft da schief. Die Plugins scheinen in eine Endlosschleife zu kommen. Das steht endlos im Log # Autoloading (tagged) text, aber nie ein entsprechendes done.

Das eigentliche Problem entsteht erst beim Klicken und Neusetzen des Platzhalters. Irgendwann macht InDesign® dann mal den Platzhalter über das Return, das die Zelltexte trennt. Intern ist die InDesign®- Ablage von Texten nämlich so

    PrimaryStrory-Text\rTabelle1-Zelle(1, 1)\rTabelle1-Zelle(1, 2)\r....

Tabelleninhalte kommen direkt nach dem eigentlichen Text. Tabellenzellen sind dabei jeweils durch \r getrennt. Das ist ziemlich krass - aber naja. Die Platzhalter dürfen die \r natürlich nicht rausschmeißen, sonst ist das ganze Dokument kaputt. Deshalb passe ich auf die \r auf wie der Spitz. Bei Bedarf muß dann ein Platzhalter eben geändert werden. Ich kann seinen aber Wirkungsbereich nicht einfach einschränken in der Art:

So steht es in InDesign® (Eckige Klammern sind die Platzhalter) :

    ....[Tabelle1-Zelle(1, 1)\r][Tabelle1-Zelle(1, 2)]\r...

Ich will aber die eckige Endklammer VOR dem \r :

     ....[Tabelle1-Zelle(1, 1)]\r[Tabelle1-Zelle(1, 2)]\r...

So läuft das nicht. Ich muß den gesamten Platzhalter entfernen und dann über den neuen (kleineren) Bereich NEU setzen.

Das wäre mal Punkt 1. Jetzt kommt Punkt 2:

Wenn ein Platzhalter geladen wird, kann das natürlich TaggedText sein. Dieser Text kann weitere Platzhalter enthalten. (Das ist eigentlich nicht okay. So was tut man nicht. Aber "man" ist ja immer genau einer weniger als Alle.). Jedenfalls muß der neue Text mglw. auch noch mal geladen werden. Das schafft natürlich gewisse Probleme. Im Quelltext hab ich dazu die folg. Bemerkung stehen (OMG, auch schon fast elf Jahre her.)

//	
// 20.02.2004 : Kommt man hierher über ein Load-Skript, führt der Aufruf zu einer Endlos-	
// schleife, denn natürlich befindet sich an der Stelle *pos* ein Platzhalter - nämlich der, der	
// hier gerade geladen wird.	
//	
load_placeholder (new_content, current_placeholder, ...);

Damit die Endlosschleife vermieden wird, bekommt die Laden-Funktion den aktuellen Platzhalter mit current_placeholder mitgeliefert. Und den gibt sie dann auch an load_placeholder weiter. Das passt dann drauf auf, dass zwar in dem neuen Bereich new_content alles neu geladen wird, aber nicht, wenn da current_placeholder drüber liegt.

Soweit klar?

Man sieht jetzt auch schon, was passiert. Den current_placeholder gibts gar nicht mehr. Der wurde ja weiter oben gerade entfernt und (mit gleichen Daten) neu angelegt. Da kann das load_placeholder aufpassen wie es will. Die Lösung ist natürlich, das die Platzhalter auf ihre DATEN geprüft werden. Und so ist es jetzt auch gefixt.

Dazu gibt es jetzt die neue Funktion

    strch

Mehr dazu in der Doku.

Die Funktion strlen gibt ja die Anzahl der ZEICHEN im String zurück, nicht die Anzahl der Bytes Kann man auch irgendwie die Anzahl der Bytes rausfinden?

Die Funktion hat einen zweiten (optionalen) Parameter. Default ist 0. Hat dieser Parameter den Wert 1, wird die Länge des Strings in Bytes berechnet. Das geht schon länger, nur in der Doku hat die Angabe gefehlt. Das ist jetzt nachgeholt.

Gibt es eine Möglichkeit, mit Hilfe von cScript die Größe einer Datei zu bestimmen?

Bisher nicht. Ab jetzt

    file::size

Damit kann die Größe von Dateien und Ordnern bestimmt werden. Mehr dazu in der Doku.

Immer wenn ich eine neue InDesign® angelegt habe, erscheint im Logfile diese Meldung hier:

    # == ERROR 1201 (oberste Ebene nicht gefunden) while building/reorganizing products ==
    #     Initializing process:
    #     Internal : ImportFocus::ImportFocus
    #     Intention : Determine start page and destination layer.
    #     Translate background layer definitions ('except', 'behind', ...) into existing document layers.
    #     Loading background data and opens progress bar if needed.
    #     MessageNr : 5

Was ist das?

Das passiert nur bei geöffneter Palette "Produkte des Dokumentes". Diese Palette passt ihren Inhalt natürlich immer an das aktuelle Dokument an. Beim Anlegen eines neuen Dokumentes kommt die Meldung über einen Dokumentwechsel bevor das Dokument zum aktiven Dokument gemacht wird. Die Meldung muss einen in diesem Fall nicht beunruhigen, trotzdem wird das Ermitteln der Produkte des Dokumentes jetzt an dieser Stelle unterbunden.

Früher konnte man mal per Drag & Drop ein Seitentemplate einer Seite zuordnen. Mit der aktuellen Version (4.0 Rev 7021) geht das, zumindest unter Windows mit InDesign® CS6, nicht; das Drag&Drop ist deaktiviert (siehe Screenshot).

Die Zuordnung über den Button an der Palette funktioniert einwandfrei.

Mit Comet3.4 ging es auch nicht mehr. Jetzt geht es wieder.

Wenn ich in dem Dialog zur Einstellung der Eigenschaften von Templates das BuildSupport-Skript ändere, werden offenbar nicht alle Untertemplates geändert. Das Template für rechte Seiten hat danach immer noch die 0.

Das ist gefixt.

Ich mache folgendes:

elements = page::templates::count_elements(pageTemplateId);

Das Übergebene Pagetemplate hat definitiv nur ein Element, aber es wird mir 3 zurückgegeben. Sind irgendwie immer zwei zu viel.

Der Fehler trat nur in XML-Offline-Pools und SOAP-Vrbindungen auf und ist gefixt. Jetzt wird die richtige Anzahl zurückgegeben.

Falsch waren auch die Funktionen page::templates::get_element_info_by_sequ und page::templates::get_element_info_by_index. Da wurde dann immer das erste Element mit der passenden Sequenz (bzw. passendem Index) gefunden, egal, zu welchem Seitentemplate es gehört hat. Das ist ebenfalls gefixt.

Wir benötigen folgende Gestaltungsregeln für Tabellen:

• Zeilenhöhe
• Spaltenbreite
• Gleichmäßige Spaltenbreite

Es gibt die folgenden neuen Regeln

1. Zeilenhöhe : Ändern von Zeilenhöhen in der ERSTEN Tabelle des Textes.
2. Spaltenbreite: Ändern von Spaltenbreiten in der ERSTEN Tabelle des Textes.
3. Spaltenbreiten anpassen : Die Spalten des angegebenen Bereiches bekommen alle die gleiche Breite. Insgesamt sind die Spalten bei Rahmenanpassung (3. Parameter) so breit, dass die Tabelle genau den Rahmen ausfüllt, in dem sie beginnt. Ohne Rahmenanpassung wird die bisherige Summe der Breiten gleichmäßig verteilt.

Für alle drei Regeln gilt : Bei verketteten Textrahmen wird im gesamten Text der Kette nach der Tabelle gesucht! Es wird immer die ERSTE gefundene Tabelle des Textes der Rahmenkette bearbeitet. Haben mehrere Rahmen der Kette diese Regel, wird die Regel mehrfach ausgeführt!

# [Microsoft][SQL Server Native Client 11.0]Das COUNT-Feld ist nicht korrekt, oder es besteht ein Syntaxfehler, SQLSTATE=07002

Das Problem tritt nur unter Windows und mit Unicode-MSSQL-Datenverbindungen auf.

In den Texten "Dokument" und "Datenbestand" der Aufgabenpalette werden keine Tabs gezeigt. Die Zeichen werden einfach weggelassen. Das ist nur unter Windows so.

Das verwendete Standard-Control für den MultilineText verschluckt unter Windows die Tabs offenbar. Eine vollständige Lösung dafür wäre, ein eigenes Control zu implementieren. Aufwand Minimum 2-3 Wochen. Wenn Sie das wollen, machen wir das natürlich. Als pragmatische Lösung werden die Tabs in der Anzeige jetzt lediglich durch 4 Blanks ersetzt.

Das geht jetzt.

Ich habe in meiner Aufgabenliste auch geänderte  Text-RAHMENPlatzhalter. Wenn die Dokumentauswahl im TEXT des Rahmen steht, werden diese Einträge aber nicht ausgewählt, sondern immer nur dann, wenn auch tatsächlich den RAHMEN auswähle. Irgendwie ist das ja auch klar. Andrerseits ist der Text ja durch den Rahmen entstanden - dann könnte der Platzhalter ja auch markiert werden, oder?

Ja, klingt logisch. Ist bisher niemandem aufgefallen. Das ist jetzt wie oben gewünscht realisiert.

In der Aufgabenpalette wird ein Textplatzhalter als geändert angezeigt. Wenn der Text des Platzhalters etwas länger ist und der Textänderung sehr kurz (z.B. nur aus einem Zeichen besteht), dann kann man die geänderte Textstelle nur sehr schwer im Dokument finden.

Die Angabe "1. Differenz" ist jetzt erweitert um das Textstück, das direkt nach der Abweichung steht. Z.B.

Dokument : ABCDEEFG
Datenquelle : ABCDEFG
1. Differenz : [5] 'E' direkt vor 'EFG'

Zusätzlich wird bei ALT-Klick in die dritte Spalte des Status-Feldes nicht mehr der gesamte Text des Platzhalters im Dokument ausgewählt, sondern nur noch der Text ab der ersten Änderung bis zum Platzhalter-Ende.

Die Zeichen werden jetzt einheitlich dargetsellt. Damit ist das Problem behoben.

"%!TT<ParaStyle:>aaa
<ParaStyle:>bbb
<ParaStyle:><CharStyle:tst>ccc<CharStyle>"

Wenn ich davon mit get_netweight_str den Netto-Text hole, erhalte ich das hier
als Ergebnis

"aaa
bbb
CharStyle:>ccc

Der Fehler ist gefixt. Er hatte auch Einfluß auf die Darstellung des "Dokument" der Aufgabenpalette.

Mein Platzhaltertext enthält Text der Form "12/15". Unter Windows wird daraus in der Aufgabenpalette unter 'Dokumenttext' "12\15".

Das ist natürlich eine Folge von Bug 3659. Weil dort fälschlicherweise angenommen wurde, dass der Rahmeninhalt ein Pfad ist, wurden danach auch alle / durch systemkonforme \ ersetzt.

Ist mit Bug 3659 gefixt.

Egal, wie aktuell der Text eines Rahmen-TEXTplatzhalters ist, der Rahmen erscheint IMMER in der Aufgabenpalette. Dort werden dann aber aktueller Text und Datenpool-Text als gleich erkannt.

Ja. Um den Sync-Status zu berechnen, wurde leider als Dokumenttext immer der Bildpfad des Rahmens verwendet. Der ist natürlich bei Textplatzhaltern leer. Nur wenn der Platzhalter den leeren Text eingesetzt hat, kam der Rahmen also nicht in die Aufgabenliste.

Um in der Aufgabenpalette aktuelle Dokument-Änderungen anzeigen zu können, wird hier der Text jeweils neu ermittelt. Hier wurde auch bisher schon der richtige Dokumenttext verwdendet - was dazu geführt hat, dass der Platzhalter zwar als "Out of sync" markiert war aber die Palette keine Änderungen erkennen konnte.

Das ist gefixt.

Sobald im Skript-Editor etwas schreibe, erscheint plötzlich über dem Texthintergrund das Button "Überfrüfen". Das kann ich dann auch klicke - aber es stört halt, dass es über dem Text (und nicht unten bei den anderen Button) liegt.

Je echt, nervt total. Mich auch. Das Button liegt jetzt wieder an der richtigen Stelle.

hyperlink::get_source kann nur Links von RAHMEN holen, nicht von Textstellen.

Das geht jetzt auch für Textbereiche, siehe dazu in der Doku.

frame::textlength liefert die Textlänge immer ohne Tabellen-Inhalte. Will man durch den gesamten Text inkl. aller Tabellenzellen, bräuchte man aber die gesamte Länge :-(

frame::textlength hat jetzt einen weiteren Parameter analog textmodel::fullllength mit dem man auch die Länge inkl. aller Tabelleninhalte erhalten kann.

In der Doku steht, dass textmodel::fulllength (total) folgende Ergebnisse liefert :

    0 : nur Textrahmen
    1 : gesamte Textkette

Das scheint abef nicht zu stimmen. Ich bekomme jedesmal die gleiche Länge - nämlich die über die gesamte Textlänge.

Ja, die Doku war an dieser Stelle falsch. Gemeint war:

    0 : Länge des Haupttextes
    1 : Länge des Textes inkl. aller Tabellenzellen

Das ist in der Doku korrigiert.

Ein Platzhalter lädt einen Text über die Funktion  textmodel::replace(). Dieser Text enthält TaggedText und ein " - Zeichen (Quotation Mark , <0x0022>).

Beispiel:

%!TT<CharStyle:fett>1/4" Schlüssel<CharStyle:>

Beim Laden des Textes wird das Quotation Mark allerdings trotzdem durch Typografische Anführungszeichen ersetzt. Dies ist anscheinend abhängig von den Importoptionen von Tagged-Text über den Platzieren-Dialog von InDesign® Ablage—>Platzieren…—>Importoptionen—>Typografische Anführungszeichen verwenden. Ist der Haken hier gesetzt, so werden die Anführungszeichen auch im Platzhalter ersetzt.

Dafür gibt es jetzt die Funktionen

prefs::get_convert_quotas
prefs::set_convert_quotas

Mehr dazu in der Online-Doku.

Es gibt ja einige Möglichkeiten herauszufinden wie ein Hyperlink hervorgehoben werden soll. Ob die Linie(n) gestrichelt sind oder durchgezogen kann ich aber nicht erfragen.

Nimmersatt! Die Funktion hyperlink::borderwidth hat jetzt den weiteren Parameter *style*, mit dem kann diese Eigenschaft jetzt erfragt werden.

Gibt es in cScript eine Möglichkeit herauszufinden, ob ein Rahmen einen Hyperlink gesetzt hat?

Bisher nicht. Ab jetzt : hyperlink::get_source. Mehr dazu in der Online-Doku.

Kann ich mit run_javascript den return-Wert des ausgeführten Javascriptes abholen?

Nein, bisher ging das nicht. Das Ergbnis des Aufrufes iat laut Doku immer (nur) die Angabe, ob das Skript erfolgreich ausgeführt werden konnte oder nicht.

Ab v3.4 R7021 hat die Funktion einige zusätzliche Parameter, mit denen kann der return-Wert des Skriptes abgeholt werden. Mehr dazu in der Online-Doku.

Das PullDown für die Produkttemplates im Dialog für den Seitenaufbau reagiert nicht auf die Auswahl der Domain.

Gefixt

Tja, und das schon seit Version 1 der Comet-Plugins. Keiner hats gemerkt - jetzt ists gefixt.

Ist nur ein Schreibfehler : "Um die Dokumentauswahl mit einem Platzhalter zu verknüpfen, klicken Sie bitten in ...". So kann ich nicht arbeiten!

Na gut - gefixt.

Die Funktion link::gettext liefert immer nur einen Leerstring als Ergebnis.

Ja, die Funktion ist deprecated und durch die Funktion link::content ersetzt. Ich habe das in der Doku jetzt entsprechend eingetragen.

NEU : Seitentemplates kann ein Skript zugeordnet werden. Dieses Skript wird dann jedesmal ausgeführt, wenn eine Dokumentseite mit diesem Seitentemplate versehen wird. Der Aufruf erfolgt sowohl bei manuellen Verknüpfungen als auch beim Produktaufbau, Reorganisationenen und bei Aufrufen des Skriptbefehles page::set_info mit dem Info-String "id".

Die Skripte werden als Actions mit der ClassID 54 definiert.

Mehr dazu in der Doku.

Du hast in Bug 3557 ja die Login-History in den Windows-Benutzerordner "verbannt". Kannst Du das auch für die checkout-xml der Publikationspalette tun? Das Problem haben wir da nämlich auch.

Gefixt in R5958

Wir benötigen einen Scriptbefehl zum Ändern bereits definierter Farbfelder.

Dazu gibt es jetzt die Funktionen

color::count_swatches ()
color::get_nth_swatch ()
color::redefine_swatch ()
color::get_space ()
color::get_tint ()
color::get_colors ()
color::is_spot ()
color::is_locked ()
color::get_type ()
color::is_reserved ()

Das ist auch ein falscher Name. Der erste Pfadteil ist ja leer. Kein Wunder, dass das nicht funktioniert. Und es ist ein typisches InDesign®- Ding, dass NICHTS auf 0 oder leer geprüft wird.

Wir fangen diesen Fehler jetzt vorher ab. Im Logfile steht dazu dann diese Meldung

# Wrong style name ':style_name', cannot apply this style!

Ein Platzhalter in der Tabelle wird, trotz nicht korrekter Daten, nicht auf "Changed" gesetzt.

Gefixt.

Dieser Fehler tritt natürlich nicht immer auf - es muß schon ein ganz besonderer Saft sein. Nämlich:

1. Mehrspaltiger Text
2. Im Text sind Absätze mit der Einstellung "Spaltenspanne" oder "Unterteilte Spalte"
3. Der Text eines Absatzes mit Spaltenspanne/Unterteilte Spalte ändert sind beim Laden so, dass er über eine andere Zahl von Spalten verteilt werden muss als vorher.
4. Dieser Text muß sich genau im letzten Rahmen der aktuellen Textkette befinden.

Nur dann tritt der Fehler auf.

Das ist gefixt.

FYI

Wen es interessiert, hier die Erklärung.

Gut zu wissen 1

Mehrspaltige Texte werden von InDesign® als Liste von Textstücken verwaltet. Ein zweispaltiger Text über drei Rahmen besteht aus sechs Textstücken. Will man den Übersatz bestimmen, fragt man also das sechste Textstück. So weit so gut. Ein bißchen unübersichtlicher wird es, wenn der Text Spaltenspannen enthält. Jede Spaltenspanne erzeugt nämlich selbst ebenfalls Textstücke, und zwar für jede aktuell belegte Spalte eines.

Gut zu wissen 2

InDesign® rendert Textänderungen erst dann, wenn wirklich gezeichnet werden muß. Will man die aktuelle Textgestaltung haben (eine Voraussetzung zur Ermittlung des Textübersatzes), muß das Rendern ausdrücklich erzwungen werden.

Und jetzt zur Situation

1. Der Text wurde geändert.
2. Wir holen das letzte Textstück.
3. Wir lassen bis zu diesem Textstück alles neu zeichnen was "damaged" ist.
4. Wir ermitteln den Übersatz im letzten Textstück.

PENG!

Das letzte Textstück ist nicht mehr das letzte Textstück. Weil sich die Spaltenverteilung geändert hat, ist die Liste der Textstücke jetzt länger. Im vorher letzten Teilstück steht jetzt ein ganz anderer Text. Und am Ende ist ein neues Teilstück entstanden. Und unglücklicherweise ist unser altes letztes Teilstück das Ende einer Spaltenspanne geworden - die ... keinen Übersatz hat.

Oder eben :

Do des muas ma hoid kenna schoo da Bladl Hendl da, hog di hi hallelujah sog i, luja, von: Jedza soi gschmeidig nix Gwiass woass ma ned nomoi Wurscht hod trihöleridi dijidiholleri Deandlgwand. Fei ned woar Gams Buam zünftig schaugn Brodzeid, Charivari Buam naa ham. Edlweiss noch da Giasinga Heiwog auf’d Schellnsau Milli middn, an nia need. Gamsbart des is schee Bussal wia hoid wea ko, dea ko is des liab bittschön kimmt. Kloan schoo auf der Oim, da gibt’s koa Sünd des wiad a Mordsgaudi bittschön, ebba Schbozal heid Woibbadinga. Spernzaln wia da Buachbinda Wanninger lem und lem lossn nomoi naa ghupft wia gsprunga, Lewakaas! De Sonn pfenningguat wann griagd ma nacha wos z’dringa, pfiad de i mechad dee Schwoanshaxn Almrausch i hab an. Gidarn i waar soweid auf der Oim, da gibt’s koa Sünd nackata, und glei wirds no fui lustiga: Habedehre mei wos Xaver Schneid i spernzaln!

Kumm geh schaugn gfreit mi Woibbadinga und sei back mas Kuaschwanz! Radler Trachtnhuat Fünferl Broadwurschtbudn des muas ma hoid kenna samma auffi. Af Maderln Biagadn, da! I Gams hogg ma uns zamm i bin a woschechta Bayer, Semmlkneedl a Hoiwe. Soi Woibbadinga auffi Resi, Vergeltsgott Gamsbart: Xaver Foidweg hoid do legst di nieda gwiss, ned und sei in da greana Au! Schüds nei de i sog ja nix, i red ja bloß Kuaschwanz, Schorsch Biawambn. Obandeln bittschön nia need des is a gmahde Wiesn Foidweg measi Biaschlegl. Om auf’n Gipfe wos naa jo mei measi Jodler bitt Maderln Schneid hogg ma uns zamm i hob di liab. Baddscher sammawiedaguad boarischer, ognudelt. Oba i hob di liab Schmankal a geh Musi hea? Wia da Buachbinda Wanninger sog i sog i Ewig und drei Dog mi Steckerleis i, Engelgwand.

Om auf’n Gipfe Kuaschwanz oans Meidromml nix Gwiass woass ma ned, gscheit. A bissal wos gehd ollaweil hinter’m Berg san a no Leit do legst di nieda zua Fünferl sauba. Naa Edlweiss gschmeidig ghupft wia gsprunga, Milli. Gamsbart samma Goaßmaß gscheckate auszutzeln i moan oiwei, Schaung kost nix: Brodzeid Kuaschwanz wos von Schdeckalfisch, dahoam jo leck mi greaßt eich nachad gscheckate! Pfenningguat trihöleridi dijidiholleri ognudelt wos Deandlgwand Schbozal obacht Resi back mas midanand a bravs. A so a Schmarn sei wos Kuaschwanz i daad. A Woibbadinga wann griagd ma nacha wos z’dringa oamoi und Biazelt nia need, Gidarn auf gehds beim Schichtl glei obacht. I moan oiwei i Mamalad is ma Wuascht ham nackata Breihaus. Ozapfa da hoam damischa Spezi mechad im Beidl mi auf’d Schellnsau, a bravs. Fünferl Breihaus es.

Der Fehler tritt als Seiteneffekt des Features aus Bug 3601 auf und ist gefixt.

Durch die Einführung des Threshold-Parameters für Alphakanäle bei frame::image kann ich keine Bilder mehr mit weicher Kante platzieren. Eigentlich ist das aber gerade der Charme des Alphakanals im Vergleich zum Freistellpfad.

Ist gefixt. Als Treshold muß dafür bei frame::image ein Wert > 255 angegeben werden.

In meinem Projekt haben Bilder eigene IDs, sind aber trotzdem mit Produkten ("Styles") oder Artikeln ("Items") verknüpft. Beim Platzieren setzt der Load-Platzhalter des Rahmens die Built-By-IDs so, dass immer ein Style/Produkt in der Produktrecherche ausgewählt werden sollte. Platziere ich nun das Bild aus der Produktrecherche, funktioniert das auch. Platziere ich es hingegen mit dem gleichen Template aus der Previewpalette, funktioniert es nicht.

Das ist gefixt.

Rahmennotizen, die über die Comet Notes Palette exportiert und wieder importiert werden, gehen verloren.

Der Fehler ist in 3.4 / 4.0 R5936 gefixt.

Wenn ich in InDesign® ein Skript editiere (z.B. über die Palette Platzhalterwerte), dann gehen in dem Skript Umlaute verloren, wenn das Skript länger als 3999 Zeichen ist.

Der Fehler tritt nur bei Unicode-Datenbankverbindungen auf.

Das ist gefixt.

Achtung: Der gleiche Fehler hat auch Shapes und W2MLs der Tabelle pageitems betrofffen. Auch hier gingen beim Sichern Umlaute verloren. Das ist damit ebenfalls gefixt.

table::colorize_cmyk

Ähnliche Fälle hatten wir ja schon, es hing immer damit zusammen, dass Platzhalter neu geladen / Werte geändert wurden und offenbar das Erstellen von JPEGs InDesign® noch nicht überzeugend veranlasst, auch alle Texte neu zu rendern.

Abhilfe schafft, dass im Hintergrund nach irgendwelchen Dokumentänderungen alle potentiell geänderten Spreads im Modus kPrinting (der für die JPEG Generierung allerdings unbrauchbar ist) neu gezeichnet werden.

Nun handelt es sich hier aber um ein frisch geöffnetes Dokument, mit dem "noch gar nichts" passiert ist, trotzdem fehlen Texte. Was ist da los?

Naja, das "gar nichts" entpuppt sich im vorliegenden Fall bei näherer Betrachtung als ziemlich heftiges DocumentOpen Event-Skript, das beim Öffnen jedes Dokuments ausgeführt wird. Das können wir nicht mitkriegen und auch nicht generell behandelkn, daher gibt es für InDesign® Server den neuen Kommandozeilenparameter

-cometparanoidredraw [ on | off ]

Ist der Schalter an, werden mit dem InDesign® Server alle Spreads eines neu geöffneten Dokuments als potentiell geändert markiert und somit spätestens beim Generieren von Previews neu gerendert. Dauert einen kleinen Ticken länger, ist aber dann dafür richtig.

Wenn ich

• einzelne Seiten über Aufruf der Skript-Funktion generatePDF exportieren will
• eine Seite >= Anzahl der Spreads im Dokument angebe und
• außerdem ein PDF Profil

• der Bereich der Funktion wurde nicht ausgewertet und die Angabe "Seite" (CommandScope.PAGE) schlicht ignoriert
• die Anghabe seiten/ oder spreadweise Generierung des PDF Profils wurde falsch ausgewertet
• die Gültigkeitsprüfung für die Zielseiten bzw. -spreads war ungenügend

• entweder mit CommandScope.SPREAD aufgerufen werden (bzw. in Java spreadGeneratePDF)
• und / oder ein PDF Profile angegeben werden, das Spread-weise Generierung festlegt

Wenn Templates und deren Fortsetzungen Textketten haben, müssen ja zumindest der erste und der letzte Rahmen der Ketten immer die gleichen Kennungen haben. Das funktioniert dann aber bei Fortsetzungen nicht mehr, weil ja die Kennung jetzt nicht mehr eindeutig ist. Es kann durchaus passieren, dass der erste Rahmen "oben" mit dem letzen Rahmen "unten" verlinkt wird.

Das ist gefixt. In diesem Fall wird jetzt immer der letzte Rahmen 'oben' mit dem ersten Rahmen 'unten' verlinkt.

Mit diversen Tags, z.B. <login>, <user>, <host> (siehe hier), kann ich in Platzhalter-Anweisungen auf aktuelle Umgebungs-Einstellungen zugreifen. Folgendes würde auch noch interessieren:

• Aktuelle Srachversion von InDesign®
• TCP/IP
• Server oder Desktop
• MacID
• Versions-ID (wie system::version)

Diese Tags gibts es jetzt zusätzlich (siehe auch hier):

• <lang> : Sprachversion von InDesign® wie system::language
• <tcpip> wie system::tcpip
• <is_server> : 0 : Desktop, 1 Server
• <macid> : wie system::macid
• <version_id> : CS-Version wie system::version

Die Angaben der Palette "Einstellungen" werden im XML- und SOAP-File in der Datei datafiles.xml gesichert. Unter ODBC ist dafür die Tabelle globals vorgesehen. Enthält diese Konfiguration Aliasname für Pfade oder Dateien, dann wird das unter ODBC aber nicht gelesen. Erst wenn in der Palette "Einstellungen" ein Alias geändert wurde, ist dieser Alias auch in Pfaden auflösbar.

Das ist gefixt. Auch unter ODBC werden die Aliasnamen jetzt direkt nach dem Login registriert.

Ich habe eine Tabelle, dessen Zellen in der ersten Spalte verbunden sind. Diese Tabelle ist jetzt blöderweise größer als das Seitentemplate und es ist eine Fortsetzung definiert. Natürlich passt diese nicht zu umbrechende Tabelle auch nicht in die Fortsetzung und so macht er wieder eine Fortsetzung. Natürlich passt diese nicht zu umbrechende Tabelle auch nicht in die Fortsetzung und so macht er wieder eine Fortsetzung. ... ... (Bei Seite 650 habe ich dann dem InDesign®- Server eins aufs Dach gegeben.)

Ich habe jetzt zwei recht doofe Probleme.

1. Eigentlich muss ich hier etwas umbrechen, was ich nicht umbrechen kann, da im PubServer bereits die Tabellenzellen verbunden werden. :( Das dürfte in dieser Konstellation unlösbar sein.
2. Der Comet dürfte doch eigentlich nicht bis zum St.-Nimmerleinstag weitermachen, sondern sollte idealerweise ganz bockig im Übersatz bleiben, weil er eh keine Chance hat fortzusetzen, oder? Kannst Du das abfangen?

Problem

Das Problem besteht darin, dass durch das Anlegen weiterer (kleiner) Rahmen der Übersatz überhaupt nicht verändert wird. Keiner der Folgerahmen kann auch nur eine einzige Zeile der Tabelle zeigen.

Und das Problem ist noch etwas allgemeiner: Die Tabellenzellen müssen ja nicht zwangsläufug verbunden sein. Es reicht vollkommen aus, dass eine Zeile zu hoch ist. Es reicht auch schon, dass ein Text zu hoch ist.

Lösung

Der Prozess des Produktaufbaues prüft jetzt nach dem Anlegen einer Fortsetzung jedesmal die aktuellen Übersätze aller Rahmen, die Fortsetzungen haben. Wurden ausgehend von der ersten Fortsetzung bereits zwei neue Seiten mit Fortsetzungen gefüllt und hat sich der Übersatz nicht geändert - dann geben wir auf.

Bemerkung 1

Das klappt auch dann, wenn der Umbruch innerhalb einer Tabelle ist.

Bemerkung 2

Zwei Seiten werden deshalb versucht, weil die Höhe der Rahmen jeweils von den verwendeten Seitenelementen abhängt und in aller Regel zweiseitige Dokumente oder Dokumente mit zweiseitigen Seitentemplates aufgebaut werden. Der theoretische Fall, dass mehr als zwei Seiten benötigt werden, um auf ein Seitenelement zu treffen, das den Übersatz verkleinern kann, ist lösbar und kann als Feature-Request (Aufwand voraussichtl. zwei Tage) gelöst werden.

Reaktion

Woran erkennen Sie, dass der Aufbau eines Produktes wegen eines nicht-lösbaren Übersatzes abgebrochen wurde?

• Im Dokument findet sich natürlich mind. ein Rahmen mit Textübersatz.

• Im Logfile finden Sie Meldungen der Art

# ============================
#
# Giving up solving oversets for this product
#
# ============================
# ERROR while building products : Objekt (3, 0, 0 ) :

In mind. einem Rahmen des Templates konnte der Übersatz nicht behoben werden. Das Anlegen der Seite 6 wurde deshalb unterbunden.

• Hat das aktuelle Template ein Aufbauhilfe-Skript, wird dieses Skript mit der Situation
  
      gSituation == kUnsolvableOversets
  
  aufgerufen. Der Aufruf erfolgt ganz am Ende des Aufbaus des Produktes. In der Liste gFrames finden Sie jeweils die ersten Rahmen der Textketten, deren Übersatz nicht auflösbar ist. Hier ein Beispielskript, das diese Rahmen rot einfärbt:
  

#include "internal/types.h"
							
int main ()
{
	int			f		= 0;
	ItemRef		frame	= item::alloc ();

	while (1)
	{
		if (gSituation == kUnsolvableOversets)
		{
			if (!gFrames)	break;
			for (f = 0; f < itemlist::length (gFrames); f++)
			{
				itemlist::get (gFrames, frame, f);
				frame::color_rgb (frame, 255, 0, 0);	
			}
		}

		// Handle other situations
		
		break;
	}
	
	return 0;
}

Die in R5567 eingeführte Parser-Methode "Optimiert" funktioniert am Mac nur für XML-Offline. Im SOAP-Fall hilft sie leider nichts.

Das ist gefixt. Die Methode "Optimiert" funktioniert jetzt am Mac auch für SOAP-Verbindungen.

Wenn in einer MS-SQL-Datenbank die Spaltennamen sehr lang werden (ab ca. 50 Zeichen), stürzt der Comet beim Aufruf ab, und zwar sowohl auf dem Mac (CS6, Comet 3.4 Rev 5321, mit Openlink-Treiber) als auch auf dem PC (CS6, weiss grad nicht, mit Native Client. Unter MySQL kann ich das Problem so nicht nachvollziehen; möglicherweise hat das mit Unicode/UTF-16 vs. UTF-8 zu tun.

Das ist gefixt.

ich habe folgenden bug in indesign cs 6 festgestellt. dieser tritt nach entfernen der Comet Plugins nicht mehr auf.

als voreinstellung für das dokument muss der sogenannte intelligente textumfluss mit einfügen von neuen seiten am ende des dokuments und löschen von leeren seiten aktiviert sein.

wenn auf so erzeugte seiten nachträglich eine andere musterseite angewandt werden soll, wird an der stelle eine neue seite mit der soeben angewandten als musterseite erstellt und bereits bestehende seiten gegen das dokumentende verschoben.

dieses verhalten zeigt sich beim anwenden über c-script genauso wie bei manuellem zuweisen von musterseiten.

Problem

Das Problem daran ist folgendes:

InDesign® löscht bei Musterseiten-Wechseln freigestellte Musterrahmen nicht automatisch. In den allermeisten Fällen ist das (mindestens) verwirrend. Im Produktaufbau und bei Seitenreorganisationen kann es sogar zu Fehlern führen.

Stellen Sie sich vor, Sie haben eine Seite mit dem Musterseiten-Rahmen F. Dieser Rahmen wird freigestellt. Es entsteht der Rahmen F'. Ändern Sie jetzt die Musterseite, bleibt F' auf der Seite stehen - zusätzlich zu den neuen Musterseiten-Rahmen. Jetzt ändern Sie die Musterseite noch einmal, zurück auf die erste Einstellung. Oooops, jetzt haben Sie die Rahmen F und F' auf ihrer Seite. Das kann nicht richtig sein!

Die Comet-Plugins löschen daher beim Wechsel von Musterseiten automatisch alle freigestellten Musterseiten-Rahmen (siehe auch Bug 3255 und Bug 3521). Dieses Verhalten führt aber in einigen speziellen Fällen zu Fehlern und kann daher abgeschaltet werden. Fehler treten immer dann auf, wenn die Musterseiten verkettete Textrahmen haben und im Dokument der intelligente Textfluß mit automatischem Anlegen/Löschen von Seiten aktiviert ist. Beim Wechsel der Musterseite geht der Textfluß dann nicht mehr durch die geänderte Seite und der automatische Textfluß legt sofort eine neue Seite an.

Lösung

Es gibt jetzt des neue Menü

    Zusatzmodule -> Comet -> Bei Musterseitenwechsel freigestellte Rahmenlöschen

Mit diesem Menü kann das automatische Löschen freigestellter Musterseiten-Rahmen bei Musterseiten-Wechseln abgeschaltet werden.

Zusätzlich kann das Verhalten mit den neuen Skript-Befehlen

prefs::get_remove_old_masters ()
prefs::set_remove_old_masters ()

erfragt und geändert werden.

ACHTUNG

Beachten Sie, dass ein Abschalten der Funktionalität zu Fehlern beim Produktaufbau und bei Seitenreorganisationen führen kann!

Diese Option soll ja sicherstellen, dass zuerst leere Dokumentseiten gefüllt werden bevor neue Seiten angelegt werden. Das funktioniert auch. Meine Seiten sind aber nicht ganz leer - auf den im Seitentemplate eingestellten Hintergrundebenen sind nämlich Inhalte drauf. Sollten die nicht ignoriert werden?

Die Prüfung ignoriert ab jetzt in diesem Fall Rahmen der Gestaltungsebenen.

Die Struktur ist komplex: Es gibt im XML ein placeholder-Element, das Metadaten und den kompletten Platzhalter-Inhalt enthält, darunter noch eine Liste von Rahmen, über die sich der Platzhalter erstreckt (bei verketteten Textrahmen können das mehrere sein).

Aktuell wird bei mehrspaltigen Texten derselbe Rahmen in der genannten Liste mehrfach aufgeführt, jeweils (erfreulicherweise wenigstens) mit identischem Inhalt. Die Anzahl der Vorkommen entspricht der Anzahl von Spalten im Textrahmen PLUS für jeden Absatz, der über mehrere Spalten geht noch einmal extra.

Das ist gefixt.

Genauer: Die Platzhalter sind vorhanden, als Breite der vom Text eingenommenen BBox und Area wird aber 0 angegeben.

Das passiert bei Platzhaltern, die über genau eine Zeile gehen, die mit CR (Ascii 13) abgeschlossen wird und ist gefixt.

Ich habe ein Rahmen, der wiederholende Elemente anlegt. Bei Neuanlegen der wiederholenden Elemente werden alle bisherigen Wiederholungen gelöscht und neu angelegt. Soweit ist alles gut.

Jetzt dupliziere ich den Rahmen inkl. aller Wiederholungen. Wenn jetzt neu angelegt wird, bleiben die Rahmen im Dokument stehen und es werden weitere Rahmen erzeugt.

Erklärung

Ja, und wenn man die Kopie auf der gleichen Seite anlegt, werden die Wiederholungen des Originales gelöscht. Jeder Rahmen der Wiederholung bekommt bei seiner Anlage die Information, welcher Rahmen ihn erzeugt hat. Damit können die Rahmen bei Neuanlage gelöscht werden. Beim Duplizieren von Rahmen wird diese Information von InDesign® natürlich nicht automatisch angepasst. So entsteht der Fehler.

Lösung

Wir sind der Auffassung, dass das ein ganz spezieller Anwendungsfall ist, der nicht vom Comet-Standard-Leistungsumfang abgedeckt wird. Eine vollständige Lösung des Problemes bearbeiten wir gerne als FEATURE-Request. Der Aufwand dazu wird +/- eine Woche betragen. In der Standardanwendung kann aber der Befehl

Bearbeiten -> Als Cometgruppe einfügen

verwendet werden. In diesem Fall werden auch die Verweise der wiederholenden Elemente korrigiert. Siehe dazu auch Bug 3586.

Beim Duplizieren von Rahmen gehen ja alle Cometgruppen verloren (siehe dazu auch Bug 3584). Gibt es eine Möglichkeit, die Rahmen nach dem Kopieren zu einer neuen Gruppe zusammenzufügen?

Dazu gibt es jetzt den neuen Menübefehl

Bearbeiten -> Einfügen als Cometgruppe

Alle Rahmen, die damit aus der Zwischenablage eingefügt werden, werden automatisch zu einer neuen Cometgruppe zusammengefügt.

Duplizierte Rahmen sollen keine Cometgruppen mehr haben. Hintergrund ist, dass gar nicht entschieden werden kann, zu welcher Gruppe duplizierte Rahmen gehören sollen: Zur bisherigen oder bilden sie eine neue Gruppe? Was passiert, wenn zwischen Dokumenten dupliziert wird (abgesehen davon, dass die Zwischenablage ihre Herkunft vergessen hat)?

Auf dem Mac funktioniert das auch, unter Windows aber merkwürdigerweise nicht.

Gefixt.

Nach einer Reorganisation verschwinden die Magneten als wären sie gelöscht. Dieser Fehler trat nicht unter R4616, erst bekannt R5122 ebenfalls unter 5600 gefunden.

Einfache Nachstellung: Neues Template bestehen aus 2 Rahmen die über einen Magneten verbunden werden. Diese Template über die normale "Mauer" aufbauen. Darstellung der Magnete zeigt diese in ganzer Pracht. Palette "Produkte des Dokumentes" öffnen und Reorganisation anstoßen. Die Magnete verschwinden.

Ooh Mist, stimmt. Und das seit R5122. Das war am 10. Dez. 2013, also vor fast einem dreiviertel Jahr!

Gefixt.

In der Doku steht, dass frame::set_objectstyle mit einem leerem Stilnamen den Objektstil des Rahmens entfernen würde. Tut es aber nicht. Es wird immer der Stil deer "[Einfacher Grafikrahmen]" gesetzt.

Das ist richtig. Die Doku war hier mißverständlich. Gefixt ist aber dass auch bei Textrahmen der Stil "[Einfacher Grafikrahmen]" gesetzt wird. Für Textrahmen wird jetzt der im Dokument eingestellt Standardstil für Textrahmen gesetzt (also im Normalfall "[Einfacher Textrahmen]").

Wirklich nur ein lighter als light Problem :)

Wenn einem Rahmen der Standard-Objektstil "[Ohne]" zugewiesen ist und ich get_objectstyle(gFrame) ausführe, liefert die Funktion "[None]". Wenn ich aber set_objectstyle(gFrame, "[None]") mache, bekomme ich einen "Internen Fehler". set_objectstyle funktioniert dann wieder mit der Übersetzung "[Ohne]".

Ich würde erwarten, dass die Funktionen das gleich behandeln.

Ja, hätte ich auch gedacht. Tut Adobe aber nicht. ich übersetze die Namen der Standardstile deshalb jetzt selbst. In einem deutschen InDesign® geht also jeweils:

"[Ohne]", "[None]"
"[Einfacher Grafikrahmen]", "[Normal Graphics Frame]
"[Einfacher Textrahmen]", "[Normal Text Frame]"

Die Funktion frame::get_objektstyle hat jetzt ausserdem den zusätzlichen Parameter doTranslate (default 0). Ist der 1, werden Standardstile in die Sprache des verwendeten InDesign® übersetzt.

Die Funktion frame::is_textframe liefert unterschiedliche Werte je nachdem sie unter Desktop oder Server läuft.

Desktop : Textinfo: 0, 2, 0
Server  : Textinfo: -1, 0, -1

Gefixt.

ACHTUNG: Der Fix betrifft auch die Funktionen

document::html_export ()
frame::insert:macro ()
placeholder::to_xml_element ()
placeholder::get_prefix ()
placeholder::get_postfix ()
textmodel::fulllength ()
textmodel::store ()
textmodel::restore ()
textmodel::insert_macro ()
textmodel::floating ()
textmodel::hasfloating ()
textmodel::intline_ ()
textmodel::inline_above ()
textmodel::anchor ()
textmodel::get_anchor ()
textmodel::clear_placeholders ()
textmodel::remove_redundant_tags ()
textmodel::gremove_redundant_tags ()

Irgendwelche Aufrufe von document::concat mit InDesign® Server verursachen Absturz.

Gefixt.

Beim Drag and Drop von Produkten in Textplatzhalter stürzt InDesign® reproduzierbar ab.

Das ist gefixt.

Das sollte doch eigentlich nicht gehen? Rahmen dagegen können nämlich nicht Textplatzhaltern verlinkt werden.

Ein bißchen komisch ist auch, dass bei leerer Textauswahl der RAHMEN-Platzhalter gesetzt wird. Das ist vor allem dann gefährlich, wenn der Eintrag [Kein Platzhalter] gewählt wird, dann wird nämlich der Rahmenplatzhalter entfernt.

Diese Fälle sind jetzt ausgeschlossen. Textplatzhalter können nur gesetzt und entfernt werden, wenn auch wirklich Text ausgewählt ist. Rahmenplatzhalter können nur bei aktiver Rahmenwahl gesetzt und entfernt) werden.

Wenn ein Dokument kyrillische Notizen enthält, fallen beim Import die Leerzeichen weg. Genau genommen gilt folgendes: wenn ein Leerzeichen zwischen zwei InDesign®- Tags (z.B. zwei Umlauten) steht, wird es beim Import weggelassen.

Das Problem der verlorenen Whitespaces tritt ganz allgemein immer dann auf, wenn der Text einer XML-Datei sog. Entities der Form <....> im laufenden Text eines Elementes enthält. Es ist auch unerheblich, ob die spitzen Klammern XML-konform codiert sind:

<Text>Ich wei&lt;0x00DF&gt; &lt;0x00FC&gt;ber alles Bescheid.</Text>

Der gelesene Text wird jetzt leider zu :

Ich weißüber alles Bescheid.

Das kann weder im ersten noch im zweiten Fall richtig sein. Aber im zweiten Fall ist es auch noch falsch geschrieben. Leider kommen aber im Zusammenhang mit TaggedText genau die oben verwendeten Entities für "Sonder"zeichen sehr häufig vor.

Das Problem wird durch einen Fehler im verwendeten XML-Parser der Apple-CoreFoundation verursacht. Apple empfiehlt, diesen Parser nicht mehr zu verwenden und stattdessen den ebenfalls integrierten NSXMLParser zu verwenden. (NS steht für NextSTEP und ... naja, das ist auch schon eine Weile her.)

Nun, wie die Bemerkungen vermuten lassen - es gibt einen neuen XML-Parser. (Wir haben NICHT den NextSTEP-Parser verwendet. Wenn sich jetzt schon die Gelegenheit bietet, für Mac und Windows einen einheitlichen XML-Parser zu verwenden, dann nutzen wir diese Gelegenheit doch auch.)

Aus Gründen der Rückwärts-Kompatibilität sind die alten Parser weiter verfügbar und werden im Standardfall auch angewendet. Auf die neuen Pars-Möglichkeiten kann mit den Menü

    Zusatzmodule -> Comet -> XML-Auswertung

zugegriffen werden. Bitte beachten Sie, dass bereits eingelesene Dateien bei Änderungen der Einstellungen NICHT neu eingelesen werden. Folgende Möglichkeiten sind verfügbar :

• Klassisch : Windows : msxml, Mac : built-in CoreFoundation-Parser CFXMLParser
• Optimiert : Unter Windows ist die Einstellung gleichbedeutend mit "Klassisch". Unter Mac werden Whitespaces um Unicode-Zeichen der Form <0xXXXX> geschützt. Damit können Texte wie oben richtig gelesen werden. ACHTUNG: Es werden ausschließlich Entities der Art <0xXXXX> berücksichtigt. Im TaggedText "aaa<cSize:72.000000> <cSize:>bbb" geht das Leerzeichen zwischen aaa und bbb weiterhin verloren.
• Schnell : In die Plugins integrierter schneller und systemunabhängiger XML-Parser. Der Parser ist etwa 50% schneller als der CoreFoundation-Parser und msxml.

Für InDesign®- Server verwenden Sie die Programm-Option -cometxmlparser mit den Optionen:

• classic oder 1 für Klassisch
• optimized oder 2 für Optimiert
• fast oder 3 für Schnell

Unabhängig von der gemachten Einstellung werden Notizen IMMER im Modus "Schnell" bearbeitet.

HINWEIS : Bei Verwendung der Methoden "Optimiert" bzw. "Schnell" sollten bestehende Projekte vor der Produktivphase getestet werden.

Enthält der Pfad eines Eintrages der Palette "Previews" einen Namen, der mit einer Zahl, n, t, b, ... beginnt, kann die zugehörige Datei nicht gefunden werden. Offenbar wird der \ im Pfad mit dem nachfolgenden Zeichen verbunden (wenn das geht, \t z.B. geht). Man sieht das ganz gut in der Palette "Preview-Details". Dort steht dann statt

---> "C:\Users\Paul\Desktop\tolles Bild.png"

<--- "C:\Users\Paul\Desktop    olles Bild.png"

Welch ein Irrtum. Ist gefixt.

Der Fehler ist gefixt.

Die Reihenfolge, in der die Gestaltungsregeln in einer Cometgruppe ausgeführt werden, wird über die Kennung der einzelnen Rahmen festgelegt. Wenn ich die Regeln eines bestimmten Rahmens immer zuletzt ausführen möchte, muß ich also ALLEN Rahmen eine Kennung geben. Gibt es dafür eine andere Möglichkeit?

Die Kennung ∞ bewirkt jetzt, dass die Regeln dieses Rahmens immer zuletzt ausgeführt werden.

Gibt es eine Funktion zum Löschen von Nägeln und Magneten?

Dafür gibt es jetzt die Funktionen

    frame::rmv_magnets
    itemlist::rmv_magnets

Beachten Sie bitte, dass Magentabstände nach dem Ausführen von Gestaltungsregeln automatisch angepasst werden. Löscht eine dieser Regeln diese Magnete, können die Abstände also nicht mehr angepasst werden. In der Doku von itemlist::rmv_magnets finden Sie eine Beschreibung, wie Sie in diesem Fall vorgehen können.

Um zu prüfen, ob ein Dokument alle benötigten Produkte (und in der richtigen Reihenfolge) enthält, kann man die aufgebauten Produkte im Dokument gegen die aktuelle Auswahl der Produktrecherche testen. Dabei kann eine Ebene angegeben werden, bis zu der auf der Suche nach aufbaufähigen Produkten in die Produktbäume eingetaucht werden darf. Das klappt auch.

Ein Problem tritt aber dann auf, wenn sich Produkte in verschiedenen Ebenen finden: Ich habe aufbaufähige Produkte (also Produkte mit einem definierten Template) sowohl in der Ebene 2 als auch in der Ebene 3 der Produkt-Struktur.

• Wähle ich Ebene 2 als maximale Tauchtiefe, werden alle Produkte, die erst in Ebene 3 enthalten sind, als zu löschen markiert.
• Wähle ich Ebene 3 als maximale Tauchtiefe, werden umgekehrt alle Produkte von Ebene 2 als zu löschen markiert.

Ja, das ist ein Fehler. Der Vergleich der Listen wurde immer so gemacht, dass nur Produkte der tiefsten angegebenen Ebene ermittelt wurden. (Das sollte eigentlich nur dann geschehen, wenn für das sync gleichzeitig die Shift-Taste gehalten wurde).

Der Fehler ist gefixt

Reproduktion im Comic-Showcase:

Den Ordner Comet Tutorial / Comic Jahrbuch 2009 / Comic Referenz aufklappen. Der Ordner Comic Referenz sollte als Template "Standard" verwenden. Nun diesen Ordner markieren, den Seitentemplateaufbau starten mit der Einstellung "Unterprodukte der Ebene" = 1 -> Es werden alle 33 Produkte aus dem Ordner aufgebaut. Nun dem Ordner selbst ein beliebiges Template zuweisen und den Vorgang mit den gleichen Einstellungen wiederholen. -> Es wird nur ein einziges Produkt aufgebaut. Offensichtlich wird nicht rekursiv nach Produkten gesucht, sofern die ausgewählte Struktur selbst ein Template verwendet. Hat sie keins, klappt alles wie es soll.

Jetzt wo ich noch mal drüber nachdenke, bin ich selbst nicht sicher, ab es sich hierbei um einen Bug oder doch um einen Fall von "works as designed" handelt. Aber ich hätte gerne eine professionelle Meinung der Entwickler dazu.

Und hier die "professionelle Meinung derEntwickler":

Das ist richtig so. Die Idee des Verfahrens ist:

Okay, ich weiß nicht, wo sich meine Produkte für den Aufbau befinden. Aber wenn ein Produkt mit einem Template verknüpft ist, soll das aufgebaut werden. Wenn jetzt schon die oberste Ebene brauchbar erscheint (ein definiertes Template hat), wird dieses Produkt halt aufgebaut.

Aber man kann das natürlich leicht abschalten: Einfach die Checkbox

    Nur tiefste Ebene verwenden

aktivieren. Dann wird genau das gemacht, was oben gewünscht ist.

BTW : Mglw. sind die Beschriftungen im Dialog mißverständlich. Ich habe die Beschriftungen daher leicht geändert:

    Unterprodukte der Ebene --> Unterprodukte bis Ebene
    Nur tiefste Ebene verwenden --> Nur diese Ebene verwenden

Auch der Hilfetext ist jetzt etwas ausführlicher.

Hier ein Testfall zur Demonstration des Fehlers:

Man nehme einen Test-Platzhalter:

int main()
{
	textmodel::replace("<0x200A>10#mm");
	return 0;
}

Darauf eine Textgestaltungsregel:

Suche nach "#.*"
Ersetze mit: "ERSETZT"

Führe ich das LOAD aus bekomme ich im InDesign®: "{Hairspace}10ERSETZT" - Das ist richtig!

Mache ich im Platzhalter aus der 10 eine einstellige Zahl z.B. 9, erhalte ich: "{Haispace}9#mm". Der ganze Ausdruck trifft jetzt nicht mehr.

Setze ich in meinem Test-Platzhalter anstatt dem Sonderzeichen (Hairspace) ein Wald- und Wiesen-Zeichen ein. z.B. A, dann funktioniert wieder alles ganz hervorragend. ("A10#mm" oder "A9#mm")

Der Fehler ist gefixt.

FYI

Die Funktion zum Ausführen des reg. Ausdruckes verlangt eine natürlich eine Startposition, ab der gesucht werden soll. Das ist der char-Index im String, nicht, wie bisher verwendet, der Zeichen-Index.

Die Regel "Suchen/Ersetzen" sucht zuerst nach dem reg. Ausdruck, erhält eine Position und ersetzt dann. Das ergibt im aktuellen Fall:

     <0x200A>9#mm Der Hairspace ist UTF-8 : E2 80 8A

Der reg. Ausdruck "#.*" wird an der ZEICHEN-Position 2 gefunden (Hairspace, 9, #). Aber das ist die CHAR-Position 4. Weil der Hairspace eben aus DREI Chars besteht. Das erklärt auch, warum es mit A oder B oder C anstatt Hairspace geht.

Gibt es irgendeine Möglichkeit herauszufinden, wieviel Seiten in einem PDF sind?

Ooh, das ist ein schwieriges Feld.

Ich habe eine Lösung gefunden, die mit der Funktion file::pdf_count_pages angewendet werden kann. Mehr dazu in der Online-Doku.

In der Palette "Einstellungen" können ja Alias-Namen für Ordner und Dateien vergeben werden. Will man so einen Eintrag ändern, macht man einen ALT-Klick auf den Eintrag und kann einen neuen Pfad auswählen.

Aber was macht man, wenn der Pfad gar nicht existiert?

Bisher nichts. Das geht nicht. Die einzige Möglichkeit ist, den Wert direkt im Datenpool zu ändern.

Ab jetzt wird bei gleichzeitig gehaltener CMD-Taste kein Ordner/Dateidialog mehr gezeigt sondern ein einfacher Dialog mit einer Eingabezeile. Dort kann man seinen neuen Wert eintragen.

Kann ich mit cScript irgendwie die MacIDs des Rechners ermitteln?

Dafür gibt es jetzt die neue Funktion system::macid.

Am Mac liefert die Funktion system::tcpip immer 0.0.0.0.

Das ist gefixt, die Funktion liefert jetzt die aktuelle TCP/IP des Rechners.

printf der Skriptsprache erzeugt am Desktop keine Ausgabe.

Dem ist natürlich nicht so. Aber wenn InDesign® über den Desktop gestartet wird - also der Normalfall - gibt es keine Konsole, in die geschrieben werden könnte. Wird InDesign® über die Konsole gestartet, erscheinen dort auch die gewünschten Ausgaben.

Ich habe der Verhalten von printf so geändert, dass InDesign® (Desktop) ins aktuelle Logfile schreibt. Hier ist printf ("aaa\n"); also gleichbedeutend mit wlog ("", "aaa\n");.

InDesign® Server und comet_pdf schreiben weiterhin in die Konsole.

Das ist gefixt.

Ich habe einen ganz einfachen Fall:

Ein Bildrahmen wurde mit der Regel "Bildplatzerung anpassen" versehen und die Regel für Geometrieänderungen aktiviert. Verändere ich jetzt die Rahmengröße, sollte sich ja eigentlich die Bildposition anpassen. Tut sie aber nicht.

Es ist zum Haareraufen! Die Idee der Software-Entwicklung, möglichst kurze Funktionen zu schreiben und alles, was mehrfach verwendet wird, in eigenen Klassen und Funktionen zu implementieren, ist auch nicht so das Wahre.

Im vorliegenden Fall hat eine kleine Anpassung der Funktion frame::is_graphic_frame (Bug 3508) dazu geführt, dass die Gestaltungsregel "Bildplatzierung anpassen" nicht mehr funktioniert hat. Diese Funktion hatte sich auf das damals aktuelle Verhalten von is_graphic_frame verlassen.

Das Problem ist gefixt.

Gespiegelte Rahmen führen zu Fehlern bei der Gestaltungsregel "Bildplatzierung anpassen"

Das wird jetzt richtig gemacht.

Hat man die Regel "Bildplatzierung anpassen" für Geometrieämderungen aktiviert und zieht die rechte Seite nach links über die linke Seite (so dass das Bild gespiegelt wird), hört InDesign® mit einem "Protective Shutdown" auf.

Das geht jetzt (wieder).

Nach page::duplicate werden die kopierten Notizen nicht angepasst.

Gefixt.

Notizen auf Cometgruppen mit Fortsetzungen auf anderen Seiten malen ihren Verbindungspfeil falsch

Gefixt.

Absturz von itemlist::duplicate, wenn Rahmen doppelt in der Liste sind.

Gefixt.

itemlist::duplicate kann die duplizierten Rahmen ja zur Comtgruppe der Originalrahmen hinzufügen. Voraussetzung ist, dass die Originalrahmen alle zur gleichen Cometgruppe gehören (und ins gleiche Dokument kopiert wird). Das klappt auch. Enthält die Liste der Originalrahmen aber eine Notiz, die ja meist nicht Teil einer Cometgruppe sind, klappt das nicht.

Bei der Bestimmung der Cometgruppe für die Originalrahmen von itemlist::duplicate werden Comet-Notizen jetzt ignoriert. Damit ist das Problem gelöst.

Mit itemlist::duplicate kann ich zwar die kopierten Rahmen der Original-Cometgruppe hinzufügen. Ohne diese Option gehören die neuen Rahmen aber zu keiner Cometgruppe. Schön wäre es, wenn in den neuen Rahmen die gleichen Gruppenbildungen wären wie in den Originalen.

Die Funktion hat den neuen Parameter reconstruct. Ist der 1, werden neue Cometgruppen analog den Originalen gebildet.

Magnete werden jetzt übernommen wenn der neue Parameter reconstructCometData der Funktion gleich 1 ist.

Die Funktion wurde mind. seit 2006 nicht mehr verwendet und jetzt entfernt. Aufrufe der Funktion erzeugen lediglich den Fehler -1198 und eine Warnung im Logfile:

# DEPRECATED : document::join. Please use file::get_nth and document::concat instead.

Gefixt. Magnete werden beim Anfügen jetzt wiederhergestellt.

Magente zwischen Rahmen verschiedener Seiten eines Spreads werden nur dann wiederhergestellt, wenn die Seiten auch wieder im gleichen Spread liegen. Sonst werden sie gelöscht.

Mit dem Aufruf der Funktion document::concat kann ich InDesign® reproduzierbar zum Absturz bringen.

Ja, das passiert leider immer dann, wenn das anzufügenden Dokument Spreads enthält. Die Funktion war ursprünglich auch nur zum Anfügen einseitiger Dokumente gedacht. Leider habe ich versäumt, das in der Doku ausdrücklich zu erwähnen.

document::concat funktioniert jetzt auch beim Anfügen mehrseitiger Dokumente.

In der Index-Datei der Doku fehlen plötzlich (R5321) die Link zu den Funktionen, Variablen und Datentypen.

Sind wieder da.

Hintergrund ist, dass die Doku mit seit R5321 mit neuen Programm erstellt wird, das auch unter aktuellen Versionen von Mac OS X läuft.

Der Aufruf

    frame::replace_all (gFrame, "AA-", start);

führt zum Absturz von InDesign® wenn der Textindex start innerhalb einer Tabellenzelle liegt.

Das ist gefixt.

Ich habe folgendes Problem:

Ich öffne ein Dokument und baue auf der ersten Seite einige Produkte auf. Dann scrolle ich zur zweiten Seite und versuche dort ebenfalls einige Produkte aufzubauen. Diese Produkte werden aber immer auf der ersten Seite eingefügt.

Wähle ich links unten im Dokumentfenster als Zielseite die Seite 2 aus, geht alles gut. Ich kann auch einen Rahmen der Seite auswählen, oder, wenn keiner da ist, einen leeren Rahmen auf Seite 2 anlegen und wieder löschen, dann geht es auch. Aber ohne das geht es leider nicht.

Der Produktaufbau sucht automatisch nach der aktuellen "Frontpage". Offenbar liefert die dafür verwendete Funktion von Adobe dabei immer die erste Seite, wenn vorher noch nie eine Seiten- oder Rahmenauswahl im Dokument gemacht wurde. Das ist sehr mißlich.

Wir ermitteln die "Frontpage" jetzt auf eine andere Weise. Damit ist das Problem gelöst.

In der Produktrecherche können über IMAGEURL bzw. ICONURL bereits eigene Bilder über HTTP, FTP oder sonstige von file::download unterstützte Protokolle geladen werden. Kann ich auch Bilder direkt vom SOAP WebService anfordern?

Das geht ab R5307 mit den Schlüsselwörtern

    SOAPICON bzw.
    SOAPIMAGE

gefolgt von einem Doppelpunkt, LEERzeichen (Das ist wichtig!) und in Anführungsstrichen eine "fileId".

Beispiel

SOAPICON: "icons/123.png"

… fordert über die SOAP-Verbindung die Datei mit der fileId "icons/123.png" an.

Natürlich muss der SOAP WebService in der Lage sein, für diese Id eine geeignete Datei zu liefern und natürlich funktioniert das nur bei einer bestehenden SOAP Datenverbindung!

Das Änderungsdatum und Benutzer einer Notiz bleiben beim Bearbeiten in InDesign® und Einbuchen über die Publikationspalette nicht immer erhalten. Das Verhalten ist abhängig von

• den Regionaleinstellungen (InDesign® / OS Sprache und Datumsformat)
• dem Status der Einstellung "Auto-prompt different comments"

Ist diese Checkbox deaktiviert, kann das Datum und Benutzer einer Änderung später nicht mehr ermittelt werden. Dummerweise ist dieses Flag für im Whiteboard angelegte Notizen nie gesetzt.

Lösung

• Als Begrenzer für das Datums- und Benutzerfeld der Statuszeile wird jetzt ein Hairspace verwendet. Damit ist unabhängig von Regional-Einstellungen zuverlässiges Parsen beim Einbuchen möglich
• Es gibt den neuen Skript-Befehl prefs:show_note_history, damit kann z.B. im Login-Skript die Anzeige der Änderungshistorie erzwungen oder unterbunden werden.

Beispiel:

// Änderungshistorie niemals zeigen:
prefs::show_note_history(0);

// Änderungshistorie immer zeigen:
prefs::show_note_history(1);

// Einstellung aus XML verwenden
prefs::show_note_history(2);

Bei "niemals" oder "immer" wird die Checkbox in der Palette ausgeblendet. Wer mit der Änderungshistorie (und Whiteboard) arbeitet, sollte also die Zeile

prefs::show_note_history(1);

in sein Login-Skript mit aufnehmen.

Notizen, die im Whiteboard mit Seitenreferenz erstellt werden, sind nach dem Import in InDesign® plötzlich SeitenINDEX-Notizen. Nach Checkin über die Publikationspalette haben sie zudem einen ungültigen Seitenindex (-1) und beim erneuten Öffnen in InDesign® gehen sie dann ganz verloren.

Gefixt.

Beim Aufbau von mehreren Produkten bekommen wir reproduzierbar die Fehldermeldung "geometryNotValidErr". Werden die Produkte in kleineren Mengen aufgebaut, dann erscheint die Fehlermeldung nicht.

• 5 Produkte: Ok
• 10 Produkte: Ok
• 15: Produkte: Beim 12 Produkt kommt immer die Fehlermeldung
• Baue ich die ersten 11 Produkte und dann im zweiten Schritt das 12. auf, erhalte ich keine Fehlermeldung.

Der Aufbau ändert Seitengrößen, richtig? Bei mir werden einige Seiten recht groß. Die erste Seite, die groß wird, ist eine rechte Seite. Das ist offenbar ok. Dann wird die Seite 10 (eine linke Seite) groß. Dadurch verschiebt sich das interne Koordinatensystems der nachfolgenden Spreads.

Wenn ich jetzt die Seite nach ihrem Seiten-Rahmen frage, erhalte ich zwar die richtige Größe - aber das Rechteck liegt an einer ganz anderen Stelle. Gegen dieses Rechteck prüft der Aufbau aber, ob auf der Seite noch Platz ist. Z.B.

Seiten-Geometrie
    Left 1088.503937
    Top 174.330709
    Right 1683.779528
    Bottom 1016.220472

Ich will an der Stelle (0, 0) einfügen. Die gibts auf dieser Seite aber gar nicht. Bafff! Ende! geomtryNotValid!

Das ist gefixt.

Ich muss im "Post"-Skript wiederholender Elemente auf den auslösenden Rahmen zugreifen. Bisher ging das, indem ich den letzten Rahmen der Liste gFrames geholt habe. Das war der auslösende Rahmen. Jetzt geht das nicht mehr. Der letzte Rahmen ist offenbar der zuletzt aufgebaute Rahmen.

Ja, das stimmt. Die Doku sagt ja auch ausdrücklich, dass gFrames die Liste der NEU aufgebauten Rahmen ist. das wurde mit Bug 3370 in v3.4 R4600 gefixt. Auf den auslösenden Rahmen kann jetzt mit gFrame zugegriffen werden. Bisher hat gFrame immer auf 0 gezeigt.

Die Anweisung funktioniert eigentlich - außer wenn der angegebene Zellbereich innerhalb eines Zellverbundes anfängt und/oder endet. Dann beendet sich InDesign® mit der Meldung "Ein schwerwiegender Fehler ...".

Ist gefixt.

In Dokumenten werden manchmal Rahmen auch dann als Seitenelemente dargestellt, wenn das Dokument gar kein Seitentemplate ist.

Es handelt sich hierbei um Dokumente, die OHNE Comet-Plugins erstellt wurden (Das soll ja immer mal wieder vorkommen). Öffnet man diese Dokumente später mit Comet-Plugins, sind natürlich alle Rahmeneigenschaften, die durch Comet-Plugins gesetzt werden können, undefiniert. Genauer : Undefiniert sind sie nicht, sie bekommen DEFAULT-Werte. Im Fall der Seitenelemente war ein Wert falsch und konnte dann von den Plugins mißverständlich interpretiert werden.

Das ist gefixt.

Workaround

Fly-Out-Menü "Dokument (nicht) als Seitentemplate verwenden" der Palette "Seitentemplates" ZWEIMAL ausführen. (Nicht erschrecken : Beim ersten Mal werden ALLE Rahmen zu Seitenelementen. Beim zweiten Mal ist dann alles richtig.)

Beim Duplizieren von Druckbogen stürzt InDesign® ab. (auch mit CS 6 getestet, ebenfalls Absturz der Anwendung.) Wenn die comet Plugins rausgenommen werden, dann geht es.

Nach Neustart von InDesign® kommt eine Fehlermeldung, das ein Text entfernt wird. (Es kommen noch weitere Meldungen, aber alle haben den gleichen Sachverhalt.) Wenn man nach dem Text sucht, dann wird er auch angezeigt, als leerer Platzhalter Aber er kann nicht sichtbar gemacht werden oder verlässlich gelöscht werden.

Die Fehlermeldung hat definitiv nichts mit dem Bug zu tun. An der gemeldeten Stelle ist alles in Ordnung. Der Absturz passiert höchstwahrscheinlich dadurch, dass InDesign® den Dialog, der auch noch vollkommen falsch ist, mehrfach öffnen will - das führt ja immer zum Absturz.

Verursacht wird das Verhalten durch einen anderen Fehler von InDesign®, der dazu führt, dass freigestellte Musterseiten-Einträge nicht richtig ersetzt werden, wenn Musterseiten neu zugewiesen werden (siehe hierzu Bug 3255). Der Workaround um diesen Bug führt jetzt zu dem merkwürdigen Verhalten von InDesign® beim Duplizieren von Spreads. (Wahscheinlich kommt hier durch das explizite Löschen freigestellter Musterseiten-Einträge irgendeine interne Rahmenliste durcheinander.)

Der Fehler ist gefixt.

Workaround:

    ∀ Seiten
        ∀ Rahmen fr
            frame::set_script_tag (fr, "", "Comet_Masteritem");

Achtung : Damit ist dann aber die Wirkung des Fixes von Bug 3255 ausgehebelt!

Ich habe einen Rahmen mit dem fx-Effekt "Innerer Schein" versehen. Ist dieser Effekt an, kann er seine Cometgruppe nicht mehr anzeigen. Wird der Effekt wieder abgeschaltet ist die Gruppe sofort wieder sichtbar.

Offenbar ist hier in der Zeichen-Methode für die Cometgruppen noch die Transparenz (oder was auch immer) des Effektes gesetzt. Das Problem kann an bestehenden Rahmen nicht mehr gefixt werden.

Neu gesetzte Cometgruppen sind jetzt auch bei "Innerem Schein" sichtbar.

Ich habe einen Rahmen mit dem fx-Effekt "Innerer Schein" versehen. Ist dieser Effekt an, sind die eingehenden Magnete nicht mehr sichtbar. Schalte ich den Effekt wieder aus, erscheint die Magnet-Linie wieder. Auch wenn ich den Rahmen mit der Maus verschiebe, ist die Magnetkante sichtbar. Lasse ich die Maus wieder los, ist die Kante wieder weg.

Offenbar ist hier in der Zeichen-Methode für die Magnet-Kanten noch die Transparenz (oder was auch immer) des Effektes gesetzt. Das Problem kann an bestehenden Magneten nicht mehr gefixt werden.

Neu gesetzte Magnete sind jetzt auch bei "Innerem Schein" sichtbar.

Das ist gefixt.

Siehe auch nächste Zeile der Tabelle!

ich hab ein Ticket bekommen bei welche innerhalb einer Datei Mehrer Schlagschatten verwendet werden. Je Tiefer man das Dokumente untersucht, desto schlechter wird die Qualität des Schlagschattens. Woran könnte das im Plugin liegen?

Das Problem wird durch die eingeblendeten Nägel und Magnete erzeugt.

WORKAROUND

Ausblenden der Nägel und Magnete VOR dem Erstellen des PDFs. Achtung: Es genügt nicht, einfach die Druckansicht zu wählen!

Erklärung

Die Erklärung ist etwas langwieriger: Nägel und Magnete werden mit sog. Adornments gezeichnet. Diese Objekte haben u.a. (klar) eine Methode zum Zeichnen und eine, mit der sie festlegen können, welche Fläche der Seite sie bemalen werden. Im Fall der N&Ms ist das die gesamte Fläche zwischen den verbundenen Rahmen.

Die Methode zum Zeichnen verfügt über eine Angabe, wofür gezeichnet werden soll (Desktop, Preview, Druck, PDF, ...). Sind die N&Ms nicht druckbar, wird diese Methode beim Drucken und bei PDF sofort wieder verlassen.

Tests haben ergeben, das auch die Methode zum Bestimmen der Fläche beim Erzeugen von PDFs gerufen wird. Anders als in der Zeichnen-Methode hat diese Funktion aber keine Angabe, WOFÜR die Fläche bestimmt werden soll (Im PDF-Fall wäre die ja leer.) Zusätzlich wird die Methode auch von allen fx-Effekten (wie eben z.B. dem Schlagschatten) gerufen. Das ist eindeutig ein Fehler von InDesign®. Auch das ist nämlich nicht abfragbar. Und genau hier passiert der Fehler - im Falle von fx-Effekten muss die Funktion nämlich ebenfalls ein leeres Rechteck liefern.

Lösung

Mit einiger Mühe habe ich Kriterien gefunden, an Hand derer entschieden werden kann, ob die Methode zum Bestimmen der nötigen Fläche für den Desktop oder von den fx-Effekten bzw fürs Drucken/PDF gerufen wird. Damit konnte das Problem gelöst werden.

ACHTUNG

Die o.g. Kriterien sind nicht von Adobe beschrieben. Sie beruhen einzig auf Annahmen, die aus den Parametern der Funktion zum Bestimmen der Fläche gewonnen wurden. Getestet wurde mit CS6.

TEST

Es gibt einen einfachen Test, ob die Nägel und Magneten mit fx-Effekten kompatibel sind: Werden Rahmen mit ausgehenden Magneten und und mind. einem fx.Effekt verschoben, verändert sich die Lage des Effektes relativ zum Rahmen. Sie müssen den Rahmen mglw. mehrmals verschieben, um den Effekt zu sehen. Bei Schlagschatten liegt der Schatten dann beispielsweise irgendwo ganz anders auf der Seite.

Mit folgendem Vorgehen kann man InDesign® zum Absturz bringen:

1. Die Palette Template und Template-Verhalten in einem Fenster mit zwei Reitern zusammenführen.
2. Ein beliebiges Template öffnen
3. Palette "Template-Verhalten" nach vorne holen und dort z.B. die Darstellung der Rahmenkennung abschalten
4. Palette "Templates" nach vorne holen.
5. Geöffnetes Template etwas ändern, sichern und schließen
6. Jetzt mit Doppelklick ein anderes Template ändern.

---> Absturz

Das ist gefixt.

In einem Bildrahmen soll mit Hilfe der Gestaltungsregel "Bildplatzierung anpassen" das Bild zentriert werden. Das klappt auch, wenn das Produkt bereits platziert ist. Bei neuen Produkten jedoch nicht, da steht das Bild immer mit seiner Mitte auf der linken oberen Ecke des Rahmen.

Der Bildrahmen liegt etwas kompliziert. Er ist ein Inline eines Textrahmens, der Teil einer InDesign®- Gruppe ist.

Das ist gefixt.

Wir haben folgendes problem:

Es werden jobs an den indesign server cs6 geschickt und verarbeitet sowie ein pdf exportiert.

Nach genau 6 aufrufen wird eine weiterer aufruf gemacht mit dem ein bestehendes indesign-dokument geöffnet wird dann steht der server mit 100% cpu last.

im cometlog steht dann folgendes:

# Opening file '/Volumes/aaa/bbb/xxx.indd'

danach passiert nichts mehr.

Das Problem wurde durch das "häufige" Schliessen von Dokumenten verursacht. InDesign® hat dabei einige Dokument-Daten auf dem Stack behalten. Das ist an sich nicht weiter schlimm - InDesign® hat ja offenbar davon "gewußt".

Vorzugsweise beim Öffnen neuer Dokumente fängt InDesign® dann an, den Speicher aufzuräumen - weil da neuer Platz gebraucht wird. (Deshalb tritt der Fehler auch beim Öffnen von Dokumenten auf.) Jetzt sollen die frei schwebenden Dokument-Daten gelöscht werden.

Bis hierher ist alles okay. Die Daten haben aber eine Referenz auf das Dokument, aus dem sie herkommen. Auch okay. Nicht okay ist aber, dass Adobe diese Referenz aufzulösen versucht ohne vorher zu prüfen, ob das Dokument noch da ist. Dann beginnt die endlose Suche.

Daten vorher zu prüfen ist überhaupt Mangelware in den InDesign®- Funktionen. Das wird praktisch nie gemacht. Zeiger auf 0 prüfen? Pah! Textindex checken? Feiglinge! Nein, nein, wenn man einen Zeiger auf Daten bekommt, wird sofort dessen Inhalt geholt. Ich hab mal gefragt, was das soll, schliesslich frißt der Aufruf if (!ptr) return jetzt nicht so viel Heu. Doch tut er wohl, auf die Prüfungen wird angeblich aus Performance-Gründen verzichtet. Daß ich nicht lache.

Die Lösung das Problem kann also nur sein, die Daten so auf den Stack zu bringen, dass sie gleich beim Schliessen des Dokumentes gelöscht werden. Das geht natürlich. Aber man muß höllisch aufpassen. Im Fall der XML-Elemente hatte ich das nicht. Ich hab sogar davon gewußt. Aber ich hab mich gescheut, das zu machen, weil

• es viele Stellen sind,
• man die nicht automatisch findet
• Basisfunktionen betroffen sind

Aber offenbar führt kein Weg daran vorbei. Jetzt hab ich etwa 400 Code-Stellen geändert. Jetzt funktioniert alles! Ich habe eben das "Auf_und_Zu" 120 mal durchlaufen lassen.

Wenn ich eine Seite mit page::duplicate dupliziere, sind auf der neuen Seite keine Cometgruppen mehr gesetzt.

Ja, richtig. Das passiert auch, wenn die Seite mit Bordmitteln dupliziert wird. Und, noch allgemeiner, beim Duplizieren von Rahmen wird die Eigenschaft "Cometgruppe" nicht übernommen (Weil gar nicht eindeutig entscheidbar ist, was mit der Cometgruppe geschehen soll. Hier nur zwei Möglichkeiten : Zur alten Gruppe - wenn es die denn gibt - hinzufügen? Neue Gruppe bilden?)

Allerdings ist die Lage beim Duplizieren von Seiten etwas übersichlicher. Die Funktion hat deshalb jetzt den neuen Parameter recreateCometGroups. Dann werden die neuen Rahmen analog den alten gruppiert.

Bei Grafikrahmen, die mal ein Bild enthielten, aber aktuell leer sind, gibt die Funktion frame::is_empty_graphicframe ab CS6 die Antwort, dass der Grafikrahmen NICHT leer ist. Bis CS5.5 war die Antwort (richtig) JA. Bei Grafikrahmen, die noch nie ein Bild enthielten, ist die Anwort in beiden Fällen (richtig) JA.

Das ist gefixt. Die Funktion gibt jetzt wieder die richtige Antwort.

Wenn ich die Funktion xml::link_frame auf einen leeren Grafikrahmen anwende, wird der Rahmen dadurch zu einem Textrahmen gemacht. Der Fehler tritt erst ab CS6 auf, bei CS5.5 wurde Rahmentyp nicht geändert.

Der Fehler lag daran, dass frame::is_empty_graphicframe eine falsche Antwort geliefert hat (Bug 3508): Der Rahmen wurde weder als leerer, noch als leerer Grafikrahmen angesehen - also ist es wohl ein Rahmen mit dem Inhalt "Nich zugewiesen" - und die wurden automatisch in Textrahmen konvertiert.

Mind. seit CS5 ist es nicht mehr nötig, dass der Rahmen Grafik- oder Textrahmen ist, damit XML-Elemente angefügt werden können. Wir lassen mögliche Konvertierungen seit ab CS5 daher jetzt weg. Nur unter CS4 werden undefinierte Rahmen weiterhin zu Textrahmen gemacht.

Die Plugins versuchen, die W2ML auf der obersten Ebene des Dateisystems abzulegen und von dort aus zu sichern. Die Erstellung der Datei funktioniert aber nicht. Die Datei sollte ja eigentlich auch im XCache angelegt werden, oder?

Ja so ist es. Der Fehler ist gefixt.

Die InDesign®- Funktion Rahmen an Inhalt anpassen steckt voller Überraschungen, die man lieber nicht hätte. Hier der "Lustigste" davon:

Dieser Rahmen kann nicht an seinen Inhalt angepaßt werden. Das Problem ist das Trennzeichen am Ende. Es hilft auch nicht, (unsichtbare) Leerzeichen anzufügen. Auch andere Trennzeichen (soft hyphen, non-breaking hyphen, figure dash, en dash, em dash) gehen nicht.

Eine Lösung wäre ein Overline oder ein Underline mit Grundlinienversatz. In beiden Fällen müssen wahrscheinlich auch die Schriftgröße und evtl. der Schriftschnitt angepaßt werden.

Hier finden Sie eine Zusammenfassung der wichtigsten Fehler:

• fitframe_CS55.indd.zip
• fitframe_CS6.indd.zip

Aus Gründen der Rückwärtskompatibilität haben wir die Comet-Methoden zum Anpassen von Rahmen an ihren Inhalt (frame::fit, item::fitframe, Gestaltungsmethode Rahmen anpassen) unverändert gelassen. es gibt aber die folgenden neuen Funktionen:

• frame::fit_better
• item::fitframe_better
• Gestaltungsregel Rahmen besser anpassen

Wir raten dringend zur Verwendung der neuen Methoden zum Anpassen von Rahmen an ihren Inhalt. In den oben genannten Dokumenten finden Sie eine Vielzahl von Testrahmen für fitframe_better.

Beachten Sie bitte auch, dass im Release R5150 auch die verwandte Funktion frame::image und die Gestaltungsregeln "Bildgröße anpassen" und "Bildplatzierung anpassen" überarbeitet wurden! Hier nochmals ein Hinweis zu den entsprechenden Testdateien :

• 1_CS55.indd.zip, 1_CS6.indd.zip
• layoutrule_fitimage_CS55.indd.zip, layoutrule_fitimage_CS6.indd.zip

Für wiederholende Elemente kann ja angegeben werden, an welcher Ecke des Rahmens sie platziert werden sollen. Dabei kann man aber leider nur die Referenzpunkte selbst angeben. Ein Abstand von, sagen wir mal 10 Punkten rechts neben der rechten oberen Ecke ist aber nicht möglich.

Die Angabe pin des Build-Strings kann jetzt mit einem optionalen Offset versehen werden :

pin=rt+(10.0, 0.0)

Die Angabe erfolgt in Punkten. Mehr dazu hier.

Wiederholende Elemente werden seit einiger Zeit immer auf der untersten Dokumentebene angelegt.

Ja. Da die aktuelle Ebene sich ständig ändern kann, ist sie ein sehr unsicheres Ziel. Bei InDesign®- Server ist sie zudem gar nicht definiert. Bei der Korrektur einiger Stellen, an denen die aktuelle Ebene trotzdem verwendet wurde, haben wir die wiederholenden Elemente leider übersehen (Und ein Jahr lang alle anderen auch).

Geben die wiederholenden Elemente keine explizite Ebene an wird jetzt die Ebene des auslösenden Rahmens verwendet.

Die Funktion frame::reimport_all bearbeitet alle Rahmen des Dokumentes. Na, jedenfalls fast alle. Rahmen, die auf keiner Seite (also vollständig im Arbeitsbereich) liegen, werden aber leider nicht neu verknüpft.

Die Funktion enthält jetzt den zusätzlichen optionalen Parameter includePastebaord. Ist der ungleich 0, werden auch die Rahmen neu verknüpft, die keiner Seite zugeordnet werden können.

Die Funktion itemlist::allframes holt alle Rahmen des Dokumentes. Na, jedenfalls fast alle. Rahmen, die auf keiner Seite (also vollständig im Arbeitsbereich) liegen, werden aber leider nicht gefunden.

Die Funktion enthält jetzt den zusätzlichen optionalen Parameter includePastebaord. Ist der ungleich 0, werden auch die Rahmen gefunden, die keiner Seite zugeordnet werden können.

Das Gleiche gilt für die Funktion itemlist::allframes_of_doc.

Wenn die Preview-Palette Previews von TIFF-Bildern berechnen soll, stürzt InDesign® bei einigen Bildern woederholbar ab. Bei anderen TIFFS funktioniert das Erstellen der Previews.

TIFF-Bilder können im sog. XMP-Header Angaben zur Bilddrehung enthalten. Diese Drehung wird beim Platzieren der Bilder nicht angewendet. Im Preview (z.B. im Desktop-Icon) ist zu sehen. In der Preview-Palette soll sie nicht angewendet werden. Deshalb wird dieser XMP-Header beim Erzeugen des Previews gelesen. Die dafür verwendete InDesign®- API-Funktion von Adobe scheint dabei bei einigen Bildern zu Fehlern zu führen, die später zum Absturz des gesamten Programmes führen.

Wir lesen die TIFF-Drehung jetzt anders. Damit ist das Absturz-Problem gelöst UND gleichzeitig werden die XMP-Drehungen respektiert.

Ich habe eine Cometgruppe, bei der ich die Magnete unterdrücken will. Die Magnete werden hier erst in einer eigenen Gestaltungsregel angewendet. Wie kann ich das machen?

Hintergrund

Es handelt sich um eine gedrehte InDesign®- Gruppe bei der einige Rahmen ihre Höhe und/oder Breite ändern können und dadurch andere Rahmen anpassen. Mit dem normalen Magnet-Mechnismus geht das leider nicht. Die Rahmen verschieben sich dabei falsch. Es geht aber, wenn man die Gruppe zuvor auf 0° dreht, dann die Magnete anwendet und die Gruppe zum Schluß wieder zurückdreht. Leider werden die Magneten aber auch vom normalen Laden schon ausgeführt und machen alles kaputt.

Die Funktion prefs::enable_magnets hat jetzt einen weiteren Parameter. In diesem Parameter kann eine Cometgruppe übergeben werden. Bei allen so registrierten Cometgruppen werden die Magnete beim Laden nicht ausgeführt. Die Sperre gilt bis zur nächsten Idle-Time.

Der Aufruf von prefs::enable_magnets muß in einem Text-Platzhalter des ersten Rahmens gemacht werden, der geladen wird.

ACHTUNG : Dieser Platzhalter darf dann natürlich nur in Cometgruppen verwendet werden, in denen die Magnete beim Laden unterdrückt werden sollen.

In der Palette "Template-Verhalten" sind nur normale Rahmen sichtbar, aber keine InDesign®- Gruppen. Ich habe folg. Situation:

Gruppe 1
    Rahmen A
    Rahmen B
Gruppe 2
    Rahmen C
    Rahmen D

Und ich muß die Platzhalter des Rahmens D zuerst laden lassen. Das kann ich aber in der Palette gar nicht einstellen. Ohne Gruppen würde das gehen. Mit Gruppen wird die Reihenfolge willkürlich festgelegt. Auch die Reihenfolge der Rahmen der Gruppen ist dann willkürlich.

Alles sehr spannend. Und sehr technisch. Aber, kurz gesagt: Die Ladereihenfolge ist in dieser Situation tatsächlich nicht von der Sortierung im Template-Verhalten abhängig.

Ich habe zwei Dinge gemacht:

1. Gruppen werden jetzt in der Palette angezeigt. Die Anzeige war dabei das´kleinste Problem. Das größere Problem war das Verschieben der Einträge. Jetzt werden ja mglw. nicht mehr einzelne Einträge verschoben, sondern ganze Gruppen. Und die Verschiebung muß auch auf die Gruppe beschränkt bleiben - wenn es denn eine Gruppe gibt. Das geht jetzt.
2. Auch beim Laden von gruppierten Rahmen wird jetzt die Reihenfolge aus "Templateverhalten" eingehalten.

... und zwar je mehr gedreht, um so mehr verschoben. Der Rahmen steht danach einfach nicht mehr an der gleichen Stelle.

Oder genauer : Bei ungedrehten Rahmen funktioniert alles richtig. Hat man aber einen Rahmen, der schon gedreht und dreht den auf einen anderen Winkel, z.B. auf 0°, dann wird als Fixpunkt die linke obere Ecke der Boundingbox um den gedrehten Rahmen verwendet, aber nicht die linke obere Ecke des Rahmens selbst. Das gibt dann merkwürdige Ergebnisse.

Gefixt.

Bei Magneten an gedrehten Rahmen ist es schwer erkennbar, welches der Start- und welches der Zielrahmen ist.

Der Teil der Magnetlinie am feststehenden Rahmen wird jetzt in der gleichen Farbe (grün oder rot) wie der mittlere Abstandsteil gezeichnet. Das ist, weil die Linien recht dünn sind, immer noch recht dezent - aber man kann es sehen.

# Suppressing frame::resize (old size = new size).

frame::resize prüft vor der Ausführung, ob sich die Rahmengröße überhaupt ändern würde. Bei der Ermittlung der aktuellen Größe wurde aber die aktuelle Skalierung ignoriert. Das wird jetzt gemacht. Damit ist der Fehler gefixt.

Für die Funktion müssen ja immer Werte angegeben werden. Wenn ich nur die Höhe der horizontalen Streifen ändern möchte, muss ich dafür auch die Breite der vertikalen Streifen wissen. Ich kann die mit get_pasteboard_gutter erfragen. Aber da erhalte ich mitunter eine -1.0 als Antwort. Wenn ich das dann als Breite einsetze, bekommen ich einen Streifen der Breite 0.0. Das wollte ich eigentlich nicht.

Kann man nicht einen Parameter-Wert festlegen für "Unverändert lassen"?

Das geht jetzt :

• -1.0  : Unverändert lasse
• -10.0 : Standard (595.276 bzw. 72.0)

ACHTUNG: Als Standardwerte werden immer 595.276 bzw. 72.0 verwendet. Evtl. geänderte Programm-Voreinstellungen werden ignoriert.

Wenn ich den grünen Haken der Aufgaben-Palette (unten links in der Palette) drücke passiert rein gar nichts. Wozu ist denn das Button?

Das stimmt. Und das seit etwa zwei Jahren. Eigentlich sollte mit dem Button der Status der ausgewählten (oder aller) Aufgaben als "Erledigt" gesetzt werden. Seit längerem wird der Status aber immer wieder mit dem aktuellen Stand im Dokument abgeglichen - und das überschreibt die gemachten Änderungen sofort wieder.

Das ist jetzt nicht mehr so. Der manuell gesetzte Status bleibt in der Palette erhalten - jedenfalls eine Weile. Der so geänderte Status ändert nämlich lediglich den Listeneintrag. Das Dokument kennt diesen Wert nicht, das Dokument hat diesen Status noch nicht einmal. Das Dokument berechnet ihn! Wird jetzt ein anderer Platzhalter im Dokument ausgewählt, wird der Status erneut berechnet - und dann wird auch die manuelle Änderung in der Liste wieder zurückgesetzt.

Allens klar?

Wenn ich in der Aufgaben-Palette viele Einträge habe, wird InDesign® sehr langsam. Schon wenn man mit der Maus in einen Platzhalter klickt, kann das bis zu fünf Sekunden dauern. SO KANN ICH NICHT ARBEITEN!

Stimmt. Das ist wirklich super lästig. Grund war eine etwas übereifrige Anpassung der Liste an die Dokumentauswahl. Das ist jetzt behoben. Jetzt geht es wieder so flott, als wäre die Palette gar nicht offen.

Wenn man in der Aufgaben-Palette die Lupe drückt, erscheint möglicherweise ein Progress-Balken. Der Balken hat ein Abbrechen-Button. Wenn man das drückt, gehen Platzhalter im Dokument verloren.

Man kann das sehr einfach reproduzieren. Man muß tatsächlich nur mal die Suche abbrechen. Dann klickt man irgendwo ins Dokument - dort fehlen jetzt nicht überall, aber doch über weite Strecken alle Textplatzhalter. Und diese Aktion ist auch nicht rückgängig zu machen!

Dieser Fehler tritt nur im Umgang mit der Aufgabenliste auf. Grund des Fehlers ist, dass wir den von Adobe präferierten Vorschlag für das Abbrechen von Aktionen verwendet haben. Dies hat sich im Kontext der Aufgabenliste als fatal herausgestellt.

Der Fehler ist gefixt.

Mit der Palette "Gestaltungsregeln"kann immer der erste ausgewählte Rahmen/Textplatzhalter bearbeitet werden. Versteh ich auch, die Ziele können ja völlig unterschiedliche Regeln haben, so dass es nicht klar ist, was passieren soll, wenn EIN Parameter geändert wird.

Beim Löschen der Layoutrules (Button "Weißes Quadrat") werden jetzt alle ausgewählten Rahmen bearbeitet. Und die Info am gelben Zettel des Buttons, dass das Ganze nicht rückgängig zu machen sei, die war natürlich falsch und ist auch weg.

Wird in einer Rahmenkette eine Tabelle umbrochen, erhält frame::get_textpos als Position immer irgendeinen Wert innerhalb des Tabellenankers. Aus dieser Angabe kann man lediglich schließen, dass hier eine Tabelle umbrochen wird - aber nicht, wo der Umbruch ist.

Die Funktion hat dafür jetzt weitere (optionale) Parameter. Mehr dazu in der Online-Doku.

Bei mehrspaltigen Texten liefert die Funktion frame::get_textpos für die Textlänge immer nur die Anzahl der Zeichen in der ERSTEN Spalte.

Das ist gefixt. Jetzt wird die Anzahl der Zeichen aller Spalten zurückgegeben.

Ich habe ein Template mit einem Text. Der Text enthält mind. zwei Inlines. Diese Inlines haben Rahmenplatzhalter. Wird das Template geladen, kann es sein, dass sich die Inlines selbst löschen. Dabei bleibt der Aufbau stehen mit der Meldung "Skript : main not defined".

Es exotisches Problem. Es tritt nur auf, wenn mind. zwei Inlines gelöscht werden. Auslöser war nicht, dass der Rahmen gelöscht wurde, sondern dass das zugehörige Textmodel durch das Löschen des Inlines um ein Zeichen kürzer wird.

XML-Queries mit mehreren orderby-Attribute werden mitunter falsch sortiert.

Im vorliegenden Fall sollen Spalten sortiert werden, die float-Zahlen enthalten. Erschwerend kommt hinzu, dass die Zahlen als Dezimaltrenner nicht den Punkt, sondern ein Komma verwenden.

Seit Bug 3327 können Textspalten auch dann richtig sortiert werden, wenn sie Kommazahlen enthalten.

Zwei Dinge aber wurden nicht implementiert:

1. Komma als Dezimaltrenner
2. Fälle der Art "1.9 AAA", "1.9 BBB". Diese Strings hatten den gleichen Wert 1.9 und ihre Reihenfolge zueinander daher undefiniert.

Fälle der Art "1.9 AAA", "1.9 BBB" werden jetzt richtig sortiert. Als Dezimaltrenner wird (aus Gründen der Rückwärts-Kompatibilität) weiter nur der Punkt zugelassen.

Zuätzlich zu asc und desc können die folgenden Angaben in der orderby-Klausel angegeben werden:

• asc_int, desc_int (als integer sortieren)
• asc_float, desc_float (als float sortieren, Dezimaltrenner Punkt oder Komma)
• asc_datetime, desc_datetime (als Datum,Uhrzeit sortieren)
• asc_string, desc_string (als case sensitiver String sortieren)
• asc_ustring, desc_ustring (als case insensitiver String sortieren)

Ja genau, so ist es. Die erste Regel/Bedingung wird ausgeführt, der Rest nicht mehr. Der Fehler betrifft aber zum Glück nur Inline-Rahmen und tritt erst ab CS6 auf.

Der Fehler ist als Seiteneffekt des Fixes von Bug 3010 entstanden und besteht seit v3.3 R3144 (29. Aug 2012). Er tritt erst ab CS6 auf und nur bei Inlines.

Der Fehler ist jetzt gefixt.

InDesign® stürzt beim Einfügen eines Prduktes mit folgendem Fehlerbericht ab:

0 PublicLib.dylib PMRect::IndexToPointIndex(long)...
1 ...nDesign.PageAdapter [Model] FramePolicyTagData::Chain::MapUID...
2 ...nDesign.PageAdapter [Model] FramePolicyTagData::MapChainUIDs...

Gefixt.

Gefixt. Magnete und Notiz-Verbindungen zu Rahmen werden jetzt wiederhergestellt.

Gefixt.

Bis v3.4 R4545 war es so

• Platzhalter verknüpfen wenn id1 != 0
• Laden, wenn autoload = 1

Das geht ab R4545 nicht mehr. Verlinkt wird nur noch, wenn autoload=1 ist.

Das alte Verhalten ist widerhergestellt.

Ich kopiere die aktuelle Rahmenauswahl in ein anderes Dokument. Das Zieldokument ändert sich zwar - aber Rahmen sind dort nicht zu sehen.

Ooops, stimmt. Die Zielposition wird falsch ausgewertet. Das ist jetzt gefixt. Der Fehler ist als Seiteneffekt des Fixes von Bug 2973 entstanden und seither (v3.3 R3120, 12. Aug. 2012) unentdeckt geblieben.

Übergebe ich dagegen "" als Name der Zielebene, ist alles gut.

Das ist gefixt.

Ja, so ist es. Hier ein Beispiel:

In einer deutschen ID-Version wird für die Regel "Rahmen anpassen" der Wert für "Festhalten X" mit "rechts" festgelegt. Öffnet man das gleiche Dokument mit einer englischen ID-Version, hat der Parameter aber den Wert "left".

Das ist gefixt. An bereits erstellten Dokumenten muß NICHTS geändert werden. Es genügt, neue Plugins zu haben.

... und nicht die wirkliche Größe des Bildrahmens zurück.

Dafür hat die Funktion frame::get_imagesize jetzt den Parameter bboxType :

• 0 : (Default) Größe der BoundingBox um das möglw. gedrehte Bild ermitteln
• 1 : Größe de Bildrahmens

frame::image_getpos liefert immer eine Position, die realitv zum äusseren Rand der Rahmenkontur ist. Hat der Rahmen also eine Kontur der Stärke 10 und das Bild steht an der Position (0, 0), dann liefert die Funktion (-5, -5).

Funktion frame::image_getpos hat jetzt einen weiteren Parameter:

• boundsKind = 0 (default) liefert den bisherigen Wert
• boundsKind = 1 liefert den Wert relativ zum Pfad des Rahmens (blauer Rahmen)

Hier finden Sie Testdateien :

• 1_CS55.indd.zip, 1_CS6.indd.zip
• layoutrule_fitimage_CS55.indd.zip, layoutrule_fitimage_CS6.indd.zip

Ich habe einen Rahmen mit einer 10 pt starken Kontur. Die Kontur ist mittig ausgerichtet. Wenn ich diesen Rahmen auf 200 verbreitere, erhalte ich die Breite 190. Ist die Kontur aussen, erhalte ich sogar nur 180. nur wenn die Kontur innen liegt, wird das Ergebnis richtig.

Das ist gefixt. Die Funktionen

• frame::bbox
• frame::get_size
• frame::resize

haben jetzt jeweils den weiteren optionalen Parameter boundsKind, mit dem gesteuert werden kann, welchen Pfad man meint.

Das <in:>-Tag kennt ja eine Reihe von Optionen, mit denen der Inline gestaltet werden kann. Klar sind da längst nicht alle Möglichkeiten implementiert, die in InDesign® gesetzt werden können.

Könnte man dem Inline einen Objektstil mitgeben, könnte man alle fehlenden Attribute ebenfalls unterstützen. Das hätte auch den Vorteil, dass Inline-Rahmen dokumentabhängig (z.B. für Sprachvarianten) unterschiedlich gestaltet werden können.

Bisher ist das dadurch gelöst, dass man dem <in:>-Tag die ID eines Templates mitgibt - und alle Rahmeneinstellungen am Template macht.

Aber die Idee ist gut. Es gibt daher für das <in:>-Tag jetzt die weitere Option

    objectstyle 'stylePath'

Der Objektstil wird NACH dem Setzen der Anker-Eigenschaften und VOR dem Anwenden aller anderen Rahmenattribute angewendet. Das bedeutet:

• Ankereigenschaften können vollständig im Objektstil festgelegt werden. Das ist einfacher als über <in:>-Tag-Optionen
• Alle anderen vom <in:>-Tag unterstützten Rahmen-Attribute können die Einstellungen des Objektstiles überschreiben.

Der Objektstil wird natürlich nicht angewendet, wenn Inlines über Template-IDs geladen werden.

ACHTUNG

Die Unterstützung von Objektstile für <in:>-Tags ist ein good will-Feature, das auf Kundennachfrage kostenfrei implementiert wurde. Support dafür machen wir natürlich gerne - aber dann als (kostenpflichtiges) Feature-Request.

Ich verwende in einem <in:>-Tag die Option "fitframe". Dadurch wird aber leider der Abstand des Rahmens zur Zeile verändert und der Rahmen schwebt dann ziemlich weit über der Grundlinie. Das sieht doof auf und man bekommt diesen Offset leider auch manuell nicht wieder weg. Das Bild zeigt links die Verwendung des <in:>-Tags ohne "fitframe" und rechts die irritierende Verwendung mit "fitframe".

Das ist gefixt. Der Rahmen bleibt jetzt im definierten Abstand von der Grundlinie stehen.

ACHTUNG

Die Option "fitframe" ändert die Breite einzeiliger Inlines nicht mehr. Mit der (neuen) Option "fitframe_hw" wird auch die Breite einzeiliger Inlines angepasst. Das Bild zeigt die unterschiedliche Wirkung der Optionen "fitframe" und "fitframe_hw".

Ich verwende innerhalb eines <in:>-Tags die Option "wrap". Leider wird die vollkommen ignoriert.

Das ist gefixt.

Aber kann mir jemand ein Beispiel zeigen, in dem die Konturführung von Inlines angewendet und sinnvoll ist?

Ich habe drei Rahmen A, B, C.

Fall 1

1. Magnet A -> C setzen
2. Magnet B -> C setzen

Der Magnet A->C sollte jetzt entfernt werden. Er bleibt aber bestehen.

Fall 2

1. Magnet A -> C setzen
2. Alternativen Magnet B -> C setzen

Der Magnet A->C sollte jetzt ebenfalls als alternativer Magnet (gestrichelt) dargestellt werden. Er bleibt aber als normaler Magnet stehen.

Verschiebt man einmal den Rahmen C, sieht man, dass alles in Ordnung ist. Es handelt sich lediglich um ein kleines Darstellungsproblem, das jetzt gefixt ist.

Ich rufe document::place_items mit einer gültigen ObjektID und autoLoad=0 auf. Das entsprechende Template wird eingesetzt und wie erwartet nicht geladen.

Was ich aber erwartet hätte, wäre, dass die Platzhalter im Template mit der übergebenen ObjektID verknüpft werden. Das ist offenbar nicht der Fall. Das Template wird so eingesetzt, wie es abgespeichert war.

Bis v3.4 R4545 war es so

1. Platzhalter verknüpfen wenn id1 !=
2. Laden, wenn autoload = 1

Das ging ab R4545 nicht mehr. Verlinkt wurde nur noch dann, wenn autoload=1 war. Das alte Verhalten ist widerhergestellt.

Verkettungen zwischen Textrahmen werden nicht in Templates übernommen!

In XML-Offline-Verbindungen klappt es. Aber mit Datenbank- und SOAP-Verbindungen nicht.

Im Release R4444 hat das Gleiche noch funktioniert.

Ja, sorry. Der Fehler tritt als Seiteneffekt des Fixes von Bug 3385 ab v3.3 R4671 auf.

Der Fehler ist gefixt. Textverkettungen werden wieder in die Templates übernommen.

Ich lasse in einer Schleife mit table::fit_col alle Spalte einer Tabelle so anpassen, dass es keine Übersätze mehr gibt. Funktioniert gut. Aber wenn ich danach ein Undo mache, wird das Pasteboard ganz groß. Erst im nächsten Undo-Schritt wird es wieder klein und die Tabelle kommt wieder in ihren Anfangszustand.

Jetzt ist nur noch ein Undo-Schritt nötig.

Ich verwende folg. Skript, um alle Zellen-Oversets einer Tabelle zu beseitigen:

int main ()
{
	Table	T        = table::alloc ();
	int		selStart, cols, col;

	// Get the currently selected table	
	textmodel::selection (selStart);
	table::get (T, gFrame, 0, selStart);

	// Fit all columns	
	cols    = table::columns (T);
	for (col = 0; col < cols; col++)
	{
		table::fit_col (T, col);
	}

	return 0;
}

Das funktioniert super. Jedenfalls fast immer. Wenn aber ein TEIL der Tabelle im Übersatz liegt, wird mind. eine Spalte der Tabelle sehr breit.

Ja, die Spaltenbreite beträgt dann etwas über 1000 Punkte. Das ist genau das Abbruchkriterium "Maximale Spaltebreite erreicht". Mit einem

    textmodel::force_redraw

vor table::fit_col kann das verhindert werden.

Das ForceRedraw ist ab o.g. Release nicht mehr nötig. Es wird automatisch gemacht.

Statt dessen wird immer die aktuelle Importeinstellung von InDesign® verwendet:

1. Datei ->Platzieren
2. "Importoptionen anzeigen" aktivieren
3. Wert des Popupmenüs "Beschneiden auf"

Der Import mit frame::place_pdf_with_crop verwendet jetzt die im Parameter cropTo angegebene Beschnitt-Methode.

Die Funktionen layer::get_index und layer::get_name funktionieren für Inline-Rahmen nicht immer. Immer der letzte Inline eines Textes findet keine Ebene.

Der Fehler ist gefixt.

Workaround

ItemRef 	parent = 0;

if (frame::isinline (gFrame))
{
	parent = item::alloc ();
	frame::parent (gFrame, parent);
}
else parent = gFrame;

textmodel::replace (layer::get_name (parent));

return 0;

Kann ich mit cscript Seiten einnerhalb eines Dokumentes verschieben?

page::move

In der Seiten-Palette kann man Seiten auf das Button "Neue Seite anfügen" ziehen. Dann wird eine Kopie der Seite ans Ende des Dokumentes angefügt. Kann man das auch mit cScript machen?

page::duplicate

Die neue Seite wird immer am Ende des Dokumentes angefügt (wie auch beim Duplizieren von Seiten mit Hilfe der Seiten-Palette). Um die Seite zu verschieben, kann der neue Befehl page::move verwendet werden.

Das folgende Skript legt hinter der Seite des aktuellen Rahmen eine Kopie der Seite dieses Rahmens an:

int main ()
{
	page::duplicate (0, page::get (gFrame));
	page::move (0, document::pages (), page::get (gFrame));

	return 0;
}

Seit kurzer Zeit gibt es ja die Möglichkeit, eigene Notizformen anzulegen. Unter CS6 funktioniert das prima, während es unter CS5.5 zu komischen Phänomenen kommt. Getestet hab ich das auf dem Mac mit 3.4 Rev 5122.

Folgendes Testszenario:

• lege einen Pfeil und einen Polygon-Textrahmen an und verwandle beide in Comet-Notizen (ohne Titel, ohne Auto-Prompt)
  
  
• sichere beide als Notizvorlagen ("Pfeil" und "Octa") Hier wird es seltsam: im content-Element des Pfeils steht wirres Zeug, das ein bisschen wie Base-64-codierter Binärcode aussieht.
  
  
• Hänge an einen Rahmen in einem anderen Dokument Notizen mit den neuen Typen an - den Textrahmen einmal mit und einmal ohne Inhalt Der leere Textrahmen wird in beiden Versionen zum Bildrahmen, was m.E. auch nicht korrekt ist.
  
  
• Exportiere die Notizen und importiere sie wieder Jetzt wird es sehr seltsam: in CS5.5 werden der Pfeil und der leere Textrahmen mit komischen Pixelgrafiken gefüllt - die sieht man auch wiederum als wirres Zeug in der notes_cs5.5.xml. Wenn man den Rahmen an den Inhalt anpasst, verwandelt sich der Pfeilrahmen in eine Pfeilspitze - scary. In CS6 wird der leere Polygonrahmen wieder zum Textrahmen, was eigentlich ganz schön ist.

Mein Wunsch wäre:

1. in CS6 sollten auch leere Textrahmen durchgängig Textrahmen bleiben
2. dann sollte sich CS5.5 verhalten wie CS6, das ist nämlich ziemlich geil.

Neue Notizen werden jetzt IMMER zu Textrahmen gemacht. Einzige Ausnahme ist, wenn der Rahmentyp das nicht erlaubt (z.B. bei Linien).

Ist in der Notizen-Palette die Option "Textwerkzeug aktivieren" ausgewählt, wird nach dem Anlegen einer Notiz der Textcursor ans Ende des Textes dieser Notiz gesetzt und das Textwerkzeug aktiviert.

Das sogenannte wirre Zeug ist ein Binärblob des Bildes der Notiz. Das macht eigentlich nur dann Sinn, wenn die Notiz aus einem eingebetteten Bild besteht. Im o.g. Fall ist das nicht so. CS5.5 hat hier aus den Eigenschaften"Graphikrahmen" und "Kein Bild" fälschlicherweise geschlossen, dass es sich dann um ein eingebettetes Bild handeln würde. Das ist gefixt.

Wenn ich neue Notizen erstelle (Toolbar oder +-Button) bekommen diese Notizen immer mal wieder andere Einstellungen für

• Status
• Rolle
• Typ

Welche Werte werden dann da als Startwert verwendet und kann ich das irgendwie beeinflussen?

Neue Standard-Notizen (Rechteck, Ellipse, Polygon, Stern, Herz) bekommen jetzt immer die folgenden Werte :    

Benutzerdefinierte Notizen bekommen die Werte, die das Original beim Sichern hatte.

Wenn ich Notizen, die eine Kontur haben, unsichtbar und wieder sichtbar mache, verändert sich deren Position entsprechend der Konturstärke.

Das ist gefixt.

Hatte heute die Buch->PDF (book::export_) nochmals getestet und festgestellt das diese keine PDF auf Netshares oder Laufwerksbuchtstaben abweichend von C: anlegt.

Das ist gefixt.

Die Funktionen file::exists, file::isfolder und file::isfile liefern bei Netshares oder Laufwerksbuchtstaben abweichend von C: falsche Ergebnisse. Die Funktionen liefern IMMER 0 zurück.

Diese Fehler sind gefixt.

kurze Frage zu der Hyperlink Funktion Create. Hier könnte man ein externes Dokument angeben für die Zielseite. Dieser Teil der Funktion ist jedoch noch als nicht-aktiv beschrieben. Daher meine Frage, hast du hier schon was geändert? Der Kunde möchte Hyperlinks verwenden hat jedoch als Ziel mehrere Dokumente und ist sich gerade unschlüssig wie dies zu realisieren ist.

Ja, das ist richtig. Die hyperlink-Funktionen sahen bisher keine Links zu externen Seiten vor.

ACHTUNG : Die Funktion hyperlink::create wurde entfernt. Zur Erzeugung von Links zu Seiten können die Funktionen

• hyperlink::create::pagedest
• hyperlink::frame_create_pagedest

verwendet werden. Ist der Zielpfad der Aufrufen leer (0 oder ""), wird ein Link innerhalb des Dokumentes erzeugt. Ist der Zielpfad nicht leer, wird der Link zu dieser Datei erzeugt. Das Zieldokument braucht dafür weder geöffnet sein noch überhaupt existieren. Beachten Sie aber, dass Links immer auf indd-Dateien zeigen müssen. Wird der Link im exportierten PDF dann geklickt, sollte die entpsrechende Ziel-PDF-Datei aber dann schon da sein :-)

Leider funktioniert das Ganze aber nicht, wenn Verweise innerhalb von Tabellen erzeugt werden sollen.

Ausserdem wird gewünscht, dass nicht nur der leere Zielpfad Verweise innerhalb des Dokumentes anlegt. Es wäre vielmehr schön, wenn die Funktion auch automatisch testen würde, ob ein gegebener Zielpfad gleich dem Pfad des aktuellen Dokumentes ist und in diesem Fall dann ebenfalls interne Links erzeugt (obwohl die entsprechende Abfrage ja auch im Skript gemacht werden könnte.).

Verweise können jetzt auch in beliebigen Tabellenzellen angelegt werden.

Die Funktion testet jetzt, ob ein nicht-leerer Zielpfad gleich dem Pfad des aktuellen Dokumentes ist und legt auch in diesen Fällen interne Links an.

wenn ich die Image-Position eines gedrehten Bildes mit frame::image_getpos (gFrame, &x, &y); auslese, erhalte ich auf der y-Position nicht die Werte, die mir InDesign® am Desktop anzeigt.

Die x-Position funktioniert. Das tritt nur bei Bildern auf, die eine Dreh- oder Scherwinkel habe. (rotate & skew)

... und das entsprechende gilt auch für frame::image_pos. Die neue Bildposition wird auch falsch gesetzt. Ist der (blaue) Rahmen gedreht oder verzerrt, sorgt das für weitere Fehler.

Die Werte die InDesign® anzeigt, werden offenbar so berechnet:

Linken obere Ecke der BOUNDINGBOX des blauen Rahmens - linker oberer Referenzpunkt des braunen Bildrahmens

frame::image_getpos berechnet diese Werte jetzt richtig auch bei beliebigen Drehungen, Verzerrungen und Skalierungen von Bild und/oder Bildrahmen. Ebenso setzt frame::image_pos die neuen Werte jetzt auch bei Drehungen und Verzerrungen richtig.

Ich habe hier eine EPS-Datei, die sich manuell prima platzieren lässt. Wenn ich die über frame::image() platziere, hängt sich InDesign® (CS 6, mit Comet 3.4 Rev 5122) auf.

Testscript:

char    *path    = "/Users/thorsten/Desktop/pre201016.eps";

int main()
{
	int res;
	
	res = frame::image(gFrame, path);
	showmessage("Platziert mit Rückgabewert %d (%s)", res, serror(res));

	return 0;
}

Das ist merkwürdig, weil an der Stelle, an der ID hängen bleibt, nichts geändert wurde. Der Import durchläuft die Liste aller möglichen Import-Provider (HTLM, InCopy, Image, ... ingesamt etwas über 150 Formate) und fragt jeweils, ob der jeweilige Importer etwas mit der Datei anfangen kann. Beim Format "Sound" bleibt CS6 jetzt stehen. Ich überspringe dieses Format daher jetzt.

Damit funktioniert der Import des gegebenen EPS-Bildes.

Beim Aufräumen einzelner Seiten wir vor und nach der Seite jeweils ein Seitemtemplate in die "Produkte des Dokumentes" eingefügt. Dadurch entstehen beim Reoragnationen feste Seitenumbrüche an diesen Stellen. Das ist eigentlich nicht das, was man erwartet.

Das Aufräumen von Seiten erzeugt jetzt keine zusätzlichen Seitenumbrüche mehr. Seitenumbrüche können über die Liste der Produkte des Dokumentes angelegt werden.

Wird der Skriptbefehl productlist::reorganize mit einer Seitennummer und dem (neuen) Flag kCropPage ausgeführt, legt diese Anweisung vor und nach der Seite Seitenumbrüche an.

Auf einer aufgebauten Seite wird ein Produkt gelöscht. Diese Seite soll jetzt neu reorganisiert werden. Dazu gibt es vier Möglichkeiten :

1. Alt-Klick des Reorganisations-Buttons der Produktrecherche
2. Alt-Klick des Reorganisations-Buttons der "Produkte des Dokumentes"
3. Das Menü "Seite reorganisieren" der Produktrecheche
4. Der Skriptbefehl productlist::reorganize

In den ersten drei Fällen ist das Ergebnis gleich : Die Produkte der Seite werden richtig reoganisiert. Das letzte Seitenelement der Seit bleibt unbelegt

Der Skriptbefehl macht das Gleiche füllt aber den letzten Element-Platz mit dem ersten Produkt der Folgeseite.

Die einzelnen Möglichkeite zum Aufräumen einer Seite sind jetzt gleich: In allen Fällen werden jetzt nur noch die Produkte der aktuellen Seite umorganisiert. Produkte auf Folgeseiten bleiben unverändert. Zuätzlich gibt es neue Möglichkeiten, um leere Stellplätze der aktuellen Seite mit Produkten der nachfolgenden Seiten zu füllen:

1. Alt-SHIFT-Klick des Reorganisations-Buttons der Produktrecherche
2. 02.12.1013-Klick des Reorganisations-Buttons der "Produkte des Dokumentes"
3. Das Menü "Seite füllen und aufräumen" der Produktrecheche
4. Der Skriptbefehl productlist::reorganize mit dem (neuen) Flag kFillPage

Das Menü "Seite reorganisieren" heißt jetzt "Seite aufräumen.

Zumindest in manchen Zusammenhängen funktioniert das Reorganisieren von Einzelseiten nicht: Versucht man die Seite mit Alt-, passiert gar nichts. Versucht man, ein Skript zu verwenden (productlist::reorganize(0, 0, gFrame, start_page);) landen plötzlich Produkte der Vorgängerseite auf der aktuellen Seite.

Das ist gefixt.

Beim Reorganisieren entstehen Rahmen mit merkwürdigen Bildinhalten:

1. Das "Donat"-Tool über den Bilder wird nicht mehr aktiviert
2. Über dem Bild ist weiter das diagonale Kreuz leerer Bildrahmen
3. Zugehörige XML-Elemente der Rahmens werden in der Dokumentstruktur nicht mehr ausgewählt. Erst wenn mit dem weissem Pfeil direkt das Bild (der braune Rahmen) ausgewählt wird, reagiert auch die XML-Struktur).

Das stimmt leider. Der Fehler entsteht so: Beim Reorganisieren muß ein Template getauscht werden. Der neue Bildrahmen bekommt dabei den Inhalt seinen alten "Bruders" als Kopie. Das geht in den allermeisten Fällen gut. Nicht gut geht es, wenn die Rahmen XML-Elemente haben UND

• das XML-Element des alten Rahmens aus dem Bild (!) und nicht auch dem Rahmen erzeugt wurde. (Mit Bordmitteln ist das einfach zu machen: Normalerweise zieht man den Rahmen in die Strukturliste. Aber InDesign® verbietet es nicht, statt dessen auch den BILD-Rahmen (also den braunen Rahmen) zu nehmen.)
• oder Ziel und Quelle unterschiedliche Element-Attribute haben.

Das Ganze ist leicht mit dem Skriptbefehl frame::copy_image nachzustellen (dessen Implementierung auch bei der Bildübergabe der Reorganistion verwendet wird.) Hier schafft man es sogar, dass ein Grafikrahmen VIELE unterschiedliche Bilder enthält. Wäre eigentlich ein nettes Feature.

Der Fehler ist gefixt.

Wenn ich in der Palette "Comet-Notizen" mit + eine neue Rahmennotiz anlege, wird die immer auf der untersten Ebene des Dokumentes angelegt. Schöner wäre natürlich, die Notiz käme auf die gleiche Ebene wie der Rahmen.

Wenn ich in der Palette "Comet-Notizen" mit + eine neue Rahmennotiz anlege, wird die immer auf der untersten Ebene des Dokumentes angelegt. Schöner wäre natürlich, die Notiz käme auf die gleiche Ebene wie der Rahmen.

InDesign® stürzt wiederholbar ab, wenn der Pfad eines Bildplatzhalters ein Ordner (und keine Datei) ist. Der Fehler besteht seit v3.4 R4650, vorher ging das.

Man könnte denken, dass dieser Fall sinnlos ist. Man darf halt im Platzhalter keinen Ordner als Pfad angeben. So ist es leider nicht. Es können leicht nur Ordner-Pfade übergeben werden wie das folgende XML-Beispiel zeigt:

"$DATAFILE"
select "$IMAGES" || "/" || image, 1 node posters.poster where ID = <ID>

Immer dann, wenn ein Poster kein Bild hat, bekommt man als Ergebnis einen Ordner-Pfad.

Ist wieder gefixt. In v3.3 bestand der Fehler nicht!

kurze Frage zu der Hyperlink Funktion Create. Hier könnte man ein externes Dokument angeben für die Zielseite. Dieser Teil der Funktion ist jedoch noch als nicht-aktiv beschrieben. Daher meine Frage, hast du hier schon was geändert? Der Kunde möchte Hyperlinks verwenden hat jedoch als Ziel mehrere Dokumente und ist sich gerade unschlüssig wie dies zu realisieren ist.

Ja, das ist richtig. Die hyperlink-Funktionen sahen bisher keine Links zu externen Seiten vor.

ACHTUNG : Die Funktion hyperlink::create wurde entfernt. Zur Erzeugung von Links zu Seiten können die Funktionen

• hyperlink::create::pagedest
• hyperlink::frame_create_pagedest

verwendet werden. Ist der Zielpfad der Aufrufen leer (0 oder ""), wird ein Link innerhalb des Dokumentes erzeugt. Ist der Zielpfad nicht leer, wird der Link zu dieser Datei erzeugt. Das Zieldokument braucht dafür weder geöffnet sein noch überhaupt existieren. Beachten Sie aber, dass Links immer auf indd-Dateien zeigen müssen. Wird der Link im exportierten PDF dann geklickt, sollte die entpsrechende Ziel-PDF-Datei aber dann schon da sein :-)

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 verwendet). 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.

Oh, das ist keine gute Idee. Bei XYZ gibt es die Anweisung an alle Repros, dass immer der Alphakanal mit dem Namen "Transparenz" verwendet wird.

Das Problem bestand ja darin, aus der reinen Bilddatei die Namen der Alphakanäle zu ermitteln. Das funktioniert nur dann, wenn die Kanäle Namen haben, sonst nicht. Ich habe deshalb die Möglichkeit, Alphakanäle über ihren Namen zu setzen, deaktiviert.

Mit den Funktionen

• image::count_alpha_channels
• image::alpha_channel_name
• image::alpha_channel_index
• image::alphaindex

können jetzt Informationen zu Alphakanälen ermittelt werden. Damit kann der Index zu einem Namen ermittelt werden. Dann kann der Kanal über seinen Index angewendet werden. Aber (WICHTIG) : Dazu muss das Bild zuvor gesetzt sein und die Bilddatei muss existieren.

Das passiert jetzt nicht mehr.

In "Produktrecherche" und "Produkte des Dokumentes" gibt es ja jeweils ein Popup mit allen Templates. Mit einem kleinen Popup davor können die Einträge auf eine Domain beschränkt werden.

Könnte man die Einträge der Domain-Auswahl so aktivieren/deaktivieren, dass nur die Eiträge aktiv sind, bei denen dann auch Templates gefunden werden? Das würde unnötiges Suchen nach Templates sehr erleichtern.

In dem Menü mit den Bereichen sind jetzt nur noch die Einträge aktiv, bei denenauch tatsächlich Templates gefunden werden.

In "Produktrecherche" und "Produkte des Dokumentes" gibt es ja jeweils ein Popup mit allen Templates. Mit einem kleinen Popup davor können die Einträge auf eine Domain beschränkt werden. Könnte man in diesen Einschränkungen auch noch die Möglichkeit "Ohne Bereich" haben, so dass man nur die Templates sieht, die KEINER Domain zugewiesen sind? In der Entwicklung sind das nämlich meist die, mit denen man am meisten arbeitet.

Ist geschehen :

Was auch immer ich in diese Attribute schreibe - das Ergebnis bleibt unverändert.

Nein, die Attribute haben keine Wirkung mehr. Alle zur Tranformation nötigen Daten sind in den anderen Angaben vollständig enthalten.

ACHTUNG: Das heißt nicht, dass die Attribute nicht mehr in der note.xml enthalten sein müssen. Aus Gründen der Rückwärts-Kompatibilität müssen die Attribute weiter enthalten sein. Ihre Werte werden nur nicht mehr angewendet.

Notizen, die auf einen gedrehten Rahmen zeigen, werden nach Aus- und wieder Einblenden falsch positioniert. Die Position ist dann relativ zur linken oberen Ecke der Boundingbox um den gedrehten Rahmen, nicht mehr relativ zu (gedrehten) Ecke.

Das Gleiche gilt für verzerrte Rahmen und wir Notizen auf Cometgruppen, dessen Hauptrahmen gedreht/verzerrt ist.

Das ist die inverse Situation zu Bug 3425 - aber eben ganz anders. Ist gefixt.

Ich habe eine Rahmennotiz. Wenn ich jetzt den Rahmen, auf den die Notiz zeigt, drehe, verschiebt sich die Notiz. Das soll sie ja mglw. auch - aber die Verschiebung ist nicht richtig. Einfach kann man das wie folgt nachstellen:

1. Rahmennotiz erstellen
2. Beide Rahmen an der linken oberen Ecke justieren
3. Zielrahmen drehen

Die Notiz sollte danach ja weiter an der (gedrehten) linken oberen Ecke des Zieles stehen. Tut sie aber nicht.

Ist gefixt. Gilt ebenso für Verzerrungen.

Rahmen- und Gruppennotizen bekommen ein falsche XY-Position im Dokument, wenn man die Notizen aus- und wieder einblendet und der Notizenrahmen gedreht oder verzerrt (skewed) ist. Das Gleiche passiert, wenn man die Notizen exportiert und dann wieder importiert.

Der Fehler ist gefixt.

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.

Es gibt jetzt die neuen Menüs

    Nägel und Magneten -> Lesereihenfolge zeigen
    Nägel und Magneten -> Adaptionsfehler zeigen

Mit denen kann die Anzeige der Lesereihenfolge (und der letzten Adaptionsfehler des Rahmens) ein- und abgeschaltet werden. Die Einstellung gilt pro Dokument. Default ist, dass beide Anzeigen abgeschaltet sind.

Meine Notizen haben die Standardtransparenz 33%. Die wird auch angewendet. Aber nicht bei Notizen, die mit einem Rahmen oder einer Cometgruppe verknüpft sind. Dann ist die Transparenz weg. Die Flächentransparenz des Rahmens ist zwar gesetzt. Ich kann sie auch mit ganz normalen InDesign®- Mitteln ändern - aber dargestellt wird sie nicht. Komisch.

Die Verbindung zum Rahmen wird immer von der Rahmenmitte aus gezeichnet. Bei transparenten Rahmen würde sie dann dort, wo der Rahmen Fläche hat (das können ja konkave Formen sein), durchscheinen. Damit das nicht passiert, die Fläche vor dem Zeichnen im Hintergrund einmal als Clippath gesetzt. Das ist, nun ja, nicht ganz unaufwendig. Und leider hat Adobe die dazu nötige Funktion im CS6-SDK einfach gestrichen. Beim Implementieren eines Ersatzes ist der Fehler mit der Transparenz aufgetreten, der jetzt behoben ist.

Ich baue mit app.comet.execTemplate ein Produkt auf. Das erzeugte Dokument ist auch richtig. Leider sind aber die Previews, die ich davon hole, alle weiß. Ich habe folgende Funktionen getestet:

    app.comet.getPreview
    app.comet.getPreviewOfClipping
    app.comet.cometGroupGetPreviews

Noch einer aus der nervigen Reihe : CS6-Seitengrößenänderungen-Rahmenpositionen. Ist gefixt.

Laut Doku liefert die Methode xmlquery::exec() 0 oder einen Fehlercode, kann es sein, dass stattdessen bei einer erfolgreichen Ausführung eine 1 zurückgegeben wird? Zumindest funktioniert unter dieser Annahme mein Skript fehlerfrei, nachdem ich mehrere Stunde gesucht habe, warum ich einen "Fehlercode" statt 0 zurück bekommen.

Das tut uns leid. Ja, die Doku war falsch und ist korrigiert :

    1 : Okay
    0 : Fehler

Mit dem +-Button der Palette "Comet-Notizen" kann man ja zu jedem Rahmen der aktuellen Auswahl eine Rahmennotiz erstellen. Dabei wird immer eine Rechteck-Notiz angelegt. Könnte man da eine Auswahl bereitstellen, welcher Notiztyp angelegt werden soll?

Dafür gibt es jetzt vor dem +-Button ein Popup, mit dem der Notiztyp ausgwählt werden kann:

Siehe auch Bug 3409 und Notizvorlagen.

Da sieht man mal, was da so für Arbeit drin steckt ...

Also, wenn ein Notiz eine einfache senkrechte oder waagerechte Linie ist, dann ist der Notizen-Status sehr klein (weil der Rahmen ja praktisch entweder keine Höhe oder keine Breite hat). Das ist natürlich nicht ganz so gut.

Gefixt.

Ja klar, deshalb macht man das ja. Es ist auch wirklich nur ein Luxusproblem: Ich will lediglich den Farbindex ändern, so dss die Notiz in der Palette eine andere Farbe bekommt. Geht das?

Alt-Taste beim Wählen der Farbe gedrückt halten! Siehe auch gelber Zettel der Farbauswahl.

Gefixt.

d.h., keinen Status, Benutzer, letzte Änderung

Wird jetzt gemacht.

Das ?, ! oder √ steht dann also auf dem Kopf und/oder ist seitenverkehrt.

Der Wunsch, das zu richten, mag vielleicht albern klingen. Gedreht ist gedreht, gespiegelt gespiegelt, dann bewegt sich der Status halt mit. Verwendet man aber Striche (mglw. mit Pfeilen am Ende) ist das ein bisschen anders. Geht der Pfeil von oben links nach unten rechts, ist mit einer Notiz vielleicht alles in Ordnung. Dupliziert man diese Notiz (und warum sollte man das nicht tun?) und verändert sie so, dass der Pfeil jetzt von rechts oben nach links unten geht, dann sieht der Status nicht mehr gut aus.

Gedreht ist gedreht - dabei soll es auch bleiben. Aber bei Drehungen nahe 90° (und natürlich Vielfachen) und bei Spieglungen wird der Status jetzt ungedreht und ungespiegelt gezeigt. Nahe 90° heißt mit einer Differenz von 5°. Alles dazwischen wird weiter gedreht gezeigt.

Hier zweimal die gleiche Notiz in unterschiedichen Richtungen:

Ich habe ein Tabelle mit einer Excel-Datei verknüpft, die Umlaute im Namen hat. In der Palette werden die Umlaute falsch dargestellt.

Ist jetzt richtig.

Wenn ich die Palette XCell öffnen will, stürzt InDesign® ab.

Ist gefixt. Die Palette geht wieder auf.

Unter seltenen Umständen kann es vorkommen, dass InDesign® bei Verwendung von frame::image abstürzt. Der Test ist wie bei Bug 3398. Mit dem Fix von Bug 3398 ist das Ganze zwar stabiler geworden. Sind jetzt aber auch die Bilder vorhanden, stürzt InDesign® leider immer noch ab.

Gesucht, gesucht, gesucht, gesucht.

Gefunden!!

Jetzt funktioniert es.

Ebenfalls gefixt. Der Status sollten jetzt bei allen Farben und in allen Farbräumen (RGB, CMYK, Lab) gut sichtbar sein.

Mitunter zeigen Comet-Notizen keinen Status im Rahmen. Der Status ist das große !, ? oder √ im Rahmenhintergrund.

Ja, das ist immer dann der Fall, wenn die Notiz ein leerer Grafikrahmen ist.

Hintergrund ist, nun ja, der Hintergrund. Damit der Status nicht den Text überdeckt muß bei Texten zuerst der Status gezeichnet werden . Bei Bildern dagegen muß der Status nach dem Bild gezeichnet werden, sonst überdeckt das Bild den Status. Der Fall mit leeren Bildrahmen wurde dabei übersehen.

Ist gefixt. Danke, 1, setzen.

Es gibt jetzt einen Menübefehl, mit dem die aktuell ausgewählten Rahmen zu Notizen gemacht werden können. Die Rahmen werden dabei immer zu Seitennotizen gemacht.

Palette "Comet Notizen" -> Rahmen zu Seitennotiz machen

Zusatzmodule -> Aufgaben -> Rahmen zu Seitennotiz machen

Wenn ich eine neue Comet-Notiz angelegt habe, sind zwei Undos nötig, um das rückgängig zu machen.

Jetzt ist nur noch ein Undo nötig.

Seit Bug 2948 können Comet-Notizen ja mehrere Kommentare beinhalten. Die einzlenen Kommetare werden dabei durch

> 05.11.2013 15:12, paul

voneinander getrennt. Nachdem das mal ganz wichtig war, ist es jetzt plötzlich störend und soll wieder weg.

Also gut. Die sog. Prompts vor den einzelnen Kommentaren können jetzt entfernt werden. In der Palette "Comet-Notizen" gibt es dazu ein entsprechendes Knöpfchen:

    √ Auto-Prompt für Kommentare

Wird das ausgeschaltet, werden die Prompts entfernt.

Achtung: Die Angaben zu Uhrzeit und Benutzer gehen dabei verloren und werden beim erneuten Einblenden der Prompts auf die aktuellen Werte gesetzt!

Angeblich ist es störend, dass an den Comet-Notizen Informationen zur Notiz dargestellt werden (oben links Name, Datum, ..., über der Fläche der Status). Wir sollen das daher ausschaltbar machen.

Dann halt. Diese Eigenschaften sind jetzt pro Notiz ein- und ausschaltbar.

Achtung : Seitennotizen, die ja keine Verknüpfung darstellen, sind dadurch mglw. nicht mehr von "normalen" Dokumentrahmen unterscheidbar:

Ja, ist einzusehen. Die Absatztrenner am Ende sind jetzt weg.

Ja klar, ist ja auch keiner gesetzt. Könnte man aber nicht statt dessen den Inhalt (oder Teile davon) anzeigen lassen? Das wäre doch schön.

Okay, wenn das schön wäre. Dann wollen wir dem doch nicht im Wege stehen. Bei Notizen ohne Titel wird jetzt deren Inhalt in der Palette gezeigt.

Zeilentrenner und Return werden dabei durch ¬ ersetzt.

ACHTUNG: Der angezeigte Inhalt wird natürlich nicht synchron zu Dokumentänderungen gehalten. Er wird beim Neuladen der Liste ermittelt.

In der Palette "Comet-Notizen" können Notizen nach bestimmten Kriterien gesucht werden. Die Suche beeinflußt aber nicht, ob Notizen im Dokument sichtbar sind oder nicht.

Sollen nur bestimmte Notizen im Dokument gezeigt werden, funktioniert das wie folgt:

1. Alle Notizen ausblenden
2. Suche starten
3. Alle gefundenen Listeneinträge auswählen
4. Ausgewählte Notizen sichtbar machen

Nun die Frage : Kann man das auch einfacher gestalten?

Man kann (ab jetzt) : Dazu einfach beim Auslösen der Suche (Enter bzw. fn+RETURN, erstes Button links unten in der Palette) die ALT-Taste festhalten.

Ich habe folgenden einfachen Test:

1. Öffnen eines Dokumentes
2. Einfügen eines Templates
3. SaveAs des Dokumentes
4. Schliessen des neuen Dokumentes

Das ganze wird in einer Schleife beliebig oft wiederholt. Oder besser : Soll. Geht aber nicht. Spätestens beim 10 Durchlauf stürzt alles ab. Der Fix von Bug 3398 kann mit diesen Abstürzen nichts zu haben. Dieser Fix hat ausschließlich die Desktop-Versionen betroffen.

Ist gefixt. Jetzt lassen sich mit dem gleichen Testfall 1.000 Dokumente erstellen!

In der Palette Comet-Notizen kann man ja nach dem Titel von Notizen suchen. Könnte man auch im Inhalt der Notizen suchen lassen?

Das geht jetzt. Vor dem Suchfeld ist jetzt ein Popup mit den Auswahlen :

Die bisherige Suche hat immer am Anfang des Titels gesucht. Für eine Inhaltssuche ist das ein bisschen mager. Deshalb befindet sich hinter dem ersten Popup zusätzlich ein zweites mit der folgenden Auswahl:

Dieses Popup haben auch die Suchfelder "Geändert von" und "Zugewiesen an" erhalten. Die in den Popups gemachten Einstellungen sind Neustart-Resistent.

Eine Comet-Notiz die von einem Benutzer namesn "Müller" oder "Bäcker" erstellt wurde, wird versteckt. Später wird sie wieder sichtbar gemacht. Jetzt ist aus Müller aber leider "M&#xFC;ller" geworden. Damit könnte Herr Müler noch umgehen. Aber wenn die Notiz jeder erneut versteckt und wieder sichtbar gemacht wird, wird auch noch das & codiert :

    M&üller

Und so immer weiter.

Gefixt. Müller bleibt jetzt Müller und König bleibt König.

In der Palette Comet-Notizen kann nach Titel, "Erstellt von" und "Zugewiesen an" gesucht werden. Das funktioniert - aber nur, wenn der Suchstring keine Umlaute enthält.

Das ist gefixt.

Ich habe folgenden einfachen Test:

1. Öffnen eines Dokumentes
2. Einfügen eines Templates
3. SaveAs des Dokumentes
4. Schliessen des neuen Dokumentes

Das ganze wird in einer Schleife beliebig oft wiederholt. Oder besser : Soll. Geht aber nicht. Spätestens beim 10 Durchlauf stürzt alles ab.

Der Fehler ist gefixt.

Nein, frame::image stürzt normal nicht ab. Es müssen schon sehr besondere Umstände sein.

1. Wir haben einen Bildrahmen mit dem Bild A
2. Das Dokument wird gesichert und geschlossen
3. Das Bild wird weggeschmissen
4. Das Dokument wird neu geöffnet. Der Bildlink steht jetzt auf "missing"
5. Das Bild wird wieder hergestellt (z.B. über einen Download)
6. jetzt kommt frame::image mit dem alten Pfad A

... und dann stürzt InDesign® ab.

Der Fehler ist gefixt.

Ich habe einen um 90° gedrehten Rahmen. Wenn auf diesen Rahmen ein frame::fit angewendet wird, stürzt InDesign® CS6 ab. Bis CS5.5 ging das gut.

Das ist gefixt.

Seit R4616 stürzt InDesign® unter Windows ab, wenn Inlines mit dem <in>-Tag eingefügt werden sollen.

Das ist gefixt.

Kann ich auch Einträge der Preview-Palette platzieren, die im Fomrat INDD, IDML oder IDMS sind?

Es ist jetzt möglich, auch INDD, IDML oder IDMS als Bildformat zu verwenden. Dazu einfach einen Bildeintrag anlegen, der auf die gewünscht Datei verweist.

Bitte beachten:

• Wie auch "normale" Bilder müssen die Dateien im LAN verfügbar sein.
• Bei Mehrseiten-Formaten (INDD, IDML) werden alle Rahmen der ersten Seite eingesetzt.
• Die Dokumente werden wie "Snippets" behandelt, d.h. auch, ss werde keine Produkt-Verknüpfungen gesetzt oder geladen.

Wir betrachten das als good will feature. Änderungen und Fixes werden als Feature requests behandelt.

Ich will eine Textauswahl durch ein Preview-Snippet ersetzen. Das Snippet wird eingesetzt. Befindet sich die Auswahl in einem Platzhalter, wird dabei der gesamte Platzhalter ersetzt. Aber ohne Platzhalter wird die Textauswahl nicht gelöscht. Das Snippet wird immer an den Beginn der Textauswahl gesetzt.

Das ist gefixt. Bei Platzhaltern wird nach wie vor der gesamte Platzhalter ersetzt. Ohne Platzhalter wird jetzt exakt die aktuelle Textauswahl ersetzt.

Ich ersetze eine Rahmenauswahl eines Dokuments durch Snippet der Preview-Palette. Das funktioniert ordentlich. Verwende ich das gleiche Snippet noch einmal, um eine andere Rahmenauswahl zu ersetzen, stürzt InDesign® ab.

Der Absturz passiert nur dann, wenn ich das Snippet-Button verwende.

Der Fehler ist gefixt.

Der Aufruf

li = document::place_indesign ("$DESKTOP/aaAABB.idms", 1, "", 0, 1, 10.0, 10.0);

erzeugt folg. Fehlermeldung, wenn die Datei nicht gefunden wird:

# Pageitem (tmp) file not found : '/Users/paul/Desktop/aaaabb.idms'

Die Dateien werden also case-insensitiv gesucht.

Der Fehler ist gefixt.

In manchen Konstellationen wirkt sich placeholder::change_tags unterschiedlich aus, je nachdem, ob man einen Text- oder Rahmenplatzhalter bearbeitet. In einem Platzhalterscript, das sowohl neue Rahmen anlegt als auch die IDs ändert, bekommen Text- und Rahmenplatzhalter unterschiedliche IDs.

Im Script steht folgendes:

placeholder::change_tags(fr, 3, "ID", id, kAnyPlaceholder);
placeholder::change_tags(fr, 3, "ID2", id2, kAnyPlaceholder);
placeholder::change_tags(fr, 3, "ID3", id3, kAnyPlaceholder);
placeholder::change_tags(fr, 3, "STRINGID", sid, kAnyPlaceholder);

Den Rahmen fr hole ich am Anfang des Scripts über textmodel::get_frame, um Verwirrung mit gFrame zu vermeiden. Die IDs werden auch für alle Platzhalter gesetzt, allerdings erstaunlicherweise die gleichen IDs.

Im vorliegenden Fall legt der Laden-Platzhalter, der auch placeholder::change_tags aufruft, weitere Rahmen an. Diese Rahmen werden mit Text gefüllt, der wieder Platzhalter enthält - und zwar den gleichen Platzhalter wieder. Es entsteht also eine Rekursion.

Leider ist aber die Funktion frame::replace, mit der der getaggte Text in die neuen Rahmen eingefügt wird, nicht rekurions-fest. Dadurch entsteht der Fehler.Ich habe deshalb drei neue Funktionen implementiert :

• frame::rinsert
• frame::rappend
• frame::rreplace

Diese Funktionen sind vollkommen identisch zu den entsprechenden Funktionen ohne 'r' mit der Ausnahme, dass die rekursions-fest sind.

Damit ist das Problem gelöst.

Bei

char 	mess[256];
					
xmlquery::error(tree, mess);
showmessage("Fehler '%s' beim Lesen der Daten", mess);

bekomme ich die Fehlerbeschreibung nicht geliefert.

Der "Fehler", der hier gefunden werden sollte, war ein "missing node" im XML. Das ist aber im eigentlichen Sinne gar kein Fehler. XMLQuery liefert in diesen Fällen einfach keine Ergebnisse. Standardfall ist eine (fast) leere XML-Datei, etwa:

<objects>
</objects>

Die Anweisung

select id node objects.object where id = 1

für diese Datei ist ja nicht falsch, sie findet nur nichts.

Mit der neuen Funktion xmlquery::get_exec_infos können jetzt auch Warnungen dieser Art aufgefangen werden:

XMLTree	tree	= xmlquery::open ...;
char 	execInfos [4096];
:
:
xmlquery::exec (tree);
if (xmlquery::get_exec_infos (execInfos)
{
	showmessage("XMLError %s", execInfos);
}

Bei der verwendung von xmlquery::errnum bekomme ich die Meldung

    undeclared identifier: xmlquery::errnum(tree);

Kleiner Copy/Paste-Fehler in der Registrierung der Funktion für cScript. Das ist gefixt. Die Funktion kann jetzt wieder benutzt werden.

Die Funktionen page::templates::get_element_info_by_index/sequ geben keine Werte zurück.

Das ist gefixt.

Bisher gab es das Menü "Einfügen ohne Formatierung". Das ist jetzt weg :-(

Ja, mit dem Fix von Bug 3251 wurde dasMenü entfernt. Es gibt jetzt ein neues Menü :

    Unformatiert einfügen in Platzhalter

Dieses Menü existiert und Mac UND Windows.

Das geht jetzt.

... genau! Die Y-Position ist falsch. Und zwar genau um die Hälfte der Höhenänderung. Ober halb der Seitenmitte zu tief, unterhalb zu hoch.

Bedankt Euch bei Adobe!

Ist gefixt.

dito document::insert_macro und document::place_indesign

Ich habe ein Dokument, dessen Seitengrösse irgendwann geändert wurde. Werden hier mit itemlist::move_to Rahmen neu positioniert, stimmen leider deren Y-Positionen nicht mit meiner Eingabe überein.

Ist gefixt.

Ich habe ein Dokument, dessen Seitengrösse irgendwann geändert wurde. Wird hier mit itemlist::bbox die Boundingbox einer Rahmenliste erfragt, stimmt die leider nicht.

Das Problem ist gefixt.