27.10.2011

Der Skriptbefehl document::adapt führt reproduzierbar und immer zum Absturz von InDesign®.

Der Fehler ist als Folge des Fixes von Bug 2210 entstanden und besteht seit :

• v3.2.3 R2606, 14.08.2011
• v3.3 R2636, 06.09.2011

Er ist jetzt behoben. Es wird für diesen Fix auch noch mal ein neues Releasevon 3.2.3 geben.

Soll in eine Tabellenzelle ein Bild eingesetzt werden bei dem im Pfad ein Umlaut vorkommt, dann wird das Bild nicht gefunden. Ein vorheriges file::exists() auf den Bildpfad sagt allerdings, dass die Bilddatei existiert.

Wenn ich den Pfad ohne Umlaute verwende (ä -> ae) dann wird das Bild gefunden und geladen. Der Pfad mit Umlaut funktioniert auch bei der Methode frame::image, von daher würde ich mal tippen, dass die Methoden den Pfad möglicherweise unterschiedlich behandeln.

    Beispielpfad: C:\myview\Projekte\hazet\Aufträge/018093ba.tif

Der Bereich "C:\myview\Projekte\hazet\Aufträge" wird aus einem Einstellungs-Wert gelesen, der Dateinamen kommt aus den XML-Daten.

Laut einer Kundenaussage stürzt das InDesign® auf einem Mac in diesem Fall sogar ab, das konnte ich aber noch nicht testen, da ich gerade keinen Mac habe. Werde ich aber bei Gelegenheit testen und ergänzen.

Falsche Zeichenkodierung verwendet. Der Fehler ist behoben.

FYI

Der Absturz wurde wahrscheinlich dadurch ausgelöst, dass InDesign® an dieser Stelle bei einem falschen Bildpfad eine Standard-Warnung zeigt. Befindet man sich jetzt in einer Schleife (z.B. Produktaufbau), wird die Warnung mglw. mehrfach gezeigt - und übereinander liegende modale Dialoge führen dann zu dem Absturz. Selbst ein Bein gestellt.

06.09.2011

Es gibt leider bisher keine Funktion, um den Objektstil eines Rahmens zu ermittlen.

Stimmt. Deshalb jetzt die neue Funktion frame::get_objectstyle.

Gibt es eine Möglichkeit, Abweichungen der gesetzten Rahmeneigenschaften und dem gesetzten Objektstil per cScript zu entfernen? (entspricht dem Button +-Entferner der Palette 'Objektformate').

Nein, bisher gab es das nicht.

Die Funktion frame::set_objektstyle hat jetzt den zusätzlichen Parameter clearOverrides. Ist der ungleich 0, werden Abweichungen vom Objektstil entfernt.

Mit frame::set_objectstyle kann man zwar den Objektstil eines Rahmens setzen. Aber es gibt leider keine Funktion, um den Objektstil wieder von einem Rahmen zu entfernen.

Wird frame::set_objectstyle jetzt mit dem Stilnamen "" gerufen, wird der gesetzte Objektstil entfernt.

Workaround

Man kann den Objektstil natürlich auch jetzt schon entfernen : "[Einfacher Textrahmen]" oder "[Einfacher Grafikrahmen]" entfernen den Objektstil ja auch. Allerding muss dazu den Rahmentype kennen und das Ganze ist sprachabhängig.

In der Doku steht, dass frame::set_objectstyle mit dem Rahmen 0 den aktuellen Skriptrahmen verwendet. Das stimmt aber nicht, man muss an dieser Stelle gFrame verwenden.

Ist gefixt.

Seit CS5 erzeugt der Befehl frame::copy_image einen Fehler, wenn der Bildrahmen leer ist. Der Fehler wäre nicht schlimm, aber leider wird die Funktion auch bei der Seitenreorganisation verwendet. Und die hört leider bei diesem Fehler mit dem Aufräumen auf und macht alle Änderungen der Reorganisation rückgängig.

Wirklich unangenehm. Der Fehler ist gefixt.

Unter CS5 gibt die frame::is_empty_graphicframe auch bei leeren Bildrahmen die Antwort, dass der Rahmen nicht leer sei.

Der Fehler ist gefixt.

Workaround

char    ipath [5000];

strcpy (ipath, "");
if (	frame::is_valid (gFrame)
	&&  frame::is_graphicframe (gFrame)
	&&  !frame::has_embedded_image (gFrame)
	&&  frame:: image_getpath (gFrame, path) == 0
	&&  strlen (ipath) > 0)
{
	// Der Rahmen ist ein Bildrahmen ohne Bild
}

Beide Funktionen holen nur den eigentlichen Stilnamen. Ist der Stil in eine Hierarchy einsortiert, fehlt aber leider der Pfad der Hierarchy.

Das ist jetzt gefixt. Beide Funktionen ermitteln jetzt den gesamten Stilpfad.

Das folgende Script führt unter Windows zu Absturz. Auf dem Mac wird es ausgeführt.

int main()
{
	FloatList colWidth = floatlist::alloc();

	floatlist::append(colWidth, 1.34);
	floatlist::append(colWidth, 3.14);

	floatlist::release(colWidth);

	return 0;
}

Der Fehler ist gefixt (Ein double-free hat den Fehler verursacht)

Workaround

floatlist::release kann in diesem Skript weglassen werden. Es wird automatisch released. In Skripten, in denen die Liste in einer Schleife neu angelegt wird (das floatlist::release also nötig ist) genügt es, vor floatlist::release die folgende Zeile einzufügen :

    floatlist::clear (yourList);

Wird beim Aufräumen eines Dokumentes ein Produkt auf eine neue Seite verschoben muss in der Regel das Template gewechselt werden. Dabei werden die Inhalte von Rahmen gleicher Kennung übernommen. Hat ein Template eine Fortsetzung, wird dabei aber leider der Rahmen aus der Fortsetzung verwendet und nicht der Rahmen der Hauptgruppe.

Merkwürdig, dass das noch nicht aufgefallen ist. Der Fehler ist jetzt gefixt.

Die Liste der Templates bleibt nach dem Laden (Lupe) immer leer. Wenn ein neues Template angelegt wird, erscheint das in der Liste. Aber beim erneuten Laden der Liste ist auch das neue Template weg. In der Datenbank scheint alles okay zu sein. Das Logfile zeigt, dass alle für das Laden der Templates nötigen Anweisungen ausgeführt werden und fehlerfrei sind.

Spannend. Das Problem tritt nur auf, wenn die Tabelle pageitems das Attribut memberships enthält. Fehlt es, funktioniert alles. Das wäre dann auch der Workaround.

Das Problem wurde durch eine unsinnige if-Einschränkung in den Plugins erzeugt, die so blöd ist, dass sie eigentlich nur durch Unachtsamkeit reingekommen sein kann. Merkwürdig ist, dass der Fehler 1 Jahr unbemerkt blieb. Er ist jetzt behoben.

Bei einigen TIFF-Bildern wird beim Erzeugen des Previews für die Palette ein Dialog mit dem Text

    Fehler beim Lesen des TIFF-Bildes. Das Bild ist u.U. beschädigt ...

gezeigt. Das Preview wird dann trotzdem erzeugt. Die Meldung ist aber nervig. Kann man die nicht wegmachen?

Die Meldung wird von InDesign®, nicht vom Cometen erzeugt. Wir sind natürlich nicht in der Lage, diese spezielle Meldung zu unterdrücken. Aber wir können während der Previewgenerierung ALLE Alerts unterdrücken. Das wird jetzt gemacht. Kann ein Preview tatsächlich nicht erzeugt werden, ist das ja in der Palette erkennbar.

14.08.2011

Wird im Textfluss aufgebaut, stürzt InDesign® Server ab, sobald eine neue Seite angelegt werden muss.

Gibt es eine Funktion, um die Textfarbe eines Textbereiches zu setzen?

Jetzt ja, drei :

    textmodel::set_color
    textmodel::set_color_rgb
    textmodel::set_color_cmyk

In Sync-Skripten muss man immer wieder die Strings des Datenpools mit dem aktuellen Platzhaltertext im Dokument vergleichen. Das birgt gleich mehrere Schwierigkeiten, die in jedem Skript aufs Neue umgangen werden müssen :

• Leere Strings des Datenpools werden als Hairspace im Dokument eigesetzt.
• Unterschiedliche Zeichenkodierungen (meist UTF8 vom Datenpool und <0xXXXX>-Tags vom Dokument)
• Unterschiedliche Darstellung der Absatztrenner
• TaggedText aus dem Dokument ist meist ausführlicher als der des Datenpools
• Typografische Anführungszeichen

Kann man diese Stringvergleiche nicht skriptseitig etwas vereinfachen?

Die Funktionen strcmp und strncmp haben jeweils einen neuen (optionalen) Parameter namens netWeight. Ist der auf != 0 gesetzt, werden anstelle der eigentlichen Strings deren "Netto"inhalte verglichen. Die Netto-Werte der Strings werden wie folgt berechnet :

• Leerstrings werden durch einen Hairspace ersetzt
• UTF-8-Zeichen werden einheitlich in <0xXXXX>-Tags übersetzt
• Beginnt der Text mit %!TT wird (wenn vorhanden) das direkt darauf folgende ParaStyle-Tag entfernt
• Alle weiteren ParaStyles werden durch Zeilentrenner ersetzt
• Alle anderen TaggedText-Tags werden aus dem Text entfernt
• Alle Zeilentrenner werden vereinheitlicht
• Alle doppelten Anführungszeichen werden in " übersetzt. Alle einfachen Anführungszeichen werden in ' übersetzt.

Strings werden ja intern als UTF8 abgelegt. Gibt es Funktionen, mit denen ein Byte-Index in einen Zeichenindex und umgekehrt umgerechnet werden kann?

Die neuen Funktionen get_utf8index und get_realindex machen das jetzt.

ich möchte anregen, eine Comet-Funktion in die Scriptsprache zu integrieren, die es erlaubt, Texte per RegularExpressions / RegEx zu filtern und zu verändern. Anwendungsfälle würde es sicher zu genüge geben!

Intern haben wir natürlich schon lange eine Maschine zur Behandlung regulärer Ausdrücke. Ich habe die jetzt ein bisschen angepasst und über strreplace und strstrpos nach aussen freigegeben : Der Suchstring dieser Funktionen kann jetzt jeweils ein regulärer Ausdruck sein (Er muss in diesem Fall mit "regexp:" beginnen, dann folgt der reguläre Ausdruck).

Mehr dazu und eine Kurzeinführung in reguläre Ausdrücke, Beispiele und eine Testdatei in der Doku unter strreplace bzw. strstrpos.

Hier eine Testdatei (CS5.5)

Enthält ein Previewpfad TaggedText-kodierte Zeichen der Form <0x00FC>, wird die Datei nicht gefunden. Okay, diese Kodierung gehört auch nicht an diese Stelle und wird hier auch gar nicht mehr benötigt. Sie wird aber leider doch recht häufig verwendet.

Okay, wird unterstützen das jetzt in Pfaden der Previewpalette (aber nicht allgemein für alle Dateipfade!).

Enthält ein Pfad eines Preview-Eintrages kyrillische (oder andere Unicode-) Zeichen, stürzt InDesign® ab. Dabei ist es egal, ob die Datei existiert oder nicht. Die Preview-Einträge werden zunächst auch alle geladen. Der Absturz kommt scheinbar erst, wenn einer der Pfade in die Palette geschrieben werden soll.

Auffällig ist auch, dass bei Pfaden die Umlaute enthalten und die auf zwei Zeilen der umbrochen werden müssen, an der Umbruchstelle genau so viel Zeichen fehlen wie der Pfad Umlaute enthält. Alles klar? Hier ein Beispiel:

    /Users/paul/Desktop/124567889äöü/qwertzu/abc.JPG

wird so umbrochen :

    /Users/paul/Desktop/124567889äöü/qw
    zu/abc.JPG

Die drei Zeichen "ert" fehlen.

Der Fehler ist gefixt.

Ein Platzhalter baut zusätzlich Rahmen mit document::place_items auf. Ein Parameter dieses Kommandos steuert, dass die neuen Rahmen zur gleichen comet-Gruppe gehören sollen wie gFrame, also der auslösende Rahmen. Leider gehören die neuen Rahmen nach dem Aufbau NICHT zur comet-Gruppe des Platzhalter-Rahmens, sondern zu keiner Gruppe. Im Template für die erste Seite wird ein ähnlicher Platzhalter benutzt, dessen neu erzeugte Rahmen korrekt der comet-Gruppe zugeordnet werden.

Meine Vermutung ist, dass die comet-Gruppierung bei Aufbau einer Fortsetzungsseite erst zu spät gemacht wird, nach dem Aufbau.

Nein, der Fehler war was ganz anderes.Vor dem Einsetzen der Fortsetzung gibt der Produktaufbau die (interne) Versprechung, dass die Rahmen mit den Kennungen des Haupttemplates bereits geladen sind. Sind sie ja auch. Diese Rahmen werden dann nach dem Einfügen ins Dokument nicht automatisch geladen. Nach dem Laden des Templates werden alle neu entstandenen Rahmen zu einer Comet-Gruppe zusammengefasst.

Weil die Rahmen der Fortsetzungen aber natürlich auch noch geladen werden müssen, wird das etwas später nachgeholt. Klappt auch alles prima. Nur dass an dieser Stelle nicht die Differenz aus den Rahmen vor und nach dem Laden weitergegeben wurde sondern einfach die Liste der vom Template eingefügten Rahmen. Und da haben die beim Laden zusätzlich angelegten Rahmen natürlich gefehlt.

Das ist jetzt gefixt.

Sollte da nicht erst 'Z' kommen?

Eigentlich schon. Kommt jetzt auch.

Im Template-Editor werden automatisch die Kennungen der Rahmen angezeigt (der große Buchstabe im Kreis in der Mitte des Rahmens). Diese Anzeige kann über die Palette 'Template-Verhalten' ausgeblendet werden. Wird der Rahmen jetzt aber verschoben oder in seiner Grösse geändert, wird diese Kennung sofort wieder eingeblendet.

Ausgeblendete Kennungen bleiben jetzt auch nach Geometrieänderungen unsichtbar.

Achtung : Wird der Template-Editor wieder neu geöffnet, werden die Kennungen wieder alle eingeblendet.

Enthält ein Template InDesign®-Gruppen, werden beim Einsetzen des Templates ins Dokument die Rahmenkennungen (Palette 'Template-Verhalten') gezeigt. Man kann die Kennungen zwar manuell wieder entfernen, besser wäre aber sicher, die Kennungen würden gar nicht erst erscheinen.

Die Kennungen werden beim Sichern der Templates entfernt - leider bisher nicht in Unterrahmen von InDesign®-Gruppen. Das wird jetzt gemacht. Der Fehler ist damit gefixt.

Achtung : Ais Performance-Gründen werden die Kennungen einmal beim SICHERN des Templates entfernt, nicht x-mal beim Einsetzen. Die entsprechenden Templates müssen also mit der neuen Version einmal gesichert werden.

Fehlt die Biddatei eines Bildrahmens oder enthält der Rahmen ein eingebettetes Bild, führt frame::copy_image zum Absturz von InDesign®.

Fehler hochgesetzt auf 'crical', weil der selbe Befehl auch bei der Reorganisation verwendet wird und dann natürlich auch zum Absturz führt.

Der Fehler ist gefixt.

Bei starken Seiten-Verkleinerungen werden Adaptionen nicht mehr ordentlich ausgeführt. Rahmen rechts und unten auf den Seiten nicht mehr richtig adaptiert.

Der Fehler ist seit v3.1 R2223 gefixt mit der Einschränkung, dass es unter CS3 weiter zu Fehler kommen kann.

Adaptionen mit Verkleinerungen, bei denen Rahmen ohne Nägel von der Seite fallen würden, funktionieren jetzt auch unter CS3.

14.07.2011

Die Guillemets (« und ») werden nicht in die korrekten Tags ("<0x00AB>" und "<0x00BB>") konvertiert, sondern in komisches Zeug. InDesign® selbst konvertiert beim Export korrekt.

Anscheinend übrigens nicht nur die. Folgender Code:

int clean_text_for_load(char *txt)
{
	char    *	temp    = alloc(strlen(txt));

	wlog("", "### before conv:  '%s'\n", txt);
	
	// convert to utf8
	tagged_to_utf8(temp, txt);
	strcpy(txt, temp);
	wlog("", "### after conv:   '%s'\n", txt);
	
	utf8_to_tagged(temp, txt);
	wlog("", "### after reconv: '%s'\n", temp);

	release(temp);

	return 0;
}

schreibt ins Logfile:

### before conv: '<ParaStyle:Gr<0x00F6>ssen>38<0x2013>40, 40<0x2013>42, 42<0x2013>44, 44<0x2013>46, 48<0x2013>50'
### after conv: '<ParaStyle:Grössen>38–40, 40–42, 42–44, 44–46, 48–50'
### after reconv: '<ParaStyle:Gr∫ssen>38<0x2013>40, 40<0x2013>42, 42<0x2013>44,
44<0x2013>46, 48<0x2013>50'

Auch komisch, oder?

Ja, wir haben bisher alle Zeichen >= 256 in Tagged-Zeichen übersetzt. Die < 256 wurden jeweils systemkonform übersetzt. Dein ö da oben ist dann also ein Mac-ö geworden. Das ist jetzt geändert : Alle Zeichen >= 128 bekommen jetzt Tagged-Zeichen.

Nach dem Einfügen eines Templates per DragDrop bleibt InDesign® reproduzierbar stehen. Im Logfile steht, dass das Einfügen des Templates erfolgreich ausgeführt wurde und die temporäre Datei des Templates gelöscht wurde. Im Task-Manager kann man sehen, dass die Applikation mit 100%-Prozessor-Auslastung arbeitet. Das selbe Problem tritt auf, wenn ein Rahmenplatzhalter neu verknüpft werden soll. Auch hier kann man im Logfile sehen, dass alles erfolgreich aktualisert wurde - und dann steht InDesign®.

Das Problem trat bisher nur unter Windows Vista auf. Andere Windows-Versionen und Mac funktionieren.

Der Fehler ist gefixt.

11.07.2011

Im alten Textfluss-Aufbau konnte der Textfluss-Aufbau so eingestellt werden, dass zwischen den Produkten automatisch ein Trenntext eingefügt wurde. Im neuen, Seitentemplate-gesteuerten Aufbau geht das nicht mehr, oder?

Stimmt, Trenntext zwischen den Produkten war hier bisher nicxht vorgesehen. Das geht ab jetzt. Die entsprechenden Einstellungen werden im jeweiligen Template gemacht. Es gibt zwei unterschieldliche Trenntexte : Einen Text für das erste Produkt und einen für alle weitere. Folgende Trenntexte können eingestellt werden :

• Kein Trenntext
• Leerzeichen<
• Absatz
• Eigener Text (kann auch %!TT sein)
• -
• Datenbankskripte der Klasse 46

Mehr dazu in der Online-Doku.

Für das Feature ein eine Erweiteruing des Datenmodelles nötig, mehr dazu siehe hier.

Enthält ein Seitenelement ein Textfluss-Element, stürzt der Aufbau beim zweiten Produkt, das in das Textelement eingefügt werden soll, ab. Der Fehler tritt nicht auf, wenn der Text, der (via Template) eingefügt wird, mit einem Return endet.

Der Fehler ist gefixt.

Beim Produktaufbau sind einige Strings nicht übersetzt und werden als k0x098700....StringKey angezeigt :

1. Eine Meldung vor der Reorganisation
2. Einige Gelbe Zettel im Aufbau-Dialog

Das ist immer wieder komisch. Eigentlich ist alles richtig. Aber erst wenn man die Definitionen noch mal ein bisschen umbenennt (z.B. eine 2 an den Namen) werden sie richtig angezeigt.

Unter MS SQLServer führt showmessage zum Abbruch der Datenbankverbindung. Der Fehler scheint daran zu liegen, dass showmessage automatisch nach einer Übersetzung der Nachricht sucht und dafür die Datenbankabfrage

    select key, translation from messages where language = ...

sendet. key list aber leider ein MS SQLServer-Schlüsselwort.

Der Fehler kann jetzt wie folgt behoben werden :

1. Ändern des Attributes messages.key in messages.keyword
2. Anlegen eines neuen Eintrages in der Tabelle keywords mit den Werten keyword="KEY" und value="keyword".
3. Neuloggin

... jedenfalls nicht, wenn der Musterseitenname einen Bindestrich enthält. "A-Rasteraufbau" funktioniert perfekt "A-Rasteraufbau-horizontal" nicht. (möglicherweise liegt es auch nicht am Bindestrich sondern an der Länge, aber ich könnte mir einen strtoken-Fehler vorstellen).

Das ist jetzt gefixt.

Wenn ich einen Magneten zur Oberkante eines sehr flachen Rahmens setzen will, wird statt dessen ein Magnet zur Unterkante dieses Rahmens gesetzt. Ist der Rahmen etwas höher klappt es. Das selbe passiert analog bei Magneten zur linken Seite.

Ja, das stimmt. Die Anfasspunkte haben aktuell eine sensitive Fläche von 10 Punkten um den eigentlichen Punkt. Das ist jetzt geändert, Die sensitive Fläche ist jetzt nur noch 2 Punkte groß.

01.07.2011

Wenn ich Musterseitenrahmen mit page::masteritems_load() lokalisiere, gehen die Verkettungen zwischen den Rahmen verloren. Dabei ist es egal, ob die Rahmen auf der gleichen Seite oder auf verschiedenen Seiten des gleichen Spreads liegen.

Das passiert auch, wenn ich mit page::masteritems_load(-1, 3) alle Elemente auf einmal lokalisiere.

Das Problem ist gefixt.

Die Rahmenliste der Palette "Template-Verhalten" ist nach Öffnen der Paletteleer obwohl das aktuelle Dokument eigentlich Rahmen enthält. Auch bei Dokumentwechseln wird die Liste nicht immer aktualisiert.

Diese Liste sollte jetzt immer richtig aktualisiert werden.

Die Rahmen von Templates werden durch einen Kreisausschnitt markiert, der anzeigt, zu welchem Untertemplate der Rahmen gehört. Dieser Kreisausschnitt scheint nicht immer richtig zu sein. Wenn man z.B. ein 4-seitiges Template per Doppelklick öffnet, werden die Rahmen unten links mit einem Viertelkreis unten rechts gekennzeichnet und die Rahmen unten rechts haben den Viertelkreis unten links. Und zweiseitige Templates zeigen immer nur Viertelkreise. Fügt man dann neue Rahmen hinzu oder verschiebt bestehende Rahmen, werden die Kreisausschnitte wieder richtig.

Ist das nur ein Darstellungfehler oder hat das auch funktionale Konsequenzen?

Das ist nur eine etwas fehlerhafte Drastellung und hat keinen Einfluss auf die Funktion der Templates. Trotzdem irgendwie nur semi-profesionell - deswegen ist das jetzt gefixt.

Bei der Konfiguration eines Templates werden ständig die Dreiecke zur Fortsetzung von Textrahmen zurückgesetzt. Man kann das leicht reproduzieren, indem man einen Rahmen mit Fortsetzung mit einem Magneten versieht. Danach hat der Rahmen keine Fortsetzung mehr.

Der Fehler ist gefixt, die Einstellung der Fortsetzung bleibt jetzt erhalten.

Änderungen des Skriptes am Dokument werden bei document::save ignoriert. Das Dokument wird immer im Zustand des Dokumetes vor dem Skript gesichert.

Das Problem wird durch die automatisch um jedes Palettenskript gelegte Undo-Sequenz erzeugt. Um sichern zu können, muss diese Sequenz zuerst beendet werden. Ab diesem Release wird das automatisch gemacht.

Workaround

Vor dem Sichern die Sequenz beenden und danach mit einer neuen Sequenz beginnen:

document::end_sequence (0);
err = document::save(outRef,kSuppressUI);
document::begin_sequence ("Weiter nach Save", 1);

Mit

    @LOADLIST framelabels

kann das Parameter-Popup einer Gestaltungsregel ja mit den in der Cometgruppe verwendeten Rahmenkennungen gefüllt werden. Sehr schön. Hat man jetzt eine Cometgruppe mit Fortsetzung passiert folgendes : Wird beispielsweise der Rahmen C fortgesetzt, erscheint das C so oft im Popup, wie es Fortsetzungen gibt. Eigentlich nicht schlimm - aber man kann ja dann keine Auswahl treffen, welchen der Rahmen man eigentlich meint.

Ja, blöde Sache das. Das Popup zu ändern ist einfach : Die Einträge erscheinen jetzt jeweils nur einmal im Popup.

Schwieriger war schon die Funktion frame::get_cometgroup_member. Die ist jetzt so geändert, dass zuerst in der Fortsetzungsgruppe nach der Kennung gesucht wird. Erst wenn dort kein geeigneter Rahmen gefunden wurde, wird in der gesamten Cometgruppe gesucht. Damit ist dann automatisch auch gleich ausgeschlossen, dass ein Rahmen auf Fortsetzungs-Rahmen einer anderen Fortsetzungsgruppe zugreifen kann.

Die Zugehörigkeit eines Rahmens zu einer Fortsetzungsgruppe wird ebenfalls erst ab diesem Release ins Dokument geschrieben. Mit älteren Dokumenten funktioniert das Verhalten also so nicht.

Gestaltungsregeln, die auf Geometrieänderungen reagieren sollen und ein frame::resize enthalten, führen zu einer Endlosschleife. InDesign® kann dann nur noch abgebrochen werden.

Ja, stimmt leider. Merkwürdig daran sind folgende Dinge :

1. Das scheint nicht bei Bildrahmen zu passieren.
2. Auch frame::moveto führt nicht zu einer Endlosschleife.
3. Die Gestaltungsregel müsste (wenn schon), dann ja eigentlich rekursiv gerufen werden - jedes frame::resize müsste sie dann sofort neu rufen. Das ist nicht so. Der erneute Aufruf der Gestaltungsregel kommt zeitverzögert NACH dem Ende der Regel.

Sehr merkwürdig.

Workaround

Die Regel sollte vor frame::resize prüfen, ob der Rahmen bereits seine Zielgrösse hat und frame::resize nur rufen, wenn das nicht so ist.

Lösung

Der Fehler ist gefixt.

In einem Template werden ZWEI Textrahmen fortgesetzt. Die Grösse des zweiten Textrahmens soll dabei über Magneten durch den ersten Textrahmen gesteuert werden. Das führt zu einer Endlosschleife von InDesign®.

(Der Magnet setzt die neu ermittelte Grösse jedesmal wieder zurück.)

Dafür kann es ja nun leider keine wirkliche Lösung geben. Ich breche die Anpassung der Textrahmengrösse jetzt ab, wenn nach der Anwendung der Magneten wieder die alte Rahmenhöhe eingestellt ist. Die Endlosschleife wird damit verhindert.

01.07.2011

Wenn ich nach dem Einloggen direkt per Findstatement ein Produkt auswähle, ist das angezeigte Template immer "Standard", und die Platzierungsinfos werden nicht richtig angezeigt.

Wenn ich hingegen einmal in der "Standardsuche" auf die Lupe klicke, funktioniert es immer, auch mit den Findstatements.

Wenn ich übrigens einmal nach dem Einloggen ein Findstatement ausgeführt habe, wird auch in der Standardsuche kein Template angezeigt.

Das Problem ist gefixt.

Ein Produktaufbau mit Fortsetzungen in den Templates wird bei der Seitenreorganisation dadurch zerstört, dass alle Fortsetzungen durch das Haupttemplate ersetzt werden. Der Fehler ist in allen Releases von v3.2.3 enthalten.

Der Fehler ist jetzt gefixt.

Manchmal führt mein InDesign® folgendes Statement aus:

select p.ID, p.objectstatementid, p.sequencenr, p.name, p.statement,
p.needsSelection, p.condition, p.IsDefault from previewstatements p,
userxdomain x where p.ClassID = 6 and (0 = 0 or p.domainID = 0 or
p.domainID=x.domainID) and x.UserID = 0 and (p.ObjectStatementID > 0
|| p.ObjectStatementID < 0) order by p.sequencenr, p.name;

Auf dem SQL Server gibt das eine Fehlermeldung, weil || nicht erlaubt ist, es müsste or heißen. Mir scheint dies kein Panelstatement zu sein. Könntest Du das ändern? Danke!

Ist gefixt.

Ab Version 3.2.3 R2480 stürzt InDesign® reproduzierbar ab, wenn die Palette "Platzhalterwerte-Info" geöffnet wird.

Da ist mir bei der Einführung der Pre/Postfix-Platzhalter ein kleiner Fehler unterlaufen. Das ist jetzt gefixt.

21.06.2011

Bilder, die eine "Drehungsinformation" (vermutlich im IPTC-Header) haben, werden in der Preview-Palette falsch (ungedreht) dargestellt. Vermutlich ist tiff:orientation dafür zuständig. Etwas differenzierter stellt es sich so dar:

• im Finder: Bild wird im Querformat angezeigt
• in Photoshop und Vorschau: Bild wird im Hochformat geöffnet.
• Öffnen-Dialog von Photoshop und InDesign®: Bild wird im Quer-(Listendarstellung) oder Hochformat (Thumbnails) angezeigt
• InDesign®: Bild wird im Hochformat platziert.
• Comet: Bild wird im Querformat angezeigt.

Das geht jetzt für InDesign®-Versionen ab CS4. Gedrehte TIFF/LAY-Bilder werden in der Preview-Palette richtig dargestellt. Für die falsche Darstellung in Finder und Öffnen-Dialog habe natürlich keine Lösung.

Merkwürdigerweise werden in der Aufgabenpalette Platzhalter, die sich ganz oder teilweise im Übersatz befinden, nicht mehr angezeigt. In Version 3.2.1 funktioniert das.

Ja, leider ist die Prüfung, ob sich ein Platzhalter auf einer gesperrten Ebene befindet (Bug 2349) fehlerhaft gewesen. Dieser Fehler ist jetzt gefixt. Platzhalter im Übersatz werden jetzt wieder gefunden.

Der Fehler bestand seit v3.2.2 R2400 (16.4.2011).

18.06.2011

linklist::load() macht einfach nix. Im Logfile wird ausgegeben, dass linklist::load() fehlerfrei funktioniert hat. Platzhalter mit Auge markieren und auf "Laden" klicken, macht ebenfalls nix. Comet 3.2 Rev 2411 für CS5 funktioniert mit demselben Script und demselben Vorgehen.

Testscript:

#include "internal/types.h"

int main()
{
	LinkList    text_phs    = linklist::alloc(1);
	int			err    		= 0;

	while (1)
	{
		if (gRun > 1) break;

		linklist::insert(text_phs, 10);
		linklist::insert(text_phs, 11);
		linklist::insert(text_phs, 37);

		wlog("", "load linklist with %d placeholders\n",
		linklist::length(text_phs));
		err = linklist::load(text_phs, kDesignateSelected);
		wlog("", "linklist::load() returned %d (%s)\n", err, serror(err));

		break;
	}

	linklist::release(text_phs);

	return 0;
}

Das ist ein kritischer Fehler. Auch das Aktualisieren einer Auswahl von Platzhaltern z.B. über die Platzhalterpalette geht nicht. Werden ALLE Platzhalter aktualisiert, funktioniert es. Hat der erste Platzhalter mit einem Auge eine ID grösser 200 funktioniert es auch.

Das Problem ist durch einen kleinen Fehler bei der Implementierung der neuen Outside-Platzhalter (prefix before/after) entstanden und jetzt behoben.

Workaround

Fügt man in die Platzhalterliste bei linklist::load als ersten Eintrag eine NICHT EXISTIERENDE PlatzhalterID GRÖSSER 200 ein, geht alles. Das obige Skript
könnte also mit der Zeile

    linklist::insert(text_phs, 100000000);

nach "if (gRun > 1) break;" repariert werden.

Für das Neuladen einer Auswahl von Platzhaltern mit IDs kleiner/gleich 200 mit Bordmitteln gibt es keinen Workaround.

Der Fehler bestand seit v3.2.3 R2480 (25.5.2011).

Fügt ein Skript an eine Tabelle im Platzhalter weitere Zeilen an, funktioniert danach textmodel::append nicht mehr richtig. Der Text wird an einer falschen Textposition eingefügt.

Nach einigem Nachdenken bin ich drauf gekommen : Durch das Einfügen weiterer Tabellenzellen wird der interne Tabellenanker länger - damit ändert sich natürlich (wie auch bei textmodel::insert oder table::insert) die Variable gLen - und muss daher auch an dieser Stelle neu berechnet werden. Das wird jetzt gemacht - und schon gehts.

In verschiedenen Skriptanweisungen können Platzhalter aus dem Text entfernt werden :

textmodel::clear_placeholders ()
table::insert_rows ()
table::insert_cols ()
table::compress_colwise ()
table::build ()
textmodel::insert ()

Leider werden die Platzhalter aber NIE entfernt.

Der Fehler ist merkwürdigerweise seit über einem Jahr unentdeckt geblieben. Es war ein winziger Copy/Paste-Fehler bei der Einführung der Comet-Textplatzhalter. Die entsprechenden Funktionen haben jetzt versucht, diese neuen Comet-Platzhalter zu löschen - aber nicht mehr die normalen.

Der Fehler ist gefixt.

10.06.2011

Man kann beim Aufbau und/oder Aufräumen ja festlegen, dass unsichtbare Ebenen als Gestaltungsebenen behandelt werden sollen und damit die Produktordnung nicht stören. Aber so gesehen sind unsichtbare Ebene ja auch keine Gestaltung - sie tragen jedenfalls nicht sehr viel dazu bei. Könnte man unsichtbare Ebenen nicht automatisch ignorieren?

Unsichtbare Ebenen werden jetzt bei Aufbau und Reorganisation ignoriert. Das hat auch den schönen Nebeneffekt, dass man ohne umständliche Gestaltungsebenen einfach seine Sprachvarianten aufräumen kann. Man muss lediglich die nicht benötigten Ebenen ausblenden.

Baut man Produkte über Gestaltungsebene auf, sollten diese Ebenen ja eigentlich auch beim Aufräumen übergangen werden. Leider werden Rahmen dieser Ebenen aber auch mit in den Produktaufbau eingefügt.

Der Fehler ist gefixt. Die dazu nötigen Infos werden jetzt richtig in die Produkte eingetragen und von dort wieder gelesen.

06.06.2011

We see some strange behavior that the KPLaceWithFittingOptions is not always working. It looks very random when it does and when it does not work. We added some logging and see that the frame gets to the KPLaceWithFittingOptions, but it does not place it with this option every time. So sometimes it takes over the frame fitting settings and sometimes it doesnt. Have you heard about problems with this? The code to place an image in to a frame with this option looks like this: errorcode = frame::image( gFrame, result, kPlaceWithFittingOptions);

The function is NOT working randomly - it's working never. The problem was a wrong flag for backward compatibility down to CS4. kPlaceWithFittingOptions always placed the image in the left top corner of the frame under CS4. This problem is fixed now.

03.06.2011

in den 3.2.3 ab R2414 Versionen kann ich im Tabellenmodul keine ColumnRecordStringIDs den Zellen zuweisen. Da steht dann in der generierten Tabelle gar nichts oder was falsches drin.

Beim Fix von Bug 2319 ist aufgefallen, dass die Methode, die die Zellen-ID holt jeweils Zeilen und Spalten vertauscht. Das wurde gefixt. Leider war in der Setzen-Methode die gleiche Vertauschung. Bisher hatten sich diese Fehler aufgehoben. Ab R2414 nicht mehr.

Das ist jetzt gefixt.

Es gibt ja den Befehl itemlist::create_snippet. Damit wird ein Comet-Snippet einer Rahmenliste angelegt. Kann man eine Rahmenliste auch als InDesign®-Snippet (idms) in eine Datei exportieren?

Der Befehl itemlist::create_snippet kann das (mit ein paar neuen Parametern) jetzt machen.

Gibt es eine Möglichkeit, die ID des Elternobjektes und die Unterobjekte eines Produktes einfach zu ermitteln?

Nein, natürlich nicht. Die Produktstruktur ist ja von der aktuellen Suchanweisung der Produktrecherche abhängig und kann immer anders sein.

Mit den (neuen) Anweisungen product::get_parent und product::get_children können aber Elternobjekt und Unterprodukte der aktuellen Produktstruktur ermitttelt werden.

Die Befehle suchen (rekursiv) im aktuellen Produktbaum nach dem Objekt mit der übergebenen ID und liefern Elternobjekt/direkte Unterobjekte. Die Produktrecherche muss dazu mind. im obersten Level geladen sein. Ist ein Objekt sichtbar in der Produktrecherche, können die Ergebnisse recht schnell geholt werden. Ist das Objekt nicht sichtbar, muss mglw. die komplette Produkthierarchie durchsucht werden. Das braucht natürlich einige Zeit.

Beginnt die Cometgruppe, ab der aufgeräumt werden soll mit einem Seitentrenner, wird eine neue Seite angelegt.

Das ist gefixt.

Enthält das Dokument Produkte, die auf einer neuen Seiten beginnen, werden bei der Reorganisation an diesen Stellen neue Seiten erzeugt. Dadurch entstehen am Ende des Dokument jedesmal neue leere Seiten.

Der Fehler ist gefixt. Die Reorganisation versucht jetzt, bestehende Seiten zu verwenden. Erst wenn keine weiteren Seiten mehr im Dokument sind, werden neue Seiten angelegt.

Ab CS5 werden beim Ändern einer Musterseite für eine Dokumentseite auch Änderungen der Seitengrösse unterstützt. Die Funktion page::set_masterpage hat deshalb den neuen Parameter resizeChoice bekommen. Der wird aber aber offenbar nicht ausgewertet - die Seite behält immer ihre alte Grösse. Und das, obwohl die Musterseite eine ganze andere Grösse hat.

Der Fehler ist gefixt.

Für Seitentemplates kann eine Liste von Musterseiten definiert werden. Wird im Zieldokument eine der genannten Musterseiten gefunden, wird diese Musterseite auf die aktuelle Dokumentseite angewendet. Sollte jedenfalls. Was passiert ist folgendes : Die Musterseite wird angewendet - aber immer auf die nächste (neu angelegte) Seite.

Der Fehler ist gefixt. Die Musterseiten werden jetzt richtig angewendet.

Wenn man beim Login einen Fehler macht (z.B. ein falsches Passwort) wird der Dialog ja erneut geöffnet. Leider stehen dann ganz falsche Angaben in den Feldern des Dialoges, nicht mehr die alten.

Das ist ja eigentlich schon ganz lange so - und nervt immer wieder. Ich hab das jetzt mal behoben.

Unsichtbare Rahmen werden vom Seitenaufbau so behandelt, als wären sie sichtbar. Das ist zumindest verwirrend.

Unsichtbare Rahmen werden in "normalen" Templates auch weiter so behandelt.

Neu ist : Templates, die NUR aus unsichtbaren Rahmen bestehen, belegen auch keinen Platz im Aufbau. Damit eignen sich diese Templates gut zum Einfügen von Seitenumbrüchen : Sie wollen zwar beim Einfügen einen eigenen Platz im Seitenelement, teilen den dann aber mit Nachfolge-Produkten.

Damit ein Template neu Seiten anlegen kann, muss für mind. einen Rahmen des Templates in der Palette "Template-Eigenschaften" die Eigenschaft Neue (linke/rechte) Seite eingestellt sein. Der Rest geht automatisch.

ACHTUNG I Unsichtbare Rahmen werden bei "Alles auswählen" auf der Seite nicht mit ausgewählt - also auch nicht gelöscht oder verschoben, wenn man auf diese Art die Seite leer bekommen will.

ACHTUNG II Unsichtbare Rahmen gibt es erst ab CS5!

Templates, die einen Seitenwechsel erzeugen, machen Probleme in N:1-Seitenelementen :

• Auf der neuen Seite wird oben im Raster so viel Platz freigelassen, wie auf der alten Seite belegt ist.
• Hinter dem eingefügten Template wird noch ein weiterer Seitenwechsel gemacht. Es wird also nur ein Produkt auf der neuen Seite angelegt.
• Bei Rasterplätzen, die ihren Inhalt nach dem Einfügen justieren müssen (z.B. horizontal und vertikal justiert) stürzt der Produktaufbau ab.

Diese Probleme sind jetzt behoben. Seitenwechsel funktionieren jetzt auch in N:1-Elementen.

Ist es möglich, mehrere Produkte gleichzeitig mit mehreren Rahmen (Cometgruppen) jeweils 1:1 zu verlinken und zu laden - also das erste Produkt mit der ersten Cometgruppe, des zweite Produkt mit der zweiten Cometgruppe usw.?

Ja das geht jetzt. Einfach mind. einen Rahmen jeder Cometgruppe auswählen. Dazu die gewünschten Produkte auswählen. Dann SHIFT-CMD-Klick in das Status-Button des ersten Produktes. Siehe dazu auch den Film iun der nächsten Tabellenzeile.

Ich würde gerne die Option zum Template-Austausch auch beim reinen Drag&Drop-Aufbau nutzen. Das geht im Augenblick nur über "Reorganisieren".

Da geht jetzt über die Produktrecherche zu machen. Hier ein Film, der MultiLink und Templatewechsel demonstriert :

I delete one element from a comet group. Probaply ist the "main" frame of comet group. After that in groups XML we cannot find the comet group. Another elements I can delete. The will not destroy comet group.

Das Problem ist jetzt gefixt.

25.05.2011

Im CometServer bearbeitete Notizen sollen im InDesign® Dokument im Desktop aktualisiert werden, auch wenn kein InDesign® Server eingesetzt wird.

Die Konfiguration muss dafür nicht geändert werden, wird ein Dokument über die Publikationspalette und den Skript-Befehl priint:ceckout ausgebucht, werden vom CometServer automatisch Notizen angefordert. Sofern Notizen über den InDesign® Server angelegt wurden, werden weiterhin die verwendet, sonst (sofern vorhanden) die runtergeladenen.

Gelegentlich kommt es zu Abstürzen beim Ausführen der SOAP-Operation checkoutDocument (= Ausbuchen vom CometServer).

Ursache war aller Wahrscheinlichkeit nach eine falsche Antwort vom SOAP Service: statt wie erwartet ein Objekt mit Fehlercode wurde ein SOAP Fault gesendet, das wurde von den PlugIns nicht richtig ausgewertet.

Kann man die "Produkte des Dokumentes" mit der Auswahl der Produktrecherche irgendwie so markieren, dass die Unterschiede zwischen Wirklichkeit und Traum sichtbar werden?

In der Palette "Produkte des Dokumentes" gibt es jetzt ein Button , mit dem der Abgleich gemacht werden kann. Die Darstellung der Unterschiede in der Liste ist hoffentlich selbsterklärend.

Wichtig : Der gelbe Zettel am Button.

Für die Auswahl der Unterprodukte im Seitenaufbau-Dialog kann man ja die Tiefe der gewünschten Unterebene angegeben. Die Angabe ist immer 0-basiert und wenn Unterprodukte vorhanden sind wird immer exakt bis zu dieser Ebene getaucht. Wir hätten gerne zwei Änderungen:

1. Die Tiefe soll relativ zur Auswahl interpretiert werden.
2. Wird ein Unterprodukt mit einem definierten Template gefunden, muss nicht tiefer getaucht werden.

1. Das ist jetzt so implementiert. 0 ist immer die Ebene des ausgewählten Eintrages.
2. Man kann wählen, ob die Tiefenangabe ein Maximum ist oder ob auch zwischendurch abgebrochen werden kann.

In der Online-Doku sind dazu einige Beispiele.

... was z.B. zur Folge hat, dass ein Bild, das manuell im Rahmen anders beschnitten und positioniert wurde, nach manuellem Verschieben auf eine andere Ebene wieder auf den durch die Gestaltungsregel definierten Zustand gesetzt wird - wenn als Anwendungsregel "Rahmen eingefügt und geladen" aktiviert ist.

Anderes Beispiel: einem Bildrahmen ist die Gestaltungsregel "Auf andere Ebene verschieben" zugewiesen. Wenn die o.g. Anwendungsregel aktiviert ist, lässt sich das Bild nicht mehr manuell auf eine andere Ebene verschieben, weil durch das Verschieben wieder die Gestaltungsregel ausgeführt wird und das Bild zurück auf die Ursprungsebene kommt.

Ist das ein Bug oder ein Feature?

Doof, in der Tat. Das Problem ist, dass InDesign® beim Verschieben von Rahmen auf eine andere Ebene oder Seite jeweils zwei Events sendet :

1. Rahmen gelöscht
2. Rahmen angelegt

Und das zweite Event ist durch nichts von dem Event zu unterscheiden, das beim tatsächlichen Anlegen eines Rahmens gefeuert wird. ... und dann werden die Layoutrules gestartet.

Ich hab das alles etwas geändert : Das Ereignis "Nach Anlegen und Laden" (+) wird jetzt explizit nur nach dem Einfügen von Templates ausgeführt (Produktaufbau, Drag und Drop von Produkten, document::insert_macro, document::place_items, ...) Die Produkte sind dann bereits geladen (* -siehe unten). Beim Verschieben von Rahmen auf andere Ebenen oder Seiten oder beim Duplizieren von Rahmen mit Copy/Paste, Drag/Drop, Was/weiss/ich werden die Regeln nicht mehr ausgeführt.

*) Die Regeln werden auch ausgeführt, wenn die Rahmen via Skript z.B. mit document::place_items eingefügt und nicht sofort geladen (autoload = 0) wurden. Der Rahmen ist in diesem Fall aber noch nicht geladen. Die Regeln müssen dann nach dem Laden im Skript explizit ausgefürt werden (itemlist::apply_layout_rules).

When I use the following:

showmessage(system::getenv(str, "PATH"));

I get an error message: csystem::getenv not defined.

system::getenv is fixed now and works for Windows too. If you want to use getenv ("PATH") to retreive the dektop or document folder, please use $DESKTOP, $DOCUMENTS and/or file::uncurtain.

Der Select der am Indesignserver abgesetzt wird um die Jobs zu ermitteln enthällt in der where Kausel ein "Rownum < 2" somit ist die Sortierung hinfällig und falsch!

Das Problem tritt nur bei Oracle-Datenbanken auf. Oracle wendet zuerst die where-clause an und dann die Sortierung. "where ROWNUM < 2" limitiert die Rückgabe auf eine Zeile und sortiert dann diese eine Zeile. Man müsste das über zwei geschachtelte Selects lösen.

Das Problem ist gefixt für OCI-Verbindungen zur Oracle-Datenbank mit dem Plugin CoreService[Oracle].

Achtung

Bei ODBC-Verbingungen zur Oracle-Datenbank besteht das Problem weiter und kann nicht gelöst werden. Der Datenbanktyp ist in diesem Fall hinter dem ODBC versteckt. Dadurch ist keine Sonderbehandlung für Oracle möglich.

Dieses Verhalten sollte eigentlich gesteuert werden über die Checkbox "Bereits importierte Produkte überspringen", hatte ich gedacht. Es kann ja vorkommen, dass das gleiche Produkt auf mehreren Seiten angezeigt werden soll (in unterschiedlichen Kategorien, bspw.).

Ganz gleich, ob die Checkbox aktiviert oder nicht aktiviert ist, die doppelten Produkte kommen nicht heraus.

Das beschriebene Verhalten gilt nur, wenn man versucht, die Produkte hintereinander, IN EINEM Arbeitsgang auszugeben. Versucht man es danach nochmal, werden alle Dubletten aufgebaut, aber natürlich hinten an den bestehenden Aufbau gehängt.

Der Aufbau beginnt ja immer hinter der Cometgruppe des ersten ausgewählten Rahmens - insofern stimmt "aber natürlich hinten an den bestehenden Aufbau gehängt." nicht.

Der Rest stimmt. Es war irgendwann eine dringende Forderung, dass die Produktliste für den Aufbau keine Doppler enthalten darf. Ich hatte damit jedenfalls nur Mühe - und jetzt noch Ärger. Ich habe die Doppler-Prüfung jetzt rausgenommen.

Ist beim Seitenaufbau die Option "Bereits importierte Objekte überspringen" aktiviert, entsteht für jedes Produkt, das aufgebaut werden soll aber bereits im Dokument enthalten ist, ein "Loch" im Aufbau : Das Seitenelement für das nicht importierte Objekt bleibt leer und wird übersprungen. Bei N:1-Elementen mit festen Abständen wird ein Abstand zuviel freigelassen.

Die Option hat offenbar noch niemand verwendet. Der Fehler ist jetzt gefixt.

In den Bildern von Whiteboard und Templates werden Rahmenüberdeckungen falsch wiedergegeben. Rahmen im Hintergrund liegen hier plötzlich vor ihren Vordergrundrahmen.

Die Rahmen wurden für die Previews in der falschen Reihenfolge gezeichnet. Der Fehler ist gefixt.

Über die Preview Palette können auch Datenbank- Objekte mit eine Template in das Layout übernommen werden. Das ist eine sehr gute Funktion. Typischerweise werden dafür spezielle Templates angelegt, die typischerweise nicht mit der Produktrecherche funktionieren. Das führt häufig zu Bedienungsfehlern.

Anforderung

Daher wäre es gut, wenn es eine zusätzliche Sichtbarkeit „Preview Panel ony“ implementiert wird.

Ist umgesetzt.

Es wäre schön, wenn neue Rahmennotizen auch direkt und schnell über das Kontextmenü angelegt werden könnten.

Das geht jetzt. Wie beim -Button der Notizen-Palette wird auch hier zuerst nach Name und Inhalt der Notiz gefragt. Danach wird an jeden der ausgewählten Rahmen eine entsprechende Notiz angefügt.

Im aktuellen XML-Datenpool sind die Felder pageitems.

pageitems.
    pageitem
        record
            id
            id2
            stringid

angelegt. Logt man sich von diesem Datenpool ausgehend in einer Datenbank ein, können dort keine Templates mehr angelegt oder gesichert werden.

Der Fehler ist gefixt.

Workaround

Es gibt mehrere Möglchkeiten :

1. Die Elemente in pageitems.xml entfernen. Sie werden (wie in der Doku beschrieben) zur Zeit sowieso nicht benutzt.
2. Den Datenpool an eine andere Stelle verschieben. Dann wird er gar nicht mehr geladen.
3. Die Attribute auch in der Daten bank anlegen.

Bei jedem Aufbau der wiederholenden Elemente eines Rahmens werden die neuen Rahmen wieder neu erzeugt - ohne die alten zu löschen.

Wird der Hauptrahmen der wiederholenden Elemente nicht gelöscht (also ohne die Angabe post=delete_parent im Formatstring der Wiederholung), werden die von diesem Rahmen angelegten Rahmen bei erneutem Aufbau jetzt automatisch gelöscht. Das geht natürlich nicht, wenn der Hauptrahmen gelöscht wurde - aber dann kann man ja auch die Elemente nicht mehr aufbauen.

Im Submenü "Wiederholende Elemente" gibt es ausserdem zwei neue Untermenüs zum Löschen der Rahmen, die aus wiederholenden Elementen entstanden sind - dazu ist der Hauptrahmen nicht nötig.

Die Rahmen aus Wiederholungen werden bei sichtbaren Platzhaltern mit zwei kleinen überlappenden roten Quadraten rechts oben in der Ecke gekennzeichnet.

Hat ein Template einen Rahmen für wiederholende Elemente (multi frames - Platzhalter) mit der Einstellung

    post=delete_parent

stürzt InDesign® beim Seitenaufbau ab. Wird der Parentrahmen nicht gelöscht, passiert der Absturz nicht.

Der Fehler ist (recht aufwendig) gefixt.

Beim nachträglichen Einfügen von Produkte ins Dokument wird zuerst geprüft, ob an der Einfügestelle ein N:1-Element (ein sog. Rasterelement) steht. Wenn ja, wird in diesem Element mit dem Aufbau begonnen (siehe auch Bug 2401). Dabei wird aber leider das im Seitenaufbau-Dialog eingestellte Standard-Template nicht berücksichtigt sondern immer die in den Produkten hinterlegten Templates verwendet.

Das funktioniert jetzt richtig.

Workaround

Die aufzubauenden Produkte mit einem Template versehen (entweder über die Palette Produktrecherche oder den Skriptaufruf product::set (p, kPageitemid, ..).

... beim Einfügen über Seitentemplate-Aufbau ist alles korrekt.

Die Cometgruppen-Zuordnung war nicht ganz richtig. Das ist jetzt gefixt.

Das hatte ich immer so verstanden, dass Produkte nicht erneut ins Dokument übernommen werden, wenn bereits ein Produkt mit der gleichen ID vorhanden ist. Das scheint aber nicht so zu sein, wie ich gerade festgestellt habe. Ist das ein Bug oder habe ich etwas nicht richtig verstanden?

Die Prüfung wurde bisher nur auf Rahmenplatzhalter gemacht. Das funktioniert auch. Jetzt werden auch die Textplatzhalter geprüpft.

Achtung

Dazu muss im ungünstigsten Fall das gesamte Dokument durchsucht werden. Das kann natürlich etwas dauern.

Wir benötigen eine Erweiterung der Platzhalter um die Möglichkeit, AUSSERHALB des Platzhalters Text ins Dokument einzusetzen. Dieser Text muss beim Laden des Platzhalters automatisch aktualisiert werden. Es sollte folgenden Möglichkeiten geben :

• Text VOR wenn Platzhalter leer/nicht leer
• Text NACH wenn Platzhalter leer/nicht leer

Das kann man jetzt machen. Mehr dazu in der Online Doku :

• InDesign/Plugins/extensions.htm
• InDesign/Plugins/placeholdervalues.html#prefix

Hier ein Platzhalter mit Pre- und Postfix. Die Trenntexte werden mit speziellen Platzhaltern versehen und können auch nach manuellen Änderungen im Dokument noch aktualisiert werden.

Ich habe folgenden Text, der mit textmodel::insert eingefügt werden soll :

    <cFont:'Menlo'>abc

Der Text wird eingesetzt, aber der Font wird nicht angewendet. Mit Arial (z.B.) klappt es. Der Font 'Menlo' ist installiert und kann in InDesign® auch verwendet werden.

Ja, das ist jetzt gefixt.

In der Palette Platzhalterwerte können ja die Werte (z.B. die Load-ID) vom Platzhaltern manuell geändert werden. Die Änderung wird aber nur in Teile des Platzhalters übernommen.

Die Änderungen, die man in der Palette macht, werden immer auch die gesamte Dokumentauswahl angewendet. Wenn die Auswahl nicht den ganzen Platzhalter enthielt, konnte es tatsächlich passieren, dass Platzhalterteile unverändert blieben und andere geändert wurden. Das ist jetzt gefixt. Auch Platzhalter, die nur teilweise in der Dokumentauswahl liegen, werden jetzt vollständig geändert.

Das Ladenskript eines Rahmens legt mit frame::duplicate weitere Rahmen an. Platziert man das Produkt per Drag and Drop, werden der Rahmen und die Duplikate richtig positioniert. Baut man das Produkt mit dem Seitenaufbau ein, verrutschen die Duplikate relativ zum Originalrahmen.

Der Fehler ist gefixt.

Wenn man Platzhalter hat, die sich komplett selbst ersetzen (also nicht nur ihren Inhalt sondern auch den Platzhalter selbst) kann die Aufgabenpalette zum Absturz von InDesign® führen :

1. Aufgabenliste laden
2. Alle Platzhalter aktualisieren
3. Einen der Platzhalter, die sich selbst ersetzt haben, in der Aufgabenpalette anklicken

   -> Absturz

Ja sehr misslich. Und knifflig zu beheben, wie man sich denken kann. Das ist jetzt gefixt. Die Listeneinträge verweisen auf den neu erzeugten Platzhalter und wählen diesen aus, wenn man den Listeneintrag klickt.

Die Comet-Plugins sind jetzt auch für CS5.5 verfügbar!

Es wäre schön, wenn man eine Möglichkeit hätte, alle Gruppen-Notizen der ausgewählten Rahmen auswählen zu können. Am besten wäre ein Menüeintrag im Kontextmenü dafür.

Diesen Menüpunkt gibt es jetzt. Es werden alle zur Rahmenauswahl gehörigen Gruppen-Notizen ausgewählt. Sind auch Notizen oder Gruppennotizen in der Dokumentauswahl, werden auch alle Schwester-Notizen ausgewählt. Ebenso werden auch alle unsichtbaren Grppen-Notizen der Rahmen in der Liste ausgewählt.

Notizen an Rahmen werden nicht ausgewählt.

Es wäre schön, wenn man eine Möglichkeit hätte, alle Rahmen-Notizen der ausgewählten Rahmen auswählen zu können. Am besten wäre ein Menüeintrag im Kontextmenü dafür.

Diesen Menüpunkt gibt es jetzt. Es werden alle zur Rahmenauswahl gehörigen Notizen ausgewählt. Sind auch Notizen in der Dokumentauswahl, werden auch alle Schwester-Notizen ausgewählt. Ebenso werden auch alle unsichtbaren Notizen der Rahmen in der Liste ausgewählt.

Notizen an Cometgruppen werden nicht ausgewählt.

Das müsste man mal austauschen.

Das ist geschehen.

Die Previewpalette können ab v3.1 R1730 ja auch mit Hilfe von Skripten geladen werden. Leider werden diese Einträge aber nicht im Suchpopup gezeigt. Was mache ich falsch?

In das Attribut ObjectStatementID muss ein Wert ungleich 0 eingetragen werden, auch wenn diese Anweisung hier ja gar nicht benötigt wird. In der Doku steht dazu der Vorschlag, die -1 zu verwenden. Das schlägt aus zwei Gründen fehl :

1. Die Plugins holen bisher nur Einträge mit ObjectStatementID > 0. Das ist jetzt gefixt. Es darf auch -1 verwendet werden.
2. Das Attribut ObjectStatementID ist meist als unsigned int definiert - da bringt die -1 gar nichts. In diesem Fall kann man etwa 0xffffffff verwenden. Oder irgendeine andere positive Zahl. Die Anweisung, auf die verwiesen wird, wird sowieso nicht geladen.

Workaround

Irgendeine Zahl > 0 eintragen. Die Anweisung, auf die verwiesen wird, wird sowieso nicht geladen.

Kann man irgendwie die Gestaltungsregeln eines anderen Rahmens der Cometgruppe ausführen?

Man kann : Mit frame::apply_layout_rules und itemlist::apply_layout_rules können die Gestaltungsregeln anderer Rahmen schon seit v3.1 R1550 (Sept. 2009 ausgeführt werden. Das hat zwei Nachteile :

Man kann nur ALLE Regeln der Zielrahmen ausführen. Auswahlen von Rahmen gehen nicht. Und zweitens : Man muss die Regeln selber schreiben.

Deshalb gibt es jetzt zwei neue Dinge :

1. Die neue Regel "Ereignis senden"
2. Die neue Bedingung "Ereignis ausführen"

Der Sender gibt dabei an, welcher Rahmen der Cometgruppe (identifiziert über dessen Kennung) gemeint ist und liefert einen Schlüssel (irgendein beliebiger Text). Der Empfänger prüft den Schlüssel und führt dann alle Regeln aus, die zur Bedingung gehören. es ist erlaubt, an dieser Stelle wieder ein Ereignis (auch mit dem gleichen Schlüssel und an den aufrufenden Rahmen) zu senden - es muss aber sichergestellt sein, dass irgendeine Art von Abbruchbedingung defniert ist (z.B. eine Prüfung auf Textübersatz).

In der Online-Doku ist das Ganzemit einem Beispiel ausführlich beschrieben.

Das geht jetzt. Mehr dazu hier. Gleichzeitig wurde die gesamte Palette etwas überarbeitet. In der Online-Doku ist das neue Verhalten beschrieben.

Mit angelegte Rahmennotizen können nur in mehreren Schritten mit Titel und Inhalt versehen werden (+, Textauswahl setzen, Text schreiben, Notiz in der Palette auswählen, Name setzen). Besser wäre, wenn vor dem eigentlichen Anlegen der Notiz Titel und Inhalt in einem Dialog erfragt werden.

So wird das jetzt gemacht.

Wenn man mit dem -Button der Palette neue Notizen anlegt, bekommen die als Standardgrösse immer die Grösse des Rahmens, für den sie angelegt werden. Besser wäre aber, wenn sie ein bisschen kleiner wären, oder?

Die erste Rahmennotiz wird jetzt 1/4 so groß wie der Rahmen (halbe Breite, halbe Höhe). Alle weiteren Notizen nehmen die Grösse der letzten Notiz des Rahmens.

Wenn man mit dem -Button der Palette neue Notizen anlegt, entspricht die in diesen Notizen eingestellte Schrift nicht den Einstellungen der Palette für neue Notizen. Bei Notizen, die mit dem Button der Werkzeugleiste angelegt werden, stimmt die Schrift.

Die Absatzstil/Schrifteinstellung der Palette wird jetzt auch bei den Rahmennotizen ausgewertet.

Die StringID einer Tabellenzelle kann aus drei Teilen zusammengesetzt werden, die durch |--| getrennt werden.

    Root|--|Column|--|Row

Macht man diese Einstellung im Tabellenmodul wird aber bei Klicken der Checkbox für die ColumnRecordStringID die StringID der Spalte eingesetzt und bei RowRecordStringID die der Spalte.

Der Fehler ist gefixt.

Das ist leider noch richtig. Die Reihenfolge in der Multi-String-ID ist jetzt zwar richtig. Aber bei ColumnRecordStringID wird die RowRecordStringID verwendet und umgekehrt.

Jetzt ist es richtig. Auf alte Tabellen hat die Änderung keinen Einfluss.

In dem Augenblick, wo ich einen Platzhalter ebenen- oder dokumentweit aktualisiere, werden alle Gestaltungsregeln aktualisiert, bei denen "Aktualisieren von Platzhaltern" aktiviert ist, auch wenn dieser Platzhalter überhaupt nichts mit dem Rahmen zu tun hat, dem die Gestaltungsregel zugewiesen ist.

Auf diese Art und Weise gehen alle manuellen Änderungen an "völlig unbeteiligten" Rahmen verloren. Ich hätte erwartet, dass die Regeln nur dann neu angewendet werden, wenn ein Platzhalter innerhalb des betreffenden Rahmens aktualisiert wird.

Wird das Laden der Platzhalter auf eine Auswahl von Platzhaltern und/oder RecordIDs eingeschränkt, werden die Gestaltungsregeln jetzt nur noch für Rahmen ausgeführt, deren Platzhalter entweder selbst diese Einschränkung erfüllen, oder die passende Textplatzhalter enthalten.

Achtung

Da dafür alle Texte nach den gewünschten Platzhaltern durchsucht werden müssen, kann das Aktualisieren von Auswahlen jetzt etwas länger dauern!

Kann man in einer Gesdtaltungsregel, die z.B. beim Aufbau, Laden und bei Geometrieänderungen ausgeführt wird, herausbekommen, welche Situation sie gerade eben ausgeführt?

Mit der neuen globalen Variablen gWhen kann man das jetzt erfragen.

Kann ich die Parameter einer Gestaltungsregel im Skript ändern?

Im allgemeinen geht das nicht. Das Hauptproblem ist, wie die Regeln identifiziert werden können. Regeln können ja im gleichen Rahmen mehrfach verwendet werden.

Mit Hilfe der neuen Funktion

    frame::change_rule_param

können aber die Parameter der gerade ausgeführten Gestaltungsregel geändert werden. Mehr dazu in der Online-Doku.

Setzt man mit Hilfe der Palette "Platzhalter" für einen Rahmen einen Platzhalter, werden die die Gestaltungsregeln "Nach Geometrieänderung" ausgeführt.

Der Fehler ist gefixt.

Wird in InDesign® CS5 ein Text mit einem Absatzstil formatiert, der den Text unterstreichen soll, wird die Unterstreichung unsichtbar, sobald ein Comet-Platzhalter auf den Text verknüpft wird. Es handelt sich hierbei um ein reines Anzeigeproblem in InDesign®, im Ausdruck ist der Text unterstrichen.

Das stimmt nicht ganz. Die Durchstreichung wird nur unsichtbar, wenn deren Versatz <= 0 ist. Ist der Versatz grösser (oder die Linie dicker), wird sie sichtbar.

Das Problem ist folgendes : Textteile werden in einer festgelegten Reihenfolge gezeichnet. Später gezeichnete Teile überdecken bereits gezeichnetes. Die Reihenfolge ist :

1. Unterstreichung
2. Text
3. Durchstreichung

Die Textplatzhalter werden nach der Unterstreichung und vor dem Text gezeichnet. Damit sieht man die Unterstreichung nicht mehr. Ich kann sie auch vor der Unterstreichung zeichnen lassen, dann sieht man Teile der Platzhalter nicht mehr (Und da Unterstreichungen häufig verwendet werden, um Text farbig zu hinterlegen, sieht man dann den ganzen Platzhalter nicht mehr.) Auch nicht gut. Eins geht jedenfalls nicht : Die DrawPriority on the fly während dem Zeichnen zu ändern.

Ich habe das Dilemma jetzt dadurch etwas gemildert, dass die Platzhalter mit einer Transparenz von 20% gezeichnet werden. Dann sieht man die Unterstreichung noch ein wenig, und die Platzhalter noch ganz gut. Bei mehr Transparenz werden die Platzhalter etwas sehr blass - dafür sieht man dann die Unterstreichung besser. Aber ich denke, Platzhalter kommen eindeutig häufiger vor als Unterstreichungen.

Das Bild zeigt einige Platzhalter mit Text und Unterstreichungen vor verschiedenfarbigen Hintergründen.

In der Doku steht, diese Regeln werden beim Einfügen von Vorlagen und beim Laden und Aufbau von Rahmen abgeschaltet. Verlinkt man ein Produkt aber mit Shift-Click direkt über die Palette mit einem Rahmen, werden diese Regeln trotzdem ausgeführt.

Dieser Fehler ist gefixt.

Wir bräuchten eine Gestaltungsregel die einen Rahmen relativ zu einem anderen Rahmen der Cometgruppe positioniert.

Die neue Standardregel heißt "Rahmen positionieren".

Wir bräuchten eine Gestaltungsregel zum Ausrichten eines Rahmens an einem anderen Rahmen der Cometgruppe.

Die neue Standardregel heißt "Rahmen ausrichten".

Hat ein Parameter einer Gestaltungsregel eine Werteliste, wird beim Hinzufügen der Regel zu einem Rahmen natürlich ein Eintrag dieser Liste ausgewählt (Der erste oder der angegebene Default). Wenn da z.B. "links" ausgewählt ist, würde man meinen, die im Rahmen hinterlegte Regel hat jetzt auch den Parameterwert "links". Hat sie aber nicht, der Wert ist "". Man muss erst noch einmal den Eintrag auswählen, damit der Wert übernommen wird. Das ist natürlich nicht so gut.

Das wird jetzt richtig gemacht.

In der Liste der Regeln werden jetzt hinter dem Namen der Regel ausserdem deren aktuelle Parameter angezeigt.

Beim Import von Snippets mit mehreren Rahmen stürzt InDesign® ab.

Der Fehler ist gefixt.

Nachdem man jetzt eine ganze Reihe von Standardfunktionen hat, mit denen das Werte-Popup eines Parameters einer Gestaltungsregel gefüllt werden kann (@LOADLIST colorprofiles, imagecolorprofiles, pdfprofiles, ...) kommen weitere Wünsche :

Kann man so eine Standardfunktion auch haben für alle Kennungen der Cometgruppe, zu der der aktuelle Rahmen gehört?

Man kann. Die Funktion heisst @LOADLIST framelabels.

Parameterwertelisten von Gestaltungsregeln, die ist @LOADLIST geladen wurden, enthalten immer den Eintrag 'Leer'. Wählt man diesen Eintrag aus, bekommt der Parameter den Wert "Leer" und nicht "".

Der Fehler ist gefixt.

Enthält ein Parameter einer Gestaltungsregel Sonderzeichen (z.B. Umlaute) werden die nach Sichern und Neuöffnen des Dokumentes nicht mehr richtig dargestellt - und natürlich macht die Regel dann auch was Falsches.

Der Fehler ist gefixt.

Gibt es eine Funktion, mit der aus der Cometgruppe eines Rahmens ein anderer Rahmen mit einer bestimmten Kennung ermittelt werden kann?

Die neue Funktion

    frame::get_cometgroup_member

macht das jetzt.

Workaround (ab v3.2 R2267)

ItemRef get_cometgroup_member (ItemRef fr, char * label)
{
	int 		groupID		= frame::get_cometgroup (gFrame, 1);
	ItemLis		group 		= 0;
	ItemRef 	sibling		= 0;
	ItemRef 	resul		= 0;
	char 		lbl 		[256];
	int 		i;

	// Selbst?
	frame::get_smart_item_data (fr, lbl);
	if (strcmp (lbl, label) == 0)	return item::alloc (gFrame);

	// Keine Cometgruppe - schlecht!
	if (!groupID)	return 0;

	// Cometgruppe durchsuchen
	group 			= itemlist::get_cometgroup_members (0, groupID, 1);
	if (!group) 	return 0;
	sibling 		= item::alloc ();

	for (i = 0; i < itemlist::length (group); i++)
	{
		sibling = itemlist::get (group, sibling, i);
		frame::get_smart_item_data (sibling, lbl);

		if (strcmp (lbl, label) == 0)
		{
			result = item::alloc (sibling);
			break;
		}
	}

	// Aufräumen
	itemlist::release (group);
	item::release (sibling);

	// Fertig
	return result;
}

In welcher Reihenfolge werden eigentlich die Rahmen bearbeitet, wenn nach dem Laden/Aufräumen die Gestaltungsregeln bearbeitet werden.

Hintergrund ist, dass eine Regel einen anderen Rahmen der Cometgruppe verwendet, um seine Position neu zu berechnen. Dazu müssen für diesen Rahmen die Gestaltungsregeln natürlich auf alle Fälle früher berechnet worden sein. (Der Rahmen wird dabei über seine Kennung aus der Cometgruppe gesucht.)

Die Rahmenreihenfolge wurde bisher über die Rahmen-UIDs festgelegt . Jüngere Rahmen zuerst. Das ist natürlich eine schwer zu beeinflussende Reihenfolge. Deshalb wird als Reihenfolge jetzt die Rahmenkennung verwendet. Diese Kennung wird in der Palette Template-Verhalten gesetzt. Die Kennungen werden dabei mit Hilfe der UTF-8-Kodierung der Strings sortiert . Kleinere Kennungen zuerst. (Die Regeln des Rahmens A werden also vor denen des Rahmens B ausgeführt.)

Über die Einträge der Liste der Notizenpalette lassen sich ja im Dokument die zugehörigen Notizen-Rahmen auswählen. In der ersten Spalte, in der der Status der Notiz angezeigt wird, geht das nicht. Wäre schön, wenn das auch ginge.

Das geht jetzt.

10.05.2011

Auf dem Mac funktioniert das wunderbar, auf einer Dose werden die „ und “ leider ignoriert. Die «» funktionieren auf beiden Systemen (siehe Screenshots).

Der Fehler ist gefixt. Folgende Anführungszeichen werden ersetzt :

Holt man mit file::download zweimal die gleiche Datei und diese Datei wurde beim zweitenmal auf dem Server geändert, erhält man wieder die alte Datei. Erst nach Neustart von InDesign® wird die geänderte Datei geladen.

Unter Mac tritt dieser Fehler nicht auf.

Ja, wie die Doku von Microsoft sagt, chached die verwendete Funktion URLDownloadToFile bereits geladene Dateien. Dieser Cache wird jetzt vor jedem Download geleert und der Fehler damit behoben.

Workaround

Gibt man, durch ? oder & getrennt, der URL eine immer andere Endung mit, die auf dem Server nicht verwendet wird, kann man das Verhalten umgehen und die URL wird jedesmal neu geladen.

Wenn in einem Script ein typografisches Anführungszeichen vorkommt, wird das zu irgendwas komischem konvertiert. Das passiert bei “, ”, und „ - die französischen « und » funktionieren.

Das war eigentlich mal mit Absicht eingebaut - schon gaaanz lang her - etwa 2003. Die meisten Skripte waren damals in XM-Elementen der Rahmen implementiert. Und bei Copy/Paste hat InDesign® immer aus normalen Anführungszeichen die typografischen gemacht. Das hat genervt ohne Ende. Deshalb wurden die Zeichen

    „“ und ‚‘

immer automatisch ersetzt durch " bzw. ', wenn ein Skript gesichert wurde. Wird jetzt nicht mehr gemacht.

Merkwürdiges Phänomen: will man einen Namen für ein Seitenelement eingeben, schafft man bei schnellem Tippen maximal 2 Zeichen, bevor der Textcursor zum Anfang des Textes springt.

Ähnliches Verhalten bei der Eingabe von Werten für Mindestabstände:man kann dort nur unter Schwierigkeiten andere Werte eingeben, es erscheint sofort nach dem Löschen wieder der komplette Eintrag "0 mm". Es ist nicht möglich, z.B. 0,5 mm oder 3 pt einzugeben.

Das zweite - ja stimmt. Hier wird nach jedem Tastendruck versucht, den String in einen gültigen Wert für einen Abstand umzuwandeln. Das geht aber erst, wenn die Eingabe fertig ist. Ich habe deshalb für diese Felder den Live-Update abgeschaltet.

Das erste kann ich nicht nachvollziehen. Ich habe den Live-Update aller Textfelder der Palette trotzdem abgeschaltet. Änderungen werden nun nicht mehr live beim Schreiben in Palette und Dokument aktualisiert. Erst beim Verlassen des Textfeldes wird der Wert ins Dokument übernommen. (Um die Änderungen auch in den Datenpool zu übernehmen, muss wie bisher der grüne Aktualisierungs-Pfeil gedrückt werden.)

Um Seitenumbrüche beim Produktaufbau zu erhalten, muss man in die Produktliste an den gewünschten Stellen PageTemplate-Einträge einfügen. Leider sind die eingefügten Objekte immer vom Typ "Produkt". Seitentemplates kann ich nicht einfügen. Der Aufbau bricht dann an der ersten Stelle, an der so ein "Produkt" steht, natürlich ab.

Das Seitentemplate wird so definiert:

product::set (pPage, kProductType, 4); 
product::set(pPage, kID, 3);   // Pagetemplate-ID

Die Eigenschaft kProductType wurde leider gar nicht ins Produkt übernommen. Der Fehler ist gefixt.

Beim Aufbau in mehreren Arbeitsschritten beginnt der jeweils folgende Schritt (fast) immer auf einer neuen Seite.

Der Aufbau beginnt nicht auf einer neuen Seite, sondern hinter dem aktuellen Seitenelement. Da das template nur ein Element hat, ist das im Beispiel immer eine neue Seite.

Das hatte ich eigentlich bedacht, dass beim Einfügen 1:N-Stellplätze zuerst weiter gefüllt werden müssen. Aber leider hab ich einen kleinen Fehler bei der Prüfung der Template-Einstellungen gemacht. Bei meinen Tests hatte das falsch geprüfte Feld dann immer gerade den passenden Wert.

Der Fehler ist gefixt.

Workaround

Wenn das 1:N-Element die Eigenschaft 'Produkt darf im nächsten Element fortgesetzt werden' aktiviert hat, kann auch in der fehlerhaften Version in 1:N-Elemente eingefügt werden. Wenn man die Checkbox gesetzt hat, natürlich wieder die Eigenschaft 'Element mit mehreren Produkten füllen' einstellen!

Ändert man manuell das Seitentemüplate einer Dokumenteseite, wird beim Aufräumen dieses Template auch in alle Nachfolge übernommen. Ist das richtig?

Ja, das ist im Prinzip richtig. Seitentemplates haben ja einen eingestellten Nachfolger. Der wird dann beim Aufräumen verwendet. Erst ein über den Aufbau erfolgter Seitenumbruch beendet das.

Natürlich ist das Verhalten doch eher überraschend. Das Verhalten der Aufräumbuttons ist deshalb jetzt ein bisschen geändert :

Das Aufräumen beginnt immer mit der Cometgruppe des ersten ausgewählten Dokumentrahmens. Der folgenden Tabelle können Sie entnehmen, mit welchen Tastenkombinationen Sie die Reorganistion beinflussen können:

Das Menü der Produktrecherche enthält inzwischen ziemlich viele Einträge. Zu diesen Einträgen kommen dann noch die Palettenaktionen des Datenpools. Damit wird das Menü dann vollständig unübersichtlich. Kann man die Standardeinträge vielleicht irgendwie in Untermenüs zusammenfassen?

Das Menü sieht jetzt so aus :

Ich möchte an dieser Stelle noch mal darauf hinweisen, dass die Palettenmenüs des Datenpools auf sehr einfache Weise ebenfalls in Untermenüs zusammengefasst werden können : Der Name kann als ^-getrennter Pfad geschrieben werden. Jeder Pfadteil erzeugt ein weiteres Untermenü :

Punkt 1^Aktion 1.1
Punkt 1^Aktion 1.2
Punkt 1^Aktion 1.3

erzeugt die folgenden Einträge

Punkt 1 >
    Aktion 1.1
    Aktion 1.2
    Aktion 1.3

Mehr dazu in der Online-Doku.

16.04.2011

Das ist jetzt so.

Die Funktionen zur Unterstützung der Rahmeneinpassungsoptionen werden jetzt auch in CS4 unterstützt :

frame::image akzeptiert das Platzierungsflag

    kPlaceWithFittingOptions

Mit dieser Angabe wird das Bild so platziert, wie es in den Rahmeneinpassungsoptionen eingestellt ist. Diese Einstellungen werden ausserdem durch die Funktionen

    frame::set_fitting_options
    frame::get_fitting_options
    frame::apply_fitting_options

unterstützt.

Hat ein Rahmen eines Fortsetzungstemplates die Gestaltungsregel "Hide/Show" zum Verstecken des Rahmens, ist der Rahmen nach dem Aufbau trotzdem sichtbar.

Ein Test mit einer eigenen Regel, in der ein wlog geschrieben wird, zeigt, dass die Regeln hier offenbar gar nicht ausgeführt werden.

Der Fehler ist gefixt.

Kann man das machen? Vielleicht indem ein Skript ausgeführt wird?

Das geht jetzt. Anstelle einer Liste von Werten für den Parameter kann jetzt auch folg. geschrieben werden :

    @LOADLIST stdfunc | actionID [defaultEntry]

actionID ist natürlich die ID einer definierten Aktion (mit ClassID 44). stdfunc ist eins der folgenden

• colorprofiles
• imagecolorprofiles
• pdfprofiles
• printprofiles
• fonts
• parastyles
• charstyles
• objstyles
• tablestyles
• cellstyles

Mehr dazu wie immer in der Doku.

Die Gestaltungsregel "Proportionen erhalten" scheint bei manuellen Grössenänderungen einwandfrei zu funktionieren. Wird Sie beim Laden z.B. nach FitFrame ausgeführt, macht sie komische Dinge - ich hätte gedacht, dass der Rahmen dann, ...

Das Problem besteht darin, festzulegen, was eigentlich die Basisproportion ist. Dazu wird jetzt die Rahmengrösse verwendet, wie sie bei der letzten Änderung einer Regel des Rahmens war.

Gefixt in 3.2.2.

Wird ein Dokument mehrfach aufgeräumt und eine Gruppe dadurch mehrfach neu angelegt geht die Zuordnung persistente ID <=> Dokument ID verloren.

Der Fehler ist behoben und aus der Zuordnungstabelle werden verwaiste Einträge jetzt auch ab und an gelöscht.

Hat mein eine InDesign®-Gruppe als Inline (oder verankerten) Rahmen eingesetzt, wird bei frame::fit der Referenzpunkt ignoriert. Es wird immer der Punkt unten rechts festgehalten.

Der Fehler ist gefixt.

Wendet man frame::moveto auf einen Inline-Rahmen passiert zwar etwas, aber die Ergebnisse scheinen eher zufällig zu sein und nichts mit der Eingabe zu tun zu haben.

Ja richtig. Die Lage dieser Rahmen wird ja vom Text, der den Rahmen enthält, bestimmt. Um die Position von Inlines zu ändern gibt es zwei Möglichkeiten :

• Die Ankerposition
• Die Ankereinstellung

Mit textmodel::get_anchor, textmodel::anchor, textmodel::inline_und textmodel::inline_above können diese Einstellungen geändert werden.

Hat mein eine InDesign®-Gruppe als Inline (oder verankerten) Rahmen eingesetzt, wird bei frame::resize der Referenzpunkt ignoriert. Es wird immer der Punkt unten rechts festgehalten.

Der Fehler ist gefixt.

Hat mein eine InDesign®-Gruppe als Inline (oder verankerten) Rahmen eingesetzt, können deren Unterrahmen den Gruppenrahmen nicht ermitteln. frame::get_group liefert dann immer den Fehler -1. Wird die selbe Gruppe nicht als Inline verwendet, klappt alles.

Der Fehler ist gefixt.

Obwohl mein Template Untertemplates für linke und rechte hat, wird beim Einfügen eines Produktes immer das Template der linken Seite verwendet. Ziehe ich das Template selbst auf eine rechte Seite, wird das richtige Template verwendet.

Das ist kein Fehler in den Plugins. Sind die Rahmen der Templates mit horizontalen Magneten verbunden, werden die beim Einfügen auf rechten Seiten wieder hergestellt - und dann sieht das Template aus, als käme es von einer linken Seite.

Das Problem entsteht beim automatischen Anlegen der Untertemplates über die Palette "Template-Eigenschaften". Da die Magnet-Einstellungen stark benutzer-abhängig sind, kann hier keine automatische Anpassung der Magneten (und evtl. zugehöriger Nägel) gemacht werden. Es wird aber jetzt eine Warnung gezeigt, dsss mglw. Nägel und Magneten korrigiert werden müssen.

Das ist ja eigentlich auch gut so. Aber wenn man da jetzt z.B. Produkte reinlädt, kann es sein, dass die alle die gleiche ID haben (weil sich die Produkte vielleicht erst in ID2 unterscheiden). Was kann man denn dann machen, um die Einträge richtig zu identifizieren?

Die Labels der Popupmenüs können jetzt jeweils mit der Kennung @INDEX versehen werden. Diese Kennung wird ausgefiltert und diie vorher als IDs verwendeten Popupwerte werden als (0-basierter) Index angesehen.

Hat das erste Popup das Label "Produkt 1@INDEX" wird also "Produkt 1" als Label verwendet und eine 3 in der Wert-Variable bedeutet, der vierte Eintrag wurde ausgewählt.

Ich selektiere einen Rahmen und führe ein Palettenskript mit der Methode document::store_macro aus:

    document::store_macro(dbc,"data","library_asset",snid,"preview",600);

Es wird ein preview gesichert aber "data" ist leer. Im logfile steht folgendes (kein binfile!):

    update library_asset set 
        data = _latin1 [binfile ],
        preview = _latin1 [binfile .../werkii_.gif],
        magnets = 0
    where ID = 39;

document:store_macro geht jetzt wieder. Das Attribut magnets muss nicht mehr in der Zieltabelle vorhanden sein. Es wird nur noch geschrieben, wenn table == "pageitems" und attr == "data" sind.

Leider werden Platzhalter auf gesperrten Ebenen in der Aufgabenpalette völlig ignoriert. Das finde ich als Standardverhalten auch gut, aber hätte gern eine Chance, gesperrte Ebenen auch zu prüfen.

Das Bestimmen der Out-of-sync-Platzhalter geschieht in zwei Schritten :

1. Status neu berechnen
2. Platzhalter sammeln

Im ersten Schritt wurden die gesperrten Ebenen ausgeschlossen, im zweiten nicht. Die angezeigten Aufgaben waren dadurch nicht immer gleich, wenn man Ebenensperrungen geändert hat .

Die Palette hat jetzt eine Checkbox, in der angegeben werden kann, ob die gesperrten Ebenen ausgeschlossen werden sollen oder nicht. Diese Option werten beide Schritte aus.

Hat ein Textrahmen einen inneren Rahmenabstand (Inset) ensteht bei der Anwendung des Absatz-Keils  mit textmodel::justify ein Textübersatz.

Die Abstände von der Rahmenkante müssen natürlich von dessen Grösse abgezogen werden, wenn der Keil berechnet wird. Der Fehler ist gefixt.

Die Gestaltungsregel 'Vertikale Textausrichtung' tut leider nichts. Im Logfile steht die Meldung, dass das Skript leer sei.

Leider richtig. Der Fehler ist gefixt. Jetzt können sowohl die InDesign®-Einstellungen für die vertikale Ausrichtung (Dialog 'Textrahmenoptionen') eingestellt werden als auch das Comet-Verfahren für den vertikalen Keil zwischen Absätzen (Absatz-Keil).

(nur in der englischen Version)

Das ist gefixt.

Wenn ich in ein XML

<?xml version="1.0" encoding="UTF-8"?>
<assets>
    <asset id="0">
        <path/>
    </asset>
</assets>

per xmlquery eine weitere Zeile einfüge, wird aus dem Attribut "id" in der neuen Zeile ein Element "id":

<?xml version="1.0" encoding="UTF-8"?>
<assets>
    <asset id="0">
       <path/>
    </asset>
    <asset>
        <id>0</id>
        <path>blah</path>
    </asset>
</assets>

Der Bug ist gefixt. "id" wird weiter als Element geschrieben werden.

Achtung: Die Schreibweise <path/> wird weiterhin nicht unterstützt und statt dessen <path></path> geschrieben.

Es gibt immer wieder Nachfragen zu den in InDesign®-Dokumenten und Templates verwendeten Farbprofilen. Die Skriptsprache hat jetzt eine Reihe von Funktionen, die diese Problem lösen helfen. Hier ein (sehr) kurzer Überblick. In der Online-Doku und die Funktionen ausführlich und mit Beispielen beschrieben.

prefs::get_preserve_color_profiles und prefs::set_preserve_color_profiles

Die Funktion steuert, wie mit unterschiedlichen Farbprofilen von Template und Zieldokument verfahren werden soll. Ist das Flag eingeschaltet, werden die Einstellungen des Dialoges Bearbeiten>Farbeinstellungen... zur Konfliktauflösung verwendet.

Achtung : Die expliziten Farbeinstellungen für Bilder bleiben dabei unverändert!

color::count_profiles und color::get_nth_profile

Ermitteln der verfügbaren, eingebetteten bzw. verwendeten Farbprofile von System, Dokument und Bildrahmen.

color::set_profile

Setzen der Farbprofile von Dokumenten und Bildern (Menüs Bearbeiten>Profile zuweisen... und Objekt>Farbeinstellungen für Bild...)

Gestaltungsregel "Farbeinstellung des Bildes"

Setzen der Farbeinstellungen für ein Bild. Die Einstellungen entsprechen dem Dialog von Objekt>Farbeinstellungen für Bild.... 

Die Screenshots zeigen einen Rahmen, der bei Geometrieänderungen die Farbeinstellungen des Bildes ändert. (Wobei Geometrieänderungen wohl eher der unwahrscheinliche Anwendungsfall sind, nur zur Demo halt.)

svn 2379

01.04.2011

Versucht man mit frame::remove einen Rahmen einer InDesign®-Gruppe zu löschen, die selbst als Inline in einem Text eingefügt ist, erhält man den Fehler 1121 und der Rahmen wird nicht gelöscht.

Der Fehler ist gefixt.

Will man die ID-Listen im Script weiterverwenden, müssen immer vier Aufrufe an list::alloc gemacht werden. Bei der Verwendung muss man dann ziemlich aufpassen, dass die eigentliche ID aus diesen Listen richtig zusammengesetzt wird. Schöner wäre eigentlich, man könnte die IDs in EINEM Aufruf und in einer Liste holen.

Dazu bietet sich ja die Liste IDTypeList an. In der alloc-Methode dieser Liste können jetzt (wie in list::alloc) die PalettenID und das Auswahlkriterium angegeben werden. Dann wird die Liste beim alloc entsprechend gefüllt.

Mehr dazu in der Online-Doku von idtypelist::alloc.

Die selektierten/markierten Einträge bekomme ich über folgenden Funktionsaufruf "List li = list::alloc(9,kEyeMarked,1);". Gibt es auch eine Funktion mit der ich per Skript diese Markierung in der Publikations-Palette setzen kann?

Dafür gibt es jetzt den neuen Skriptbefehl

    idtypelist::mark_in_panel

In der Doku steht, wenn der Zielpfad leer ist, wird die PDF-Datei neben der Dokumentdatei angelegt. Die Funktion liefert aber einen Fehler. Das ist nicht schlimm, es gibt ja einen einfachen Workaround : Den Pfad mit documen::path, file::path und file::shortname zusammenbauen.

Der Fehler ist gefixt.

Beim PDF-Export eines Dokumentes wird immer automatisch der Acrobat-Reader geöffnet und in den Vordergrund geholt. Das ist recht störend. Existiert die PDF-Datei bereits, kommt ausserdem eine Fehlermeldung, dass die Datei nicht geändert werden kann, weil sie im Reader geöffnet ist. Und danach wird sie trotzdem geändert (?).

Ja, das stimmt. Leider kann das Verhalten auch nicht mit der Exporteinstellung "PDF nach Export anzeigen" gesteuert werden. Und die API-interne Schnittstelle, mit der das Anzeigen nach dem Export ebenfalls unterdrückt werden kann, funktioniert auch nicht :-(.

Glücklicherweise verfügen wir neben document::export_ noch über den Skriptbefehl

    document::pdf_export

Mit dem kann exportiert werden, ohne dass danach der Reader geöffnet wird.

Ich habe document::export_ trotzdem so geändert, dass bei "pdf" jetzt (intern) document::pdf_export verwendet wird. Der Export wird seitenweise gemacht.

ACHTUNG : document::pdf_export kann nicht mit einem UIFlag gerufen werden (bzw. hier ist ein weiterer Fehler in der Adobe-API : Das Flag wird einfach ignoriert - nochmal :-( ). Alle nötigen Einstellungen sollten also über das Exportprofil definiert sein.

Workaround

Versionen vor v3.2.2 R2378 können die Anweisung document::pdf_export verwenden.

Die Funktion file::upload ist nicht implementiert. So steht es auch in der Doku. Kann man sie trotzdem implementieren?

Die Funktion geht jetzt wieder. Sie ist jetzt auch für Windows verfügbar.

Hinweise

• Zum Upload wird FTP verwendet.
• Im Zielsystem werden keine Ordner angelegt. Enthält der URL also einen Ordnerpfad für das Ziel, muss der Ordner im Zielsystem existieren.

Wir benötigen cScript-Funktionen, mit denen Strings Base64-kodiert werden können und base64-codierte Strings wieder dekodiert werden können.

    encode_base64
    decode_base64

machen das Gewünschte.

ACHTUNG

Beide Funktionen allokieren den Ergebnisstring selbst. Die Ergebnisse müssen mit release wieder gelöscht werden!

Wir benötigen eine cScript-Funktion, mit der der md5hash einer Datei berechnet werden kann.

Dafür gibt es jetzt die Funktionen

    file::md5hash
    strmd5hash

Die zweite Funktion berechnet den m5hash eines beliebigen Strings. Obwohl dasauch für kurze Strings geht, macht das macht natürlich nur Sinn für lange Strings.

Hat man mit Hilfe des orangen Pfeiles () einen Eintrag der Preview-Palette ins Dokument eingefügt, sollen diese Einfügungen (Text, Bild, Rahmen) nachbearbeitet werden. Z.B. soll mglw. das Platzhalter-Objekt angepasst werden. Dafür brauchen wir einen Mechanismus, der über den Datenpool gesteuert werden kann.

Die Einträge der Preview-Palette können jetzt mit einem zusätzlichen Wert geladen werden, der die ID einer Aktion enthält, die nach dem Einfügen ausgeführt werden soll. Der Name dieser Aktion wird in der Palette jeweils hinter dem Namen des Eintrages gezeigt. Die Aktion wird jeweils direkt nach dem Einfügen ins Dokument durch den orangen Pfeil ausgeführt.    

Eine vollständige Beschreibung ist in der Online-Doku zu finden.

Gibt es eine Möglichkeit, Tabellen und Tabellenzellen mit zwei weiteren Infos zu versehen, die in Skripten gesetzt und ausgewertet werden können? Hintergrund ist, dass Tabellen im Datenpool eine eindeutige Kennung und eine Prüfsumme haben, die im Syncscript verwendet werden sollen, um zu testen, ob die Tabelle oder einzelne Zellen neu geladen werden müssen.

Dazu gibt es jetzt acht neue Funktionen :

    table::get_info1
    table::set_info1
    table::cell::get_info1
    table::cell::set_info1

Und jede Funktion noch mal mit Info2.

Gibt es eine Möglichkeit, den Tabellenplatzhalter herauszufinden, der eine Tabelle aufgebaut hat? Dieser Platzhalter wird ja beim Aufbau der Tabelle gelöscht.

Diese Information wird wird beim Einsetzen der Tabelle in die neue Tabelle eingetragen. Bisher kann sie aber über cScript nicht erfragt werden.

Mit den neuen Funktionen

    table::get_table_placeholder_id
    table::get_table_placeholder_text

können diese Angaben jetzt auch mit cScript ermitttelt werden. Der Text ist dabei der unformatierte Text des Platzhalters vor dem Einsetzen der Tabelle.

ACHTUNG

Die beiden Werte begleiten die Tabelle so lange sie besteht. Wird die Tabelle kopiert, bleiben diese Werte ebenfalls erhalten.

Berechnet man die sichtbare Fläche eines Rahmens werden auch die Rahmenteile von der Fläche abgezogen, die von unsichtbaren Rahmen oder von Rahmen von unsichtbaren Ebenen kommen.

Der Fehler ist gefixt.

Mit table::cell::is_overset kann erfragen, ob eine Tabellenzelle eine Übersatz hat. kann man auch erfragen, ab welcher Textposition der Übersatz ist?

Die Funktion hat jetzt einen weiteren Parameter, mit dem die Textposition des ersten Zeichen im Übersatz geholt werden kann. Der Index ist Zellen-relativ.

siehe auch hier

[Comet 3.2.1]

In 3.2.1 R 2363 (CS4, Mac) ist der Fehler irgendwie noch drin (sowohl im Pfad- als auch im Namensteil).

Äh doof, stimmt. Ich habe nur "unsere" interne file-Klasse repariert (Das ist NICHT die file-Klasse von cScript, sondern eine, die noch einige Ebenen tiefer liegt.) document::path u.a. verwenden aber die Methoden der InDesign®-API von Adobe. Dort ist das leider auch nicht richtig. Diese Adobe-Funktionen werden gefühlte 10000 mal in den Plugins verwendet. (In diesem Fall) glücklicherweise ist die InDesign®-API aber auch an der Stelle FILE zu PFAD gewohnt unhandlich und wir machen das in der Regel an einer zentralen Stelle mit einer eigenen Funktion, in der die API-Funktionen verwendet werden. Das habe ich mal korrigiert. Der dort verwendete Aufruf wird im gesamten Plugin-Code nur einmal (nämlich hier) verwendet, so dass der Fehler damit gefixt sein dürfte.

Die previews der Vorlagen sind ja meistens nicht sehr aussagekräftig. Wäre es möglich, das  wir die Previews separat updaten könnten, am besten mit einem Preview aktuell ausgewählter Rahmen? So könnte man nach dem Anlegen des Templates mal ein Produkt aufbauen und dieses als Preview sichern.

Wird das Sichern-Button der Template-Palette (grüner Aufwärtspfeil) mit gehaltener CMD-Taste gedrückt, werden jetzt die Previews aller ausgewählten Templates der Palette durch einen Snapshot der aktuellen Rahmenauswahl des Dokumentes ersetzt.

Gibt es die Möglichkeit, die Popupmenüs dieser Dialoge auch direkt (und nicht über sql oder xmlquery) mit Einträgen zu füllen. Als Beispiel etwa die Dateien eines festgelegten Ordners.

Die Popupmenüs können jetzt über zwei weitere Parameter in askstring2 bzw. akspopup2 mit Daten gefüllt werden. Dafür wird jeweils eine IDTypeList übergeben, die in ID1 die ID und in StringID den jeweiligen Popuptext enthalten.

Wir benötigen einen Dialog mit zwei Popup-Menüs. Beide Menüs werden über Datenbankanweisungen gefüllt. Ändert der Benutzer die Auswahl im ersten Dialog, muss der zweite Dialog entsprechend dieser Auswahl neu geladen werden.

askstring2 kann jetzt einen zweiten Popup-Eintrag haben, der ebenfalls über Datenbankanweisungen gefüllt wird. Ändert sich die Auswahl im ersten Popup, wird dieses Popup gemäss dieser Auswahl neu geladen.

Ausserdem gibt es zur enfachereren Handhabung den neuen Befehl akspopup2, der lediglich zwei Popupmenüs (und keine weiteren Textfelder) enthält.

Im Datenpool abgelegte InDesign®-Bibiotheken sollen über irgendeinen Mechanismus auch importiert werden können.

Es gibt jetzt das neue Menü

    Datei:Neu:Bibliothek importieren...

Die Aktionen des Menüs können im Datenpool über Skripte gesteuert werden. Im Normalfall sollte dabei mit Hilfe von askstring2 oder askpopup2 eine Liste der verfügbaren Bibliotheken gezeigt werden. Nach Auswahl einer Bibliothek kann diese dann (wie und wohin auch immer) importiert werden - das ist ebenfalls Skriptaufgabe. Mehr dazu siehe in der Online-Doku.

Wir müssen InDesign®-Bibliotheken und Informationen über deren Inhalte exportieren. Gibt es dafür eine Möglichkeit?

Jede Bibliothekspalette hat jetzt einen neuen Menüeitrag

    Bibliothek:exportieren

Was dieses Menü macht, kann über den Datenpool mit Skripten definiert werden. Die Funktionen des Moduls library unterstützen die Skripte dabei. Mehr Infos sind in der Online-Doku zu finden.

library::open öffnet keine Bibliothek. Weitere Aufrufe an das Modul können daher gar nicht erst verwendet werden.

Ja, das stimmt leider. Bei der Anpassung von CS2 auf CS3 (ja, doch schon so lange!) ist da ein Fehler in der Umrechnung der Dateipfade passiert.

Das Modul wurde vollkommen überarbeitet und enthält jetzt neben Funktionen zum Öffnen und Schliessen von Bibliotheken Funktionen zum Platzieren, Kopieren, Ändern und Löschen von Bibliothekseinträgen. Insgesamt stehen 22 Funktionen zur Verfügung. In der Online-Doku sind für jede Funktion Beispiele zu finden.

Beim Einsetzen von Einträgen aus InDesign®-Bibliotheken werden Magneten zwischen den Rahmen falsch generiert.

Die Fehler sind gefixt.

(v3.2.1 R2363) Der Fehler ist gefixt

Man bekommt zwar die richtige Anzahl der in der Liste ausgewählten Templates, aber die IDs der Einträge sind falsch. Die IDs stimmen nur, wenn alle jeweils alle Vorgängereinträge der Liste geöffnet sind.

Der Fehler ist bei der Einführung der Treeviews in der Liste passiert und jetzt gefixt.

18.03.2011

Aus aktuellem Anlass : Die Comet-Plugins werden seit ihrem ersten Release ausschließlich ohne Atomstrom entwickelt.

Bei installiertem comet-Plugin ist die CS-Basis-Ansichts-Funktionalität gestört. Die Hintergrundfarbe für "Vorschau" verstellt sich, Umschalten per Klick auf das UI-Element funktioniert nicht (nur Shift-W) und Änderungen der Papierfarbe gehen nicht durch. Bei Entfernen der comet-Plugins funktioniert alles einwandfrei.

Der Fehler ist gefixt.

FYI

Templates und Seitentemplates zeichnen beide in den Seitenhintergrund. (Templatetyp, Seitentemplate-Name, ...). Damit weitere Zeichenroutinen ausgeführt werden können, muss die eigene Funktion einen Wert zurückgeben, der wie folgt beschrieben ist :

bool16    result;   // Tell the draw event dispatcher to
                    // keep calling other handlers and
                    // allow the drawing agent
                    // to complete its draw.

Ja richtig, ich hab TRUE zurückgegeben. Und das war falsch - weitermalen
erfordert FALSE. Muss man auch erst mal drauf kommen.

Die StringID einer Tabellenzelle kann aus drei Teilen zusammengesetzt werden, die durch |--| getrennt werden.

    Root|--|Column|--|Row

Macht man diese Einstellung im Tabellenmodul wird aber bei Klicken der Checkbox für die ColumnRecordStringID die StringID der Spalte eingesetzt und bei RowRecordStringID die der Spalte.

Der Fehler ist gefixt.

Platzhalter im Overset werden von der ToDoListe im Treeview-Modus nicht dem richtigen Rahmen zugeordnet. Sie erscheinen als Einträge ohne Cometgruppe/Produkt in der Liste.

Der Fehler ist gefixt

10.03.2011

Kunde meldet das egal was er in "name" übergibt, die via SOAP herunter geladene Datei immer die "id" als Dateinamen unterhalb von "path" bekommt.

Der Fehler ist gefixt.

Workaround

Da Kunde ja die ID weiss, kann Kunde die Datei mit Hilfe von file::rename umbenennen.

When we let indesign server create a preview image using cscript image::snapshot_page() The frame containing an EPS image shows as a grey rectangle.

In the generated PDF the eps image is shown correctly. Is this a limitation of the cscript api, or just some configuration setting we need to change?

We tried this using Indesign Server CS4 on both windows and mac.

In version 3.2.1 / R2330 the image::snapshot_... functions will support an additional parameter to control the jpeg quality. This will also fix the preview bug:

image::snapshot_page (
	0, 3,
	kOriginalSize, 
	"JPEG",
	kFullResGraphics + kJPEGProgressive + kXPHigh);

See the Plug-In Online documentation or details.

Attention

InDesign® Server must be started with -previews argument or a JaveScript must set this option before inserting EPS images (app.imagePreview = true;)

Ich bräuchte eine Möglichkeit, den XML-Buffer zurückzusetzen - leider finde ich überhaupt keine Möglichkeit, das zu tun.

Es gibt jetzt die Funktion

    xmlquery::flush

Ein Aufruf der Funktion entfernt den internen XML-Baum aus dem Speicher. Beim nächsten xmlquery::open wird die Datei wieder neu geparst.

Alternnativ kann xmlquery::close mit dem neuen zweiten Parameter doFlush gleich 1 gerufen werden.

ACHTUNG

In beiden Fällen gilt: Alle XMLTrees zur gleichen Datei müssen zur flush-Zeit geschlossen sein!

file::rename vergibt merkwürdige Namen, wenn der Name Umlaute enthält.

Der Fehler ist behoben.

Hier ein Testskript:

int main ()
{
	char			path [4096];
	char			fname [256];
	char			fnew [256];
	
	strcpy (path, file::get_nth ("$DESKTOP/combining", 0));
	file::shortname (fname, path);
	wlog ("", "'%s' %d\n", path, strcmp (fname, "äöüßœå"));
	
	strcpy (fnew, fname);
	strcat (fnew, "ƒœä©.indd");
	textmodel::replace (fnew);
	file::rename (path, fnew);
	
	strcpy (path, file::get_nth ("$DESKTOP/combining", 0));
	wlog ("", "'%s'\n", path);

	return 0;	
}

Die Bösen Menschen bei Apple benutzen ja Combining Characters (bzw. - wie ich glücklicherweise lernen durfte - UTF-8 NFD) für ihre Pfadbezeichner. Das heisst, ein Umlaut (z.B. ein ä) wird nicht als normale UTF-8-Sequenz serialisiert, sondern als Kombination aus zweien (a und ¨).

Wenn ich per document::path() einen Dokumentpfad hole, werden die Zeichen auch so im String abgelegt; wenn ich z.B. per frame::image_getpath() einen Bildpfad hole, werden sie "normal" (UTF-8 NFC) abgelegt.

In der Log-Ausgabe sehen die Strings auch völlig identisch aus, aber strcmp() schlägt verständlicherweise fehl.

Gäbe es eine Möglichkeit, das zu vereinheitlichen? Ansonsten wäre eine Konvertierungsfunktion NFD <-> NFC vielleicht ganz hilfreich.

Fürs erste hab ich schon mal eine Funktion geschrieben, die die häufigsten Kombinationen konvertiert, die hänge ich gleich dran.

Pfade und Namen von Dateien werden jetzt auch auf dem Mac einheitlich in UTF-8 (NFC) geliefert. Der obige Workaround mit dem Skript ist dann nicht mehr nötig.

Ab CS5 kann man Bildplatzierungen mit dem neuen Feature

    Objekt:Anpassen:Rahmeneinpassungsoptionen

machen. Wird das von cScript unterstützt?

frame::image akzeptiert jetzt das neue Platzierungsflag

    kPlaceWithFittingOptions

Mit dieser Angabe wird das Bild so platziert, wie es in den Rahmeneinpassungsoptionen eingestellt ist. Diese Einstellungen werden ausserdem durch die Funktionen

    frame::set_fitting_options
    frame::get_fitting_options
    frame::clear_fitting_options
    frame::apply_fitting_options

unterstützt. Für die meisten Bildplatzierungen sind damit keine Gestaltungsregeln mehr nötig, um bei Grössenveränderungen von Rahmen das Bild anzupassen.

Achtung : Der Beschnittbetrag wird nach Grössenänderungen von InDesign® offenbar nicht immer richtig neu berechnet. Diesen Fehler können unsere Plugins natürlich nicht korrigieren!

04.03.2011

Kann man ein Produktliste in cScript nach irgendwelchen eigenen Kriterien sortieren?

Mit dem neuen Befehl

    productlist::sort

geht das jetzt. Mehr dazu in der Online-Doku.

Kann man ein (z.B. mit linkist::collect) erhaltene Liste von Platzhaltern irgendwie mit Hilfe von cScript sortieren, ohne die Sortierung selbst zu implementieren?

Mit dem neuen Befehl

    linklist::sort

geht das jetzt. Mehr dazu in der Online-Doku.

Kann man das Platzieren von URLs aus Internetbrowsern in InDesign®-Dokumenten irgendwie mit Aktionen (z.B. der Anlage eines Produktes) hinterlegen?

Man kann jetzt :

Dazu muss man ein wenig konfigurieren - insbesondere das, was die URLs auslösen sollen - aber dann geht es sehr schön. Mehr dazu siehe hier.

Dateien normaler HTTP-URLs können geladen werden. HTTPS funktioniert leider nicht richtig.

Das funktioniert jetzt. Bug 2302 enthält ausserdem eine Testdatei.

Enthalten Texte, die in der Preview-Palette angezeigt werden, TaggedText, sollten die Tags aus der Anzeige ausgefiltert werden.

Das wird jetzt gemacht.

Kann man das in der Produktrecherche oben rechts ausgewählte Stanardtemplate über cScript erfragen?

Die neue Funktion

    productlist::get_default_pageitem

liefert die ID des ausgewählten Eintrages. Die Palette muss dazu natürlich geöffnet sein.

Also: wenn ich bspw. in CS5 ein CS4 Dokument ausbuche (mit der Checkin / Checkout-Erweiterung) wird das an einem bestimmten lokalen Pfad erwartet. Da ein konvertiertes Dokument aber genau da nicht liegt, sondern erstmal gar keinen Pfad hat, hängt es sehr von der jeweiligen Benutzerreaktion ab, was weiter mit dem ausgebuchten Dokument passiert.

An dieser Stelle erscheint jetzt ein abschaltbarer Dialog, der

• bei OK die Datei im neuen Format überschreibt
• bei CANCEL den Vorgang abbricht, "revert" aufruft und die lokale Zwischendatei löscht

Der Dialog erscheint auch im "klassichen" Publikationen-Modus (also ohne Checkin / Checkout), bei OK wird hier ebenfalls überschrieben, bei CANCEL passiert nichts weiter, aber immerhin wurde der Benutzer gewarnt.

Kann man für die Comet-Notizen eindeutige und stabile IDs vergeben?

Bisher werden dafür die UIDs der verwendeten InDesign®-Rahmen verwendet. Die sind zwar (dokumentweit) eindeutig aber leider nicht stabil : Nach jedem Aus- und wieder Einblenden einer Notiz ändert sich diese Nummer.

Notizen bekommen jetzt eine (dokumentweite) eindeutige ID. Zusammen mit - konfigurationsabhängigen - Dokument-IDs können Notizen damit eindeutig identifiziert werden.Die IDs der Notizen werden in der Palette "Kommentare" hinter dem Namen der Notiz angezeigt :

Die IDs werden bei Neuanlage automatisch vom Dokument vergeben. Beim Einfügen von Notizen aus anderen Dokumenten (Copy/Paste, Templates, idms) wird versucht, alte IDs zu erhalten. Geht das nicht, werden neue IDs vergeben.

Beispiel

Das Dokument A enthält die Notizen 1-4. Die Notizen 1 und 2 werden gelöscht. Danach (Überraschung), enthält das Dokument A die Notizen 3 und 4. Werden jetzt aus einem anderen Dokument B die Notizen 2 und 3 importiert enthält das Dokument danach die folgenden Notizen :

• Notiz 2 (2 aus B)
• Notiz 3
• Notiz 4
• Notiz 5 (3 aus B)

Werden Notizen im Dokument ein- oder ausgeblendet, ist danach die Listenauswahl der Palette geändert. Das ist nicht weiter schlimm aber verwirrend.

Die Listenauswahl bleibt jetzt erhalten.

Achtung

Werden Notizen sichtbar gemacht, können dadurch Rahmen mehrerer Dokumentseiten ausgewählt sein. Aktionen mit Rahmen verschiedener Dokumentseiten können InDesign® zum Absturz bringen. Das passiert z.B. beim Verschieben der Rahmen auf eine andere Ebene. Diese Fehler können von den Comet-Plugins nicht abgefangen werden.

Wird ein Rahmen verschoben, sollten eigentlich die am Rahmen hängenden Notizen ebenfalls verschoben werden, oder?

Teilweise geht das schon : Wird die Rahmenposition über das Eingabefeld oder mit frame::moveto geändert, werden angehängte Notizen ebenfalls verschoben.

Jetzt werden die Notizen auch dann mit geschoben, wenn der Rahmen manuell im Dokument verschoben wird. Die Notizen müssen dabei nicht ausgewählt sein.

Beim Verschieben von Notizen wird der Rahmen, an dem die Notiz hängt aber nicht verschoben!

Bei Copy/Paste von Rahmen mit Notizen werden die dabei neu eingesetzten Notizen nicht als Notizen registriert. Verweise innerhalb der kopierten Rahmen gehen verloren.

Copy/Paste von Rahmen mit Notizen geht jetzt : Verweise werden richtiggetstellt und die neuen Notizen werden richtig im Dokument registriert.

Achtung

Notizen werden nicht automatisch mit kopiert. Sollen Notizen kopiert werden, müssen sie also in der Zwischenablage enthalten sein

Comet-Notizen können zwar in Templates eingefügt werden. Beim Einsetzen der Templates in Dokumente werden diese Notizen auch richtig ins Dokument eingesetzt. Allerdings gehen dabei die Verbindungen zu Rahmen und Cometgruppen verloren. Die neuen Notizen werden auch in der Palette "Kommentare" nicht angezeigt. Beim Erstellen der XML-Datei mit den Dokumentkommentaren fehlen die neuen Kommentare.

Comet-Notizen können jetzt in Templates verwendet werden. Rahmen/Cometgruppen-Verbindungen werden wieder richtiggestellt. Die eingefügten Notizen werden im Dokument registriert und können jetzt richtig in der Palette angezeigt und exportiert werden

Exportiert man Dokumente oder Dokumentteile in idml bzw. idms, gehen die im Original definierten Comet-Notizen verloren. Die Rahmen selbst sind nach dem Import zwar noch vorhanden, sie sind aber nicht mehr als Kommentare gekennzeichnet und auch nicht in der Palette "Kommentare" enthalten.

Das funktioniert jetzt richtig. Auch die Verweise der Kommentare auf Rahmen oder Cometgruppen werden wieder richtig hergestellt.

Öffnet man eine idml-Datei, gehen die in der Originaldatei definierten Cometgruppen verloren.

Dieser Fehler ist behoben. Cometgruppen werden jetzt wieder angelegt.

Importiert man idml/s-Dateien, können dabei Magneten entstehen die auf den Rahmen selbst zeigen. Auch Magneten zu Rahmen auf anderen Seiten können entstehen.

Das passiert immer dann, wenn in Import und existierender Datei unterschiedliche Rahmen mit gleichen UIDs enthalten sind. Der Fehler ist gefixt.

Beim Versuch, idms-Dateien in Dokumente zu importieren stürzt InDesign® ab.

Der Fehler ist behoben. Idms-Dateien können wieder richtig importiert werden.

Wir benötigen eine Gestaltungsregel, mit der Rahmen unsichtbar gemacht werden können.

Es gibt jetzt die Standardregel "Unsichtbar/Sichtbar".

Achtung

Die Regel basiert auf der ab CS5 verfügbaren InDesign®-Rahmeneigenschaft "Sichtbar/Unsichtbar" und ist deshalb auch erst in Plugins ab CS5 verfügbar.

R 2300

11.02.2011

Die Funktion strlen liefert ja die Länge eines Strings als Anzahl der UTF-Zeichen. Wie bekommt man denn die Länge in Bytes? Das ist ja unter Umständen mehr.

Das geht mit der Funktion strsize. Die ist seit R1102 (20.12.2008) auch schon in Comet 2.1 verfügbar. Leider hat sie bisher in der Doku gefehlt. Was jetzt nachgeholt ist.

Die Verwendung von findstatements unter SOAP funktioniert nicht, weil InDesign® beim Laden das Statements abstürzt.

Der Fehler ist gefixt.

Enthält die Datei findstatements.xml die Erweiterungen label1, label2, ... , dann können die Findstatements under XML und SOAP nicht mehr geladen werden. Es wird nach den Attributen alias udn sourcefile gesucht, die es gar nicht gibt.

Der Fehler ist gefixt.

Workaround

Die beiden Attribute in der Datei findstatements.xml anlegen.

Alle Funktionen mit formatierter Ausgabe (wlog, wtlog, showmessage, printf, translate, ...) führen zum Absturz, wenn der Ergebnisstring zu lang ist :

char * str = alloc (20000);

// str mit 15000 Zeichen füllen - z.b Dokument oder Datenbank
wlog ("", "%s\n\n", str);

// ---> Absturz!

Ja, das stimmt leider. In der Doku steht zwar, dass das Ergebnis nicht länger als 3000 Zeichen sein darf - aber ehrlich, wer liest das schon?

Und dass die interne Grenze eigentlich bei 10000 lag, behebt das Problem auch nur ungefähr.

Die Grenze ist jetzt bei 32 kB. Aber wirkungsvoll behoben sind die Abstürze dadurch, dass die entsprechenden Funktionen über diese Grenze tatsächlich nicht mehr schreiben können. Die Ausgabe wird fünf Zeichen vorher abgebrochen und an
das Ergebnis wird "...\n" angehangen. Und dann noch die abschliessende \0.

Hier mehr zu Formatstrings.

ACHTUNG

Dieser Fix kann nicht verhindern, dass Sachen wie

int i = 0;
:
wlog ("", "%s\n", i);
// Muss richtig heissen : wlog ("", "%d\n",i);<

oder

String str = string::alloc ();
:
wlog ("", "%s\n", str); 
// Muss richtig heissen : wlog ("", "%s\n", string::get (str));

zum Absturz führen. Das sind reine Benutzerfehler.

CS5, R 2252 und 2266: InDesign® stürzt ab, sobald in einem Script itemlist::pageframes() aufgerufen wird. In 3.1.1 R 2252 funktioniert alles prima.

Testscript:

int main()
{
    ItemList    frs;

    frs = itemlist::pageframes(-1);
    showmessage("Liste mit %d Rahmen", itemlist::length(frs));
    
    itemlist::release(frs);

    return 0;
}

Und der Parameter -1 ist es auch nicht - itemlist::pageframes(2) funktioniert genau so wenig in 3.2.

itemlist::allframes() funktioniert.

Der Fehler ist gefixt.

Workaround:

Für alle Parameter den Default-Wert anegben.

    frs = itemlist::pageframes(-1, 0, 0, "", 0, "", 0);

Gibt es solche Funktionen?

Jetzt ja :

• datapool::get_template_name
• datapool::get_main_template
• frame::get_page_element
• frame::get_template
• frame::get_chapter_id
• frame::get_smart_item_data

Die Funktionen

    placeholder::load
    placeholder::link

können ja so verwendet werden, dass nur ein gegebener Textbereich des Rahmens bearbeitet wird. Kann man auch nur den Rahmen- und keinen Textplatzhalter bearbeiten.

Ab jetzt ja, dafür einfach den Start-Textindex auf -2 setzen.

Befindet sich gFrame in einer InDesign®-Gruppe und wird diese Gruppe aufgelöst, um einen weiteren Rahmen zur Gruppe zur Gruppe hinzuzufügen, werden nicht mehr alle Rahmen richtig geladen.

Das Problem war die Neugruppierung der Rahmen und ist jetzt gefixt. Eine ausführliche Beschreibung ist unter frame::ungroup in der Online-Doku zu finden.

Folgendes muss an dem Platzhalterskript geändert werden :

Statt :

if (frame::get_group(gFrame, group_ref) == 0)
{
	frame::ungroup(group_ref, group_frames);
	itemlist::append(group_frames, fr);
	frame::group(group_frames);
}

Enweder

if (frame::get_group(gFrame, group_ref) == 0)
{
	frame::add_to_group (gFrame, fr);
}

Oder

ItemRef newGroup = item::alloc ();
:
:
if (frame::get_group(gFrame, group_ref) == 0)
{
	frame::ungroup(group_ref, group_frames);
	itemlist::append(group_frames, fr);
	frame::group(group_frames, newGroup);
	frame::regrouped (group_ref, newGroup);
}

Die Produktliste, die man mit

    productlist::get_established

erhält, enthält ja auch Einträge für die Seitentemplates. Fragt man diese Seitentemplates nach der Liste ihrer Rahmen im Dokument, ist die Ergebnisliste danach merkwürdig gefüllt.

Das ist gefixt. Die Liste wird jetzt geleert und itemlist::length (resultList) gibt in diesen Fällen jetzt 0 zurück.

Workaround

Mit product::get (p, kProductType) vorher den Typ des Produkteintrages testen. Seitentemplates haben den Produkttyp 4. Davon holt man dann die Rahmenliste eben nicht, oder?

Das ist auch in Ordnung so. Wir bräuchten aber auch die Möglichkeit, die Template-ID zu erfragen, mit der ein Produkt im Dokument aufgebaut wurde.

Mit dem Schlüsselwort kProductUsedPageitem geht das jetzt :

    product::get (p, kProductUsedPageitem);

R 2266

04.02.2011

Ist es kompliziert, ein Showmessage mit zwei und eins mit drei (konfigurierbaren) Buttons zu bauen?

Geht mit dem neuen Befehl alert.

Zieht man Produkte per Drag and Drop ins Dokument und hält gleichzeitig die Cmd-Taste gedrückt, sollten die neuen Produkte nach dem Einfügen sofort aufgeräumt werden. Alle nachfolgenden Produkte werden dabei ebenfalls neu platziert.

Das funktioniert aber nicht richtig. Manchmal passiert gar nichts, manchmal werden nicht alle Produkte eingefügt. Manchmal wird an falscher Stelle eingefügt.

Das ist gefixt und funktioniert jetzt hoffentlich richtig.

Hat man die Option "Seitenelemente zeigen" aktiviert (Kontextmenü im Dokumentfenster), werden jeden Menge Lognachrichten geschrieben :

""
select UID node pagetemplates.pagetemplate.templates.template

# 1 result found

Das ist nicht schlimm. Aber irgendwie stört das.

Okay, ist gefixt.

Ist die Palette Seitentemplates beim Login geschlossen, können keine Dokument mehr reorganisiert werden. Auch der Aufbau funktioniert dann nicht. Vor R2133 hat das funktioniert.

Der Fehler ist gefixt.

Die Reorganisation hat auch nicht funktioniert, wenn die Produktrecherche nicht geöffnet war. Das ist ebenfalls gefixt.

Kann man mit folg. Skript leicht testen :

int main ()
{
    productlist::reorganize ();
    return 0;
}

Das Skript hängt man als XML-Skript am besten an einen Rahmen, der ausserhalb einer Seite liegt.

Zum Setzen dieser Eigenschaften gibt es Funktionen. Kann man die Werte auch lesen?

Man kann :

• frame::get_scale
• frame::get_rotate
• frame::get_skew

In frame::resize kann man in den Parametern refX und refY einen eigenen Referenzpunkt angeben. Das Ergebnis scheint aber irgendwie unvorhersehbar zu sein.

Ich habe die Parameter umbenannt in offset_x und offset_y. Die Angaben werden als Offset zum aktuell verwendeten Referenzpunkt verwendet und funktionieren jetzt auch bei gedrehten Rahmen richtig. Die Position berechnet sich wie folgt :

    ∂x = ∂w * (x_ref+x_off)/w * cos (α) + h * (y_ref+y_off)/h * sin (α)
    ∂y = ∂w * (x_ref+x_off)/w * sin (α) - h * (y_ref+y_off)/h * cos (α)

Das wird jetzt für alle Winkel richtig gemacht. Mehr dazu unter frame::resize.

Mit frame::bbox kann die BoundingBox eines Rahmens ermittelt werden. Bei normalen ungedrehten Rahmen reicht das zur Grössenbestimmung aus. Bei gedrehten Rahmen ist die Rahmengrösse natürlich anders als die BoundingBox.

Ja freilich. Es gibt deshalb jetzt die neue Funktion

    frame::get_size

Wendet man die Funktion frame::resize auf gedrehte Rahmen, ist das Ergebnis falsch. Bei der Grössenänderung wird die BoundingBox um den Rahmen geändert, nicht der Rahmen selbst.

Dieser Fehler ist gefixt. frame::resize ändert jetzt auch bei gedrehten Rahmen den Rahmen selbst und passt nicht mehr die BoundingBox auf die neue Grösse an.

Die Begrenzung auf 1000 Einträge ist meines Wissens für die Produktrecherche bereits seit längerem aufgehoben, das Publikation-Panel scheint aber noch auf 1000 Einträge limitiert zu sein. Ist dies eine Einschränkung, die sich nicht ändern lässt, oder die so gewollt ist? Oder könnte auch hier in einer nächsten Version des Cometen das Limit angehoben werden?

Ich hab die Grenze mal auf 100.000 hochgesetzt. Obwohl ich ja eigentlich finde, dass 1.000 Einträge schon ganz schön viel sind - pro Ebene wohlgemerkt. Mit nur zwei Ebenen wären das 1 Million Einträge.

ACHTUNG : Sehr lange Listen können InDesign® instabil machen oder zum Absturz bringen. Eine Grenze ist dabei nicht festzumachen, das scheint an der Speicherauslastung von InDesign® zu hängen.

Bei der Verwendung von Fortsetzungstemplates werden die Rahmen, die die Fortsetzung erzwingen, so angepasst, dass das Seitenelement genau ausgefüllt wird. Es gibt aber Fälle, in denen die Rahmengrösse erhalten bleiben soll.

In der Palette "Template Eigenschaften" ist der Fortsetzungstyp eines Rahmens (2. Spalte der grau hinterlegten Rahmenoptionen) jetzt ein "tri-state"

1. off
2. Fortsetzung (mit Grössenanpassung) - gefülltes weisses Dreieck
3. Fortsetzung mit fixer Grösse - weisses Dreieck ohne Füllung

Schöner wäre es, wenn neue Notizen den Status "to do" bekommen würden.

Das ist jetzt so.

Wenn ich eine neue Comet-Notiz im Dokument anlege, ist in dem Rahmen immer eine weisse Schrift eingestellt.

Die Plugins setzen an dieser Stelle weder Font noch Farbe - es wird der Default für neue Textrahmen verwendet. Dass bei dir die Schrift unsichtbar ist, liegt also an den lokalen Einstellungen : Wenn du einen Textrahmen erzeugst, wird der bei dir immer weiss mit weisser Schrift. Warum auch immer.

Ich habe (mit einigem Aufwand) trotzdem folg. Einstellmöglichkeiten gemacht :

Ist die Angabe eines Absatzstiles leer (oder der Stil existiert im aktuellen Dokument nicht) werden entweder die Comet-Defaults (Verdana 12 Pt, schwarz) oder die aktuellen InDesign®-Einstellungen für die Schrift verwendet.

Scripterror 6 at line 32 : 
    undeclared identifier :table::reset_strokes
Scripterror 6 at line 32 : 
    undeclared identifier :table::reset_strokes_rows

Das Script ist nicht so lang:

#include "internal/table.h"

int main()
{
	Table	t = table::alloc();

	table::get(t, gFrame, 0);
	table::reset_strokes_rows(t,0,-1,eAllSides,eWeight+eColor);

	return 0;
}

Da hab ich bei der internen Funktionsbezeichnung leider jeweils das Mehrzahl-s vergessen Damit man ohne Änderung der Quellen auskommt, hab ich die Doku angepasst :

    table::reset_stroke
    table::reset_stroke_rows
    table::reset_stroke_cols

Die Grösse von Templates beinhaltet auch alle Rahmen, die nur im Textfluss verwendet werden. Dadurch erscheint das Template grösser, als es nach dem Einfügen ins Dokument wird.

Hört sich harmlos an. Aber die Templategrösse wird beim Produktaufbau verwendet, um zu testen, ob ein Template auf ein Seitenelement passt. Und das tut es dann unter Umständen nämlich nicht. Die Grösse des Templates darf also Rahmen, die beim Produktaufbau nicht verwendet werden, auch nicht enthalten.

Dieser Fehler ist jetzt gefixt. Die Templategrösse wird nur aus den Rahmen berechnet, die auch tatsächlich beim Produktaufbau eingefügt werden. Enthält das Template ausschlisslich Rahmen nur für den Textaufbau, wird die Grösse wie bisher berechnet.

Zusätzlich habe ich die Erstellung der Previews angepasst. Auch dort werden jetzt die Rahmen ignoriert, die nur im Textfluss verwendet werden Aussnahme auch hier : Wenn das Template ausschließlich Rahmen nur für den Textfluss enthält, werden diese Rahmen auch im Preview gezeigt.

Aus der Produktrecherche kann per Drag&Drop auf eine gesperrte Ebene platziert werden. Wenn ich von Hand z.B. einen neuen Rahmen anlege, kommt eine Meldung "Die aktive Ebene ist verborgen oder gesperrt..." - schön wäre, wenn die auch beim Drape&Duck käme.

Gefixt. Die aktuelle Ebene muss entsperrt UND sichtbar sein.

Bei Produktaufbau und -reorganisation werden die in den Rahmen hinterlegten Adapter-Regeln nicht ausgeführt.

Das ist aus zwei Gründen gewollt :

1. Im Produktcontext werden die Adaptionen ausgeführt, um Magnetabstände wiederherzustellen. Die Regeln der Adaption zielen aber meist auf Grössenänderungen der Dokumentseiten.
2. Die Skripte der Seitenadaption sind direkt in den Rahmen hinterlegt. Im Produktcontext ist es aber üblich, Skripte on the fly aus dem Datenpool zu laden. Das würde unweigerlich zu jeder Menge Ärger führen.

Es gibt aber durchaus Situationen, in denen bei der Wiederherstellung der Magnetabstände Aktionen ausgeführt werden sollen. Deshalb :

Es gibt eine weitere Situation, in der Adapterscripte ausgeführt werden können. Neben "Vor Adaption", "bei Positionsänderung", "bei Grössenänderung" und "Nach Adaption" gibt es den zusätzlichen Typ

    "Während Produktaufbau"

Die Regeln werden bei Produktaufbau, -laden und -reorganisation immer dann ausgeführt, wenn die Magnetabstände korrigiert wurden. Die Regeln werden ausserdem in der Gestaltungsregel "Magnetabstnde wiederherstellen) ausgeführt.

Die Skripte dieser Aktionen werden bei ihrer Ausführung aus dem Datenpool geholt. Nur wenn die Aktion nicht gefunden wird, wird das im Rahmen hinterlegte Skript ausgeführt.

Beispiel

Im zweiten Bild zu Bug 2242 ist Ihnen vielleicht aufgefallen, dass der erste Rahmen mit "Der schwarze Incal" genauso breit ist, wie der grüne Textrahmen darunter. Der grüne Rahmen wurde aber offenbar durch diesen Rahmen erst nach unten verschoben - und ein Rückwärtsmagnet zum ersten Rahmen würde einen Kurzschluss bilden. Hier befindet sich jetzt am grünen Rahmen eine Regel "Während Produktaufbau", die den eingehenden Magneten ermittelt (siehe eine Tabellenzeile weiter unten :-) ) und die Breite dessen Startrahmens anpasst. Den dazu nötigen Skripttext finden Sie hier (Es ist das zweite Beispiel.).

Gibt es eine Möglichkeit, die Rahmen zu ermittlen, mit denen eine Rahmen über Magneten verbunden ist?

Mit den folg. neuen Skriptbefehlen geht das :

• frame::incoming_magnets
• frame::outgoing_magnets
• frame::get_magnet_type
• frame::get_magnet_is_white
• frame::get_magnet_is_rotation_only
• frame::get_magnet_reference

Mehr dazu in der Doku.

Die Verwendung von Funktionen, die char*-readonly-Ergebisse liefern, scheint immer wieder Schwierigkeiten zu machen wie folgender (völlig falscher) Beitrag im priint.comet Forum zeigt :

Die korrekte Syntax (so steht's auch in der Doku) für das Auslesen von stringlist-Werten lautet:

char * test = alloc(100);

test = stringlist::get(liste, i, 0);

Aber cscript akzeptiert zunächst auch

strcpy(test, stringlist::get(liste, i, 0));

Diese Schreibweise kann u.U. zu scheinbar völlig unmotivierten InDesign®-Abstürzen führen, muss aber nicht. Vor allem finden die Abstürze nicht unbedingt beim Ausführen dieser Zeile, sondern irgendwann später statt. Also: unbedingt die erste Schreibweise verwenden!

DAS IST FALSCH!

Richtig ist :

Das erste Code-Snippet ist keine korrekte Verwendung: Durch den Aufruf wird die Adresse von test geändert. Ein späterer Aufruf von release (test) kann den allokierten Speicher nicht mehr freigeben. Er versucht vielmehr, Speicher freizugeben, der von der Liste liste allokiert wurde. Das macht die Liste aber irgendwann selbst - und dann gibt es Probleme.

Die erste Schreibweise darf auf keinen Fall verwendet werden! Ich bin sicher, dass das so auch nicht in der Doku steht.

Richtige Verwendungen wären :

char * test = alloc(100); // ausreichend Platz reservieren!
// oder auch : char	test [100];
:
strcpy(test, stringlist::get(liste, i, 0));
:
release (test);

oder

char * test = stringlist::get(liste, i, 0);

   oder auch

char * test;
:
test = stringlist::get(liste, i, 0);

Ich habe jetzt in die Doku eine ausführliche Beschreibung eingefügt, wie die r/o-Returns von char*-Funktionen richtig verwendet werden :

    Development/Werk2Lib/cinterpreter.html#Static_return

Die Beschreibung jeder Funktion mit char*-r/o-Return enthält eine fette Warnung und diesen Link.

In einigen Rahmen der Fortsetzungstemplates werden die Gestaltungsregeln nach dem Laden/beim Aufräumen nicht ausgeführt. In anderen Rahmen werden die Regln dagegen ausgeführt.

Stimmt, es sind die Rahmen, für die im Haupttemplate ein Rahmen gleicher Kennung existiert. Der Fehler ist gefixt.

In Templates mit Fortsetzungen werden die Produkte falsch skaliert, wenn der Rahmen, der die Fortsetzung erzwingt, gedreht ist. Die gedrehten Rahmen sind nach dem Einsetzen ausserdem verzerrt.

Das Verhalten ist beim Fix von Bug 2233 aufgefallen und ist jetzt gefixt. Die Bilder zeigen Screenshots des Templates und seiner Anwendung.

ACHTUNG

Beim Einsetzen des Haupttemplates wird zuerst der gesamte Text in den Rahmen geladen. Durch das darauf folgende fitframe wird die Boundingbox gedrehter Rahmen aber nicht nur höher sondern auch breiter. Bei langen Texten und/oder grösserem Drehwinkel kann es dabei passieren, dass der Rahmen das Seitentemplate seitlich überragt. Dieses Verhalten kann vom Algorithmus zur Beseitung von Textübersatz derzeit nicht gelöst werden. Der Aufbau bricht an dieser Stelle ab, wenn kein Seitenelement gefunden wird, das breit genug ist. Das trifft inbesondere auf Rahmen zu, die um 90° gedreht sind.

Ist ein Bildrahmen gedreht worden (sind die Kanten also nicht waagerecht und senkrecht), dann werden die Rahmenkanten nach Ausführung der Gestaltungsregelparallelogramm-artig verzerrt. Das erfolgt nicht nur bei Rahmen, die einenBildplatzhalter enthalten, sondern bei jedem beliebigen Bild.

Workaround

int main ()
{
	frame::fit (gFrame);
	frame::polygon(gFrame,4); // Verzerrung rueckgaengig
	
	return 0;
}

Der Fehler ist gefixt. Die Gestaltungsregel "Rahmen anpassen" kann jetzt auch für gedrehte Rahmen verwendet werden.

Besondere Mühe hat beim Bugfixing das Wiederherstellen des Fixpunktes gemacht. Als Fixpunkte werden die Rahmenecken verwendet, NICHT die Ecken der Boundingbox!

Nach dem Sichern einer Template-Gruppen (Template-Editor + Grüner Pfeil in der Template-Palette), bleibt InDesign® häufig stehen.Der Fehler tritt nicht sofort auf aber nach 2-3 mal Sichern eines Templates kann man keinen Produktaufbau mehr machen.

Testbar mit jeder Comet-Installation :

1. Doppelklick eines Templates
2. Sichern des Templates
3. Aufbau

Wiederholt man die Schritte 2 und 3, stürzt InDesign® meist bereits bei der ersten Wiederholung ab.

Der Fehler ist gefixt.

Manchmal kommt es vor, dass Bilder keine Data Fork haben. Wenn diese Bilder auch keine Resource Fork haben (also 0 byte), wird das vom Cometen beim Platzieren und beim Anzeigen in der Preview-Palette abgefangen. Wenn sie eine Resource Fork haben, versucht der Comet, das Bild zu platzieren / anzuzeigen und stürzt ab. Siehe auch Bug 2132.

Der Fehler ist gefixt.

Beim Sichern von Rahmen eines geöffneten Template-Editors wird immer das Template überschrieben, das den Editor geöffnet hat. Die Auswahl in der Template-Palette wird ignoriert.

Das ist richtig und eigentlich auch Absicht. Dieses Verhalten soll davor schützen, versehentlich ein falsches Template zu überschreiben. Leider kann manso aber auch keine Kopie eines bestehenden Templates machen.

Das kann jetzt gemacht werden, wenn beim Sichern gleichzeitig zur Alt-Taste(die ja Standard ist) auch noch die

    Shift-Taste

gehalten wird. In diesem Fall wird versucht, das erste ausgewählte Template derTemplate-Palette zum Sichern zu verwenden.

ACHTUNG : Das bisher gängige Verfahren zum Sichern von Templates ist ab Comet 3.2 geändert :

Beim Sichern von Template-Editoren wird immer das gesamte Dokument gesichert.

In "normalen" Dokumenten wird wie bisher die aktuelle Rahmenauswahl für dasTemplate verwendet. Besteht das Zieltemplate aus mehreren Untertemplates wird ermittelt, ob sich die Rahmenauswahl auf einer rechten oder linken Seite befindet und das entsprechende Untertemplate gesichert. Fortsetzungen können mit gehaltener SPACE (NICHT Shift)-Taste gesichert werden.

Verwendet man textmodel::scale_font mit dem Parameter *chunkWise* = 0 (also der gesamte Textbereich bekommt die gleiche Grösse), macht die Funktion nichts, wenn ein Wert für die Minimalgrösse der Schrift angegeben ist. Ist *chunkWise* = 1 funktioniert alles.

Der Fehler ist gefixt.

Workaround

Versionen vor Comet 3.2 R 2245 verwenden die Funktion mit dem Parameter *chunkWise* = 1. Sollen tatsächlich alle Schriftgrössen eingeebnet werden, hilft nur ein kleiner Trick:

Vor der Ausführung die folg. zwei Zeilen ausführen

textmodel::scale_font (0, 0, kEnd, 0.8, 0, 1, 0);
textmodel::scale_font (0, 0, kEnd, 1.25, 0, 1, 0);

Wichtig ist, dass das Produkt der beiden Skalierungen 1.0 ergibt. Der Textbereich muss natürlich dem eigentlichen Aufruf von scale_font angepasst werden.

Wendet man die Funktion frame::move_to_layer auf Unterrahmen von Gruppen oder auf Inline-Rahmen an, stürzt InDesign® ab. Das Skript wird zwar fehlerfrei bis zum Ende ausgeführt. Beim ersten Redraw des Rahmens aber stürzt InDesign® ab.

Ja, das ist richtig. Rahmen von Untergruppen müssen immer auf der gleichen Ebene liegen. Ebenso müssen Inline-Rahmen (was naheliegend ist) auf der gleichen Ebene wie der Rahmen ihres Textes liegen.

frame::move_to_layer testet diese Eigenschaften jetzt und erzeugt bei Bedarf den Fehler 1274 oder, wenn der (neue) Parameter mvGroup gleich 1 ist, verschiebt das oberste Objekt (also die oberste Gruppe bzw. den obersten Textrahmen). Hier finden Sie auch ein Beispiel, wie Sie in Versionen von Comet 3.2 R2245 den Fehler vermeiden können.

12.01.2011

Beim Einfügen und Löschen von Tabellen per cscript werden die globalen Variablen cStart und cLen nicht aktualisiert. Die gute Nachricht: textmodel::start() und textmodel::length() funktionieren.

Wenn das leicht zu ändern ist, könnte man das beheben; sonst sollte es zumindest in der Doku stehen.

Übrigens werden die globalen Variablen auch beim Einfügen von Text nicht aktualisiert.

Ja, beim Fix von Bug 2184 ist mir das auch aufgefallen. gStart und gLen sind globale Variablen, die beim Skriptstart gesetzt werden. Aber innerhalb des Skriptes können sich ja ändern.

Und das werden sie jetzt auch.

ACHTUNG : Änderungen der Werte dieser Variablen können zwar gemacht werden. Bei der nächsten Verwendung im Skript bekommen sie aber wieder ihre aktuellen Werte :

int main ()
{
	wlog ("", "#1 gStart = %d\n", gStart);
	gStart    = gStart - 1;
	wlog ("", "#2 gStart = %d\n", gStart);

	return;
}

Und hier die Logausgabe eines Platzhalters mit diesem Skript:

#1 gStart = 12
#2 gStart = 12

Wenn ich eine Tabelle habe, die - sagen wir mal - 4x4 Zellen hat, und ich in die erste Zelle (0,0) einen Textplatzhalter positioniere, der eine Tabelle an dessen Ende erzeugt (-1), dann kommt diese Tabelle in Zelle 0,0 zum Vorschein.

Soweit so gut.

Habe ich in dem Platzhalter ein Textmodel-replace "" zu beginn (vor dem Erstellen der Tabelle), dann wird die Tabelle richtigerweise auch gelöscht. Sie befindet sich ja im aktuellen Textmodel.

Soweit immer noch gut.

Wenn die neue Tabelle jetzt allerdings am Ende des Platzhalters (-1) erzeugt wird, dann ist die Tabelle allerdings immer ausßerhalb des aktuellen Textmodels. Ja sie ist sogar außerhalb der Zelle. In meinem Fall bei x 1, y 0.

Zum Einen ist die Position der Tabelle somit falsch und zum Anderen ist sie durch ihre neue Position auch nicht mehr durch das Textmodel-replace zum Löschen erreichbar.

Ich habe auch versucht, die Position am Ende des Platzhalters durch gLen anzugeben, um sicherzustellen, dass es nicht etwa an -1 für das Ende des Platzhalters liegt.

Aus dem Bauch raus würde ich sagen, dass sich gStart und gLen evtl. bei Textänderungen nicht während der Laufzeit der Platzhalter entsprechend ändert. Evtl. betrifft es auch nur den Umstand, wenn sich Tabellen im Textmodel befinden.

Wenn ich das richtig verstanden habe, haben Sie einen Textplatzhalter an dessen Ende (zum Platzhalter gehörend) eine Tabelle steht. Das folgende Skript wäre ein Gerüst für solch einen Platzhalter.

int main ()
{
	int            T = table::alloc ();

	if (!T)         return;

	textmodel::replace ("VOR", 0, kEnd);

	table::create (T, gFrame, 2, 2, kEnd, 0, 20.0, 20.0);
	table::release (T);

	textmodel::append ("NACH");

	return 0;
}

Das Problem war sehr schwer zu beheben und hat insgesamt 60 Code-Änderungen nötig gemacht.

(Es bestand im Wesentlichen darin, dass beim Löschen/Einfügen von Tabellen die Gesamttextlänge nicht nur um die -obendrein variable- Anzahl der Zeichen für den Tabellenanker geschrumpft/gewachsen ist. Auch die Zelltrenner (jeweils ein \r) und die Zellinhalte gehören zur Länge des Gesamttextes. Aber die Anzahl dieser Zeichen muss man freilich erst rausfinden - und zwar die Anzahl, die InDesign® tatsächlich zeigt. Das Zeichen <0x200B> hat zwar 2 Bytes, ist aber nur EIN Hairspace usw.)

31.12.2010

Kann man auch einzelne Dokumentseiten als PDF exportieren. Mit document::export_ können ja nur vollständige Dokumente exportiert werden.

Man kann. Mit dem neuen Skriptbefehl document::pdf_export.

Wählt man als Einfügestelle für den Seitenaufbau einen Rahmen innerhalb eines nichtvollen 1:N-Seitenelementes, wird ein neues leeres Seitenelement erzeugt und der Aufbau in diesem neuen Element begonnen. Eigentlich würde man erwarten, dass das aktuelle Element erst einmal gefüllt wird.

Produkte in ein bestehendes Seitenelement können mit DragDrop und gehaltener CMD-Taste gemacht werden. Das oben beschriebene Verhalten wäre so gesehen eine Erweiterung : Aufbau mit teilweisem Aufräumen.

Mit recht hohem Aufwand ist das Verhalten beim Aufbau jetzt wie folgt :

1. Wird der Aufbau in einem 1:Element gemacht und ist
2. die Einfügestelle befindet sich in einem 1:N-Element

das im Aufbau ausgewählte Seitentemplate gleich dem aktuellen Seitentemplate wird jetzt zuerst das aktuelle 1:N-Element gefüllt. Das Element wird dazu natürlich vorher komplett neu aufgeräumt. Ist das Element gefüllt, werden weitere Elemente verwendet und bei Bedarf neue Seiten angelegt. Produkte hinter dem 1:N-Element werden NICHT aufgeräumt.

Bonus

Ist in der aktuellen Seite noch kein Seitentemplate festgelegt aber die Rahmen der Seite liegen so, dass sie in einen 1:N-Rahmen des neuen Seitentemplates (das im Aufbau-Dialog gewählt wurde) fallen WÜRDEN, dann WERDEN sie auch in dieses neue Element eingeräumt. Das Verhalten ist also genauso, als wären die Rahmen bereits platziert.

Enthalten die Rahmen von Fortsetzungstemplates Platzhalter, werden die beim Aufbau zwar richtig verknüpft aber nicht geladen.

Der Fehler ist gefixt.

Wenn ich in der Palette "Template-Verhalten" für einen Rahmen die Eingeschaft "Fortsetzungsrahmen" (weisses Dreieck) setze, ändert sich manchmal die Grösse des Rahmens.

Diese Rahmen haben eine Gestaltungsregel, die auf Geometrieänderungen reagiert.

Hintergrund

Alle Comet-Tools zum Setzen von Rahmeneigenschaften (Platzhalter, Gestaltungsregeln, Nägel, Magneten, Template-Verhalten, Adapter-Verhalten, ...) senden intern nach Ausführung das Ereignis "Geometrieänderung". Das ist nötig, damit InDesign® die Rahmenänderungen auch im Dokument anzeigen kann.

Lösung

Bevor eine Eigenschaft im Template-Verhalten eines Rahmens ändert, muss die Gestaltungsregel "NachGeometrieänderung" dieses Rahmens deaktiviert werden.

Allgemein

Bei der Vergabe von Gestaltungsregeln, die auf Geometrieänderungen reagieren,sollte man äussert sparsam sein. Diese Regeln können sehr oft gerufen werden. Und in den meisten Fällen sind die entsprechenden Aktionen (meist ist es ja nur ein fitframe) schon an anderer Stelle ausgeführt. FÜR DAS EINFÜGEN UND LADEN VON PRODUKTEN UND FÜR DEN PRODUKTAUFBAU WERDEN DIESE REGELN NICHT BENÖTIGT!

Im allgemeinen sollten diese Regeln erst an Templaterahmen angefügt werden, wenn der gesamte Aufbau klappt und man an speziellen Stellen will, dass auf manuelle Änderungen reagiert werden soll. Wenn dann beispielsweise ein fitframe einen Rahmen immer wieder klein zieht, kann das für Benutzer auch sehr lästig sein.

Öffne ich ein gesichertes Template mit Doppelklick in der Template-Liste sieht mein Template anders aus, als es beim Sichern ausgesehen hat. In der gesicherten Template-Datei ist noch alles in Ordnung.

Das passiert immer dann, wenn Rahmen des Templates Gestaltungsregeln "Nach Anlegen" (+) haben. Die werden in dieser Situation nämlich ausgeführt - weil die Rahmen ja neu angelegt werden.

Das Verhalten ist trotzdem lästig. Deshalb werden diese Gestalungsregeln jetzt beim Öffnen eines Templates unterdrückt. Die Rahmen des Templates bleiben dann unverändert.

Ab CS5 können Rahmen einzeln unsichtbar gemacht werden. Kann man das als Skriptbefehl haben?

Man kann :

    frame::hide
    frame::show
    frame::is_hidden

Mehr dazu in der Online-Doku.

CS 5 zeigt in der Ebenen-Palette alle ItemRefs der aktuellen Seite. Dort können Namen vergeben werden. Diese Namen sollten man in Skripten nutzen können:

• einem ItemRef einen Namen geben
• den Namen eines ItemRefs auslesen
• zu einem Namen alle ItemRefs im Dokument/Seite finden

Mit den Funktionen

    frame::get_name
    frame::set_name

geht das jetzt (CS5 vorausgesetzt). Um die Liste der Seiten-Rahmen eines bestimmten Namens zu erhalten, kann die (leicht erweiterte) Funktion

    itemlist::pageframes

verwendet werden. Der gewünschte Name kann als regulärer Ausdruck angegeben werden. Statt [^\\0]* darf dabei auch das %-Zeichen verwendet werden :

    "%Cometgroup 206%"  == "[^\\0]*Cometgroup 206[^\\0]*"

12.12.2010

Will man die Einstellungen eines Templates über den Template-Dialog (blauer Punkt in der Palette Templates) ändern, wird ein falscher SQL-Befehl ausgeführt und die Änderungen können nicht gesichert werden :

update 
    typeid = ?, domainid = ?, stateid = ?, 
    placeholderID = ?, description = ?,
    scriptid = ?, active = ?
where id = ?

Da fehlt offensichtlich "pageitems set" hinter dem update. Unter XML funktioniert das Ganze.

Der Fehler ist gefixt.

Ist es möglich, den Aufruf placeholder::load so zu ändern, dass nur bestimmte Platzhalter und/oder Produkte neu geladen werden?

Das ist natürlich möglich und jetzt auch realisiert, mehr dazu siehe Online-Doku.

Gibt es eine Funktion, mit der erfragt werden kann, ob ein Absatz Teil einer Aufzählung ist?

textmodel::get_para_listtype liefert das Gewünschte, mehr dazu siehe Online-Doku.

Beim Klick auf den Öffnen-Pfeil der Ordner der Templates-Palette stürzt InDesign® reprodizierbar ab. Der Fehler tritt ab R2177 auf.

... und ist jetzt wieder gefixt.

28.10.2010

Die Produktpalette sind meist so konfiguriert, dass Oberprodukte, die nicht importiert werden können/sollen, keine Template-ID haben. Ein Einstellung, automatisch alle Produkte ohne Template zu übergehen, würde also Sinn machen.

Der Seitenaufbau-Dialog enthält jetzt eine entsprechende Checkbox. Ist die angeklickt, werden Produkte ohne Template nicht mehr mit aufgebaut - sonst werden sie mit dem ausgewählten Template des Dialoges aufgebaut.

In der Skriptsprache heist das entsprechende Flag kSkipEmptyTemplates.

Nach dem Aufräumen entstehen merkwürdige Seitentemplates mit der ID 0 zwischen den Produkten. Diese Einträge entstehen immer vor der Seite, ab der als letztes aufgeräumt wurde. Will man später diese Seite wieder aufräumen, wird das Aufräumen mit der (berechtigten) Meldung, dass das Seitentemplate 0 nicht aufgelöst werden kann, abgebrochen.

Workaround

In der Desktop-Version können diese Einträge mit Hilfe der Liste 'Produkte des Dokumentes' manuell aus der Liste entfernt werden. Danach kann wieder aufgeräumt werden.

Lösung

Alle Produkte des Dokumentes tragen intern eine Absatz-Kennung. Diese Kennung wird bei Reorganisationen verwendet, um Seitenumbrüche wieder herstellen zu können.

Leider bekamen bei Reorganisationen ab einem festgelegten Rahmen oder einer festgelegten Seite die Rahmen eine neue Absatzmarkierung. Das ist natürlich falsch - die Produkte sollen ihre Absatzzuordnung behalten. Und das tun sie jetzt auch. Der Fehler ist damit gefixt.

Reorganisation mit Alt-Click räumt das Dokument ab der Cometgruppe des ersten ausgewählten Dokumentrahmens auf. Befindet sich diese Cometgruppe innerhalb eines 1:N-Elementes, funktioniert das nicht. Teilweise werden dabei sogar neue Produkte angelegt.

Der Fehler war, dass an der richtigen Cometgruppe mit Aufräumen begonnen wurde. In diesem Fall muss aber am ersten Produkt des 1:N-Rahmens mit dem Aufräumen begonnen werden - also doch etwas weiter oben. Das funktioniert jetzt.

Fügt man in ein 1:N-Seitenelement weitere Produkte mit automatischem Aufräumen (cmd-Taste beim Fallenlassen der Produkte) ein, werden die neuen Elemente immer in einem neuen Seitenelement angelegt.

Der Fehler ist gefixt. Da automatische Einfügen in 1:N-Elemente funktioniert jetzt.

08.10.2010

Enthalten Dokumentseiten sichtbare Comet-Notizen, so werden diese Notizen mit in die Seitenreorganisation aufgenommen - mit einigen unschönen Folgen, wenn z.B. die Notiz auf einer anderen Seite landet, als ihr zugehöriger Rahmen.

Das ist gefixt, Comet-Notizen werden bei der Reoganisation jetzt ignoriert.

Enthält eine Seite Hilfslinien, scheitert die Seiten-Reorganisation daran, dass für die Hilfslinie kein Seitenelement gefunden wird.

Oje, natürlich sollen die Hilfslinien nicht mit in den Produktaufbau einsortiert werden. Der Fehler ist behoben.

01.10.10

Beim Sichern von Templates soll zusätzlich automatisch eine IDML-Version der Templatedatei mitgesichert werden.

Geht jetzt. Die IDML-Datei wird unter XML und SOAP "neben" der INDD-Datei abgelegt, also bspw. pageitems/data/123.idml. Unter SQL wird sie natürlich in die Datenbank gesichert. Das macht entweder das Panelstatement 121 oder, wenn das fehlt oder leer ist, die Anweisung update PageItems set dataIDML = LATIN1 ? where id = ? (LATIN1 wird durch den aktuellen Wert aus keywords ersetzt)

Das Feature muss eingeschaltet werden mit:

    prefs::add_idml_to_templates (1)

am besten im Login-Skript.

Freigestellte Musterseitenrahmen führen bei Seitenreorganisationen zu Fehlern. Dann wird versucht, auch diese Rahmen aufzuräumen. Das sieht erstens ziemlich blöd aus. Und zweitens geht es auch meist nicht, weil die Musterseitenelemente zu groß für jedes Seitenelement sind.

Na so was. Ist behoben.

Seitenelemente mit mehreren Produkten können diese Produkte ja horizontal und vertikal ausrichten. Es wäre eigentlich ganz brauchbar, das auch für 1:1-Elemente zu haben. So könnte man bspw. auf rechten Seiten alle Produktgruppen rechtsbündig platzieren.

Das geht jetzt. Die eingefügten Cometgruppen können jetzt im Seitenelement ausgerichtet werden. Vertikaler und horizontaler Keil sind hier natürlich nicht möglich und werden deshalb ignoriert.

(Nur XML-Offline) Öffnet man ein Template per Doppelklick über die Palette Templates und schreibt dieses Template zurück in den Datenpool, sind danach

    ALLE TEMPLATES GELÖSCHT!!

Im XML-Ordner fehlt der komplette Ordner pageitems/data.

Der Fehler tritt immer dann auf, wenn eins der Untertemplates im Template-Editor keine Rahmen enthält. Also :

• seitenspezifische Templates : Seiten 2, 3, 4, oder 5
• Spread-Templates : Seiten 1 oder 2

Sind die Untertemplates alle definiert, passiert nichts. Sonst - stimmt leider leider :

    DER GESAMTE DATENORDNER MIT DEN TEMPLATES WIRD GELÖSCHT!

Der Fehler ist gefixt. Comet 3.2 ist noch in der Testphase, trotzdem :

    KEINE COMET 3.2-RELEASES VOR 2140 WEITERGEBEN!

Sind Untertemplates leer, werden die entsprechenden Templates jetzt gelöscht - aber auch nicht mehr! Ist das Basistemplate leer, wird eine Warnung gezeigt und das Sichern abgebrochen.

Gibt es die Möglichkeit, nur eine einzelne Dokumentseite zu reorganisieren?

Ja, mit dem CMD-Click ins Reorganisieren-Button der Produktrecherche oder mit dem Menübefehl "Seite reorganisieren" der Produktrecherche. Dann wird nur die aktuelle Dokumentseite aufgeräumt.

ACHTUNG

Die Seite kann natürlich mehr Produkte enthalten, als draufpassen. Überzählige Produkte werden auf die nächste Seite verschoben und dort (in ihrer aktuellen Reihenfolge) an die Seitenpositionen (0, 0), (1, 1), (2, 2), ... gelegt. Wird diese nächste Seite reorganisiert, werden diese Produkte dann als erstes verwendet. Das geht gut, solange das erste Seitenelement nicht in diese Rahmen hineinragt - danach KANN die Reihenfolge ein bisschen falsch werden. Da Seitenelemente in der Regel nicht bei (0, 0) beginnen, ist alles gut. Aber mal ehrlich : Da geht jemand her, schiebt 30 Produkte von der Grösse 1/8 Seite auf eine Seite und räumt dann nur diese eine Seite auf - da muss ein bisschen Strafe auch mal sein.

@Christoph : Fürs Whiteboard : IProductsServiceUtils::reorganize und der Skriptbefehl productlist::reorganize unterstützen das auch.

Bisher kann die Reorganisation von Dokumenten nur mit Hilfe der Palette "Produkte des Dokumentes" gemacht werden. Schön wäre, wenn auch die Produktrecherche so ein Button (analog "Aufräumen" für den Rasteraufbau) bekäme.

Und wenn man schon dabei ist - auch ein Menübefehl vielleicht?

Button und Menübefehle sind eingebaut. Mit beiden Werkzeugen kann das Dokument (oder die aktuelle) Seite reorganisiert werden. Seitentemplateämderungen, -wechsel, Seitenwechsel, Leerseiten, Templatewechsel, ... können natürlich hier nicht gemacht werden. Dazu wird nach wie vor die Palette "Produkte des Dokumentes" benötigt.

Nach der vollständigen Definition einer Smart-Template Gruppe mit Textrahmen, die sich automatisch fortsetzen können, wird die Fortsetzung trotzdem nicht verwendet.

Die Seitenelemente erlauben ebenfalls Fortsetzungen und hätten genügend Platz, den ersten Teil des Templates auszunehmen.

Oh Schreck! Nach eingehender Prüfung hier die Lösung : Die Textrahmen, die sich fortsetzen können, haben fürs Laden die Gestaltungsregel "Rahmen anpassen".

Dann passiert folgendes :

1. Template einsetzen
2. Laden
3. fit:frame auf den Textrahmen.

Der Textrahmen ist jetzt erstens zu groß fürs Seitenelement und zweitens hat er sowieso keinen Übersatz mehr - braucht also auch die Fortsetzungsvorlage gar nicht mehr.

Um nicht verschiedene Templates für Drag and Drop und den Aufbau verwenden zu müssen jetzt folg. Lösung :

Befindet sich das Template im AUFBAU, werden alle HÖHEN-Änderungen in Platzhalterskripten und Gestaltungsregeln an Rahmen, die eine Fortsetzung erlauben (Dreieck-Symbol in der Palette Template-Verhalten) nach dem Laden wieder rückgängig gemacht.

Schon funktionierts.

Bei der Reorganisation des Dokumentes ändert sich mitunter die Reihenfolge der Produkte im Dokument.

Das tritt z.B. beim Einfügen von Produkten ins Dokument, beim Löschen von Cometgruppen oder auch einfach bei der Wiederherstellung der Rahmenpositionen auf.

Der Fehler tritt immer dann auf, wenn mehrspaltige Seitentemplates verwendet werden. Das Problem ist, dass für die Bestimmung der Produkt-Reihenfolge bisher ausschließlich die XY-Position der Cometgruppe verwendet wurde. Dann kommt mit Sicherheit das erste Produkt der zweiten Spalte vor dem zweiten Produkt (der ersten Spalte).

Mit großem Aufwand werden jetzt die der Seite hinterlegten Seitentemplates und deren Elemente zur Bestimmung der Reihenfolge verwendet. Dabei wird auch darauf geachtet, ob ein Seitenelement zeilen- oder spaltenweise aufbauen kann.

Damit stimmt die Produktreihenfolge jetzt.

ACHTUNG : Zur Bestimmung der Position wird immer die linke obere Ecke des Rahmens um die jeweilige Cometgruppe verwendet!

Es wird eine Funktion benötigt, mit der Bilder in andere Rahmen übernommen werden können. Schön wäre es, wenn dabei Bildposition, -skalierung, -drehung, ... usw. übernommen werden würden. Ganz super wäre es, wenn auch die fx-Effekte erhalten blieben. Und spitze wäre es, wenn bei unterschiedlichen Rahmengrössen auch die Bildpositionierung (z.B. rechts-unten) wiederhergestellt würde.

Der neue Befehl

    frame::copy_image

kann all das. Alle Grössen, Skalierungen, etc. bleiben erhalten. Alle (Bild)effekte werden übernommen. Und was die Positionierung angeht : Nachdem das Bild kopiert wurde, können die Gestaltungsregeln für Geometrieänderungen aufgerufen werden. Dann stimmt auch die Positionierung wieder.

ItemRefs können geholt und gelesen (getint) werden. Eine Funktion zum Setzen eines ItemRefs (z.B. für einen speziellen Rahmen) wäre auch nicht schlecht.

Mit

    item::define

geht das jetzt.

In einigen (seltenen) Fällen wäre es schön, wenn man die Nägel und Magnenten auch drucken bzw. im PDF zeigen könnte. Das ist insbesondere bei Dokus und Beschreibungen sinnvoll.

Das Kontextmenü, in dem die Sichtbarkeit von Nägeln Magneten und RahmenUIDs eingestellt werden kann, enthält jetzt den zusätzlichen Eintrag

    Druckbar

Ist das aktiviert, werden die Nägel und Magnente (und bei Bedarf auch die Rahmen-UIDs) mit gedruckt resp. exportiert.

Mit der Seitenreorganisation ist eines der mächtigsten Comet-Tools endlich realisiert. Eigens für die Reorganisation gibt es die neue Palette Produkte des Dokumentes. Ein kurzer Film zeigt die Palette im Einsatz.

Für Seiteaufbau und -reorganisation gibt es ein eigenes Tutorial. In der Online-Doku ist nur das PDF des Tutorials enthalten. Das komplette Tutorial kann auf Nachfrage über Werk II bezogen werden.

Mit dem Kontextmenü

    Cometgruppe:Auswählen

wählt man bei Cometgruppen, die über mehrere Seiten gehen nur die Rahmen einer Seite aus.

InDesign® verbietet die Auswahl von Rahmen, die auf verschiedenen Spreads liegen. Mit normalen Bordmitteln ist eine solche Auswahl daher auch nicht zu machen. Wir können so eine Auswahl trotzdem machen. Das Problem ist, dass InDesign® sehr leicht zum Absturz gebracht werden kann, wenn eine Rahmenauswahl über mehrere Spread geht.

Lösung

Bei der Auswahl der Comet-Gruppe werden nur die Gruppenrahmen ausgewählt, die auf der aktuellen Seite liegen. (Das war bisher nicht so.)

Mit gehaltener SPACE-Taste werden alle Gruppenrahmen ausgewählt, egal auf welchem Spread. Eine komplette Gruppe kann so gelöscht werden. Alle anderen Aktionen (inkl. erneutem Öffnen des Kontextmenüs) können zum Absturz von InDesign® führen!

(svn 1965)

Produkte können ja mit dem Status forceDelete (= -1) in die Produktrecherche geladen werden. Woran kann man denn dort erkennen, ob ein Produkt gelöscht werden soll oder nicht?

Bis jetzt gar nicht. Und ab jetzt wird der Produktname in der Palette in Italic-Shrift gezeigt :

Achtung : Mit dem Fix von Bug 1505 in diesem Release werden diese Produkte auch vom Seitenaufbau ausgeschlossen!

Die Farben für Platzhalter müssen immer entweder in der Datei colors.xml (XML und SOAP) oder das Panelstatement 11 (SQL) definiert werden. Hat man dafür keine Daten, ist es recht mühselig, brauchbare Farben zu definieren.

Das stimmt, die Definition von Farben ist ein bisschen mühselig. Hinzu kommt, dass die Farbnamen natürlich nicht lokalisiert sind. Mit Comet 3.2 müssen die Farbdefinitionen nicht mehr im Datenpool gemacht werden. Sind keine Farben definiert (colors.xml bzw. das Panelstatement 11 fehlen oder sind leer), werden Standardfarben verwendet. Das sind die selben 49 Farben, die auch für die Seitenvorlagen und die Notizzettel verwendet werden.

Im Dialog zum Seitenaufbau werden bisher alle verfügbaren Seitentemplates gezeigt. Das Popup sollte eingeschränkt werden auf die Seitentemplates, die tatsächlich verwendet werden können.

Sind die Seitentemplates richtig konfiguriert, macht es nichts aus, ein Seitentemplate für eine rechte Seite zu wählen, obwohl der Aufbau auf einer linken Seite beginnt. Der Aufbau sucht sich das passende Template selbst.

Zur besseren Übersichtlichkeit wird das Popup trotzdem wie folgt eingeschränkt :

• Auf linken Seiten werden keine Seitentemplates für rechte Seiten gezeigt

• Auf rechten Seiten werden keine Seitentemplates für linke Seiten gezeigt

Der Dialog kann mit einem bevorzugten Seitentemplate gerufen werden. Dieses Template wird immer im Popup gezeigt.

Das sollte doch eigentlich nicht so sein, oder? Wenn ma z.B. eine Hintergrundebene verwenden will, kann man gar nichts aufbauen.

Im Dialog zum Seitenaufbau können jetzt Ebenen festgelegt werden, deren Rahmen nicht auf Überschneidungen mit den neuen Rahmen geprüft werden. Der Skriptbefehl productlist::establish hat zusätzliche Parameter, mit denen diese
Ebenen ebenfalls festlegt werden können. Folgende Möglichkeiten sind vorgesehen :

• Unsichtbare Ebenen

• Alle ausser "Name der aktuellen Ebene"

• Alle hinter ""Name der aktuellen Ebene"

• Unterste Ebene

• -

• Ebene 1

• Ebene 2

• :

• Ebene N

Die aktuelle Ebene ist in der Liste deaktiviert. Im Skriptbefehl wird die Angabe der aktuellen Ebene in der Desktopversion ebenfalls ignoriert. Es können beliebig viele Ebenen angegeben werden.

Ebenenänderungen während des Aufbaus werden ignoriert. Werden beim Aufbau z.B. neue Ebenen hinzugefügt und alle Rahmen aller Ebenen ausser der aktuellen sollen ignoriert werden, werden die Rahmen der neuen Ebenen trotzdem geprüft. Auch die Änderung der aktuellen Ebene oder Umbenennungen der Ebene haben keinen Einfluss auf die Prüfungen.

nur Mac

Können Dokumente automatisch in einem bestimmten Intervall gesichert werden?

Ja das geht auf zwei Arten :

[Ab Comet 3.2] Für alle Dokumente im Menü Zusatzmodule:Comet:Automatische Sicherung:...

Für einzelene Dokumente mit

    document::save (gDocument, kSuppressUI, -millisecs_intervall, 0);

Das macht man dann am besten im AfterOpen- oder AfterShow Skript.

Vorlagen können automatisch gespiegelt und mit Nachfolgern versehen werden. Zur Verwaltung der Einstellungen in den Rahmen der Vorlagen gibt es die neue Palette Vorlagenrahmen. Rahmen können ihre Einstellungen für Vorlagen im Dokument zeigen :

Eine ausführliche Beschreibung finden Sie hier.