Problem: Dokument kann ausgebucht werden, aber beim Einbuchen stürzt InDesign® ab (immer).

Dieses Problem tritt nur mit Mac OS X auf und ist mit diesem Release gefixt.

Ich habe eine Produktliste, wo ich bei vielen Produkten ein eigenes Seitentemplate (kGridid) und Template (kPageitemid) definiere. Bei jedem Seitentemplate wurde in der Palette "Seitenelemente" eine Musterseite definiert.

Wenn ich via productlist::establish() mit dem Flag kPreferProductPT alles aufbaue, sind die Musterseite jedoch nicht gesetzt.

Ja, die Musterseiten der Seitentemplates werden in diesem Fall leider nicht angewendet (und übrigens auch nicht, wenn die Seitentemplates direkt in die Produktliste eingefügt werden). Erst durch expliziten Einfügen der Seitentemplates in die Liste UND der Angabe

product::set (p, kMasterpage, masterpage);

funktioniert das Setzen der Musterseiten. Das ist natürlich nicht ganz richtig. Die Unterlassung ist jetzt gefixt und der Aufbau inkl. angewendeter Musterseiten sollte jetzt funktionieren.

ACHTUNG : Seitentemplates mit definierten Musterseiten können zu einem anderen Ergebnis des Produktaufbaus führen als in früheren Plugin-Versionen.

CometTest [Server] plug-in missing for CC2018/18 Mac

Plug-ins are available now

My project is running well while using CC2017 but crashes with CC2018. We examined the project more closely and found that it works if we remove all inlines from our products.

Problem is solved now (internal note : see GetOwnerPageUID)

The panel Comet Admin -> Comet shows some German text (Tabellenzellen) in the English version of the plug-ins and some English text in the German version (run ends at).

fxd

The hint to the legal notes for third party software used in priint:comet plug-ins refers to the frFR folder of the OFFLINE documentation. But there is no folder frFR inside this documentation.

Well, you're right. We have it only in German and in Engllish. The link now refers to the English version (enEN).

Ich habe eine Notizen-XML mit über 200 Notizen. Der Import dieser Notizen in ein Dokument klappt zwar gut - dauert aber fast 1 Minute.

Für den Import der Notizen sind eine Vielzahl von Aktionen und insbesondere eine Vielzahl von Abfragen der XML-Datei nötig. Das dauert leider in der Summe eine gewiße Zeit. Trotzdem ist es uns gelungen, den Import deutlich zu beschleunigen. Im Testfall sind es jetzt nur noch 12 Sekunden. Der Import ist damit mehr als viermal schneller geworden.

Vielleicht noch eine Bemerkung am Rande: 200 Notizen sind ja auch keine Kleinigkeit mehr. Besonders wenn man bedenkt, dass die Notizen Arbeitshinweise sind. Mglw. sollte man an so einer Stelle auch mal den Workflow überdenken. Ist nur als HINWEIS gedacht, aber Notizen als Datenbank-Ersatz sind vielleicht doch überdenkenswürdig.

Bei Verwendung der Funktion floatlist::add_aLl stürzt InDesign® am Ende des Skriptes ab.

Das Problem lässt sich (als Workaround) so lösen:

    floatlist::add_all(prices_sorted, prices, 1);

Hintergrund ist ein fehlerhaftes "double free", wenn ein Eintrag in eine andere Liste übernommen wird. Mit dem deleteFromSource=1 werden die Doppler vorher entfernt.

Das Problem ist gefixt.

• Laden, Sichern und Statusberechnung (Aufgaben-Palette) von Platzhaltern
• Tabellenaufbau mit Hilfe des Tabellenmoduls
• Skriptunterstützung durch table::cell::set_type und table::cell::get_type
• TaggedText durch das neue Tag graphiccell
• Skriptunterstützung der Rahmeneinpassungoptionen durch frame::set_fitting_options et al.
• Unterstützung der Rahmeneinpassungoptionen in den Tags in und graphichcell

Achtung : Von comet_pdf werden die Grafikzellen bisher noch nicht unterstützt.

Für die Arbeit mit Grafikzellen in Tabellen gibt es zwei neue cScript-Funktionen:

• table::cell::set_type
• table::cell::get_type

Wenn man eine InDesign® Datei mit place_indesign platziert, werden die Magneten visuell richtig angezeigt, aber sie bewirken (teilweise) nichts mehr.

fxd

FogBugx 21979 - Grahikzellen im TaggedText

Seit CC2015 unterstützt InDesign® sog. Grafikzellen. Das ist eigentlich sehr praktisch und man kann damit auf die Inlines in den Zellen verzichten. Leider bietet Adobe aber keine Möglichkeit, die Grafikzellen irgendwie über den TaggedText zu definieren. 

Für die Inlines gibt es auch keinen Standard, aber da haben wir das WERK II Tag <in:>. Könnte man sowas auch für die Grafikzellen machen?

Dafür gibt es jetzt das neue Tag

   <graphiccell: ... >

Die Syntax ist bis auf ein paar wenige Ausnahmen identisch mit dem in-Tag (z.B. kann man Grafikzellen nicht aus existierenden Rahmen erzeugen sondern muß sie immer neu anlegen - daher wird hier die Angabe eines Templates auch gar nicht erst unterstützt.) Mehr dazu hier.

FogBugx 21978 -  Rahmen-Einpassungsoptionen im in-Tag

Ist es möglich, das in-Tag so zu erweitern, dass dort auch die InDesign® Rahmen-Einpassungs-Optionen des neuen Rahmens festgelegt werden können?

Ja, des geht jetzt. Mehr dazu hier.

Das nur für den Mac verfügbare Plugin CoreService [Oracle] mit einer nativen Oracle-Verbindung (OCI) startet leider in den CC-Versionen nicht.

Das Problem lag hauptsächlich an zwei Dingen:

1. Einer veralteten OCI-Library im Plugin

2. Fehlende oder falsche Installation von OCI auf dem ausführenden Rechner.

Die CoreService [Oracle] Plugins wurden gefixt. Und in der Offline-Doku finden Sie eine aktualisierte Beschreibrung was wo auf dem ausführenden Rechner installiert werden muß, damit OCI funktioniert

Der Fix von Fall 21618 in R20300 funktioniert leider noch nicht ganz: In in-Tags werden die Infos nicht gesetzt.

In in-Tags aus Templates hat der Fix leider nur funktioniert, wenn das Template eine InDesign® Gruppe war. Das hab ich jetzt gefixt.

Tabellen, die über TaggedText aus dem PubServer in Dokumente eingefügt werden, sollten vor dem Einfügen einem Integritätstest unterzogen werden können. Der Test sollte insbesondere die Anzahl der Zeilen, Spalten und Zellen prüfen und sicherstellen, dass Zellbereiche nicht zu groß sind oder sich überschneiden.

Bei Fehlern darf die Tabelle nicht importiert werden. Es soll statt dessen ein Fehlertext ins Dokument eingefügt werden.

Der Integritätstest ist jetzt implementiert und kann in den Funktionen zum Einfügen von Text (texmodel::insert, frame::insert, textmodel::replace, frame::replace, ...) aktiviert werden. Mehr dazu hier.

Wenn in einer W2ML Datei Schriftarten in Stilen definiert sind, die auf dem System nicht installiert sind, werden diese beim Import in InDesign® durch die Defaultschriftart ersetzt.

Es ist in InDesign® nicht möglich Schriftarten zu setzen die auf dem System installiert sind. Das schränkt uns beim W2ML import sehr ein.

Die Suche nach einem Workaround hat einen katastrophalen InDesign® Bug aufgedeckt ohne dessen Behebung wir hier nichts machen können. Adobe ist informiert.

Wir geben aber jetzt eine Warnung aus wenn Stile im W2ML definiert sind, die nicht installierte Schriftarten verwenden.

In document::notes::import kann man über ein Flag steuern, ob Notizen komplett ersetzt werden sollen oder ob die importierten Notizen im Dokument hinzugefügt werden sollen. Das Flag wird aber offenbar ignoriert und die Notizen werden immer ersetzt.

Das Flag wird jetzt richtig ausgewertet. Damit können jetzt auch Notizen hinzugefügt werden.

Die cScript Funktion system::controlkey funktioniert unter Windows nicht.

fxd

Ab InDesign® CC 2017 wird beim Aufklappen der Einträge der Produktrecherche die mittlere Spalte falsch verschoben, und zwar immer dann wenn das Aufklappen dazu führt, dass der Scrollbalken erscheint.

fxd

Wenn man die Optionen Ansicht->Nägel und Magneten->Zeigen und Ansicht->Web-Bilder->Rahmenmarkierung anzeigen aktiv hat, wird die Web-Bild-Rahmenmarkierung zweimal gemalt, nur einmal ist der Text sehr klein.

fxd

Das Adornment der Nägel und Magneten zeigt jetzt keine Infos der Web-Bilder mehr.

Wenn man Web-Bilder verwendet und bereits verlinkte Rahmen neu verlinkt, wird anschließend der Status falsch angezeigt ("Update nötig" oder "Unbekannt", wenn es eigentlich "Ok" sein sollte).

fxd

Kann man irgendwie herausbekommen, in welcher Textspalte eine Textposition steht? Wir haben mit textmodel::coordinates probiert - aber ganz offenbar ist das nicht das richtige Werkzeug.

Nein, ist es nicht :-) Um die Textspalte zu ermitteln, wurde textmodel::get_frame_containing um einen (optionalen) Parameter erweitert. Mehr dazu siehe hier.

Ich verwende in einem Template einen Rahmen als blauen Hintergrund. In der Liste der Produkte des Dokumentes verhält dieser Rahmen sich merkwürdig:

• Als Grafikrahmen : OK

• Als Textrahmen ohne Text : In der Lise eintsteht Eintrag "Manuell eingefügte Cometgruppe" mit dem Status "Zu Löschen". Einen Rahmen im Dokument kann dieser Eintrag nicht auswählen. Statt dessen wird immer sofort das Produkt direkt darunter ausgewählt - und das ist der blaue Rahmen.

• Als Textrahmen mit Text : OK

Seehr merkwürdig.

Nach Prüfung der Situation hat sich ergeben, dass der zitierte blaue Rahmen Reste einer leeren Comettextgruppe enthielt. Es konnte nicht reproduziert werden, wie dieser Platzhalter entstanden ist, aber die Liste der Produkte des Dokumentes schliesst leere Comettextgruppen-Platzhalter jetzt aus. Damit ist das Problem gelöst.

Um für eine SOAP-Verbindung über https ein Zertifikat anzugeben, muß in der Konfigurationsdatei soapflags.ini die Zertifikat-Datei angegeben werden. Das die sichere Verbindung (das s von https) inzwischen Standard ist, müßte also überall diese soapflags.ini angelegt werden.

Könnte man für die Zertifikat-Datei nicht einen Default verwenden, wenn soapflags.ini keinen entsprechenden Hinweis enthält?

Fehlt beim SOAP-Login die Datei soapflags.ini oder enthält diese Datei keinen Hinweis auf eine Zertifikats-Datei wird jetzt automatisch versucht, die Datei

$PREFS/werkii/certs.pem

zu verwenden. Weitere Hinweise finden Sie hier.

Zur Unterstützung von Web-Bildern gibt es jetzt das Plugin URLLink bzw URLLink [Server]. Es ist für alle unterstützen InDesign® Versionen verfügbar und muß installiert sein, damit die cScript-Funktionen frame::link_url, ... ausgeführt werden können.

In der aktuellen Version hat das Plugin noch keine Palette.

Für den PDF-Renderer comet_pdf ist ab jetzt ein BETA-Release der LINUX-Version verfügbar. Das Programm finden Sie im Ordner 3 bin/linux des Installationsordners von comet_pdf. Eine Kurzanleitung zur Installation finden Sie in der Datei 1 ReadMe.html des Installationsordners.

Enthält ein Seitentemplate überlappende Seitenelemente, wird die Reihenfolge der Produkte des Dokumentes falsch.

Ja. die Reihenfolge der Produkte wird aus ihrer aktuellen XY-Position und den Seitenelementen berechnet. Dabei wurde bisher immer das erste Seitenelement verwendet, in dem ein Produkt liegt. Diese Berechnung ist jetzt anders: Das Seitenelement eines Produktes (oder besser: der Cometgruppe eines Produktes) ist jetzt das Element mit dem geringsten Abstand der beiden linken oberen Ecke der Boundingbox um das Produkt.

Zusätzllich hat die Funktion frame::get_page_element einen zusätzichen optionalen Parameter erhalten, mit dem fetsgetlegt werden kann, ob das erste oder das nächste Element gefunden werden soll.

Gibt es eine Möglichkeit, XML Knoten ohne Rahmen-Referenz, in der XML-Struktur zu erstellen bzw. auszulesen? Attribute sind möglich mit "xml::get/set_document_attribute". Zu Knoten habe ich in der Doku leider nichts gefunden.

Mit run_javascript kann aus cScript heraus InDesign® Javascript ausgeführt werden. Damit sollte Ihr Vorhaben realisierbar sein.

Zusätzlich sind im neuen Release einige weitere cScript-Funktionen zur Bearbeitung der XML-Struktur von ID-Dokumenten enthalten:

• xml::add_attribute_elem
• xml::remove_attributes_elem
• xml::create_element
• xml::delete_element
• xml::path_elem
• xml::get_element_by_path

# Unknown error -10 while executig regular expression '#pragma[\s]+var'

Um den Fehler beheben zu können, wäre es schön, wenn das etwa genauer wäre.

Statt der Fehlernummern werden jetzt Fehlernamen (z.B. PCRE_ERROR_BADUTF8 statt -10)ausgegeben. Eine ausführliche Beschribung der Fehler finder Sie in der Dokumentation von PCRE.

Beim Fehler PCRE_ERROR_BADUTF8 wird zusätzlich die Textstelle des fehlerhaften UTF-8-Zeichens ins Logfile geschrieben. (Sie können diesen Fehler übrigens leicht mit der Option PCRE_NO_UTF8_CHECK in strstr et al. umgehen.)

Beim Auswerten regulärer Ausdrücke mit PCRE können laut der Doku von PCRE eine Reihe von Optionen verwendet werden. Gibt es eine Möglichkeit, diese Optionen auch über cScript zu verwenden? Hilfreich wäre insbesondere die Option PCRE_NO_UTF8_CHECK, mit der PCRE erlaubt wird, auch Nicht-UTF-Strings zu durchsuchen.

Für die Funktionen, die beim Auswerten regulärer Ausdrücke von PCRE verwendet werden, können jetzt jeweils eigene Optionen angegeben werden. Die Optionen werden in folgenden Funktionen unterstützt:

• strstr
• strstrpos
• strreplace
• string::replace (ab v4.1)
• string::find (ab v4.1)

Wenn ich in der Aufgaben-Palette "Platzhalter" und "Selektierte Rahmen" gewählt habe und auf eine Gruppe anwende, dann wird der darin enthaltene Bildplatzhalter nicht geprüft!

fxd

Bitte die Dokumentation zur Funktion dataprovider_load überarbeiten!

Die Doku von server::dataprovider_load wurde überarbeitet und ist jetzt hoffentlich besser verständlich.

Bei gruppierten Rahmen werden die Gestaltungsregeln nicht immer ausgeführt, wenn die Gruppe als Ganzes aktualisiert wird oder ein gruppiertes Template aufgebaut wird.

Ja, da ist uns tatsächlich etwas durch die Lappen gegangen. Der Fehler ist gefixt.

Ich habe ein in-Tag, in dem infos1 und infos2 definiert werden. Der Inline-Rahmen wird über die Angabe pageitemID no. definiert. leider werden die Angaben für infos1 und infos2 nicht in die Template-Rahmen übernommen. Was mache ich denn da falsch?

Das ist so auch gar nicht vorgesehen. Hier wird ja angenommen, dass alle Einstellungen bereits im Template gemacht wurden. Lediglich geladen wird das eingesetzte Template noch - dabei werden infos1 und infos2 aber nicht verändert.

Weil es ziemlich schwierig ist, nach dem Einfügen des Textes rauszufinden, welche Rahmen und Platzhalter neu sind, haben wir die Syntax des in-Tags etwas erweitert:

Mit apply_infos im in-Tag können jetzt auch beim Einfügen von Templates die Infos1 und -2 übernommen werden: 

    apply_infos int
        0 : off
        1 : nur Rahmen mit Platzhalter
        2 : alle Rahmen
        4 : Textplatzhalter

Mit apply_infos 7 werden also alle Rahmen und alle Textplatzhalter des eingefügten Templates mit den Werten aus Infos1/2 des in-Tags versehen.

Ich habe mit frame::link_url einen URLLink in einem ID-Dokument angelegt. Dann habe ich das Bild aus dem Rahmen gelöscht und versucht, das Bild erneut zu laden. Leider funktioniert das nicht. Die Prüfung des URL-Links ergibt, dass der Link okay ist.

Fehlende Bilder werden jetzt wieder als 'outdated' Link erkannt.

fxd

Ich habe mit frame::link_url einen URLLink in einem ID-Dokument angelegt. Dann habe ich das ID-Dokument auf einen anderen Rechner kopiert und dort mit document::update_url_links versucht, den Link zu aktualisieren. Aber das Bild wird nicht automatisch nachgeladen. Deshalb habe ich mit document::check_url_links geprüft, ob es überhaupt URL-Links gibt, die aktualisiert werden müßten. Leider hat diese Prüfung aber ergeben, dass gar nichts aktualisiert werden muß. Offenbar ist die Prüfung, ob es 'outdated' Links gibt, nicht richtig.

Ja, da ist bei einer nötigen Refaktorierung des Quellcodes ein kleiner aber folgenreicher Fehler passiert, der jetzt behoben ist. document::check_url_links funktioniert jetzt wieder.

Die Funktion document::check_url_links kann als Parameter zwei Listen bekommen, in die die Ergebnisse der Überprüfung eingetragen werden. Default für die Listen ist jeweils 0. Damit stürzt die Funktion ab. Erst wenn man allokierte Listen übergibt, funktioniert die Anweisung ohne Absturz.

fxd

Ich habe für einen Platzhalter eine Store-Action geschrieben, die den formatierten InDesign® Text zurückschreiben soll. Etwa so:

update mytable set mytext=<tttext> where id = <ID>

Das funktioniert. Aber wenn der Text im InDesign® Absätze enthält, entsteht beim späteren Einsetzen der so gesicherten Texte vor jedem Absatz ein zusätzlicher Softreturn.

fxd

Es kommt offenbar vor, dass Benutzer im Whiteboard Comet-Notizen der Größe 0 anlegen. In der notes.xml finden sich dann Einträge mit folgenden Werten:

bbox x="0.0" y="0.0" width="0.0" height="0.0"

Beim Versuch, diese Notizen in InDesign® zu importieren, stürzt InDesign® ab.

Solche Notizen werden jetzt in der Standardgröße 200 x 130 pt angelegt. Damit ist der Fehler plugin-seitig gefixt.

Das war ein 64-Bit-Problem bei der Umrechnung der übergebenen Variablen an die Unterfunktion. Deshalb hat das auch unter CS6 funktioniert. Der Fehler ist gefixt.

Die Offline-Doku enthielt eine Vielzahl veralteter Screenshots. Diese Screenshots sind jetzt mit InDesign CC 2017 aktualisiert worden, siehe zum Beispiel die Doku der Gestaltungsregeln. Ausserdem wurden die deutschsprachigen Screenshots der englischen Doku ersetzt durch Screenshot in Englisch.

Die Einträge der Palette "Rahmen-Etiketten" sehen merkwürdibg aus wenn sie mehrzeiligen Text enthalten - eigentlich sind in den Einträgen ja nur einzeilige Texte zu sehen, bei mehrzeiligen ragen einige Pixel der nächsten Zeile von unten nach oben heraus.

fxd

In Grafik-Tabellen-Zellen werden Bilder meist mit Rahmeneinpassungsoptionen platziert. Leider werden diese Optionen beim Einsetzen/Ersetzen von Bildern von InDesign® nicht automatisch ausgeführt, so dass nach dem Laden eines Bildplatzhalters das Bild meist falsch platziert ist. Könnte man nicht eine Gestaltungsregel machen, die die Rahmeneinpassungsoptionen anwendet?

Dafür gibt es jetzt die neue Gestaltungsregel Rahmeneinpassungsoptionen.

In der Palette Comet Admin -> Comet können Skripte, die an Dokumentrahmen hängen, ausgeführt werden. Die Palette zeigt dabei in einem Popup alle verfügbaren Skriptnamen. Leider werden die aber nicht aktualisiert, wenn ein weiteres Skript verfügbar ist (oder, in anderen Worten, wird das Attribut root.cscripts der XML-Struktur des Dokumentes verändert, sollte auch das Popup mit den Skriptnamen aktualisiert werden.

Okay, wird jetzt :-)

In der Palette Platzhalterwerte-Info könne einige Platzhaltereinstellungen auch geändert werden (ID, Name, Farbe, Klasse). Außer den Farbeinstellungen kommen die Änderungen aber nicht am Platzhalter an.

Umgedreht wird die Farbeinstellung nicht akzeptiert, wenn sie von der (großen) Platzhalterwerte-(Ohne Info)-Palette gemacht werden. Dann ändert sich die Farbe kurz und springt dann zurück auf die Farbe der Info-Palette.

Die Info-Palette ist nur (wie der Name sagt), zur reinen Info. Lediglich die Platzhalterfarbe soll hier geändert werden dürfen. So ist es jetzt auch implementiert. Die anderen Einstellungen können (mit Ausnahme des Namens, der ja im Datenpool definiert ist) über die große Platzhalterwerte-Palette geändert werden. Das Problem beim Setzen der Farbe ist behoben.

Für die Comet-Notizen können eigene Templates angelegt werden. Funktioniert sehr schön. Ein kleiner Fehler scheint aber bei der Auswertung von Freiformen unterlaufen zu sein : im Original runde Kanten werden beim Einsetzen der Notiz leider ein wenig eckig - offenbar fehlen da einige Tangenten in der eingesetzten Notiz.

Das geht jetzt richtig:

Die Prä- und Postfixtexte von Textplatzhaltern können in der Palette Platzhalterwerte konfiguriert werden. Man kann die Texte manuell eintragen oder das jeweilige Konfig-Button (Büroklammer) klicken.

Unter XML und SOAP führt die Büroklammer aber zu einem Fehler und der entsprechende Dialog zum Konfigurieren des Textes erscheint nicht.

Das ist gefixt. Der Dialog wird jetzt auch unter SOAP und XML richtig geladen:

Der Stringvergleich der Standard-Sync-Aktion -1 wird immer über die Nettoinhalte der Texte von Dokument und Datenbank des Platzhalters gemacht. Mit dem neuen Stringvergleich-Skript kann an dieser Stelle eine eigene Vergleichsmethode implementiert werden. Das ist hilfreich, wenn nachträgliche Anpassungen im Dokument erlaubt sind, aber nicht zu Einträgen in der Aufgaben-Palette führen sollen.

Mehr Informationen dazu finden Sie hier.

Mit eingeschaltetem Logfile-Schreiben wird InDesign® sehr langsam. Mit Hilfe des Mac-Terminal-Tools opensnoop haben wir außerdem festgestellt, dass viele Zugriffe auf die Logdatei offenbar gar nichts ins Log schreiben.

Man kann das Logfile-Schreiben leider nicht schneller machen. Der Sinn des Logfiles besteht ja u.A. darin, auch bei unerwarteten Situationen noch aktuell zu sein. Dazu muß immer direkt ins Log geschrieben werden, das sonst übliche Puffern des Streams kann man hier nicht verwenden.

Das Schreiben des Logfiles erfordert etwa 20-30% mehr Zeit. Im Produktivbetrieb sollte das Schreiben der Logs deaktiviert sein! Generell sollten Sie die Logfiles nur aktivieren, wenn Sie die Logs auch verwenden wollen.

Noch mehr Zeit kann das Logfileschreiben benötigen, wenn ein Virenscanner aktiviert ist. Stellen Sie auf alle Fälle sicher, dass die Logfiles im Virenscanner ausgeschlossen sind.

Leer-Aufträge an die Logfiles sind durch Anweisungen der Form wlog ("", "%s", 0) entstanden und werden jetzt verhindert.

Wir brauchen eine Möglichkeit, innerhalb eines Skriptes gemachte Dokumentänderungen wieder rückgängig zu machen. 

Mit den beiden neuen Anweisungen

document::open_sequence
document::close_sequence

geht das jetzt.

Es ist nicht möglich mittels w2ml Musterdokument die Funktion „page::masteritems_load“ zu nutzen. Die Masterelemente werden nicht gelöst.

Also, das soll heißen : Ich habe in InDesign® ein W2ML geöffnet. Auf dem so entstandenen InDesign® Dokument hat die Funktion page::masteritens:load keine Wirkung - sie stellt keine Musterseiten-Rahmen frei.

Das ist jetzt gefixt.

Nach dem Öffnen einer W2ML in InDesign® fehlen im neuen InDesign® Dokument einige Schriften.

Na da haben Sie uns ja eine harte Nuss gegeben ;).

Das Problem tritt immer dann auf, wenn die W2ML Schriften enthählt, die auf dem Rechner nicht installiert sind.

Es ist vielleicht erwartbar, dass das Probleme macht: Die Plugin-Schnittstelle von InDesign® erwartet bei der Definition von Stilen (Absatz, Zeichen) und beim Anwenden von Schriften nicht den Namen einer Schrift, sondern einen internen Index - und natürlich kann eine nicht existierende Schrift keinen Index haben.

Bei der Suche nach einem Workaround (z.B. Einsetzens eines Stückes TaggedText mit der fehlenden Schrift) sind wir auf einen schwerwiegenden InDesign® Bug gestoßen, wodurch das Dokument unwiderruflich so korrumpiert wird, dass sich die fragliche Schriftart anschließend in diesem Dokument überhaupt nie wieder verwenden lässt, auch wenn sie anschließend installiert wird.

Das Ganze haben wir Adobe gemeldet und es wird als Bug #189231547 getrackt. Bisher haben wir leider noch keine Rückmeldung. Mehr können wir an dieser Stelle leider nicht tun bis Adobe sich rührt.

Wenn derzeit Schriftarten angefordert werden, die nicht vorhanden sind, geben wir deshalb eine Warnung aus.

Achtung: Das gilt nur für Stile - wenn im Text lokal eine nicht vorhandene Schrift gesetzt ist kommt nur die InDesign® Warnung über fehlende Schriftarten.

Die cScript Funktionserver::dataprovider_load hat 2 nicht-default Parameter. Wenn man nur diese angibt wird die Funktion scheinbar nicht ausgeführt und macht dementsprechend gar nichts.

fxd

Die cScript Funktion server::dataprovider_load hat für den Parameter "search" den Defaultwert 0. Gibt man diesen explizit an stürzt InDesign® beim Aufruf ab.

fxd

Wenn mehrere Schriftarten mit dem gleichen Namen installiert sind, hängt InDesign® beim Schriftnamen ein (OTF) oder (TT) an, je nachdem woher die Schrift kommt. Beim Export und Reimport durch W2ML gehen diese Schriften dann verloren.

Na das ist mal ein kurioses Problem. Dieser Fall sollte immer nur dann auftreten, wenn zwei Schriftarten mit dem selben Namen auf dem System installiert sind (z.B. einmal als OpenType, einmal als TrueType).

Wenn beim plugin-seitigen Tabellenaufbau in der Zelle, in der eine InsertMethode ausgeführt werden soll, ein Grafikrahmen mit einem Platzhalter vorhanden ist, wird die Tabelle leer aufgebaut.

Aber schon klar, dass in den Rahmen mit automatischer Anpassung ein Feature verwendet wird, das erst seit CC2015 verfügbar ist, oder? Nämlich Tabellenzellen mit Grafikrahmen. Das wird aber von den Comet-Plugins gar nicht unterstützt. Wir sind hier noch in der Diskussion, ob wir das überhaupt machen. Die Umsetzung ist ziemlich aufwendig (Verknüpfen/Laden von Platzhaltern, Tabellen-Spaltenbreiten anpassen, diverse Skriptfunktionen, Gestaltungsregeln, PDF-Renderer, Tabellenmodul des PubServers, ...)

Für den plugin-seitigen Tabellenaufbau habe ich Grafik-Tabellenzellen jetzt implementiert. Der plugin-seitige Tabellenaufbau mit Grafik-Zellen funktioniert jetzt also.

ACHTUNG

Beachten Sie aber bitte, dass das eine isolierte Insellösung ist, die allein dieses Problem löst. Aufgabenpalette, Aktualisierung der Grahikrahmen der Tabellenzellen und andere Features der Comet-Plugins werden damit nicht funktionieren.

Es gibt seit Kurzem die Funktion frame::refpoint, was uns schon sehr gute Dienste geleistet hat, jedoch ist es in speziellen Fällen ungünstig, dass man die Werte nur relativ zur Seite erhält. Es wäre super, wenn es wie bei den bbox-Funktionen auch den Parameter für "spreadRelative" geben würde. 

Die Funktion hat jetzt einen zusätzlichen Parameter, mit dem die X-Koordinate auch spread-relativ geholt werden kann.

Der W2MLImport verwirft Schriftarten mit zusätzlichem Scjriftschnitt (z.B. Helvetica Neue 65 Medium) und ersetzt sie durch die Standardschriftart.

fxd

Wir versuchen in einem Aufbauskript Rahmen die unabhängig vom Produkt sein sollen anzulegen. Sie werden aber immer der Cometgruppe zugeordnet und können nicht entfernet werden.

Aus der Verwendung des Aufbauhilfe-Skriptes schließen wir, dass das Ganze im Produktaufbau gemacht wird. Der Produktaufbau faßt aber am Ende des Aufbaus eines Produktes ALLE Rahmen des Produktes zu einer Cometgruppe zusammen. Das ist Teil der Implementierung des Produktaufbaus und kann ohne Einschränkungen an der Seiten-Reorgansation nicht geändert werden.

Das Entfernen von Rahmen aus wie auch immer bestehenden Cometgruppen während das Produktaufbaus löst den Rahmen also nicht dauerhaft aus der Produkt-Cometgruppe.

Lösung

Das Aufbauhilfe-Skript bietet jetzt eine weitere Situation zur Bearbeitung der Produktrahmen an:

    kProductFinished

In dieser Situation ist die finale Produkt-Cometgruppe fertig und ein Aufruf von frame::remove_from_cometgroup kann Rahmen bleibend von der Produkt-Cometgruppe entfernen.

ABER ACHTUNG: Die so geänderten Produkte führen zu Fehlern bei  Seitenreorganisationen.

Mit dem Befehl document::export_ und der Zielvorgabe "package" können Dokumente verpackt werden. Das funktioniert aber nur, wenn das Dokument bereits mind. einmal gesichert war - also einen Pfad hat. Bei neuen ungesicherten Dokumenten liefert der Befehl einen Fehler. Das passiert insbesondere dann, wenn ein Dokument mit einem neueren InDesign® geöffnet wurde.

fxd.

Bilder in InDesign® müssen entweder im lokalen Netz vorhanden sein oder ins Dokument eingebettet werden. Beides hat natürlich seine Nachteile:, wenn Dokumente im Netzt bearbeitet werden sollen: Entweder erreichen Sie mglw. die Bilddateien nicht mehr oder die eingebetteten Bilder sind nicht mehr immer aktuell.

Zur Lösung des Problemes können die priint:comet Plugins URL-Bilder jetzt so laden, dass die Bilder ihren Bezug zur Originaldatei nicht verlieren und bei Bedarf über die URL aktualisiert werden können. Um zu ermitteln, ob ein Bild noch aktuell ist, wird mit Hilfe der URL nur ein sehr kurzer Statusbericht vom Server angefordert.

Mehr Informationen dazu finden Sie hier.

Das folgende Skript versucht den Inhalt eines Textrahmens zu lesen. Ist das eine gültige URL, wird das entsprechende Bild geladen und verlinkt. Bei weiteren Aufrufen des Skriptes wird das Bild nur dann aktualisiert, wenn sich das Bild am Server geändert hat. Mit gehaltener SHIFT-Taste können Sie dieses Bild prüfen, ohne neu zu laden. Gültige URLs erhalten Sie mit Rechts-Klick auf ein Bild in fast jedem Internet-Browser.

int main ()
{
	String 	str = string::alloc ();

	if (!system::shiftkey ())
	{
		frame::gettext (gFrame, str);        
		frame::image_url (gFrame, string::get (str), 9, 0.0);
	}
	else
	{
		frame::check_image_url (gFrame);
	}


	return 0;
}

Gibt es eine einfache Möglichkeit, nach einem Platzhalter der bis zum Textende geht, noch weiteren Text anzufügen. Stellt man den Cursor an die letzte Position des Textrahmens, wird jeder Text den man eingibt automatisch zum Teil des Platzhalters.

Das Verhalten ist analog jeder anderen Texteigenschaft: Ist letzte Zeichen eines Textes z.B. rot, wird auch jedes Zeichen, das man dahinter schreibt, rot. 

Mit dem Menü Bearbeiten -> Einfügen ohne Platzhalter bekommt man aber einfach Zeichen hinter den letzten Platzhalter. Wenn man sich da noch ein Tastatur-Kürzel drauflegt ...

Das Verhalten ist grundsätzlich nachvollziehbar, aber kleine Unterschiede gibt es dennoch.

Ausgangssituation: Ein Text-Platzhalter ist am gesamten Text.

Will man nun beispielsweise einen weiteren Text-Platzhalter hinzufügen, muss man entweder den vorherigen Platzhalter völlig entfernen und neu zuweisen oder man muss "Einfügen ohne Platzhalter" verwenden (was aber voraussetzt, dass man diese Funktion kennen muss).

Wie ich das erste Mal diese Problemstellung hatte, war mein erster Gedanke, in der Platzhalter-Palette nachzusehen, welche Möglichkeiten man dort hat. Könnte man vielleicht in der Platzhalter-Palette, eine Funktion hinzufügen, dass man einen Platzhalter nur auf die derzeitige Selektion anwendet oder entfernt. Wenn man z.B. mit Shift+Klick einen Platzhalter wählt?

Klar gibt es kleine Unterschiede. Einen Text einzufärben ist ja grundsätzlich etwas anderes, als den Text darauf vorzubereiten, sich (gewissermaßen selbstständig) zu verändern. Ein Unterbruch der Platzhaltereigenschaft würde ja auch eine Multiplikation des Textes bedeuten, wenn der Platzhalter geladen wird.

Wir haben dennoch jetzt eine Möglichkeit vorgesehen, Platzhalter direkt über die Palette "Platzhalter" zu trennen. Die Shift-Taste freilich eignet sich dazu nicht: Mit gehaltener Shift-Taste wird nämlich auch die Listenauswahl verändert.

Platzhalter ausschließlich über der aktuellen Textauswahl zu ändern, geht jetzt mit folgenden Zusatztasten:

Mac : CTRL
Windows : ALT GR

In beiden Fällen wird dabei zusätzlich das automatische Laden des geänderten Platzhalters unterdrückt.

Der Hinweis auf die Zusatztasten steht auch im Hilfetext der Platzhalter.

Ich habe die Aufgabe, einen Umbruch auf eine neue Seite zu erzeugen, sofern die Daten des Produktaufbaues aus einer neuen Parent-Id kommen. Das habe ich soweit umgesetzt. Die Produkte wandern tatsächlich an der gewünschten Stelle auf eine neue Seite. Allerding sieht es so aus, als würde die passende Masterpage nicht geladen werden.

Hier der relevante Ausschnitt aus dem C-Skript:

if(PageBreak != -1)
{
    p = product::alloc(kGlobalStack);
    product::set (p, kProductType, 4);
    product::set (p, kID, PageTemplateID);
    product::set (p, kMasterpage, "A-Master");
    productlist::append(pl2,p);
}

Das Problem ist gelöst. Die Musterseiten werden jetzt richtig gesetzt.

Bei Doppelklick auf einen Eintrag der Rahmen-Etiketten öffnet sich ein Dialog-Fenster in dem Schlüssel und Wert editiert werden. Aber wie bekommt man dieses Fenster wieder zu? Die Buttons "Okay" und "Abbruch" funktionieren auf dem Mac leider nicht.

Das Problem tritt nur dann auf, wenn der Wert-Text einen Scrollbalken hat UND der Textcursor in diesem Feld steht. Dann schlägt offenbar ein InDesign® Bug zu: Der (unsichtbare) Scrollteil des Textes liegt über den Buttons und nimmt alle Maus-Klicks weg.

Um das Problem zu umgehen (beheben kann das nur Adobe), haben wir die Buttons jetzt neben den Text gelegt. Dann geht alles wieder.

Workaround

Das obere Textfeld für den Schlüssel auswählen.

Das geht jetzt.

Ausführen vom Paletten- oder Frontrow-Skripten werden leider die Rahmen eingebetteter Bilder nicht mit bearbeitet.

Damit der Aufruf von frame::embed_image funktioniert, muß man vorher mit einen Aufruf von frame::remove_image das enthaltene Bild löschen. Sonst funktioniert der Aufruf leider nicht. Aber dann kann ich natürlich kPlaceLikeExisting nicht mehr verwenden.

Die Anweisung stellt jetzt die aktuellen Werte der Bildplatzierung wieder her. Damit ist das Problem gelöst.

Uns ist aufgefallen, dass SOAP-Verbindungen sehr viel langsamer geworden sind.

Nach Tests mit älteren Releases konnten wir feststellen, dass dieses Verhalten seit v4.0.5 R14303 (Weihnachten 2016) besteht - aber offenbar niemandem wirklich aufgefallen ist. Das Problem tritt sowohl unter Windows als auch unter Mac auf und verlangsamt SOAP-Verbinungen um das Zwei- bis Dreifache.

Das Problem ist behoben.

Achtung: Der in v4.0.5 R14303 gemachte Fix ist damit unwirksam. Um den alten Fix wieder zu aktivieren, muß in soapflags.ini die Zeile

    keep-alive=no

eingefügt werden. Weitere Infos dazu finden Sie hier.

Mit itemlist::move_to kann ich Rahmen auf eine neue Seite verschieben. Dabei gehen leider die Cometgruppen der Rahmen kaputt. Deshalb wollte ich itemlist::move_cometgroup_to verwenden, aber da passiert leider das Gleiche.

Gefixt. Die Cometgruppe wird jetzt nach erfolgreichem Verschieben auf eine neue Seite wiederhergestellt.

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

Ich habe einen Textplatzhalter, der den kompletten Textrahmen, in dem er selbst enthalten ist, löscht und durch andere Rahmen ersetzt. Wird dieser Platzhalter geladen, stürzt InDesign® ab.

Nun, das ist vielleicht wenig überraschend. Da wäre etwa die Stelle, die den Status des Platzhalters nach dem Laden aktualisiert und jetzt den Platzhalter gar nicht mehr findet, d.h., gesucht wird aus Performance-Gründen natürlich nicht, den Platzhalter merkt man sich vor dem Laden - aber dann ist er gar nicht mehr da.

Wir können aber die Existenz nach dem Skript prüfen und bei Nichtgefallen die ganze Aktion abbrechen. Damit ist das Problem gelöst. -fxd-

Wir stoßen derzeit auf das Problem, dass unser japanischer Partner auf MAC-Maschinen arbeitet. Dieser versucht nun das Placeholder Panel zu nutzen und einen Placeholder zu platzieren. Hier kriegt er aber eine Fehlermeldung und der Client stürzt ab.

Der Fehler trat beim Umrechnen von Text in Großbuchstaben auf. Japanisch hat zwar keine Groß- und Kleinschreibung, trotzdem kann beliebiger Text natürlich immr auch nicht-japanische Zeichen enthalten. Wir haben die Funktionen zum Umrechnen in Klein- und Großbuchstaben etwas geändert und der Fehler sollte jetzt nicht mehr auftreten.

Im TaggedText enthaltene <outw2:>-Tags werden beim Einsetzen über frame::insert etc. nicht angewendet.

fxd.

ACHTUNG

Das outw2 kann nur importiert werden, wenn die Einstellung 

Menü Zusatzmodule -> Comet -> Platzhalter aus TaggedText anlegen

aktiviert ist oder der Skriptbefehl prefs::set_tags_readable (1) irgendwann vorher ausgeführt wurde.

Wenn man über die Palette die Testresultate eines Comet Tests löscht, bleiben die Differenzbilder übrig.

fxd

Wenn ein Comet Tests fehlschlägt weil die Spreads unterschiedlich aussehen, wird derzeit nur ein Differenzbild des ersten unterschiedlichen Spreads erzeugt. Wenn man alle Differenzbilder erzeugte, würde dass die Fehlersuche vereinfachen.

Es werden jetzt alle Spreads verglichen und Differenzbilder erzeugt wenn nötig.

Comet Test Proofdaten und Testergebnisse (also die Bilder) sollten für jede InDesign® Version in einzelne Unterordner gespeichert werden.

Proofdaten und Testdaten werden jetzt in eigene Unterordner entsprechend der InDesign® Version abgelegt.

Beim Vergleich werden dazu zuerst die passenden Proofdaten gesucht, und wenn diese nicht gefunden werden wird auf die nächst ältere Version zurückgegegriffen. Mehr dazu in der Doku.

Es wäre schön, wenn man Comet Test Definitionen nicht nur aus einer XML Datei importieren, sondern auch in eine XML Datei exportieren könnte.

Es gibt einen neuen Knopf unten auf der Palette der die ausgewählten Tests in eine XML Datei exportiert. Die Hierarchie bleibt dabei erhalten.

Wenn Testdomänen selektiert sind, werden alle Unterknoten ebenfalls exportiert.

Es wäre toll wenn man an jeden Comet Test (und vielleicht auch an die Testdomänen) einen Beschreibungstext anfügen könnte.

Die Beschreibung eines Comet Tests lässt sich jetzt in dem Dialog zum Test editieren und erstellen festlegen.

Außerdem wurde der Tooltip geändert, der erscheint wenn man mit der Maus über einen Test fährt - er zeigt jetzt die Testbeschreibung anstatt der Pfade zu den Scriptdateien.

Wenn man in der Palette Comet Tests einen Test oder eine Domäne editiert wird der zugehörige Eintrag im Baum nicht richtig upgedated (wenn man z.B. den Namen ändert)

fxd

Die Definitionen der Comet Tests kann jetzt aus einer beliebigen XML Datei geladen werden. Dazu gibt es auf der Palette die Möglichkeit, eine andere XML Datei als Datenquelle anzugeben. Mehr dazu in der Comet Tests Dokumentation.

Bei den Funktionen zum Hinzufügen von Ebenen (layer::add, etc.) gibt es den Parameter "before". Laut Doku sagt er aus, dass die angegebene Ebene zur Hintergrundebene der neuen Ebene wird. Sinngemäß heißt das für mich, dass dann die neue Ebene ÜBER der bestehenden Ebene liegt. Dem ist aber nicht so.

Das Ganze ist an der Stelle ein Fehler in der Dokumentation. Intern verwendet layer::add die Funktion layer::move um die neue Position in der Liste zu bestimmen. Die Dokumentation von layer::move beschreibt den Parameter wie folgt: "Name der Ebene, unter der die Ebene liegen soll."

Wir haben uns intern darauf geeinigt die Dokumentation zu korrigieren und nicht die Funktion selbst, um Kompatibilität für bestehende Scripte die diese Funktion verwenden zu gewährleisten.

Mit installierten Comet Plugins R>=18339 braucht InDesign® CS6 auf Windows extrem lang zum starten (mehr als fünf Minuten)

fxd

Wir können keine IDML schreiben, wenn das Plugin von iComet installiert ist., InDD stürzt ab. Nur wenn das Plugin entfernt wird, funktioniert es. Gibt es da eine Lösung?

Ja, wir können das (leider) reproduzieren. Der Fehler tritt nur in CC2017 auf dem Mac auf. In Vorgängerversionen funktioniert der IDML-Export. Der Absturz passiert, wie im Crash-Log ersichtlich, im Plugin EmbeddedLink. Dieses Plugin ist für die InDesign® seitige Bereitstellung und Implementierung der priint:comet Platzhalterobjekte zuständig.

Die (ziemlich aufwendige) Suche nach dem Problem ergab, dass es sich offenbar um einen Fehler in der Code-Optimierung des verwendeten Compilers (Apple LLVM 7.1 mit Xcode 7) handelt. Standard für die Plugins ist (von Adobe vorgegeben) die Einstellung Fastest [-O3]. Stell man die Optimierung ab (None [-O0]), funktioniert der IDML-Export wieder wie bisher (und nur das Plugin wird etwas größer) - und der Rest der Funktionalität bleibt unverändert (jedenfalls in den Tests, die wir machen konnten). 

In einer SOAP-Verbindung, die aufgezeichnete Daten verwendet (Login mit Datenablage "Verwenden") wird ein SOAP putBinaryFile gemacht. Dabei stürzt InDesign® ab. Die letzte Zeile im Log ist 

# Attempt to upload file 'toc.xml' (application/xml) as '[pubserver]/toc.xml'

Der Upload kann natürlich nicht funktionieren, klar. Aber zum Absturz muß das natürlich nicht gleich führen. Ignorieren der Anweisung wäre auch genug. So wird es jetzt gemacht. Upload-Anfragen werden ignoriert und schreiben ins Log lediglich die folg. Meldung:

# IGNORE SOAP UPLOADS IN PLAYBACK SESSIONS! 

Damit ist der Absturz behoben.

FogBugx 20310 - Nächstes Format greift nicht

Die Auto-Korrektur fehlender oder leerer Absatzstile in TaggedText wurde erweitert:

• Absatzstile von Folgeabsätzen
• Geschachelte Tabellen

Weitere Informationen dazu finden Sie hier.

Es wurde eine weitere Situation gefunden, in der Kopfzeilen von Tabellen fehlen: Immer dann, wenn die Tabelle über mehrere Textrahmen geht UND die Textkette über mehrere Seiten, fehlen in den Rahmen der ERSTEN Seite die Kopfzeilen.

Aaarghh. Und Adobe rührt sich nicht mit dem Fix. Aber wir konnten auch für dieses Problem einen Workaround finden.

FogBugx 20331 - Produktaufbau : Im N:1 - Element ein Produkt "vorschalten"

internal hint : see also 20137 and 20332

Wie könnte ich in den Produktaufbau bei  Kapitelwechseln automatisch zusätzliche Templates als Trenner einsetzen? Zusätzich soll das aktuelle Kapitel am Anfang jeder Seite in einem Template dargestellt werden.

Die Kapitelwechsel kann ich mit einem Aufbau-Prescript erledigen. Das geht. Aber die Seitenumbrüche kenne ich ja leider nicht.

Ja, in der Tat, ein kniffliges Problem.

Der Produduktaufbau bietet daher jetzt die Möglichkeit sog. Produkt-Trailer an. Produkt-Trailer sind normale Templates, die im Aufbauhilfe-Skript angelegt werden können und von Aufbau und Reorganisation verwaltet werden. Mehr dazu steht hier.

Hier zwei Screenshots. Die roten Trennlinien werden dabei von der Aufbauhilfe erzeugt. Im zweiten Screenshot wurde zwischen zweitem und dritten Produkt manuell ein Produkt eines anderes Kapitels platziert.

Der Produktaufbau stürzt hin und wieder beim Ausrichten von Inhalten von  N:1-Elementenl ( z.B. beim horizontaler Keil ) ab. Schalte ich die Ausrichtung im Seitenelement ab, funktioniert alles.

Und sicher ist beim Abschalten der Justierung aufgefallen, dass das immer dann passierte, wenn das Element nur eine Spalte bzw. Zeile Produkte enthielt. Den Rest kann man sich wahrscheinlich denken - eine Division durch 0. Das ist gefixt.

Diverse Tooltips in Templates und Template-Verhalten nicht vollständig sichtbar.

Ja. Leider können wir da aber nicht vile unternehmen - InDesign® schneidet diese Texte einfach ab. Das ist sehr mißlich.

Wir haben die Texte entsprechend gekürzt.

In der Produktrecherche sind einige Hilfetexte der (früher gelben, jetzt grauen) Tooltips nicht vollständig lesbar. Besonders die Hinweise zum Drag and Drop von Produkten wären aber ganz hilfreich.

Ja. Leider können wir da aber nicht vile unternehmen - InDesign® schneidet diese Texte einfach ab. Das ist sehr mißlich. Wir haben die Texte deshalb in die Werkzeughinweise aufgenommen (und im Tooltip einen entsprechenden Hinweis einegefügt). So kann man die Hinweise jetzt lesen:

Menü : Fenster -> Hilfsprogramme ->Werkzeughinweise

Bei aktiviertem Auswahlwerkzeug (schwarzer Pfeil) werden auch die Hinweise zur Produktrecherche gezeigt.

Gedrehte Rahmen in Produkten führen zu Fehlern bei der Reorganisation:

Gedrehte Rahmen, deren Template-Verhalten so eingestellt ist, dass bei Reorganisationen die Originalgröße aus dem Template wieder hergestellt wird (ungefülltes Dreieck als Fortsetzungs-Eigenschaft) können dabei so groß werden, dass kein passendes Seitenelement gefunden werden kann und die Reorganisation abbricht.

Zur Berechnung der Größendifferenz zwischen aktueller und gewünschter Größe wurde hier fälschlicherweise die BoundingBox um den gedrehten Rahmen und nicht die tatsächliche Größe verwendet. Das ist gefixt. 

Die cScript Funktion bookmark::create hat 5 nicht-default Parameter, funktioniert aber nur wenn man mindestens 6 angibt.

Gilt auch für bookmark::create2 (4 nicht-default Parameter, man muss mindestens 5 angeben).

fxd

Die cScript Funktion book::export_ funktioniert nicht, auch wenn alle Parameter richtig sind.

fxd

Die cScript Funktion interactive::get_task_data stürzt ab,  sobald man mindestens einen der Parameter ival angibt.

Das war ein Fehler in der Dokumentation - die Parameter ival und sval waren vertauscht.

In den Beispielen der cScript-Doku sind die verwendenten Funktionsaufrufe leider nur ganz selten als HTML-Links gestaltet.

In den Beispielen werden verwendete cScript-Funkionen jetzt als HTML-Links angelegt. Außerdem werden Kommentare und "Strings" in den Beipielen gefärbt. Das sollte die Lesbarkeit um einiges verbessern.

In der cScript-Doku werden Worte, die es auch als Funkionsnamen gibt mit einem Link versehen. So sind in den englischen Dokus alle Worte wie document, boook, page, pages, now, ... HTML-Links .

Das haben wir mit einer korrigierten Version des Programmes, das unsere cScript-Doku erzeugt, geändert. Diese Worte werden jetzt nicht mehr als HTML-Links ausgeführt.

Im Logfile steht direkt bevor der Produktaufbau beginnt, folgende Zeile 

# List of pagetemplates and products

Aber dann folgt nicht die Liste sondern der Beginn des Aufbaus.

Jetzt nicht mehr. Vorher wird die Liste der aufzubauenden Produkte jetzt auch wirklich ins Log geschrieben.

In Previews von Templates geht die Transparenz von Rahmen verloren.

fxd. Hier ein Screenshot eines Templates vor und nach der Fehlerkorrektur.

Ich verwende in der Produktrecherche eigene PNGs:

ImagePath : "$DESKTOP/Bilder/' || ID || '.png"

Sind diese Bilder größer als die Icons der Palette, werden sie nicht skaliert, sondern der unskalierte mittlere Bildausschnitt gezeigt. Bei JPGs und anderen Bildern wird dagegen skaliert.

fxd. Auch PNGs werden jetzt bei Bedarf skaliert.

Vorher

Nachher

Wir haben durchweg Performance Probleme bei SOAP/Pubserver mit der Produktrecherche. Sobald Ergebnisse aufgelistet sind, reagiert die Produktrecherche extrem träge. Fenstergrößenänderungen, Verschieben der Spalten und Scrollen sind betroffen. Woran könnte das liegen. Bei MySQL-Projekten habe ich so etwas noch nicht beobachtet.

Die Untersuchung des Problemes ergab, dass hier eigene Produkt-Icons in der Palette verwendet wurde, die über HTTP bzw. SOAP geladen werden sollten. Leider waren die Bilder aber nicht verfügbar, wurden aber bei jedem Neuzeichnen der Listneinträge neu erfragt.

Wir haben das Verhalten beim Laden externer Bilder jetzt geändert : Es wird jeweils nur EIN Versuch unternommen, das Bild zu laden. Damit sollte die Palette jetzt wesentlich schneller auf Redraws reagieren.

Die cScript Funktion xmlquery::serialize kann unter bestimmten Umständen nicht den eigentlichen Zielstring buffer zurückgeben, sondern einen Fehlercode, nämlich immer dann wenn das XML String schreiben fehlschlägt.

Das führt dann bei Verwendung des Ergebnisses natürlich schnell zum Absturz.

fxd

Die cScript Funktion xmlquery::serialize bringt man folgendermaßen zum Absturz:

int main () 	
{	
	char 	* 	out 	= alloc(8192);	
	XMLTree 	tree 	= 0;	
	
	tree = xmlquery::open("C:/temp/aaa/connections.xml");	
	xmlquery::serialize(tree, out);	
	wlog("", out);	
	xmlquery::close(tree);
	
	return 0;	
}

 An sich doch alles richtig, oder (die XML Datei existiert und ist richtig)?

Das Problem an diesem Script war, dass der XML Baum zwar geöffnet wurde, aber noch nicht geladen. Das passiert erst nach einem Aufruf nach xmlquery::exec. Ein Griff auf die Daten erzeugt dann die bekannte NullPointerException.

Ab jetzt lädt xmlquery::open auch den Baum direkt.

Außerdem wird der Absturz durch eine zusätzliche Überprüfung in xmlquery::serialize abgefangen.

Die cScript Funktion xmlquery::process stürzt ab, wenn man ungültige Angaben zu den Parametern "destinationPath" und "definitionPath" macht.

Muss denn das sein?

Nein, dass muss natürlich nicht sein. In diesem Fall gibt die Funktion jetzt wie in der Doku angegeben 0 zurück.

Die cScript Funktion server::load_table_ids stürzt ab, wenn man KeyValue Paare zum Überschrieben der Standard-Ersetzungen, als Parameter angibt.

fxd

fxd

Immer wenn ich neue Plugins installiert habe, ist die Templates-Palette so klein, dass sie keinen einzigen Eintrag zeigen kann.

Die Palette kann jetzt nur bis zu mindestens drei Listeneinträgen verkleinert werden. das ist dann auch nach Neuinstallation schon so.

Das Laden der Einträge der Templates-Palette dauert ziemlich lange.

Wir konnten die Lade-Zeit deutlich verringern. In beiden Testfällen (ODBC und XML-Offline) konnten wir die Ladezeiten von jeweils 15-20 auf etwa 1-2 Sekunden verkürzen.

Sortierfähige Listen, die Einträge mit Umlauten enthalten, sortieren diese Einträge leider falsch ein.

Zum Sortieren werden jetzt die deutschen Regeln für alphabetische Sortierung verwendet. Das betrifft die folgenden Listen:

• Gestaltungsregeln : Parameter mit @LOADLIST
• Platzhalter-Palette : Domains, Bereiche, Platzhalter
• Aufgaben-Palette
• Comet-Notizen
• Produktrecherche : Popup der Templates
• Templates
• Seitentemplates
• Tabellenmodul : Gruppenzugehörigkeiten

Wenn ich in der Templates-Palette nach alle Templates suche, die mit a beginnen, werden (wie erwartet) sämtliche Templates gefunden, die mit a oder A beginnen.

Wenn ich z.B. nach ü suche, dann wird auf dem Mac gar nichts gefunden und unter Windows nur die Templates, die tatsächlich mit Klein-ü beginnen. Der Eintrag "Übung" z.B. wird aber nie gefunden.

Der Fehler war in der internen Funktion zum Umrechnen von Strings in Großbuchstaben und ist jetzt gefixt. Der Fix betrifft natürlich auch alle anderen Anweisungen, adie Case-Insesitive Suchen vorbereiten. (z.B. in der Produktrecherche).

In 1:N-Seitenelementen kann der horizontale und vertikale Mindestabstand zwischen sden Produkten eingestellt werden. Ist der X-Abstand 0, wird nur nur eine Spalte im Element gefüllt, dann geht es zum nächsten Seitenelement weiter. Ist der Y-Abstand 0, wird überhaupt nur ein Produkt in das Element gebaut.

Das ist gefixt. (Erstaunlich, wie lange sich einige Fehler halten. Dieser hier war von Angang an dabei.)

Wird ein Template in die Palette aufgenommen, bei dem die ID gleich dem Wert der TypeID ist, dann wird dieses Template nicht in der Template-Palette angezeigt. Dieses Verhalten tritt ab dem Plug-In 16511 auf.

fxd. Templates, deren ID gleich ihrer Domain- oder Typ-ID ist, werden jetzt wieder richtig angezeigt.

Die cScript Funktion linklist::insert ignoriert scheinbar den StringID Parameter:

int main ()
{
		Link 		lnk;
		LinkList 	lli 	= linklist::alloc(2);

		linklist::insert(lli, 3, 1, 1, 1, -1, "BLUE");
		lnk = linklist::get(lli, 0);
		showmessage(link::sid(lnk)); //Leerstring
		
		return 0;
}

int main () 
{
	Link 		lnk;
	LinkList 	lli 	= linklist::alloc(2);

	linklist::insert2(lli, 3, 1, 1, 1, "BLUE");
	lnk = linklist::get(lli, 0);
	showmessage(link::sid(lnk));	//Zeigt "BLUE"
	
	return 0;
}

fxd

Die cScript Funktion frame::get_layer kann unter bestimmten Umständen einen anderen Zeiger zurückgeben als auf den Eingabeparameter name , nämlich dann wenn der Eingaberahmen nicht gültig ist.

In diesem Fall zeigt der Returnwert auf einen statischen char*, was zu Problemen führen kann.

fxd

InDesign® CC2017.1 zeichnet leider die Kopf- und Fußzeilen von neuen Tabellen nicht. Erst nach Größenänderungen des Rahmens oder passenden Änderungen der Tabelle werden diese Zeilen gezeichnet.

Das ist ein Fehler von InDesign® (Adobe Bugnummer  ID-4201582). Wir können da, außer drängen und warten) auch nicht viel machen.

Leider tritt der Fehler auch in allen Zusammenhängen mit neuen Tabellen auf:

• Copy/Paste der Textrahmen

• Snippet-Export/Import deer Textrahmen

• Einfügen von Tabellen mit TaggedText

• Copy/Paste der Tabelle

Lediglich der Menübefehl Tabelle -> Tabelle erstellen... funktioniert richtig.

Das Ganze ist natürlich ziemlich schlimm für die Comet-Plugins, sowohl bei TaggedText als auch bei Verwendung von Templates. Wir haben deshalb versucht, irgendeine Art von Workaound zu finden. Und das ist uns gelungen. Kopf- und Fußzeilen von Tabellen werden jetzt in folgenden Zusammenhängen auch in CC2017.1 richtig dargestellt:

• Sichern von Templates

• Verwenden von Template (direkt und beim Produktaufbau)

• Einsetzen von TaggedText

An den anderen Situationen können wir freilich nichts ändern.

TaggedText für Tabellen benötigt zur richtigen Darstellung der Zellinhalte eiin zum Zellstill passendes <ParaStyle:pstyle_of_cstyle>. Leider fehlt das in den Texten, die die Plugins bekommen häufig. Mit der Angabe von autoFillCellParastyles>0 in den Funktionen textmodel::insert et. al. können die Plugins deshalb die fehlenden Absatzstile automatisch einfügen (siehe auch Fall 16548).

Das klappt aber nur dann, wenn auch ein Zellstil angegeben ist. Leider ist das aber nicht so häufig der Fal und häufig auch gar nicht wünschenswert:

• Ist kein Zellstil angegeben, wird der Zellstil aus dem Tabellenstil ermittelt. In der Palette Zellstile wird aber "Kein Stil" angezeigt.

• Ist ein Zellstil angegeben, wird der natürlich verwendet bleibtaber  auch dann erhalten, wenn der Tabellenstil später geändert werden sollte.

Gibt es eine Möglichkeit, dass beim Einsetzen der Absatzstile auch bei fehlenden Zellstilen der richtige Absatzstil gefunden wird?

Prinzipiell ist es natürlich möglich, den Zellstil einer Tabellenzelle aus Tabellenstil und Zellindex zu bestimmen. (Der Zellindex ist wichtig zur Bestimmung, ob eine Zelle Kopf-, Fuß- oder Body-Zelle ist oder in der linken/rechten Spalte einer Tabelle liegt.)

Das machen die Plugins jetzt automatisch, wenn autoFillCellParastyles>0 ist oder der TaggedText mit %?TT bzw. %%TT anfängt.

Die Klasse rect bietet keine Funktion, dass man Breite oder Höhe direkt ausliest. Man muss immer right - left bzw. bottom - top rechnen. rect::set_width und rect:set_height gibt es aber.

Es wär also super, wenn es beispielsweise die Funktionen rect::width und rect::height geben würde.

Diese beiden Funktionen gibt es jetzt.

Die cScript Funktion page::templates::get_info gibt immer einen Fehler zurück und liefert kein Ergebnis.

fxd

Die cScript Funktion xml::path hat 4 Parameter. Zwei davon sind default Parameter, jedoch funktioniert die Funktion nur richtig wenn alle 4 Parameter explizit angegeben sind. Ansonsten gibt die Funktion immer parameterMissingErr zurück.

fxd

Die cScript Funktion layer::add_prefixed und layer::add_prefixed_i funktionieren nicht, egal welche Parameter gegeben sind.

fxd

Verwendet man product::copy so wie es in der Doku steht bekommt man ein leeres Produkt für destination. Tauscht man die Argumente ist alles ok. Hier stimmt also die Doku nicht.

Die Beschfreibung in der Doku ist jetzt richtig.

Scheinbar werden die Parameter "info1" und "info" der cScript Funktion itemlist::masteritems nicht ausgewertet.

fxd

Es kommt immer wieder vor, dass in der Produktrecherche mehrere Einträge ausgewählt sind, obwohl im Dokument nur ein einziger Rahmen selektiiert ist. Scrollt man die Liste ein wenig oder verändert die Palettengröße, verschwindet die überflüssige Markierung.

Der Fehler tritt jedesmal auf, wenn der neu ausgewählte Eintrag bisher unsichtbar war und erst in den sichtbaren Bereich gescrollt werden muß. Es handelt sich offenbar im ein reines Darstellungsproblem in den InDesign® Listen. In den CC-Versionen von InDesign® tritt das Problem nicht auf, nur in CS6. Dort aber auf Mac und Windows und unabhängig von der Betriebssystem-Version. 

Der Fehler liegt in der Implementierung von Paletten-Listen in InDesign®. Wir konnten aber einen Workaround finden und das Problem damit fixen. Scheinbare Doppelmarkierungen in der Produktrecherche (und an allen anderen 102 (!!) Stellen) sollten dann auch in CS6 nicht mehr auftreten. 

In unserem Projekt nutzen wird die document::has_overset-Funktion, um nach dem Aufbau die Übersatztexte auf einer eigenen Ebene zu markieren. Dabei ist uns aufgefallen, dass bei Tabellen nicht alle Übersätze geliefert werden.

Auf dem langen Weg vom Skript bis zur eigentlichen Overset-Prüfung hab ich an einer Stelle Zeilenindex und Spaltenindex vertauscht. Das ist dann gefixt.

Sollte sich beim Dokumentenwechsel zu einem Dokument, das über die Publikation-Palette ausgebucht wurde, nicht auch die Auswahl in der Palette entsprechend ändern?

Das tut sie jetzt.

Wir haben in unseren aufgebauten Dokumenten Cometgruppen, die InDesign® Gruppen enthalten. Wie kann denn das passiert sein. Wenn ich die Cometgruppen manuell mit Rechtlich und "Cometgrupre -> Erzeugen" anlege, werden die InDesign® Gruppen automatisch rekursiv aufgelöst und statt der InDesign® Gruppen die Rahmen der Gruppen in die Cometgruppe eingefügt.

Das Problem dabei ist, dass dann beim Suchen nach einem Rahmen einer bestimmten Kennung Rahmen nicht gefunden werden, wenn sie InDesign® gruppiert sind.

InDesign® Gruppen sollten eigentlich NICHT Teil von Cometgruppen sein. Das ist ein Plugin-Fehler. Dieser Fehler tritt in zwei Fällen auf: 

1. Aufbau wiederholender Elemente : Das wiederholte Element enthält InDesign® Gruppen

2. Menu Comet-Gruppen -> Rahmen zu Gruppe hinzufügen : Der hinzuzufügende Rahmen ist eine Gruppe

Diese Fehler sind gefixt. InDesign® Gruppen werden jetzt nicht mehr zu Teilen von Cometgruppen (aber die Rahmen der InDesign® Gruppe schon).

Eine Cometgrupre besteht aus drei Rahmen. Zwei dieser Rahmen sind zusätzlich als InDesign® Gruppe zusammengefasst. Verschiebe ich den einzelnen Rahmen, wird die Cometgruppe wieder neu gezeichnet. Aber wenn ich die InDesign® Gruppe verschiebe, wird die Cometgruppe nicht neu gezeichnet.

Ein Darstellungsproblem - natürlich. 

fxd

Verwendet ein Textplatzhalter in einer Tabellenzelle den Aufruf table::cell::clear, um sich selbst zu löschen, stürzt InDesign® reproduzierbar ab.

Ein gewagtes Unterfangen ... Aber gut, auch das geht jetzt.

Kann man mit cScript die Referenzpunkte eines Rahmens erfragen? Besonders bei gedrehten Rahmen ist dafür ja eine ganze Menge sin/cos-Rechnerei nötig.

Dafür gibt es jetzt die schöne neue Funktion frame::refpoint.

In der Aufgaben-Palette kann man sich die ToDos einer SEITE ansehen, geht auch Druckbogen?

Ab jetzt : Ja.

Im <in>-Tag kann mit clippath ein Freistellpfad für das Bild angegeben werden. Das funktioniert auch gut - solange der Freistellpfad keine Sonderzeichen wie é, ä, ... enthält. (Und leider gibt es Leute, die sowas machen.)

Das geht jetzt auch.

Mit InDesign® Server werden leider die Funktionen zum Anwenden von Freustellpfaden für EPS-Bilder nicht angewendet.

fxd

Macht gar nichts, sieht nur komisch aus: Der Text "Dateiablage" des Login-Dialoges bei Playback-Mode (Shift-Open des Logins) ragt links ein bisschen über andere Fensterinhalte hinaus.

fxd

Ich habe vor einiger Zeit bereits einen Support-Call erstellt, jedoch konnte es dazumal nicht direkt nachgestellt werden (Fall 18397).

Heute habe ich aber einen recht simplen Weg gefunden, InDesign® zum Absturz zu bringen:

• InDesign® starten (Kein Login, kein offenes Dokument)

• Neues Dokument erstellen

• Text-Rahmen erstellen und mit beliebigem Text befüllen

• Einige Male zwischen den Paletten "Platzhalterwerte" und "Platzhalterwerte-Info" wechseln

• Dokument ohne Speichern schließen

• Alles ab Punkt 2 nochmals ausführen à Absturz bei 4.

Das ist ein sehr gutes Testverfahren. Damit bekomme ich InDesign® jetzt auch zum Absturz und konnte den Fehler fixen.

Danke für die lange Suche nach einem Test.

In unserem Projekt verwenden wir ein Master Dokument mit verschiedenen Seitengrößen. Um Kolumen-/Kapiteltitel und Fußnoten abzubilden verwenden wir die Funktion page::masteritems_load(). Diese Funktion im A4 Umfeld auch recht gut, wird jedoch eine Musterseite mit einer kleineren Seitegröße gesetzt, verspringen die Rahmen nach oben.

fxd. Der Fix betrifft auch die Funktion frame::override_masteritem.

FYI

Die InDesign® API hat glücklicherweise sogar DREI Methode zum Freistellen von Musterseitenrahmen:

1. Bei der ersten funktioniert es nicht bei unterschiedlichen Seitengrößen. Die haben wir bisher verwendet.
2. Die zweite ist so komplex, dass sie eigentlich unbenutzbar ist
3. Zum Glück : Die dritte funktioniert. Die verwenden wir jetzt.

Verwendet man product::copy so wie es in der Doku steht bekommt man ein leeres Produkt für das Ziel. Tauscht man die Argumente ist alles ok. Hier stimmt also die Doku nicht.

fxd

Die cScript Funktion xml::strcpy_frame sollte eigentlich den Eingabeparameter "result" zurückgeben. Scheinbar gibt sie aber den Parameter "xml_path" zurück, was die Benutzung erschwert.

fxd

Sorry, das war ein Fehler in den Plugins für die Desktop-Version. Apropos 'Neue Plugins' : Der Fehler bestand seit v4.0.5 R13603 (7. Sep 2016).

fxd

Workaround

Die documentId kann auch über xml::sattribute ermittelt werden:

char docid [512];
					
xml::sattribute ("/", "documentId", docid);

SOAP traffic recording

Im Logfile erscheint häufig der SOAP-Fehler -1, der keine näheren Beschreibungen enthält. Wie kann ich denn herausfinden, was da schiefgegangen ist?

Wir können aus der SOAP-Fehlermeldung -1 leider auch keine Schlussfolgerungen auf einen typischen Fehler ziehen. Der Fehler wird von der plugin-seitig verwendeten Implementierung der SOAP-Connection erzeugt. Das ist gSOAP. Dort wird der Fehler an ungefähr 250 Stellen generiert. Schwer zu sagen, welche Stelle den Fehler produziert hat.

Alle Stellen haben aber eins gemeinsam: Es soll etwas gelesen oder geschrieben werden, und es fehlen weitere Daten (oder sind zu viele). Das läßt immerhin darauf schließen, dass die Antwortdaten falsch sind.

Wir haben zwei Dinge getan, um dem näher zu kommen.

1. Zusatzbeschreibungen zu SOAP_EOF

Wir lassen jetzt an allen relevanten Stellen, die den Fehler SOAP_EOF (-1) erzeugen, weitere Infos fürs Logfile erzeugen. Diese Infos erscheinen im Log unter der eigentlichen Fehlermeldung:

SOAP_EOF (-1) reason(s) : [EOF_3] fsend ..., [EOF_23] soap_getdime, ...

Das erste Wort hinter [EOF_NN] ist jeweils der Name der Funktion, die den Fehler erzeugt. Beschreibungen der Funktionen finden Sie im gSOAP User Guide. Vielleicht hilft das schon weiter.

2. Mitschneiden des SOAP-Datenverkehrs

Aktionen und Datenverkehr einer SOAP-Verbindung lassen sich jetzt mitschneiden. Weitere Informationen dazu finden Sie hier.

Hier trotzdem noch mal zur Warnung: Die Log-Dateien einer SOAP-Verbindung können sehr groß werden! Sie enthalten u.a. auch die Daten aller Binaries, die geholt oder gesendet werden. Verwenden Sie das SOAP-Log nur zu Testzwecken!

Und noch ein Hinweis: Wir betrachten das SOAP-Log als Feature! WERK II und Partner sehen sich nicht in der Pflicht, diese Daten auszuwerten!

fxd

Das folgende Konstrukt funktioniert in InDesign CC2017 und dem Comet-PlugIn 4.0.5 R14200 einwandfrei.

sprintf (tt,"%%!TT<ParaStyle:AG_Beschreibung>Mein neuer Text");
					
frame::append(gFrame, tt);

In InDesignCC2017 und dem Comet-Plugin 4.0.5 R17002 funktioniert dies nicht mehr.

Da haben Sie einen Bug entdeckt, der mit kürzlich eingeführten Änderungen in der Version R17002 passiert ist. Mehr dazu hier.

Der Fehler besteht darin, dass doppelte Prozentzeichen in Formatstrings im Moment nicht mehr ersetzt werden, wenn keine Formatparameter mehr vorhanden sind.

Das haben wir jetzt wieder in Ordnung gebracht.

Workarounds

Einen leeren Parameter an das sprintf anfügen:

sprintf (tt,"%%!TT<ParaStyle:AG_Beschreibung>Mein neuer Text", "");

strcpy verwenden (das benutzt keine Formatstrings, es kann also auf das doppelte Prozentzeichen verzichtet werden):

strcpy (tt,"%%!TT<ParaStyle:AG_Beschreibung>Mein neuer Text");

Ein Stück Dummytext einfügen der später ersetzt wird:

sprintf (tt,"$PROZENT!TT<ParaStyle:AG_Beschreibung>Mein neuer Text");
					
strreplace(tt, "$PROZENT;", "%");

Die cScript Funktion xml::path hat 4 Parameter. Zwei davon sind default Parameter, jedoch funktioniert die Funktion nur richtig wenn alle 4 Parameter explizit angegeben sind. Ansonsten gibt die Funktion immer parameterMissingErr zurück.

fxd

Bei eps Dateien kann ein Beschneidungspfad nicht gesetzt werden. image::count_paths liefert 0. Mit image::setclip habe ich dann versucht, den ersten Pfad anzuwenden, das funktioniert aber auch nicht. InDesign® zeigt den Pfad an und ich kann ihn auch verwenden.

Gibt es zumindest als workaround eine andere Möglichkeit Pfadnamen auszulesen und Pfade zu zu verwenden?

Ja, das hat offenbar seit CS6 tatsächlich nicht mehr funktioniert und ist ab o.g. Release jetzt gefixt. Der Fehler betraf nur Freistellpfade in EPS-Bildern. Folgende Funkionen wurden gefixt:

• image::count_paths
• image::setclip
• image::setclip2
• image::pathname
• image::pathindex

Und nein, es gibt natürlich keinen Workaround außer Javascript. Das Ganze ist schwierig genug für einmal.

FYI

Das Problem wurde verursacht durch eine Funktion der InDesign® API, die zum Bestimmen der Pfade von EPS-Bildern benötigt wird. Von CS5.5 zu CS6 hat Adobe hier die Bedeutung (aber nicht Anzahl oder Typ) der Funktionsparameter geändert. Das kann kein Compiler der Welt erkennen.

Ich habe einen Produktaufbau mit Gestaltungsebenen gemacht. Das funktioniert auch bei Reorganisationen sehr gut. Jetzt müssen aber in das Dokument weitere Seitenumbrüche eingefügt werden. Dazu werden in den Produkten des Dokumentes zusätzliche Seitentemplates eingefügt Das Problem ist jetzt, dass man dann bei jedem Seitentemplate wieder exakt die gleichen Gestaltungsebenen setzen muß. Vergißt man das werden die Rahmen der Gestaltungsebenen in den Produktaufbau einsortiert. Gibt es dafür eine bessere Lösung?

Das ist mit aktuellen Mitteln nur so zu lösen wie oben beschrieben: Einfügen der Seitentemplates und manuelles Setzen der Gestaltungsebenen. Hintergrund ist natürlich, dass das eine doch eher seltene Anforderung ist.

Wir haben aber folg. eingebaut:

In der Palette Template-Verhalten kann man in der letzten Spalte der Rahmeneinstellungen (Verwendung im Produktaufbau) jetzt als dritte Möglichkeit ein "+" auswählen. Dann wird der Rahmen zwar aufgebaut, bei Reorganisationen aber ignoriert (egal, auf welcher Ebene er liegt und ob es Gestaltungsebenen gibt). 

ACHTUNG: Hat das Template mehrere Rahmen, müssen ALLE Rahmen diese Eigenschaft bekommen!

The scrollbar of the publication panel is missing in the mac version of CC2017.

Please restart your InDesign® without the the priint:comet plugins once. After re-installing the plug-ins the problem shoul by fixed.

Das ist sehr merkwürdig : Das Popup zum Ändern des Templates eines Eintrages der Produkte des Dokumentes ist zwar aufklappbar - aber nur wenn man ins obere Drittes des Controls klickt. Der untere Teil ist irgendwie deaktiviert. Auch die Checkbox "Man. Gruppen erhalten" geht nicht mehr auszuwählen.

fxd

Beim Drag and Drop in die Liste der Gestaltungsregeln wird ein weißer Balken in die Liste gezeichnet, der nach Loslassen der Maus stehen bleibt. Der Balken hat offenbar keine Bedeutung und hat keinen Einfluß auf das Ergebnis - aber es sieht unschön aus.

Das Problem tritt nur unter Mac auf.

fxd

Beim Drag and Drop in die Liste der Produkte des Dokumentes wird ein weißer Balken in die Liste gezeichnet, der nach Loslassen der Maus stehen bleibt. Der Balken hat offenbar keine Bedeutung und hat keinen Einfluß auf das Ergebnis - aber es sieht unschön aus.

Das Problem tritt nur unter Mac auf.

fxd

In Variablendeklarationen von int-Arrays wird daas erste Element mitunter nicht richtig initialisiert. Bei char-Arrays (statische Strings) klappt das - dort ist das erste Element immer 0.

fxd

ACHTUNG

Es wird immer nur das erste Element initialisiert (und das ist schon viel gegenüber dem C-Standard, bei dem gar nichts initialisiert wird.).

Ich habe in einem Skript folg. Sequenz:

placeholder::change_tags (gFrame, 0, "ID", gRecordID+1, 2, gStart, gLen, 0);
server::load_placeholder_str (str);

Beim Laden des Platzhalters wird dabei aber leider die alter ID (gRecordID) verwendet und nicht die neue (gRecordID+1).

Ja, das Skript hat eine eigene Referenz auf den Platzhalter. Durch den Aufruf von change_tags wird diese Referenz leider ungültig und verwendet seine alten Werte. Mit dem neuen (optionalen) Parameter takeCareOnMe = 1 kann das Problem behoben werden:

placeholder::change_tags (gFrame, 0, "ID", gRecordID+1, 2, gStart, gLen, 0, 1);
server::load_placeholder_str (str)

Beim erstmaligen Laden der Publikationen-Palette in CC 2017.1 sieht man nichts, erst beim Vergrößern oder Verkleinern der Palette wird der Inhalt gezeigt.

Adobe hatte (schon wieder!) ohne Ankündigung Änderungen an der Benutzeroberfläche durchgeführt die zu diesem Fehler führten.

Wir haben eine Funktion, welche bestimmte Rahmen eines Dokuments auf ein neues Dokument kopiert und speichert. Damit die Dokumente bei mehreren Durchläufen nicht immer aufblitzen, hätten wir versucht, die Dokumente im Hintergrund zu öffnen:

Visibility = 0 bei den Funktionen document::open bzw. document::open_copy

Jedoch ist es auf diese Weise nicht möglich die Rahmen via itemlist::duplicate() auf das Dokument zu kopieren. Die Rahmen werden nur auf das gleiche Dokument kopiert.

Sollte das grundsätzlich möglich sein? Mit Visibility = 1 funktioniert es problemlos.

Das ist gefixt.

Hinweise 1

itemlist::allframes als Liste der Originalrahmen birgt natürlich ein gewisses Risiko, wenn das Dokument mehrere Seiten hat. Dann auch mal schnell was von der Arbeitsfläche fallen - ein unverzeihlicher Fehler für InDesign®.

Hinweise 2

Die allermeisten cScript-Funktionen arbeiten trotz allem immer auf dem aktuellen Front-Dokument. Es ist also z.B. nicht möglich, mit layer::add auf dem Zieldokument eine neue Ebene anzulegen.

Ich habe in meiner soapflags.ini einen Timeout von zehn Stunden eingestellt:

request-timeout=36000

Die Bearbeitung bricht aber trotzdem bereits nach einer Stunde ab. Iirgendwie scheint dieser neue Timeout-Wert nicht am Soap-Servive anzukommen.

Das kann mind. vier Gründe haben:

• Die Datei ist zwar da, kann aber vom aktuellen IDS-Benutzer nicht "gesehen" werden.
  
  
• Die Plugins befinden sich an einer unerwarteten Stelle. Das ist im Server-Betrieb ein mit der Option -pluginpath festgelegter alternativer Plugins-Ordner. Der entsprechende Fix in den Plugins zum Erkennen dieser Situation ist erst ab diesem Release verfügbar.
  
  
• Die Datei ist syntaktisch falsch. Bitte beachten Sie, dass die einzelnen Angaben immer in der Form Schlüssel=Wert erfolgen müssen und dass vor und nach dem = keine Whitespaces stehen dürfen!
  
  
• Die Datei fehlt tatsächlich

Wurde beim Login keine soapflags.ini gefunden, schreiben die Plugins jetzt folgende Nachricht ins Log:

#
# soapflags.ini not found : 'your/path/to/comet/plugins/soapflags.ini'
# Please note : This file is NOT REQUIRED!
# Using default options for connection.
#

After calling color::define_rgb I checked the created color ItemRef using item::getint, and, allthough the color is created in the document, item::getint always returns 0.

An ItemRef always consists of TWO components: A so called DataBase to identify the document and the UID, an integer to define the object inside the document. We forgot to define the document for the result of color::define_rgb and therfor item::getint always returns 0 for the UID.

This is fixed.

Also fixed :

• color::define
• color::define_cmyk
• color::define_lab

Calling itemlist::duplicate with parameter reconstruct set to one seems to do nothing.

fxd

Beim Ausführen serverseitig implementierter Java-Funktionen führen Fragezeichen in den Eingaben zu [unbound value]s im Ergebnis der Funktion.

Die serverseitige Ausführung von Java-Funktionen in cScript hat ja was von Zauberrei. Aber hinter dem Vorhang wird natürlich letztlich ein (von Christoph meisterhaft zusammengesetzter und ausgewerteter) SOAP-Call an den Server abgesetzt. Und um das zu machen, ruft das Script letztlich ein cScript query::exec. Und das verhält sich, wie es sich verhalten soll: Fragezeichen (?) im Befehl werden als Markierungen für vorher mit query::input gebundene Variablen angesehen und ersetzt - nur sind in diesem Fall leider gar keine gebundenen Variablen vorhanden. Daher die [unbound value] im Ergebnis.

Das Problem wurde zweistufig gelöst:

1. Der Scriptbefehl query::execute hat einen neuen optionalen Parameter, mit dem das Ersetzen der ?-Markierungen im Befehl unterdrückt werden kann.
2. Das oben erwähnte Meisterskript von Christoph verwendet genau diesen Parameter zum Unterdrücken der Ersetzungen. Dazu ist (neben neuen priint:comet Plugins) auch ein neuer PubServer mind. 4.1.0 R12351 or 4.0.5 R12352 nötig.

Ist bei document::concat entweder die Original- oder die Zielebene gesperrt, kann der kopierte Rahmen nicht auf die richtige Ziel-Ebene verschoben werden.

fxd

Mit FogBugx 19620 wurde in R16511 eine Funktion eingeführt, die fehlerhafte Textstories aus älteren Dokumenten entfernen kann. Könnte man diese Funktionalität nicht auch als Menübefehl zur Verfügung stellen?

Man kann : Zusatzmodule -> Comet -> Unbenutzte Texte des Dokumentes entfernen

Beim Versuch, einen Textplatzhalter zu laden stürtzt InDesign® reproduzierbar ab, wenn der Textplatzhalter am Ende des Textes steht und mit einem Textanker endet.

Und ein zweiter Fehler in diesem Zusammenhang : Das Pseudo-Tag w2cross legt manchmal keinen Textanker an.

Beide Fehler sind gefixt.

Wie FogBugx 19880. Parameter "right" und "bottom" der cScript Funktion table::textcolor funktionieren nicht wenn -1 übergeben wird.

fxd

Wenn die cScript Funktion table::format mit dem Wert -1 für die Parameter "right" oder "bottom" aufgerufen wird, funktioniert sie nicht. Eigentlich sollten dann alle restlichen Zeilen/Spalten bearbeitet werden.

fxd

Im Fly-out-Menü der Platzhalterpalette gibt es beiden Einträge "Alle Platzhalter beobachten" und "Keinen Platzhalter beobachten". Ein Kunde hat jetzt festgestellt, dass in der aktuellen Version 4.0.5 (egal, ob Mac oder Win) beide Einträge nicht mehr funktionieren (er hat vorher die Version 3.3.1 verwendet). Bei „Keinen Platzhalter beobachten“ kommt ein Dialog, der nach einer Individualisierubgs-Datei fragt. Ist das ein neues Feature? Oder was bedeutet das?

Der Dialog ist hier natürlich Quatsch - das war ein kleiner Fehler in den Plugins. Der ist gefixt.

Beide Menüs waren außerdem bisher noch nicht v4 der Plugins angepaßt. Das ist jetzt gemacht und die Menüs machen wieder, was sie sollen (Alle Augen auf/zu).

Laut Doku und Hilfetext sollte die Angabe /n in Platzhalter-Prä/Postfixen zu einem Soft-Return werden. Tatsächlich eingesetzt wird aber ein Absatztrenner.

fxd.

Hier ein Screenshot. Im oberen Rahmen hat der erste Platzhalter den Postfix /n, im zweiten Rahmen den Postfix /r:

Wenn wiederholende Elemente eingesetzt werden, werden die Rahmen dieser Elemente an der ganz falschen Stelle gezeichnet, wenn "Platzhalter farbig hinterlegen" an ist.

Im Bild sollten die schwarzen Hintergründe eigentlich in den unten selektierten Rahmen sein.

fxd

Das Problem konnte dann auftreten, wenn der Layoutrahmen für die wiederholenden Elemente zu keiner Rahmenkette gehört und lag an den sog. "Adornments", die benutzt werden um unsere Platzhalter an Rahmen zu zeichnen.

Wenn ein InDesign® Server mit dem Kommandozeilenargument "-pluginpath" aufgerufen wird, um die Zusatzplugins (wie die Comet Plugins) aus einem anderen Ordner als dem Standardordner ("Plugin-Ins") zu laden, werden die Lizenzdatei und die soapflags.ini, die in diesem Ordner liegen, nicht gefunden.

fxd

Die in der InDesign® Server Standardoption -pluginpath gegebenen Ordner werden jetzt ebenfalls nach den Comet-Plugins durchsucht. Damit ist das Problem gelöst.

ACHTUNG 1: Das Problem betraf auch alle Dateipfade in Skripten etc, die mit den Alias-Namen $PLUGINS oder $COMET beginnen.

ACHTUNG 2: Entgegen einigen Beschreibungen von Adobe erlaubt der Wert von -pluginpath offenbar keine komma-getrennten Mehrfachangaben.

Die letzte Änderung (FogBugx 19672) passt soweit, dass man die Buttons initial sieht. Jedoch sind noch 2 Punkte aufgetaucht:

• Es ist nun so, dass man anfangs die Vorschau rechts neben der Liste nicht sieht. (siehe Screenshot)
  Das heißt, man müsste jedem User sagen, dass man das Fenster breiter ziehen kann und sich dort noch eine größere Ansicht "versteckt".
• Das Scrollen mit dem Mausrad funktioniert nur, wenn der Mauszeiger über der Scroll-Leiste ist.

Scrollrad geht jetzt über der ganzen Liste.

Sichtbares Preview beim ersten Öffnen ist nur möglich mit der Einschränkung, dass es dann NIE wieder ausgeblendet werden kann (InDesign® nimmt die initiale Dialoggröße zugleich als Minimalgröße). Deshalb wird jetzt über der Preview-Spalte ein gelber Hilfetext gezeigt: 

Hier ein Testskript

int main()
{
	String 		str 	= string::alloc();
	char 	* 	val1 	= alloc(1000);
	char 	* 	val2 	= alloc(1000);

	strcpy(val1, "Eins");
	strcpy(val2, "Zwei");

	str = val1 | " - " | val2
	showmessage("%s\n", string::get(str));
	// RESULT: val2 fehlt

	return 0;
}

fxd

Über die priint:suite mit publishing:server kann man Benutzernamen mit Umlauten anlegen (unser Beispiel: wco_fünf), diese Benutzer können sich dort auch einloggen und normal arbeiten.

Leider kann sich der Benutzer aber nicht über SOAP in den InDesign® Desktop-Plug-ins anmelden.

Wir müssen das tatsächlich in den PlugIns lösen: gsoap verwendet und erwartet von Hause aus Strings in System-Kodierung. Im Login-Dialog und / oder via Login-Message können wir Umwandlung in UTF-8 schon lange unterbinden, allerdings machen wir das erst nach Aufruf der SOAP-login Methode (sprich: alle später gesendeten und abgeholten Strings stimmen). Wenn wir die Dialog-Einstellungen schon vorher anwenden, können wir uns auch mit "müller" einloggen.

Gelöst bereits in R16004, 17. Feb 2017

There is no scroll bar in the publication panel. The last row of the panel with the buttons is transparent so that itself and the row behind is not readable.

Fortunately the mouse scroll wheel scrolls down the list nevertheless.

Ich nehme mal stark an, dass du die Interface Skalierung von Windows & InDesign® an hast, wenn ich die einschalte, kann ich das ganze nämlich teilweise reproduzieren. Zumindest ist bei mir dann auch der Baum am unteren Panelrand von der Statusleiste überlagert. Der Scrollbalken fehlt bei mir aber nicht.

Ab jetzt ist die minimale Fensterhöhe etwas größer, was bewirkt dass die dynamischen Widgets den Baum nicht mehr in die untere Leiste drängen sollten.

Der Absturz resultierte aus einem unerwarteten Verhalten von SOAP-Verbindungen, die im Fall von Timeouts keine Fehlerbeschreibung, sondern einfach überhaupt nichts liefern. Dieser Fehler ist behoben.

ACHTUNG: Der Fehler bestand in allen bisherigen priint:comet Plugins.

Timeout und andere Optionen einer SOAP, bzw. publishing:server-Verbindung stellen Sie über die Datei soapflags.ini ein.

Spricht etwas dagegen, in Funktionsnamen zweifache Doppelpunkte zu verwenden? Da man keine Klassen oder Namespaces definieren kann, verliert man bei vielen Funktionen und Libraries mal den Überblick. cScript erlaubt aber Doppelpunkte im Namen. Das heißt, wir könnten unsere Funktionsnamen etwas besser zuordnen:

itemlist::pm::getTopFrames()
itemlist::pm::setInfoIDs()

Spricht nix dagegen. Vielleicht wäre es aber trotzdem eine ganz gute Idee, als Modulnamen was Eigenes (und nicht gerade frame oder itemlist) zu verwenden.

Die cScript Funktion showerror übersetzt derzeit die Eingabestrings nicht. Die Funktion showmessage hingegen schon.

fxd

Die priint:comet Plugins können Daten externer Datenquellen (ODBC, SOAP) aufzeichnen und aufgezeichnete Daten später wieder verwenden. Bei der Verwendung aufgezeichneter Daten sind die ursprünglichen Datenquellen nicht mehr nötig. Mehr Informationen dazu finden Sie hier. (FogBugx 19683)

fxd

Der Aufruf der Script-Funktion wlog führt zum Absturz von InDesign,reg; wenn im String ein %s steht.

Das %s ist Teil der formatierten Ausgabe. In diesem Fall wird nach dem Eingabestring ein weiterer String erwartet, mit dem %s ersetzt werden soll. Die richtige Anwendung zur Ausgabe unbekannter Strings ist:

wlog ("", "%s", str); 

In dieser Anwendung darf der String str jetzt auch selbst %s enthalten.

Um solche Fehler in Zukunft zu umgehen, achtet die Stringfortierung jetzt darauf, ob für einen %-Platzhalter auch ein Parameter existiert. Gibt es keinen Parameter mehr, wird der %-Platzhalter direkt in das Ziel übernommen. Überzählige Parameter werden (wie bisher schon) ignoriert:

wlog ("", "%d %f %s");							// schreibt "%d %f %s"
wlog ("", "%d %f %s", 12);						// schreibt "12 %f %s"
wlog ("", "%d %f %s", 12, 1.2); 				// schreibt "12 1.2 %s"
wlog ("", "%d %f %s" 12, 1.2, "ABC");  			// schreibt "12 1.2 ABC"
wlog ("", "%d %f %s" 12, 1.2, "ABC", "DEF"); 	// schreibt "12 1.2 ABC"

Warum ist beim Öffnen des Bestelldialoges schon ein Haken bei Tabellenmodul gesetzt? Die Lizenz dazu bekommt man nur als Partner, also zusammen mit "Partnerlizenz". Eigentlich braucht man keine zwei Haken dafür.

Mir ist auch nicht klar, warum es comet und comet++ gibt. Worin unterschiedet sich comet von comet++? Braucht man beides (es sind beide Haken da)?

Könnte man die Zeile comet++ nicht ganz weglassen, so wie auch Tabellenmodul?

Die verkauften Lizenzmodelle entsprechen leider nicht 1:1 den Plugins. Möglich, dass das Tabellenmodul nur an Partner verkauft wird. Aber einen Bestell-Schlüssel brauchen wir trotzdem.

Ich habe das jetzt so geändert:

1. Das Tabellenmodul ist beim Öffnen des Dialoges immer aus.
2. Wird die Partner-Lizenz geändert, wird das Häkchen beim Tabellenmodul auch gesetzt (oder wieder entfernt).

Comet und Comet++ unterscheiden sich dadurch, dass Comet++ den (inzwischen eigentlich untersagten) Stapelbetrieb hat. Deshalb hat es eine eigene Lizenz. Das war mal extrem wichtig. Weil wir nicht wissen, welche Variante installiert wird, sind beide angehakt.

Ich verstehe diese Nachricht nicht. Sie erscheint, nachdem ich mich mit einem publishing:server verbunden habe. Und was heißt "möglicherweise"?

In der (in v4.1 neuen) Palette Übersetzungen können Key-Value-Paare von Übersetzungen bearbeitet werden. Es gibt lokale Übersetzungen (in den Dateien message_xxXX.xml des aktuellen Ordners der Comet-Plugins) und globale Übersetzungen (vom Datenpool).

PubServer in der aktuellen Version können aber Änderungen an den Übersetzungen nicht verarbeiten - das ist der Hintergrund der Meldung.

Eine Warnung wird jetzt nur noch gezeigt, wenn man

1. eine aktive Pubserver-Verbindung hat und
2. eine globale Übersetzung ändern (Editieren, Löschen, Anlegen) will

Das "möglicherweise" der bisherigen Meldung bezog sich darauf, dass aus Clientsicht nicht erkennbar ist, ob ein Server Änderungen an den Übersetzungen unterstützt oder nicht. Die Änderungen werden zwar an den Server geschickt - aber dass der (ohne Fehlermeldung oder was) die Sendung ignoriert, kann der Client nicht erkennen.

I

mein InDesign® CC 2017 hat mir gerade den Dialog oben angezeigt.

Der Text ist unvollständig. Das Bestellformular muss an license@priint.com geliefert werden. Das sollte da auch so stehen.

Womit Du vollkommen recht hast ...

fxd

Bei der Freigabe durch release ist ein Fehler unterlaufen. Das ist gefixt. Ein Testskript, das in einer Schleife 10000 Strings allokiert und sofort wieder freigegeben hat ist zudem nach nach dem Fix 100 Mal (!) schneller gelaufen.

Die cScript-Funktion table::merge_equal verwendet den TaggedText zweier Zellen um festzustellen, ob diese gleich sind. Könnte man stattdessen auch einfach den Plaintext des Zelleninhaltes verwenden?

Es gibt jetzt folgende Exportoptionen:

0 - TaggedText vergleichen (wie bisher)
1 - W2 Text mit Platzhaltern vergleichen (wie bisher)
2 - Plaintext der Zellinhalte vergleichen
3 - Nettogewicht des Plaintextes der Zellinhalte vergleichen

Wir können an einer Linie keinen Magneten setzen.

Hintergrund

Natürlich geht das normalerweise. Aber hier ist die Linie auf 53% skaliert (wie auch immer man das gemacht hat). Die sensitiven Flächen für Nägel und Magnete haben jeweils 1/3 der verfügbaren Größe, aber nicht mehr als 32 Pt.

• Die BoundingBox um die Linie ist 17 pt breit, ohne Skalierung 31 pt.

• 1/3 von 31 ist rund 10. Mit Skalierung 20 pt. 

• Weil 20 > 17 wird immer nur die linke obere Ecke sensitiv.

• Die linke obere Ecke ist aber ein Nagel und kein Magnet

Workaround

Vergrößern Sie den Rahmen temporär auf mind. 125 Pt. Dann können Magnete gesetzt werden.

Lösung

Ab jetzt wird die Rahmenskalierung bei der Berechnung der sensitiven Flächen beachtet. Ein Größerziehen der Rahmen ist nicht mehr nötig.

Wenn man einen Parameter einer Text-Gestaltungsregel bearbeitet, geht der Fokus von der Regel verloren. Beispiel:

• Textrahmen erstellen und Text schreiben
• Platzhalter über den Text legen
• Gestaltungsregel auf den Text legen (Bsp.: Absatzstil Setzen)
• Parameter bearbeiten (Bsp.: Stilname)

Kurz nach dem Schreiben geht der Fokus der Gestaltungsregel verloren. Das ist sehr mühsam, wenn man mehrere Einstellungen verändern will.

Ja, das soll natürlich nicht so sein. Allerdings tritt das Verhalten auch nur bei Textregeln auf.

fxd

Bei der Funktion retint_dialog() wird das Dialog-Fenster "abgeschnitten" dargestellt wenn nur wenige Zeilen da sind. Die Buttons werden in dem Fall auch nicht angezeigt. Wenn man das Fenster manuell vergrößert ist alles wieder in Ordnung.

Der Dialog erscheint jetzt initial in genügender Größe. Danach wird er (Neustart-resistent) in der letzten Größe wieder geöffnet.

Die Funktionen textmodel::gettext und frame::gettext schneiden bei längeren Exporten (in diesem Fall eine Tabelle) einen Teil des Exportes ab. Der resultierende Text ist maximal 989.608 Bytes groß. Der InDesign® Export aus dem Client mit aktivierten W2-Tags ist vollständig.

Ja, das können wir so nachstellen. (Bis auf die Behauptung, dass im W2ML-Export stimmt. Auch dort wird der exportierte Text abgeschnitten.) Hintergrund ist, dass für den Export ein Puffer definiert werden muß. Der war auf 1 MB festgelegt. Abzüglich der Stilinfos des normalen TaggedTextes wird der %!TT-Text dann etwa kürzer.

Das ist gefixt. Der interne Puffer wird jetzt bei Bedarf automatisch vergrößert. Damit ist das Problem gelöst.

Fügt man einmalig einen TaggedText in einen Rahmen ein, wird das InDesign® Dokument irgendwie "kaputt" und stürzt zumindest beim folgenden Menü ab:

Edit -> InCopy den Mauszeiger über die Option "Add Layer to Assignment" bewegen

Wir können das Verhalten nachstellen. Es genügt schon, dass in das Dokument IRGENDWANN und IRGENDWO ein %!TT-Text importiert wurde. Der Text kann auch längst wieder entfernt worden sein. Sobald man das genannte Menü auswählen will, stürzt InDesign® ab - egal ob ein aus %!TT entstandener Text ausgewählt ist oder nicht.

Nach einiger Suche haben wir herausgefunden, dass der Fehler in unserer Import-Funktion entsteht. Für dieses (recht komplizierte) Verfahren gibt es leider kaum Doku von Adobe. Kurz gesagt funktioniert es so, dass der Text importiert wird und dann "unter der Maus" liegt. Man kann sich das etwas so vorstellen wie den Import mehrerer Bilder in InDesign®: Da liegen alle Bilder "unter der Maus" und bei jedem Klick wird das nächste Bild im Dokument platziert So ähnlich ist das hier auch - nur dass wir den Klick gewissermaßen selbst auslösen.

Leider blieb dabei jedesmal ein unsichtbares Objekt im Dokument liegen  - die jetzt leere Textstory unter der Maus. Und dieses Objekt führt dann offenbar zum Absturz. Der Absturz ist dabei wohl eher ein InDesign® Fehler. Aber er hat eben auch offengelegt, dass da etwas anderes nicht in Ordnung war.

Wir haben das gefixt. Mit neuen Dokumenten sollte der Fehler jetzt nicht mehr passieren.

Ein bisschen merkwürdig ist aber, dass der Fehler bzw. überhaupt der ganze Import, so wie er da gemacht wird, seit zehn Jahren so ist - und offenbar so schlimm nun auch wieder nicht ist: Die Objekte nehmen kaum Platz weg (20-30 Byte pro leere Story) und haben in keinem anderem Zusammenhang bisher zu Problemen geführt.

Na, wie auch immer. Hier ein Verfahren zum Fixen alter Dokumente:

Die neue Skriptfunktion document::clean_storyscrap kann Dokumente so aufräumen, dass überflüßige Textstories gelöscht werden. Das o.g. Menü kann dann wieder benutzt werden. Fügt man diese Funktion ins AfterLogin-Skript ein, werden Dokumente beim Öffnen automatisch gesäubert. 

Inzwischen muß es hunderttausende solcher Dokumente geben. Wir konnten natürlich nur einen kleinen Bruchteil davon testen und können daher nicht mit endgültiger Sicherheit sagen, ob das Bereinigen der Dokumente nicht doch unter gewissen Umständen usw. irgendetwas löscht, was vielleicht irgendwo doch noch benötigt wird. Deshalb noch zwei Warnungen zum Thema:

• Sie sollten also vor dem Bereinigen der Dokumente Sicherheitskopien der Dokumente anlegen

• Bevor Sie das Bereinigen als automatische Aktion bei Öffnen ausführen lassen, sollten Sie eine genügend repräsentative Auswahl Ihrer Dokumente einmal durch den gesamten Workflow schicken.

Sollten Ihnen dabei Fehler auffallen, würden wir uns über einen Feedback freuen.

Im HTML export per frame::export_html könnte man doch die Zellformatoption "Zellversatz" als padding exportieren - im Moment wird diese Option ignoriert.

Das "Zellversatz" Attribut wird jetzt als "padding" auf den Tabellenzellen exportiert.

Im HTML export per frame::export_html fehlen Bilder, die nicht einem Browserkompatiblen Format entsprechen (z.B. .ai, .eps, etc...).

Es gibt jetzt einen neuen "flags" Parameter an der Funktion, mit dem man nicht-unterstützte und nicht vorhandene Bilder aus den InDesign® Previews exportieren kann.

Die Funktionen textmodel::gettext und frame::gettext schneidet bei längeren Exporten (in diesem Fall eine Tabelle) einen Teil des Exportes ab. Der resultierende Text ist maximal 989.608 Bytes groß. Der InDesign® Export aus dem Client mit aktivierten W2-Tags ist vollständig.

Ja, das können wir so nachstellen. (Bis auf die Behauptung, dass im W2ML-Export stimmt. Auch dort wird der exportierte Text abgeschnitten.) Hintergrund ist, dass für den Export ein Puffer definiert werden muß. Der war auf 1 MB festgelegt. Abzüglich der Stilinfos das normalen TaggedText wird der %!TT-Text dann etwa kürzer.

Ich habe das eben gefixt. Der interne Puffer wird jetzt bei Bedarf automatisch vergrößert. Damit ist das Problem gelöst.

Supplement

Whenever someone updates a product-template, this process requires multiple minutes. It seems that this gets slower over time. In the customers project there are a total number of 16 templates. Updating one of these templates or saving a new one requires multiple minutes per save. Besides that, as long as this saving runs, single templates appear to be locked/unavailable. It also seems that this process is getting slower with every attempt to save/update a template

In the comet-logfile one can see that most performance is consumed by multiple tranmissions of the file pageitems.xml. Within the Repository Explorer of ISON one can see that all template-xmls get touched multiple times during that save, resulting in high revisions of these files. The index.xml gets touched ~184 times per save.

The antivirus-application on the PubServer machine is configured to ignore the whole devstack directory including subfolders.

This error does not depend on the plugins

After updating to build #2308 of pubserver/devstack (with PlugIns 4.0.5. r11811) saving templates requires about 25 - 30 seconds, which is a big improvement.

Im HTML export per frame::export_html werden Softreturns als "&#xA;" aufgeschrieben, was ja auch das korrekt escapete Zeichen ist. Im Browser hat das leider keinen Sichtbaren Effekt, so dass alles weiter auf der selben Zeile steht. Wäre es nicht sinnvoll da stattdessen ein <br/> einzufügen?

... gesagt, getan.

Im HTML export per frame::export_html kann es passieren, dass eine lokale Stiländerung den Schriftschnitt eines gesetzten Zeichenformates überschreibt. Allerdings werden nicht alle CSS Attribute korrekt zurückgesetzt. Im Beispiel Setzt das Zeichenformat den Schriftschnitt auf "Condensed", eine lokale Änderung setzt diesen wieder zurück, aber im CSS kommt trotzdem "font-stretch: condensed" an.

Ach mein dummer Schnittchen! Die Schriftschnitt-Attribute werden jetzt korrekt zurückgesetzt.

Im HTML export per frame::export_html sind die Abstände zwischen den einzelnen Paragraphen (Margins) sehr viel größer als in InDesign®. Scheinbar wird ein Vielfaches der Schriftgröße verwendet. Das führt dazu dass Dokumente im Browser schon recht anders aussehen als im InDesign®.

Die Default Werte für <p> Margins sind jetzt oben und unten 3pt - das kommt dem im InDesign® schon recht nah.

Im HTML export per frame::export_html werden in den CSS Definitionen Tabellenkonturen (Farben, Stärken, Stil) scheinbar doppelt exportiert.

z.B.:

table 
{ 
	border-collapse: collapse;
	border-left-width: 1.0pt;
	border-right-width: 1.0pt;
	border-top-width: 1.0pt;
	border-bottom-width: 1.0pt;
	border-left-color: rgb(28, 28, 27);
	border-top-color: rgb(28, 28, 27);
	border-right-color: rgb(28, 28, 27);
	border-bottom-color: rgb(28, 28, 27);
	border-left-style: solid;
	border-right-style: solid;
	border-top-style: solid;
	border-bottom-style: solid;
	border-left-width: 1.0pt;
	border-left-color: rgb(28, 28, 27);
	border-left-style: solid;
	border-right-width: 1.0pt;
	border-right-color: rgb(28, 28, 27);
	border-right-style: solid;
	border-top-width: 1.0pt;
	border-top-color: rgb(28, 28, 27);
	border-top-style: solid;
	border-bottom-width: 1.0pt;
	border-bottom-color: rgb(28, 28, 27);
	border-bottom-style: solid;
	transform: rotate(0deg);
	vertical-align: top; 
}

Die Konturoptionen werden jetzt nur einmal aufgeschrieben. Hintergrund war, dass Tabellenstile sowohl Konturen für die ganze Tabelle als auch einzelne Zellen setzen können - im CSS sind das aber die gleichen Attribute.

Im HTML export per frame::export_html tauchen auf einmal die InDesign® Basis Formatnamen in den CSS Definitionen auf, z.B. "priint_0x005BNo0x0020paragraph0x0020style0x005D" (was dem unescapeten InDesign® Namen "[No paragraph style]" entspricht, also der Root Absatzstil).

Vorher wurden diese Namen nicht aufgeschrieben, sondern einfach als allgemeiner CSS Stil definiert (z.B. "p { ... }" für den Root Absatzstil)

Das ganze hatte zwar keinen Einfluss auf das Aussehen des Ergebnisses, hat jedoch das Dokument unnötig vergrößert.

Im HTML export per frame::export_html haben die Tabellenzellen zu große Abstände zueinander - eigentlich sollten da gar keine sein.

Das Ganze war ein Seiteneffekt des mit R14015 eingeführten escapings und prefixings (priint_) der Stilnamen.

doument::concat übernimmt leider die Textverkettungen des angefügten Dokumentes nicht mit ins Zieldokument..

fxd

Wenn ich die Funktion itemlist::duplicate mit der Seitennummer -1 verwende, sollte lt. Doku eigentlich die aktuelle Seite dupliziert werden. Bei Doppelseiten wird aber leider immer die rechte Seite des Spreads verwendet.

fxd.

Guten Tag,, innerhalb eines Projekts tritt folgender, kritischer Fehler in regelmäßigen aber nicht konkret reproduzierbaren Abständen auf:

Es werden ein oder mehrere Produktaufbauten per Document Planning oder Publikation Tree-Script gestartet. Bis zu einem gewissen Punkt werden diese Jobs wie gewünscht abgearbeitet.
Zu einem nicht bekannten Zeitpunkt bzw. aus einer nicht bekannten Ursache, werden angefange Jobs von den entsprechenden InDesign® Server-Instanzen nicht mehr weiterverarbeitet. Die entsprechenden Prozesse arbeiten dann mit 100% CPU-Leistung und können nicht mehr genutzt werden. Die betroffenen Dokumente bleiben ab diesem Zeitpunkt gesperrt.

Aus den zugehörigen Log-Dateien ist kein Rückschluss auf einen bestimmten Fehler möglich, die Logs von Zeitpunkt des Abbruchs befinden sich im Anhang. Startet man dann, als Reaktion, die InDesign® Server-Instantzen neu, werden die betroffenen Jobs korrekt verarbeitet. Nach einer gewissen Zeit tritt dasselbe Problem erneut auf.

Das Problem ist nicht durch das Starten eines bestimmten Jobs reproduzierbar. Jedoch lässt sich der Fehler bzw. dieses Verhalten durch das Starten einer ausreichenden Jobmenge auslösen und tritt immer wieder auf. In letzter Konsequenz ist ein sauberes Arbeiten mit dem Planner so nicht möglich.

Auf den ersten Blick wird das Problem von den InDesign® Servern ausgelöst und ist auch auf diesen begrenzt. Der PubServer ist während des Fehler weiterhin erreichbar. Die entsprechenden InDesign® Instanzen werden dann im Planner dauerhaft als Busy angezeigt.

Nach tagelanger Suche konnten wir den Fehler finden. Es war wie befürchtet ein Fehler mit einem sog. InterfacePtr, also ein Plugin-Fehler. Das verheerende Wort zu viel (::UseDefaultIID () heißt es), haben wir entfernt. Es war in der Funktion document::has_overset.

Im Logfile soll eine Warnung ausgegeben werden, wenn server::lad_placeholder (ohne str!) verwendet wird. Diese Funktion ist DEPRECATED.

So eine Warnung wird jetzt geschrieben.

# WARNING : DEPRECATED function server::load_placeholder called!"
# Use server::load_placeholder_str instead.
See offline docu cscript/server.html#load_placeholder_str for more informations.

Im Logfile soll unterschieden werden, ob die Script-Funktion server::load_placeholder oder server::load_placeholder_str (mit str!) gerufen wurde. Bisher schreiben beide Funktionen die Nachricht load_placeholder (ohne str!).

Also, dann. Das wird jetzt im Log unterschiedlich ausgeschrieben.

Wenn eine SOAP-Anweisung fehlschlägt, erhalten die Plugins zwar einen Fehlercode. Den geben Sie aber offenbar nicht weiter. Weitergegeben wird statt dessen der generische Fehler 1001. Könnte man die Fehlerursache im Logfile vielleicht etwas genauer beschreiben?

Man kann. Im Logfile werden jetzt auch Fehlernummer und Kurzbeschreibung aus der unteren SOAP-Schicht ausgegeben.

Wenn man bei einer Doppelseite mit verschiedenen Breiten die Koordinaten eines Rahmens relativ zum Druckbogen mittels frame::bbox auslesen möchte, bekommt man für Rahmen auf rechten Seiten falsche Werte geliefert. Die Angaben sind jeweils um die Größenunterschiede der linken zur rechten Seite falsch.

Sie haben natürlich recht. Ein kleines -1, eingefügt in den Plugin-Sourcecode, konnte das Problem lösen. Das Gleiche betrifft natürlich auch die Funktion itemlist::bbox.

Hi! Is there a cScript function to get the currently used memory of InDesign®. I need this information for some debugging purposes.

We implemented system::used_memory to support this. But please note : The function is for internal usage only. That means, you can use it by your own risk but ther is no support for it.

laut News in der Doku und meinem Fall 19059 ist das Problem mit dem Loginnamen "_spotlight" seit R14141 behoben. Leider habe ich den Fehler nun auch wieder in R15111

Ja, wir hatten das versehentlich nur für CC2017 gemacht. Jetzt geht es auch für CC2014 und CC2015. 

ACHTUNG!

Das Ganze ist zwar eher ein Problem des Betriebssystems, aber für CS6 bleibt das Verhalten unverändert.

Leider gibt es noch ein paar Fehler bei den FrameInfos:

1. Wenn ich die Suchkriterien erweitere, mit denen die Einträge eindeutig identifiziert werden, wird das Statement, das die Id des Eintrags ermittelt, nicht korrekt zusammengesetzt. Beispiel:
   
   select id, updatedOn
   from comet_frameinfo
   where
   ... and placeholderId,251;
2. Und hier sind ein paar Beispiele für unlogische Umwandlung der Suchparameter in SQL-Statements:
   
   searchparams =     kUseTemplateId + kUseRecordStringId;
   
   select id, updatedOn
   from comet_frameinfo
   where
       templateId=80 and frameLabel=''
       and recordStringId=''abc'
       and builtByRecordStringId='';
   
   Es wird also immer auch die Default-Kombination verwendet, auch wenn man nur einen Teil der Parameter konfiguriert hat.
3. Und noch eine Frage: Warum kann man die anderen Parameter aus den Frameinfos nicht zur Identifizierung verwenden? Ich hatte da speziell an die "klassischen" drei Integer-IDs gedacht (also "kUseRecordID","kUseRecordID2","kUseRecordID3"). Oder ist das nur ein Doku-Fehler?
4. Und sorry, ich habe noch ein Problem, das aber vielleicht einfach zu lösen ist. Als Workaround verwende ich jetzt die frameinfoid, um die Rahmeninfos eindeutig abzurufen. Zum Wiederfinden über frame::apply_frame_info() funktioniert das auch wunderbar. Wenn ich aber die frameinfoid über "frame::get_frameinfoid" auslesen will, bekomme ich immer nur einen Leerstring zurück.
5. Der Parameter kUseScriptTags wird ignoriert.

Und hier die Lösungen:

1. Es muss natürlich placeholderId = 251 heißen. Das ist gefixt.
2. Wenn einer der Default-Suchparameter angegeben war, wurden bisher alle ausgewertet. Das ist jetzt nicht mehr so.
3. Die ganze Funktionalität ist eigentlich nur für den Pubserver gedacht. Deshalb gab es die Suchparameter für die "klassichen" IDs bisher nicht. Die gibt es jetzt (funktionieren im Pubserver Fall aber nicht).
4. Die Funktion frame::get_frameinfoid war falsch verlinkt. Als Workaround kann man bis dahin frame::get_script_tag mit dem key "frameInfoId" verwenden.
5. Der Parameter kUseScriptTags wurde bisher nur im Pubserver Fall unterstützt und funktioniert jetzt auch bei Datenbanken.

Jetzt alles recht?

fxd

Using InDesign® Server on Mac I see a lot get a lot of "CFURLGetFSRef was passed an URL which has no scheme" warnings. What does that mean.

Indeed, its a warning only. After changing our plug-ins a littlte bit, you should not see it any more.

Umlaute gesicherter Login-Einträge werden im Login-Dialog als <0x00FC> gezeigt.

Die xloginhistory.xml wird scheinbar nicht als UTF8 XML gespeichert, daher werden non-ASCII Zeichen mit dem TaggedText-Format escaped.

Beim Laden der Datei wird das allerdings nicht rückgängig gemacht. Jetzt wird es das, allerdings darf man dann kein <0x00FC> oder ähnlich geartetes mehr in seinen Usernamen etc verwenden (ich hoffe das ist zu verschmerzen).

Mit der Funktion frame::export_html exportiere HTML Dokumente verlieren scheinbar beim Export die Steuerzeichen für Rechtsbündige Tabs.

InDesign® verwendet einige Steuerzeichen, die eigentlich eine völlig andere oder gar keine Bedeutung haben (z.B. ist das Zeichen für das rechtsbündige Tab eigentlich das ASCII Zeichen für Backspace).

Bisher werden einige dieser Zeichen verworfen. Jetzt werden diese Zeichen folgendermaßen beibehalten:

<?ACE HEXCODE?> , also z.B. <?ACE 8> für das rechtsbündige Tab.

Folgende Zeichen werden so behandelt:

Ich möchte ein Stück Text mit der Funktion frame::export_html exportieren. In dem Text wird ein Absatzformat mit folgendem Namen verwendet:

    Grundschrift_Hinweis_Produkt-Nr.

Daraus wird ein CSS Stil mit folgendem Namen:

    priint_Grundschrift_Hinweis_Produkt0x002DNr0x002E

An sich richtig, aber muss denn der Bindestrich auch als Hex escaped werden? Eigentlich ist das ja in CSS Stilnamen erlaubt.

Jetzt kommt der Name so raus:

    priint_Grundschrift_Hinweis_Produkt-Nr0x002E

Wenn man Comet Tests durchführt und auf der Palette keinen Test mit einem Auge markiert hat lässt sich das ganze unter CS6/Windows nicht abbrechen (der Knopf auf der Meldung fehlt).

Wenn man Eigene Beschriftungen für die Knöpfe angibt, scheint das ganze unter CS6 problematisch zu sein. Wir nehmen stattdessen jetzt die vordefinierten Beschriftungen kOKString und kCancelString - und obwohl die Inhalte genau gleich sind funktioniert es auf einmal...

Die cScript Funktion idtype::entity_id liefert scheinbar ein falsches Ergebnis. Wenn man die Funktion mit der Eingabe "505030#505029#product#Bucket#505029#505028#productgroup#Bucket#" aufruft, wird "505030" zurückgegeben, scheinbar der RecordID Teil.

Das gleiche gilt für idtype::group_id und idtype::entity_class.

fxd

Every time I open a table template in the template editor, the template will change its type after uploading it:

• Using XML-Offline orSOAP :  To 'snippet

• Using ODBC : To 'frames'

This has not been noticed for over three years (v3.4 R4255, 15. Aug 2013)!

fxd

In cScript I made the following declaration:

char ch = 'a';

But if I ask for the value of ch I always get 0. And, in addition, after inserting the following line, ch have the expected value suddenly.

ch = 'a';

Its amazing :-)

fxd. Assignments to char variables will now work as expected.

FYI

The problem was the so called little endian architecture of x86 processors:

Assigning a char to this address will change the red bits but interpreting this as an char, I got the green bits.

This error also occurs in the following functions and situations:

• document::export (..., "package", ...)
• document::get_blendingspace
• document::set_blendingspace
• document::preflight
• document::revert
• document::update_links
• frame::release_inline
• image::clipindex
• image::setclip
• image::set_alpha_channel
• layer::copy
• page::remove
• NumberingLists in w2ml
• Objectstyles in w2ml

fxd for all of them

In a template I have an image frame with a text wrap. But in the products I placed with this template, the text wrap isn't set to image frame any more but to image itself.

This is an amazing side effect of TWO fixes (Case FogBugx 18795, and case FogBugx 18877). The error also effects all text wrap function of module frame (frame::wrap, frame::getwrap, ...)

fxd now

Using frame::getwrap without default parameters will immediatelly crash your InDesing.

fxd. You can omit the defaults now. Of course.

There is a problem in creating smart templates with publishing server and comet InDesign® plug-ins.

I do not know whether the comet bridge or the comet InDesign® plug-in is the cause of the problem.

To reproduce the problem:

• open template "PDF renderer Simple 01" in template editor
• copy the two frames into a new document
• save the two frames in the new document as template with page type 'left page'
• open the new template in template editor
• set different frame labels to both frames (probably not neccessary, but I did that) on panel 'template behavior'
• press button 'create mirror page&continuation' on panel 'template behavior': now the template consists of five pages, first empty page should be ignored, then the original left page, then a right page containing the two original frames in a mirrored position. The next two pages contain a left and a right version of the template for the continuation pages. Still every thing is as expected.
• save template on template panel
• close template editor
• open template editor of same new template again. The five pages should contain the same as after pressing the button 'create mirror page&continuation', but unfortunately there is an error: the right continuation page is EMPTY.

Das Problem wurde ausgelöst durch ein für den Export der Daten nötiges internes Javascript. Unter CS6/Windows wird in diesem Fall offenbar eine (vollkommen unerwartete) Idle-Time ausgelöst. Die nutzt unsere Logik, mal schnell temporäre Dateien zu löschen - die wir aber in diesem Fall noch gebraucht hätten. Das wären nämlich die neuen Templates geworden.

Der Fehler triit nur dann auf, wenn gleichzeitig zu den normalen Templates auch deren W2ML-Varianten gesichert werden sollen. Für diesen Export ist das Javascript nämlich nötig.

Wir haben unsere Idle-Time-Aktionen etwas anders organisiert und auch unter CS6/Windows/SOAP sollten Smart.Templates jetzt vollständig gesichert werden.

On mounted volumes document::export_ does not delete the package folder after zipping it.

fxd

I use document::export_ with format "package", but nothing happens, neither a package nor an error.

fxd

Every time I use document::concat with documents created by the priint:comet plug-in, InDesing falls into an infinite loop and crashes. If I only use 'normal' files, everything is okay.

The error occurs while recreating the Comet groups inside the appended pages and is fixed now.

Leider liefert die Funktion sql::charset() immer -1 (Fehler).

Ooh, da hatte ich nachträglich eine Prüfung auf die Anzahl der Funktionsparameter eingefügt - und versehentlich 2 (statt 1) verlangt. Das ist gefixt.

Workaround

Einfach noch einen zweiten Parameter anfügen, z.B.:

sql::charset(dbc, 1);

Der Parameter wird nicht ausgewertet, er muß nur da sein. Es macht auch nicht nichts, wenn er im gefixten Release drin steht.

If To Do panel is active when InDesign® has just been started, the first document opened runs To Dos automatically. Live Update may be checked or unchecked, behavior the same. Subsequently opened documents do not start To Dos automatically.

fxd

... or not?

Yes, of course. Done now.

The Englisch cScript docu contains the German word "Dokumentation" as head lines.

fxd

I need a script method to ask for the currently sent command to a query.

query::get_command will answer the question.

I have two open documents. The ToDo panel shows the place holders of the current front document. If I now select the other document, the panel still shows the place holders of the first document. in my eyes, the to do list must be cleared in this case.

You're right. The list of place holders is now cleared on every changes of the front document.

This particular ticket pertains to "disappearing" to-dos. They describe a scenario of:

1. Run To Dos.
2. Update one To Do
3. Search for Product by Item Number
4. Assign template.
5. Drag on to page.
6. To Dos disappear every time

Yes indeed, this is not the expected behavior. 

Explanation : To keep the list of todos up-to-date, we must delete this list every time a document was closed. Since templates are 'normal' documents, the list of todos is cleared after inserting templates (or products with templates) too - obviously wrong in this situation.

This is fixed now.

To create reports of CometTest, we need some more functions to ask for the name, error state, ... of CometTests.

There are a lot of new functions now : test::count, test::get_nth_nameand so on. See here for a complete description.

Docu says that system::send_mail is Mac only. Do you see any possibility to implement a Windows version too?

Done. See here for certain infos.

Since v3.4 of the priint:comet plugins we had a plugin named XCell, but XCell is deprecated since v4.0. Is there a possibility to get it back?

Here they are (CS6, CC2014, CC2015, CC2015, Mac and Windows).

Beim Versuch einen Kunden auf die aktuelle Version priint.comet 4.0.5 R 14477 umzustellen, ist uns aufgefallen, dass sich das Mergen von Tabellenzellem mit table::merge nicht mehr so wie bisher verhält.

Bedauerlicherweise ist mir bei der Einführung der Trenntexte für die o.g. Funktion in R14200 ein Fehler unterlaufen und die Funktion verhält sich dadurch tatsächlich fehlerhaft. Das ist jetzt gefixt.

Workaround

table::merge mit dem Parameter copyPolicy = 0 aufrufen

Ein sehr lästiges Verhalten, das mich schon länger nervt: wenn ich mich von Windows aus mit einem Kundenrechner (Mac) verbinde, funktioniert in den Paletten die Kombination von ALT-Taste und verschiedenen Symbolen nicht (Platzhalter aktualisieren, Template speichern etc.). Grundsätzlich
funktioniert die ALT-Taste aber: wenn ich mit gedrückter ALT-Taste auf den Schreibtisch klicke, werden ganz korrekt alle Anwendungsfenster ausgeblendet. Am TeamViewer scheint’s also nicht zu liegen.

(Die Freundlichkeit in Person, was?)

Mein erster Versuch, mit TeamViewer von meiner Windows-VM auf meinen Mac zu kommen (gleicher Rechner), sah so aus:

Ich hab mir das Tastenproblem genauer angesehen (diesmal mit zwei Rechnern) und die Plugins aufschreiben lassen, was für Tasten da jeweils ankommen: Keine.

Dann hab ich mal in meinem Gedächtnis gekramt und bin auf die gute alte Mac-Carbon-Funktion GetKeys gekommen. Mit der hat man zu Zeiten von Mac OS 7 (sic!) die aktuellen Tasten abgefragt. Und siehe, es gibt sie noch. Und diese Funktion liefert plötzlich Ergebnisse. Offenbar sind also die Funktionen zum Abfragen der Modifier-Tasten von Adobe falsch.

Dann habe ich neue Funktionen für die Modifier-Tasten-Abfrage geschrieben und die lediglich 614 Verwendungen solcher Tastenabfragen durch die neuen Funktionen ersetzt. Damit kann man jetzt auch von einem Windows-Teamviewer die ALT-Taste an den Mac gegenüber schicken. Leo hat das als "sehr gütig von uns" bezeichnet.

Für Parameter von Gestaltungsregeln, die Wartelisten (Popupmenüs) haben, kann mit dem ! vor einem Eintrag ein Defaultwert eingestellt werden. Kann man auch für einfache Parameter ohne Wartelisten einen Defaultwert angeben?

Bisher ging das nicht. Ab jetzt geht das mit ^^ als Trenner hinter dem Parameternamen. Alles hinter diesem Trenner wird Defaultwert. Mehr dazu hier.

Ich habe einem Rahmen die Gestaltungsregel "Rahmengeometrie setzen" gegeben. Aber es passiert rein gar nichts. ???

Damit da was passieren kann, müssen drei Dinge erfüllt sein:

1. Die frameinfos müssen installiert sein (siehe hier). 
2. Der Rahmen muss seine Infos auch gesichert haben (siehe hier). 
3. Die Regel muss entsprechend konfiguriert sein.

Bei der Konfiguration der Gestaltungsregel gibt es jetzt einige kleinere Änderungen

1. Der Parameter Suchmethode wird mit dem Wert kUseDefault vorbelegt. Das ist schon mal ein guter Anfang, damit die Infos für den Rahmen gefunden werden können. Weitere Werte entnehmen Sie bitte der Doku von frame::apply_frame_info.
2. Der Parameter Wiederherstellen wird mit dem Wert SEE_DOCU_OF_frame::apply_frame_info initialisiert. DIESEN WERT GIBT ES NICHT. Aber wenn die Regel ausgeführt wird, wird durch diesen Wert eine Fehlermeldung erzeugt und erinnert Sie daran, dass Sie hier natürlich noch angeben müssen, welche Rahmeninfos eigentlich wiederhergestellt werden sollen.

Tests schlagen häufig auch dann fehl, wenn ich meine Tests ohne irgendeine Änderung an Daten oder Software ausführe. Das Problem sind dabei die erzeugten Bilder, die sich (offenbar ohne weitere Gründe) um winzige Artefakte unterscheiden.

Daran habe noch eine ganze Weile herumprobiert. PDFs zu verenden habe ich mal gleich ausgeschlossen. PDFs werden asynchron erzeugt - ruck-zuck ist der Prozessor am Limit. 

 Dann habe ich es mal mit JPGs versucht - das hat nicht geholfen (außer dass wir mit diesem Format auch keinen Pixelvergleich machen können.) War also auch nix.

 Jetzt habe ich, glaube ich jedenfalls des Rätsels Lösung gefunden:

1.  Die Previews hängen davon ab, welche Anzeigeleistung man gewählt hat (Menu Ansicht->Anzeigeleistung). Ist „Schnelle Anzeige“ ausgewählt, erhält man bei Snapshots des Typs kPrinting für Bilder nur graue Rahmen. Überraschend! Die CometTests stellen sich deshalb jetzt temporär die Auswahl „Anzeige mit hoher Qualität“ selbst ein. Schon besser so.
2. Leider gab es immer noch Artefakte. Der Grund ist absurd: Die Snapshots unterscheiden sich abhängig davon, ob bereits andere Dokumente geöffnet sind oder nicht! A-Ha! Und da macht es außerdem einen Unterschied, ob die Dokumente jeweils eigene Fenster haben (GUT, aber leider nicht der Standard) oder Reiter in einem einzigen Fenster sind (NICHT GUT, aber leider der Standard.). Die CometTests öffnen daher die Dokumente jetzt jeweils in eigenen Fenstern.

Jetzt ergeben sich hoffentlich gleiche Bilder

Offenbar fehlt bei den Mac-Plugins für CC2017 das Preflight-Plugin.

Jetzt nicht mehr ...

Ein Kunde benötigt eine Erweiterung, für die ich das Frameinfo-Management einsetzen wollte. Leider werfen die Statements frame::write_frame_info und frame::apply_frame_info Fehlermeldungen aus, die Ursache liegt darin, dass
doppelte Hochkommas statt einfacher Hochkommas verwendet werden:

select id, updatedOn from comet_frameinfo
	where 	templateId = 52
		and	frameLabel = ""
		and	recordStringId = "abc"
		and	builtByRecordStringId = "";

 Ja, das haben wir jetzt gefixt. Die FrameInfos sollten jetzt auch mit MSSQL funktionieren.

Ich habe ein sehr einfaches Template mit einem Bild. Wenn ich ein Produkt mit diesem Template platziert habe und mit dem Werkzeug "Laden" (<-) der Toolbar aktualisieren will, kommt InDesign® in eine Endlosschleife und stürzt ab.

Das war ein unerwarteter Nebeneffekt des Fixes von Fall 18918 und ist gefixt.

Ich würde gern den Skriptbefehl system::send_mail verwenden. Aber er tut nicht.

Der Befehl ist eigenlich überbordende Liebenswürdigkeit von uns, nicht? Ich habe das jetzt noch mal gefixt, aber der Befehl ist jetzt als DEPRECATED markiert.

Siehe hier zur Einrichtung des Maildienstes (Postfix).

Hat man in der Aufgabenpalette als Platzhalterquelle "Aktuelle Seite" eingestellt, muß man trotzdem erst einen Rahmen der Seite auswählen bevor die Lupe die geänderten Platzhalter der Seite findet.

Ja, die Auswahl eines Rahmens ist hier natürlich nicht zwingend nötig. Wir finden die aktuelle Seite auch ohne diesen Rahmen. Es muß also jetzt nicht mehr extra ein Rahmen ausgewählt werden, bevor die Lupe die Platzhalter der aktuellen Seite untersuchen kann.

Seit v4.0.5 werden Platzhalter in einer hierarchischen Liste angezeigt. Nun kommt der Wunsch auf, doch auch wieder eine flache Liste sehen zu können.

?

Na gut. Auf der Platzhalter-Palette gibt es jetzt dafür die Checkbox "Platzhalter als flache Liste anzeigen".

Ich habe in meinem Dokument Seiten, die einen Präfix und die römische Seitenzahl anzeigen, z.B.

A I
A II
A III

In der Aufgabenpalette wird aber als Seitennummer angezeigt:

A 1
A 2
A 3

fxd

Ich wollte mit frame::embed_file ein Postscript-Bild in ein Dokument einbetten. Der Befehl liefert zwar den Fehlercode 0 (alles gut) zurück, importiert wird aber leider nichts.

(v4.0.5 R11812) Der Fehler ist behoben

(v4.0.5 R14610) aber URLs funktionieren jetzt nicht :-(

Auch URLs gehen jetzt wieder.

Während ein Test ausgeführt wird, wird er in der Liste mit dem roten Hinweis "wird ausgeführt ..." versehen. Aber wenn der Test in einem zugeklappten Teil des Baumes ist, sieht man leider nichts davon, dass der Test gerade ausgeführt wird.

In diesem Fall wird jetzt der erste sichtbare Eltern-Eintrag der Liste beschriftet. Außerdem wird der Text noch mit einer Zählnummer (z.B. 3/8) versehen.

Im Hilfezettel des CometTests Proof-Buttons (Pfeil nach unten) steht, dass die Ergebnisbilder des Proofs automatisch geöffnet werden, wenn man nur einen Proof macht. Das geschieht aber nicht.

Ja, das geht jetzt wieder.

Unter InDesign® CC2017 scheint der Skriptbefehl image::save nicht zu funktionieren. Die Funktion liefert zwar den Fehler 0 (alles okay), aber eine Bilddatei wird nicht erzeugt.

Das war nur auf dem Mac so. In der verwendeten neueren Entwicklungsumgebung von Apple sind leider einige der für image::save nötigen Anweisungen inzwischen deprecated. Das haben wir jetzt angepasst, damit funktioniert image::save wieder.

Manchmal wäre es schön, wenn man einen Test einfach mal ausführen kann und dann das Ergebnis auch direkt sehen kann. Kann man das irgendwie ermöglichen?

Klar, man kann: Wird ein Test mit gehaltener ALT-Taste gestartet, bleibt die Testdatei am Ende geöffnet.

ACHTUNG I : Nur das Dokument des ERSTEN ausgeführten Tests bleibt geöffnet. (Sonst könnte es sein, dass man viel zu viele Dokumente offen läßt.)

ACHTUNG II : Sie sollten dieses Dokument OHNE SICHERN schließen. Sonst ist der Test bei der nächsten Ausführung mglw. aussagelos (weil schon mal ausgeführt).

Tests, die eine eigene Datenverbindung benötigen, sollten die vor dem Test auch herstellen. Das wird aber offenbar nicht getan und der Test in wird in der aktuellen Datenverbindung ausgeführt.

Oops. Gefixt! Tests können jetzt auch wieder in eigenen Datenverbindungen ausgeführt werden, ganz klar, muß sein!

Ich habe vor längerer Zeit einen CometTest erstellt. Dieser Test schlägt inzwischen fehl und ich möchte einen neuen Proof erstellen. Das funktioniert auch. Aber wenn ich den Test danach mit dem neuen Proof ausführe, schlägt der Test immer noch fehl. Woran kann denn das liegen?

Das war ein Fehler bei Löschen der alten Proof-Daten und ist gefixt.

Mit diesen Programmen wollen wir Sie bei der Entwicklung Ihrer priint:comet Projekte unterstützen. Die Programme richten sich an Projekt-Entwickler. Sie werden über Terminal bzw. Eingabeaufforderung gestartet und führen einzelene Anweisungen eines priint:comet Projektes unabhängig von PublishingServer, WhiteBoard, InDesign,reg; ... aus:

• soapzilla - Laden und Senden einzelner Dateien von bzw. an einen SOAP- oder Publishing-Service

• soapquery - Ausführen einzelner Anweisungen an einen SOAP- bzw. Publishing-Service

• xmlquery - Ausführen von XML-Anweisungen in einem XMLOffline priint:comet Datenordner

• crpt - Ent- und Verschlüsseln von crpt-Dateien eines XMLOffline priint:comet Datenordners

Mehr Informationen finden Sie hier.

Eigentlich funktioniert die Funktion document::update_links ja schon, aber ich habe hier einen Fall, in dem sie offenbar nicht funktioniert:

int main()
{
	char 		pp 		[512];
	char 		url 	[512];

	strcpy (pp, "/Users/paul/Desktop/aaa/1.jpg");
	strcpy (url, "https://priint.com/de/assets/media/home/grafic-priintsuite.jpg");

	file::download (url, pp);
	document::update_links ();
	frame::image(gFrame,pp,5);

	return 0;
}

Das Skript soll ein Bild aus dem Netz laden und in den aktuellen Rahmen setzen. Soweit, so einfach.

Das Problem ist, dass das Bild mglw. bereits im Dokument verwendet wird und diese Verknüpfungen durch den Download geändert werden. Dem will man mit document::update_links begegnen. Aber offenbar erkennt InDesign® gar nicht so schnell, dass sich die Links geändert haben. Jedenfalls werden sie hier nicht aktualisiert.

Wenn ich das document::update_links ein einem weiteren Skript etwas später ausführe, dann klappt es.

Der Skriptbefehl arbeitet jetzt auch in der beschriebenen Situation richtig.

ACHTUNG: Die Ergebnisliste von document::update_links wird auf 50.000 aktualisierte Links beschränkt - aber so ein Dokument müssten Sie erstmal hinkriegen, das über 50.000 geänderte Links enthält.

Bei einigen https-URLs funktioniert die Funktion file::download nicht. Das Problem betrifft nur Windows.

Wir haben das getestet. Die angegebenen URLs können leider auch nicht mit dem Internet Explorer geholt werden. Es scheint so, als gäbe es irgenein Rechte-Problem. Das müsste sicher serverseitig gelöst werden. Hier finden Sie ein Beispiel, wie Sie solche URLs trotzdem laden können.

Warum fasst das Tabellenmodul leere Zellen per Default (obwohl Gestaltungsregeln leern)  zusammen? Dafür habt Ihr doch extra eine Gestaltungsregel die gleiche Zellen verbindet ...

Ja, das ist Absicht. Die Spalten/Zeilen vor der multiplizierenden Zelle werden automatisch über den angelegten Zellbereich gemerged. Das Mergen kann aber mit einer einfachen Gestaltungsregel wieder rückgängig gemacht werden:

int main ()
{
	table::unmerge (gTable, gAreaLeft, gAreaTop);

	return 0;
}

Das gibt es jetzt auch als Standardregel:

Zellverbindung aufheben

Ich habe folg. Platzhalter-Präfix:

    %!TT<ParaStyle:"ROT"><ParaStyle:>

Dadurch wird zwar ein neuer Absatz eingefügt. Aber ROT wird der Absatz Vor dem Platzhalter. Setze ich das "ROT" in den zweiten Parastyle, ist gar kein Absatz rot.

Richtig wäre 

%!TT<ParaStyle:><ParaStyle:"ROT">

Dazu mußten leider einige Korrekturen in den Plugins gemacht werden. Jetzt funktioniert es.

Die Funktion document::jpeg erzeugt den Fehler 1115 (parameterMissing) wenn der Parameter resolution fehlt. In der Doku steht, dass dann 72.0 als Default verwendet wird. Gebe ich die Auflösung mit an, ist alles gut.

Der Parameter resolution darf jetzt tatsächlich weggelassen werden.

Wir benötigen öfter die Funktion „document::jpeg“. Leider werden Elemente, die über das Attribut „nicht druckend“ verfügen, dennoch im JPG angezeigt.

Unsere multifunktionale Programmier-Landschaft sieht auch dafür eine Lösung vor: Verwenden Sie einfach die Funktion document::export_ mit dem Format "JPG".

Zusätzlich hat document::jpeg jetzt den weiteren Parameter (optionalen) Parameter suppressNonPrintableFrames. Hat der den Wert 1, erscheinen nicht-druckbare Rahmen nicht mehr im Bild. Default ist das bisherige Verhalten, also 0.

Running To Dos against entire document works as expected. Running To Dos against current page does not appear to work unless you first select all frames on the current page, either before or after you run the command. As soon as frames are selected the differences shows up in the list. Selected frames works as well.

The only question I have is whether it should be necessary to select all frames on the current page when running to dos in order to display the results. There is no feedback via progress bar or beach ball that anything is happening unless you select all frames. Then everything shows up, seems counterintuitive, since search the entire document does not require selected frames?

fxd

In den Paletten Platzhalter, Templates und Seitentemplates sollten die aktuellen Objekte bei SOAP-Verbindugnen immer direkt vom Server geholt werden. Bisher geht das nur bei Platzhaltern und bei gehaltener ALT-Taste.

Das wird jetzt in allen drei Paletten (und ohne Alt-Taste) gemacht.

ACHTUNG: Auch wenn die Listeneinträge neu vom Server geholt werden, INHALTE BEREITS GELADENER Objekte werden dabei nicht automatisch immer wieder neu geladen. Das betrifft insbesondere Templates und deren Previews!

Heute wollte ich das die neuste Version des Comet-Plug-ins ausprobieren, dabei habe ich festgestellt, dass das Werkzeug «Platzhalter aktualisieren» nicht mehr funktioniert – Alt-Taste war dabei gedrückt.

Ja, der Fehler ist leider als Seiteneffekt des Fixes von Fall 18918 in R14200 entstanden. Es werden immer nur die Platzhalter der ausgewählten Rahmen aktualisiert.

fxd

In der Werkzeugpalette und in Produktrecherche sind jeweils Button für Aktualisieren und Sichern von Platzhaltern. Aber beide sehen gleich aus - zumindest bei dunkler UI. Das Bild des Sichern-Buttons scheint falsch rum zu sein.

fxd. Beim Sichern-Bild zeigt der Pfeil jetzt wieder in die richtige Richtung.

Über die Plugins kann jetzt direkt aus InDesign® geprüft werden, ob Dokumente von comet_pdf ohne sichtbare Einschränkungen dargestellt werden können. Dazu findet sich in der Palette Comet Admin -> Comet ein neues Button:

Für das Feature ist eine vollständige comet_pdf-Installation mind . R14341 nötig.

Ich kann aus die Liste der Produkte de Dokumentes keine Seitentemplates entfernen.

Doch, das geht - bei gehaltener ALT-Taste - und jetzt auch ohne Extra-Taste.

Set R14141 erzeugen Variablen vom Typ char ohne * oder [] einen Fehler beim Ausführen von cScript. Könnte man das vielleicht in eine Warnung umwandeln?

Gewünscht, gespielt. Ab jetzt werden nur noch Warnungen ins Log geschrieben.

ACHTUNG : Die Warnung hat natürlich einen handfesten Hintergrund. Wäre also gut, sich dann auch mal irgendwann dran zu halten!

Bei Timeouts von SOAP-Anfragen wird als Fehlermeldung nicht der Timeout angegegben. Statt dessen erscheint die Meldung "result code missing".

Pluginseitig wurde die Fehlermeldung jetzt so verändert, dass dort der Timeout angezeigt wird:

ACHTUNG: Sind auf dem Weg zwischen Plugins und Server Komponenten mit einem kleineren Timeout als der Timeout der Plugins (3600 oder request-timeout in soapflags.ini), kann das von den Plugins natürlich trotzdem nicht als Timeout erkannt werden!

Kann man die Prä- und Postfixe von Platzhaltern mit Hilfe des w2-Tags setzen?

Ja, das geht jetztt. Mehr dazu siehe hier.

Kann man über cScript den verwendeten Zeichensatz einer Datenverbindung (SQL, SOAP) erfragen?

Dazu gibt es jetzt die Funktionen

• soap::charset
• sql::charset

Unter neueren Windows-Systemen ist es vorgekommen, dass SOAP-Verbindungen "plötzlich" nicht mehr gingen. Nach längerer Suche ist es gelungen, diesen Fehler zu fixen.

Internal note : No KEEP_ALIVE

Zu unserer großen Freude funktioniert nach dem Fix der Funktion im letzten Release jetzt das Sortieren mit CS6-Mac nicht mehr.

Das Problem war, wie sich herausstellte, keine falsche Behandlung von 64Bit-Zahlen, sondern ob das InDesign® 64- oder 32-Bit ist. 

fxd.

Ich habe ein Bild in einem Inline-Rahmen und führe dort die Funktion frame::fit_image mit der Methode 3 (Rahmen an Inhalt anpassen) aus. Dadurch verschwindet das Bild aus dem sichtbaren Bereich.

Naja, das muß man sich mal vorstellen : Zuerst wird dem Rahmen über die Inline-Eigenschaft mitgeteilt, dass der seine Position an einer Textstelle ausrichten soll. Und dann die Anweisung, die Postion an seinen Bildinhalt anzupassen. Dem Widerspruch dieser Anweisungen ist die Bildposition zum Opfer gefallen. An dieser Stelle ist ein "einfaches" Fitframe die Lösung - und wird jetzt auch gemacht. 

Damit ist das Problem gelöst und frame::fit_image mit Methode 3 (Rahmen an Inhalt anpassen) kann jetzt auch in Inlines verwendet werden - obwohl das immer noch widersprüchliche Anweisungen sind.

Ich habe einem Inline-Rahmen die Getsaltungmethode "Rahmenanpassen" gegeben und dort eingestellt, dass auch einzeilige Texte die Rahmenbreite nicht verändern soll. Trotzdem wird der Rahmen schmaler.

Ja, in fitframe war ein Fehler, wenn die Rahmen Inlines sind. Das ist gefixt.

Ich habe in einer SOAP-Verbindung einige Front row - Buttons angelegt. Das funktioniert einwandfrei. Aber wenn ich mich aus- und wieder einlogge, verschwinden die Buttons.

Dass die Buttons beim Logout verschwinden ist natürlich völlig korrekt. So soll es sein. Die Buttons verweisen schliesslich auf Skripte, die durch die SOAP-Verbindung bereit gestellt wurden und die nach dem Logout nicht mehr verfügbar sind. Soweit so gut. 

Aber beim erneuten Verbindungsaufbau sollten die Buttons dann auch wieder erscheinen. Das hat unter SOAP tatsächlich nicht funktioniert und ist jetzt gefixt.

Mit table::get_row_max_height kann man die maximale Höhe von Tabellenzeilen holen. Gibts das auch für die minimale Zeilenhöhe?

Jetzt ja:table::get_row_min_height

Ich habe zwei Rahmen, einen oben, einen unten. Von oben nach unten geht ein Magnet. Wenn ich den unteren Rahmen verschiebe, wird der Magnet richtig neuberechnet. Wenn ich den oberen Rahmen verschiebe, bleibt der Magnet undverändert stehen und zeigt in Leere.

Ein kleines Update-Problem, das offenbar mind. seit CS6 besteht. Merkwürding, dass das noch niemandem aufgefallen ist. DerFehler ist gefixt.

Im Indesign-Client können die Notizen angezeigt werden (Comet-Notizen), die Whiteboard hinzugefügt wurden. Leider wird dort nicht der Kommentar der Notiz angezeigt. Muss das Indesign-Fenster Comet-Notizen noch in irgendeiner Weise konfiguriert werden?

Die Notizen werden natürlich angezeigt: Bdei Auswahl einer (sichtbaren) Notiz wird diese Notiz im Dokument ausgewählt und in den sichtbaren Bereich gescrollt. Zusätzlich zeigen die Notizen jetzt den (auf höchstens 255 Zeichen gekürzten) Kommentar-Text als Tooltip. Gezeigt wird immer das Textende und nur der reine Text. Wurde der Text gekürzt, erscheinen am Textanfang drei Punkte (...). Bei Textänderungen ändern sich die Tooltips synchron.

Das Tag <user> wurde in SOAP-Verbindungen bisher nicht unterstützt und ist daher leer geblieben. Das habe ich eben geändert und das <user>-Tag wird jetzt auch in SOAP-Verbindungen durch den aktuellen SOAP-Login-Namen ersetzt.

In den direkten Anweisungen von Platzhalterskripten und in Panelstatements können eine Reihe vordefinierter <Tags>, z.B. <user>, <now> oder <text> verwendet werden. Vor der Ausführung der Anweisungen werden diese Tags dann jeweils durch ihre aktuellen Were ersetzt. kann man diese Tags auch in cScript erfragen?

Dazu gibt es jetzt den neuen Befehl system::get_key_value.

Die Beschriftung mit der aktuellen Datenverbindung, die sich unten in der Palette Front row befindet, zeigt nur nach Neueröffnen der Palette den aktuellen Wert. Wird die Datenverbindung bei geöffneter Palette geändert, ändert sich das Label der Palette nicht.

fxd

Das Label mit der aktuellen Datenverbindung der Palette Comet Admin -> Comet ist so kurz, dass längere Verbindungsnamen (z.B. bei SOAP) nicht mehr angezeigt werden können. Auch wenn man das Fenster verbreitert, wird die Textanzeige nicht länger.

fxd

Um Rahmen-Skripte aus XML-Struktur des Dokumentes zu starten muß der Skriptname im Popup der Palette Comet Admin -> Comet ausgewählt werden.Zumindest unter Windows das immer ein bißchen schwierig - und insgesamt auch eine etwas unerwartete Lösung. Schöner wäre es, den Eintrag im Popup auszuwählen und dann mit einem eigenen Button die Ausführung zu starten.

fxd. Neben dem Popup befindet sich jetzt dazu ein Button mit einer Startflagge:

In der Palette Comet Admin -> Comet werden die Name der verfügbaren cScripte der XML-Struktur des Dokumentes angezeigt. Leider wird diese Liste nur aktualisiert, wenn das Dokument gesichert wird. Bei Fensterwechseln bleibt das Popup aber leider unverändert (und enthält dann Einträge, die gar nicht verfügbar sind).

fxd. Das Popup wird jetzt bei jedem Fensterwechsel aktualisiert.

Die Funktion document::preflight wirft nur dann einen Fehler, wenn der Prefight aus irgendeinem Grunde gar nicht erst gemacht werden konnte. Schöner wäre es, wenn die Funktion auch dann einen (speziellen) Fehler liefern würde, wenn der Preflight selbst Fehler gefunden hat.

Findet der Preflight mind. einen Fehler, liefert die Funkrtion jetzt den Fehler 1289 (preflightNotEmptyErr). Nur wenn der Preflight erfolgreich ausgeführt wurde und keine Fehler mehr im Dokument gefunden hat, gitb die Funktion den Wert 0 zurück.

In der cScript-Funktion document::preflight kann man sich das Ergebnis des Preflights auch in einem Ergebnisstring zurückgeben lassen. Da das Ergebnis aber sehr lang werden kann, muss man hier einen sehr großen String alliieren um auf der sicheren Seite zu sein.

Die Funktion hat jetzt einen weiteren (optionalen) Parameter, mit dem die Ausgabe begrenzt werden kann, mehr dazu in der Doku der Funktion.

Das InDesign® Standardverhalten beim Zusammenführen von Tabellenzellen ist, dass die Inhalte der verdeckten Zellen absatzgetrennt in die gemeinsame Zelle übernommen werden. So verhält sich auch der Skriptbefehl table::merge. Die Funktion hat jetzt zwei weitere Parameter, mit denen:

• erstens ein eigener Trenntext (auch TaggedText) angegeben werden kann und
• und zweitens festgelegt werden kann, ob man die Inhalte zweilen- oder spaltenweise anfügt.
• und drittens gleiche Inhalte benachbarter Zellen nur jeweils einmal übernommen werden.

Mehr dazu hier.

Mitunter ist es erwünscht, dass sich ein Platzhalter beim Einsetzen eines Produktes nicht ändert und in allen Anwendungen den gleichen Inhalt anzeigt. Dazu können der Platzhalter (Text oder Rahmen) in der Palette jetzt als Feste-Produktverknüpfung markiert werden. Mehr Infos dazu finden Sie hier.

int main ()
{
	IDTypeList  	l1  	= idtypelist::alloc ();
	IDTypeList  	l2		= idtypelist::alloc ();
	IDType   		id1, id2;
	int    			i;

	idtypelist::insert (l1, -1, 1, 0, 0, "");
	idtypelist::insert (l1, -1, 2, 0, 0, "");
	idtypelist::insert (l1, -1, 3, 0, 0, "");
	
	for (i = 0; i < idtypelist::length (l1); i++)
	{
		id1 = idtypelist::get (l1, i);
		wlog ("", "III %d === %d\n", i, idtype::id (id1));
		idtypelist::insert (l2, -1, idtypelist::get (l1, i));
	}

	for (i = 0; i < idtypelist::length (l1); i++)
	{
		id1 = idtypelist::get (l1, i);
		id2 = idtypelist::get (l2, i);
		wlog ("", "%d <---> %d\n", idtype::id (id1), idtype::id (id2));
	}

	return 0;
}

Das obig Skript füllt eine kurze IDTypeList und kopiert die Inhalte der Liste in eine andere. Ich hätte als Ausgabe 3 ### 3 erwartet, erhalte aber 3 ### 0. Die zweite Liste bleibt offenbar leer.

Ja, der Fehler war in idtypelist::insert mit einem IDType. Das ist jetzt gefixt.

Der Retint-Dialog sollte in der ersten Spalte eigentlich Bilder zeigen - tut er aber nicht.

fxd

Wir haben vor kurzem einen Kunden von CS5.5 auf CC 2015.4 umgestellt. Dabei ist aufgefallen, dass beim "Umfärberdialog" in CC 2015.4 der Beschreibungstext nur mehr einzeilig angezeigt wird.

fxd

Die cscript Funktion server::dataprovider_load stürzt ab, wenn für den Parameter "resultEntityId" der Defaultwert 0 explizit übergeben wird.

fxd

Mir ist aufgefallen, dass page::count_columns() den „Gutter“-Wert falsch ausliest, und zwar, wenn dieser über die Musterseite vererbt ist und nicht dem Standardwert von 12pt entspricht. Sobald man lokal auf der Seite einmal einen abweichenden Wert eingesetzt hat, ist der Wert korrekt. Das bleibt auch nach einem erneuten Zuweisen der Musterseite so, der Fehler tritt also nur auf, wenn es sich um eine „jungfräuliche“ Seite handelt.

Adobe hat an dieser Stelle die interne API geändert - und offenbar auch noch einen Fehler eingebaut. Schon die Doku ist etwas wirr:

enum MasterColumnRequest
{ 
	kRequestPerhapsInvalidFirstColumnData = 0,
	kRequestValidColumnData = 1
};

/**
	Get the gutter value for the page.
	@param 	wantMaster 	kTrue to get the gutter value 
				for any applied master on the page if valid.
*/
virtual PMReal GetGutter_ (
			MasterColumnRequest wantMaster = kRequestValidColumnData) const = 0;

MasterColumnRequest ist un aber kein Wert, der kTrue sein könnte. Und die Antwort dieser Funktion ist auch nicht das, was man erwartet.

Ich habe unsere Funktion page::count_columns daher jetzt so umgebaut, dass immer die richtigen Werte der aktuellen Seite ermittelt werden. Die Werte der Musterseite kann man aber - vielleicht verschmerzbar - nicht mehr erfragen.

Wenn ich Rahmen von einer Musterseite lade, werden die IDs von Textplatzhaltern nicht korrekt gesetzt, die von Rahmenplatzhaltern schon. Anscheinend setzt der Comet die Tags für alle Textplatzhalter, die von der gleiche Musterseite stammen, identisch. 

Wenn ich die Rahmen normal ins Dokument einbaue, ist alles okay.

Das Problem ist gar nicht die Musterseite sondern dass ein KOPIE des Rahmens angelegt werden. Dabei kopiert ID zwar den Rahmen und seine Text. Die internen Objekte für die Textattribute werden aber nicht kopiert - oh InDesign!reg; Beim Freitstellen der Musterseiten-Rahmen verwendet also erstmal jeder freigestellte Rahmen die gleichen internen Objekte für die Platzhalter. Und dann ist es auch kein Wunder, dass die Änderung an einem Rahmen in allen Rahmen sichtbar wird.

Zur Lösung muss also das Platzhalter-Objekt jeweilskopiert und dann neu angelegt werden. Da man leider nicht weiß, ob ein Rahmen eine noch neue Kopie ist, muß das leider IMMER gemacht werden. Immer heißt hier : Jede minimale Änderung an einem Platzhalter erfordert eine Kopie des bisherigen Platzhalters.

BTW: placeholder::link im gleichen Zusammenhang hat auch bisher schon funktioniert. Das liegt daran, dass dort auch bisher schon Kopien der Platzhalter-Objekte gemacht wurden (weil hier gleich mehrere Platzhalter-Eigenschaften auf einmal geändert werden.).

# pStyle "stilname"

kann der Platzhalter-Präfix die Absatzstile im gesamten eingefügten Platzhaltertext setzen. Gibt es eine Möglichkeit, das auch nur im ersten eingefügten zu machen.

Jas, die gibt es. Man definiere folgendes einfache Sript mit der ClassID 50:

int main ()
{
	textmodel::set_parastyle (gFrame, 0, 1, "Produkt:Zwischenüberschrift");
	
	return 0;
}

 und setze den Präfixtext so:

# "/r" Script 1000

Alternativ (und ohne zusätzliches Skript) geht es jetzt auch so:

# "/r" pStyle1 "Produkt:Zwischenüberschrift"

Mehr Informationen zu Platzhalter-Präfixen finden Sie hier.

In InDesign® CC 2015.4 werden nur die ersten zwei Comet-Icons in der Werkzeugpalette korrekt zentriert. Alle weiteren sind nach links verschoben bzw. nach oben, bei horizontaler Ausrichtung. Kommt das durch InDesign® zustande oder lässt sich da was machen?

fxd

Wenn ich ein Objektrahmen mit der Gestaltungsregel „Rahmengröße setzen“ manipulieren möchte, dann rundet Comet die ausgeleitete Größe ab, wenn man ein Komma anstat ein Punkt setzt.

fxd. Ab dem o.g. Releaase werden dann auch Kommas akzeptiert.

Wenn ich ein Template löschen bleiben dessen Einträge in framerules erhalten. Das bleibt normalerweise folgenlos. Nur wenn das Template auf einer neuen Seite beginnen soll, erbt ein neues Template diese (längst vergangene) Einstellung.

fxd

Ich habe ein Template, das breiter als eine Seite ist. Dazu passend habe ich ein Seitentemplate für Spreads angelegt. Aber leider klappt der Aufbau damit trotzdem nicht. Ich erhalte immer die Meldung, dass das Template zu groß für die Seitenelemente ist (Fehler -111000).

Prinzipiell geht das jetzt.

Die Funktion textmodel::scale_text funktioniert super, wenn alle Parameter angebe. Default-Paramter (wie in der Doku) beschrieben, scheint es aber nicht zu geben: Fehldene Paramter werden nicht durch ihre Defaults ersetzt sondern führen zu einem Fehler.

fxd. Fehlende Parameter werden jetzt durch ihre Defaults ersetzt.

Beim Speichern eines Templates, wird das Template nur als "Template mit Magneten" gekennzeichnet, wenn mindestens 1 Magnet vorhanden ist. Was auch durchaus Sinn macht ;-)

Wäre es möglich, das Speichern anzupassen, sodass auch ein Nagel bereits ein Kriterium ist, dass es sich um ein "Template mit Magneten" handelt? Es würde auch genügen, dass einfach die Nägel nicht verloren gehen.

Wir haben einen speziellen Aufbau, bei dem wir die Nägel direkt über eigene cScript-Funktionen auslesen. In diesen Logiken benötigen wir nur die Nägel, aber keine Magneten. Das heißt, bei solchen Templates müssen wir immer einen "Dummy-Magneten" hinterlegen, damit die Nägel nicht verloren gehen.

Ich hab das mal entsprechend geändert. Template speichern jetzt auch "Nur Nägel".

Die Gestaltungsmethode 'Textrahmen-Höhe ändern' führt während des Produktaufbaus zu Fehlern:

# Cannot get height of last text llne of frame 557, error 1 in textmodel::coordinates.

Die Textrahmenhöhe wird in Vielfachen der Höhe der letzten (sichtbaren) Zeile verändert. Dazu wird textmodel::coordinates verwendet. Diese Funktion wiederum benötigt die Position des letzten sichtbaren Zeichen (frame::get_textpos) - und dort trat der Fehler auf: Zum Zeitpunkt der Abfrage war der Rahmen mglw. noch gar nicht neu gerendert und InDesign® konnte die Frage deshalb auch nicht beantworten. Mit einem Redraw des Textes vor der Abfrage ist das Problem jetzt gelöst.

die Funktion system::login() liefert hin und wieder (ab einem undefinierbaren Zeitpunkt) nur mehr den Loginnamen "_spotlight". Durch einen Neustart von InDesign® ist es wieder der korrekte Username.

Ja, ich habe das auch schon bemerkt - und gefixt.

Leider führen lange StringIDs in w2-Platzhaltern auch nach dem Fix vom 11.11.2016 noch zum Absturz - die StringIDs können nur ein kleines bißchen länger sein als vorher.

Das ist frustierend. Der Absturz passiert an genau der gleichen Stelle wie vorher - beim Durchsuchen des TaggedTextes nach den w2-Platzhaltern mit regulären Ausdrücken über PCRE. Der String, der für einen regulären Ausdruck gefunden wird, ist offenbar zu lang. Der Update auf eine neue PCRE-Version war wohl doch nicht so hilfreich wie erhofft. Nur ein bisschen. Aber ein neueres PCRE gibts nicht.

Wobei man sich ja auch mal fragen kann, was 1300 Zeichen lange StringIDs die wiederum aus StringIDs bestehen, sollen? Das ergibt grob gerechnet 10 hoch 300 Möglichkeiten. Ich hab mal Google gefragt: Die Zahl der Atome im Universum beläuft sich auf eine Zahl im Bereich zwischen 10 hoch 84 und 10 hoch 89.
Und bei diesen langen IDs, ehrlich gesagt, muß man sich jetzt auch nicht wundern, wenn das eine oder andere dann doch auch mal länger dauert. Das bloß so nebenbei.

Ich hab also die Ärmel hochgekrempelt und die Platzhalter auf die naive Art mit String-Operationen aus dem Text gesucht - damit funktioniert das Beispiel dann.

Die Funktion frame::warp_contour ändert die Einstellung eines Alphakanals nicht.

Ja, das hat tatsächlich nicht richtig funktioniert und ist jetzt gefixt.

Achtung

Anders als in der Doku beschrieben, haben die Angaben tolerance und treshold doch eine Bedeutung. Der Treshold steuert, ab welcher Graustufe in Pixel zum Alphakanal gehört. Mit Treshold 0 wären das dann alle - da hätte der Aufruf wieder keine Wirkung. Mit 255 gehören nur wirklich schwarze Pixel zum Alphakanal. Weitere Infos dann wie immer in der Doku.

Wenn ich mit frame::image das Bild eines Rahmens ändere, gehen die Eigenschaften des Textumflußes für diesen Rahmen verloren und der Rahmen hat danach keine Textverdrängung mehr.

fxd. Die Konturverdrängung bleibt jetzt bei Bildwechseln erhalten.

Nach ein paar Versuchen mit dem Datentyp char zu arbeiten, sind ein paar Probleme aufgetaucht.
Ich würde erwarten, dass folgendes Programm ohne Meldung durch läuft.

int main()
{
	char 	a 	= 'a';
	char 	b 	= 'b';
	int		t 	= 0;

	if (a != a)  			showmessage("ERROR: a should be equal a");
	if (a == b)   			showmessage("ERROR: a should be not equal b");
	if (a != 'a') 			showmessage("ERROR: a should be equal 'a'");
	if (a != charIdent(a)) 	showmessage("ERROR: charIdent(a) should be equal a");
	if (a == charIdent(b) 	showmessage("ERROR: charIdent(b) should be not equal a");
	if (!charEq(a, a))		showmessage("ERROR: charEq(a, a) should be true");
	if (charEq(a, b)) 		showmessage("ERROR: charEq(a, b) should be false");
	
	t = (int)a;
	if (t == 0) 			showmessage("Why is char t = (int)a == 0");
	
	return 0;
}

char charIdent(char c)
{
	return c;
}

int charEq(char x, char y)
{
	return (x == y);
}

Ich bekomme allerdings mehrere Ausgaben. Gibt es irgendwelche Einschränkungen für den Datentyp?

Ja, der Datentyp char ohne Zeiger (* oder []) darf als Variablen-Typ gar nicht verwendet werden. Das steht leider nicht in der Doku. (Und hat in 14 Jahren auch niemand gemacht :-) )

Der Hintergrund ist historisch: Die Werte von Skript-Variablen werden in einem internen Stack verwaltet. Als ich den Interpreter gebaut habe, war es zumindest unter Mac noch so, dass nur gerade Adressen im Speicher angesprochen werden durften. Das war kein Problem für int und float (die intern beide 8 Byte verwenden). Für den char ist es verheerend und ich hätte den kompletten Script-Interpreter neu schreiben müssen (weil das natürlich auch nicht sofort aufgefallen ist.) Dann hat das aber eh keiner gebraucht - naja, so war das.

Ich habe den Interpreter jetzt aber so erweitert, dass er bei Versuchen der Art

int func_name (char a);
char a;
char b = 'x';

Fehler wirft und die Bearbeitung abbricht. Anstelle dieser char kann problemlos ein int verwendet werden. Die entsprechenden internen Typecasts beim Vergleich gegen Zeichen des Strings sind ebenfalls korrigiert.

Vielleicht noch eine kleine Warnung

Ein einzelnes Zeichen eines char*-String (also wie oben in[n]) ist immer noch 1 Bytes breit! Zeichen über Ascii 127 werden in UTF-8 dargestellt. Die Veränderung eines String-Bytes, das zu so einem UTF-8-Zeichen gehört, ist sehr gefährlich und kann InDesign® (und den Renderer) zum Absturz bringen. 

Ebenso sind direkte char-Werte nur bis Ascii 127 gültig, also etwa 'a', '\n', '§'. Nicht gültig und zu Fehlern führen Angaben wie 'Ä' oder '©'.

Ich habe in einem Skript aus Versehen einen Bezeichner verwendet, der noch nicht definiert ist. Das Skript kann dann natürlich nicht funktionieren. Aber dass dann gleich InDesign® abstürzt, muß ja jetzt nicht gleich sein, oder?

Nein, natürlich nicht. Es wird jetzt der Skriptfehler 6 (undeclared identifier) erzeugt und die Skriptbearbeitung wird abgebrochen.

mir ist aufgefallen, dass beim Hinzufügen von gruppierten Rahmen in ein Template, sich die Anzeigeinformationen zum Template-Verhalten der Gruppe nicht ausblenden lassen. Wenn man das Template speichert und ein Produkt damit aufbaut, bleiben diese Informationen dort stehen.

Es gibt wohl einen Workaround, bei dem man die Elemente einmal degruppieren und anschließend wieder gruppieren muss, nur ist es ärgerlich, dass dabei auch beispielsweise die Magnete und Abstände verloren gehen.

Das Verhalten der Plugins ist an der Stelle nicht ganz richtig : An sich sollte es nicht möglich sein, einem Gruppenrahmen (der Rahmen der die Unterrahmen als Gruppe zusammenfasst) eine Kennung zu geben - und schon gar nicht automatisch beim Einfügen.

Wir haben folgendes gemacht:

• Beim Einfügen gruppierter Rahmen in den Template Editor werden die Kennungen jetzt automatisch an die Unterrahmen der Gruppe vergeben, nicht mehr an die Gruppe.
• Die Anzeige der Template-Informationen auf Gruppenrahmen kann nicht mehr aktiviert werden
• Ein-und Ausschalten der Template Informationen auf Gruppenrahmen wirkt sich jetzt auf die Unterrahmen aus
• Setzen einer Kennung auf Gruppenrahmen über die Template-Verhalten Palette ist nicht mehr möglich

Achtung : Existierende Templates werden aber weiterhin die gezeigten Informationen auf dem Gruppenrahmen haben, um diese loszuwerden bleibt leider nur der Workaround des Neu-Gruppierens.

Ich habe einen Produktaufbau mit 1:N-Elementen. Bis R12321 hat der richtig funktioniert. Jetzt werden Produkte, die vorher in ein1:N-Elemente gepasst haben, plötzlich auf die nächste Seite verschoben. Kann das mit den Fixes für die Fälle 17937, 17984, ... zusammenhängen, über die im History-File berichtet wird?

Hier ein Screenshot (links R12321, rechts R13931)

Ja, tatsächlich, eine Folge der genannten Fixes. Ist behoben (und die alten Fixes gehen natürlich auch noch).

Wir haben im Moment ein Problem beim Aufbau einiger Tabellen per Tagged Text. Es handelt sich um ein Comet 4-Projekt.

Wir nutzen serverseitig das TableData-Objekt aus dem PubserverSDK sowie die DataProcessing-Funktion com.priint.pubserver.comet.bridge.dataprocessing.IndesignTaggedTextFunctions.tableDataToTaggedText zur Konvertierung in Tagged Text. Wenn der Tagged Text dann im Platzhalter-Laden Skript per cscript importiert wird, kommt es zu Problemen. Im InDesign® Client wird die Tabelle ohne Probleme aufgebaut. Beim Aufbau über den InDesign® Server, aus dem Planner heraus, führt der Tagged Text jedoch zum Absturz des InDesign® Servers.

Die Absturzstelle habe wir schnell gefunden: Zur Import-Vorbereitung müssen die in aller Regel ziemlich nachläßlich gemachten TaggedText-Eingaben korrigiert werden. Dazu muß mit regulären Ausdrücken der Text bearbeitet werden. Der Absturz kam immer dann, wenn der gefundene Ausdruck länger als (rund) 630 war. Genauer ließ sich das leider nicht einschränken. Im Testfall waren die StringIDs der Platzhalter bis 800 Zeichen lang (Ist das eigentlich wirklich hilfreich?).

Die Korrektur des Fehler war leider wesentlich aufwendiger. Wir mußten leider die komplette Maschine zum Bearbeiten regulärer Ausdrücke (pcre) erneuern. Die Änderungen betreffen zudem ALLE Plugins. Aber jetzt ist der Fehler gefixt.

Ich versuche eine Liste mit Produkten zu sortieren, habe jedoch das Problem, dass die übergebene Vergleichsfunktion nicht aufgerufen wird.

// Sortierfunktion
int byPosition_asc (Product a, Product b)	
{	
	wlog ("", "Lets sort!");	
	return 0;	
}	
 	
int main ()	
{	
	ProductList 	products = productlist::get("watched");
	
	// Aufruf der Sortierung mit Funktionszeiger
	productlist::sort (products, byPosition_asc);	
}

Was ein schöner Fehler. Wenn ich mir die Implementierung von productlist::sort in den Plugins so anschaue, bin ich richtig ein bißchen stolz auf mich. Dass das überhaupt geht ...  . Einziger Fehler war ein zu kleiner Typecast an der Stelle, an der der Funktionszeiger der Sortierfunktion (hier byPosition_asc) an die C++-STL weitergegeben wird. Da wurde aus der 64-Bit-Adresse aus Versehen ein int32. Bei CS6 hat das nichts gemacht - war eh eine 32-Bit-Anwendung. Aber bei CC kann das dann schon störend sein.

fxd.

Und der analoge Fehler in linklist::sort wurde natürlich auch gefixt.

In InDesign® (Desktop) kann man ja im Fly-Out der Produktrecherche eine Aufbauverfolgung aktivieren. Dabei werden von den Schritten eines Produktaufbaus jeweils Snapshots geschossen und man kann mit Hilfe dieser Bilder leichter Fehler im Aufbau finden. Leider geht das Ganze aber nicht in InDesign® Server.

Mit den neuen Skriptbefehlen

• productlist::set_build_trace
• productlist::get_build_trace

kann man die Aufbauverfolgung jetzt auch mit InDesign® Server verwenden.

Auch wenn die Rahmenauswahl verschiedene Cometgruppen enthält, werden die Rahmen bei "Einfügen als neue Cometguppe" als EINE Cometgruppe eingefügt. Gibt es eine Möglichkeit, die Gruppierungen jeweils zu erhalten?

Dazu gibt es jetzt den neuen Menübefehl "Einfügen mit analogen Cometgruppen".

server::load_placeholder_str

Tabellen in PubServer-Verbingungen können ziemlich großen TaggedText haben. Um diesen Text abzuholen, muss ein cScript vorher einen char*-String allokieren - aber das ist natürlich schwierig, wenn man gar nicht weiß, wieviel Text einen erwartet. Hier ein typisches Beispiel:

char 	* 	buffer 	= alloc(4000000); // was 1000000	
int 		err 	= server::load_placeholder(buffer,4000000);	// was 1000000

Wie könnte man dieses Problem denn lösen?

Es gibt die neue Funktion server::load_placeholder_str. Diese Funktion allokiert den nötigen Speicher selbst. Damit ist das Problem gelöst.

Zusätzlich kann nach der (inzwischen trotzdem als DEPRECATED markierten) Funktion server::load_placeholder mit Hilfe von serror die die tatsächliche Größe des Ergebnisses abgefragt werden und die Funktion im Bedarfsfall mit einem größeren Puffer erneut aufgerufen werden. Beispiel siehe in der Doku von server::load_placeholder.

Ist der letzte Text eines Rahmens eine Tabelle und hat der Rahmen keinen Übersatz, dann wird der Rahmen von der Gestaltungsregel "Textrahmenhöhe anpassen" viel zu hoch. Der Rahmen wird dann nicht um das gewünschte Vielfache der letzten Zeile höher sondern um das Vielfache der gesamten Tabelle.

Oh wow, ja klar. Das war ein Fehler. Ist gefixt.

Die Regel "Textrahmenhöhe anpassen" macht, wenn man eine Zeilenzahl (und kein %-Wert)  angegeben ist, den Rahmen immer um die angegebene Zeilenzahl höher - auch dann, wenn schon genügend Freiraum vorhanden ist.

Ja, das stimmt und war so geplant. Aber, klar, sehen wir ein, das ist vielleicht etwas ungeschickt. Die Regel hat daher jetzt den zusätzlichen Parameter "Rahmen vorher anpassen". Steht der auf "Ja", hat der Rahmen nach Ausführung der Regel einen Weißraum für genau die gewünschte Anzahl Zeilen. Hat der Rahmen einen Übersatz, wird der Rahmen wie bisher um die gewünschte Anzahl Zeilen höher gemacht.

Ich hätte erwartet, dass diese Gestaltungsregel "Rahmengröße setzen" den Textrahmen nach Ausleitung auf die angegebene Höhe anpasst. Aber scheinbar greift sie nicht. Ich leite über Planner mit InDesign® Server CC 2015 aus.

Die Gestaltungsregel "Rahmengröße setzen" enthält hier leider einer Ungenauigkeit: Fehlende Angaben werden als 0.0 mm interpretiert. Für die Höhe wird in diesem Fall die Originalhöhe aus dem Template verwendet. Bei der Breite bleibt die 0.0. Und das geht natürlich nicht.

Dieser Fehler ist gefixt - bei fehlenden Angaben (oder 0 oder 0.0) bleibt die Rahmengröße in dieser Dimension dann unverändert. Die Änderungen betreffen auch das Verhalten der Funktion frame::resize mit Werten gleich 0.0.

Workaround

Setzt man in der Breite einen Wert > 0 funktioniert die Regel auch in älteren Releases.

Werden die Funktionen frame::image oder frame::fit_image in einem Rahmen mit einer Skalierung ungleich 100% angewendet, ist die Bildgröße falsch.

Ja, das ist leider richtig. Es ist uns aber nicht gelugen, so eine Skalierung außer mit eigenen Programierungen nur mit Bordmittlen hinzukriegen. Bei den Berechnungen für Bildplatzieurungen beachten die Plugins jetzt trotzdem die Rahmenskalierung. Damit ist das Problem gelöst.

Im Templateverhalten kann eingestellt werden, ob ein Template beim Produktaufbau auf einer neuen (rechten/linken) Seite beginnen soll:

Leider funktioniert das im dargestellen Fall mit einem InDesign® gruppierten Template nicht. Es wird keine neue Seite angelegt.

Das Problem war (erwartungsgemäß) die InDesign® Gruppe im Template, das den Seitenwechsel auslösen soll. Der Fehler ist gefixt.

ACHTUNG: Die betreffenden Templates müssen nach Installation des gefixten Releases neu gesichert werden!

Workaround

InDesign® Gruppe auflösen.

Die Funktion zum Löschen eines Eintrags aus einer ItemListList mittels Index (itemlistlist::remove_pos) funktioniert nicht. Holt man sich das ItemList-Objekt via get() und löscht es mit remove() gibt es aber keine Probleme.

Oh, das war ein kleiner Index-Fehler bei der Abfrage der Funktionsparameter. Gefixt.

Workaround

Die Position noch mal in einem dritten Parameter wiederholen umgeht das Problem. Also

itemlistlist::remove_pos(ill, 2, 2);

ich möchte gerne mit frame::excel_import eine Excel-Tabelle in einen Rahmen importieren. Aber leider wird gar nichts importiert.

Ja, leider müssen zuvor einmal die Importoptionen für den Excel-Import festgelegt werden. Dazu muß einmal ein manueller Import (Menü Bearbeiten -> Platzieren... gemacht werden und im erscheinden Dialog die Option Importoptionen zeigen aktiviert werden. Danach funktioniert der Funktionsaufruf. Ab dem heutigen Release kann dann auf diesen Schritt verzichtet werden.

Der Skriptbefehl frame::excel_import wirft einen Fehler, wenn der Zielrahmen kein Textrahmen ist. Klar, Tabellen können nur in Textrahmen eingefügt werden. Aber könnte die Funktion in diesem Fall nicht den Rahmen vorher in einen Textrahmen umwandeln?

Sie kann. Ist der Zielrahmen von frame::excel_import kein Textrahmen, wird er jetzt automatisch in einen Textrahmen konvertiert. Enthält der Rahmen ein Bild, wird das Bild vorher entfernt.

Folgendes ist mir heute aufgefallen: Bei Seiten, denen keine Musterseite zugewiesen sind funktioniert die Funktion page::crop() nicht. Es wird hier immer ein interner Fehler geworfen.

Ja, die Musterseite wird geholt, weil evtl. deren Margins angepaßt werden müssen (siehe Doku von page::crop). Da ohne Musterseite auch gar nichts angepasst werden könnte/müsste, ist die Existenz der Musterseite also auch gar nicht zwingend.

fxd

Ja, die Suche bei aufgeklapptem Popup funktioniert, aber wie bereits erwähnt, ist es sehr umständlich.

Macht man die 3 Schritte, muss man dann zum Lesen der Funktion das Menü schließen. Merkt man, dass es nicht die gesuchte Funktion ist, geht man wieder ins Menü. Das Menü hat jedoch den Fokus, die Such-Markierung und die Scroll-Position verloren.
Also wieder

1. Maus-Klick aufs Menü, weil ansonsten die Suche mitten in der Seite startet und nicht im Menü (Test mit Firefox, Win)
2. Strg+F und Wort eingeben
3. Enter, Enter, Enter... (man muss alle Funktionen nochmals überspringen, die man vorher bereits hatte)
4. Funktion durchgelesen, aber nicht was gesucht wurde à Schritt 1

Generell ist es mühsam, dass die Scroll-Position jedes Mal verloren geht. Es genügt schon, wenn man versehentlich die Maus aus dem Menü bewegt.

Oh Gott! Die seitlichen Überschriften sind, wie Sie links sehen, wieder da - das Popup wieder entfernt.

frame::get_page_element liefert falsche Ergebnisse für Produkte über mehrere Seiten

fxd

Von den neuen Funktionen textmodel::set_attr und textmodel::get_attr können nahezu alle Textattribute, die von InDesign® unterstützt, bearbeitet werden. Einzelne Attributfunktionen sind nicht mehr nötig. Hier finden Sie eine Doku zu den Textattributen.

Ich habe gerade festgestellt, dass es zwar placeholder::load(), placeholder::store() und placeholder::build() gibt, aber nicht placeholder::sync(). Hat das einen tieferen Grund oder ist das einfach vergessen worden?

Das ist ein bisschen versteckt : Schau mal in der Doku von linklist::sync nach. Damit das nicht mehr so versteckt ist, gibt es jetzt auch die Funktion placeholder::sync, die exakt linklist::sync entspricht und deren Doku auch auf diese Funktion verweist.

Wird ein Dokument-Platzhalter über die Palette Platzhalter mit einem neuen Platzhalter verlinkt, wird der Dokument-Platzhalter automatisch neu geladen. Kann man das auch unterdrücken?

Ja, kann man. Bei Klick mit gehaltener ALT-Taste wird das Laden unterdrückt. Ein entsprechender Hinweis befindet sich jetzt auch im Hilfetext der Platzhalter-Liste.

Ist ein Textplatzhalter bereits mit einem Produkt verknüpft, wird der Text neu geladen, wenn er über die Palette Platzhalter mit einem neuen Platzhalter verknüpft wird. Rahmenplazthalter werden dagegen nicht neu geladen. Sollte das hier nicht auch gemacht werden?

Ja, schon. Bereits verknüpfte Rahmen werden jetzt auch neu geladen, wenn sie über die Palette Platzhalter mit einem neuen Platzhalter verknüpft werden.

Das wurde ja bereits in R13603 gelöst. Aber sollten diese Regeln dann nicht auch ausgeführt werden, wenn der Platzhalter neu geladen wird?

Sollten sie, sollten sie. Und werden sie jetzt auch.

Ist das automatische Sichern von Templates aktiviert (prefs::add_w2ml_to_templates), werden jetzt auch beim Sichern von Seitentemplates W2ML-Varianten der Seitentemplates erzeugt. Die W2ML-Varianten der Seitentemplates werden beim Textflußaufbau in comet_pdf benötigt (der demnächst umgesetzt wird.)

In XML-Offline, SOAP- und Pubserver-Verbindungen sind keine weiteren Installationen nötig. In ODBC- und Oracle-Datenverbidnungen muß die Tabelle pagetemplates erweitert werden, mehr dazu siehe hier.

Wählt man einen Platzhalter im Dokument aus, wird automatisch der zugehörige Platzhalter in der Palette Platzhalter ausgewählt. Ist der durch Scrollen der Platzhalterliste momentan unsichtbar, wird die Liste entsprechend gescrollt, so dass der ausgewählte Platzhalter sichtbar wird. So war das zumindest früher. Seit mind. R11811 wird aber nicht mehr gescroll - und die Listenauswahl bleibt mglw. unsichtbar.

fxd

Der Javascriptbefehl app.comet.setItems erwartet u.a. einen String mit den einzufügenden Seitentemplates und Produkten, die sog. items.xml. Der String muß dabei die XML als TEXT enthalten. Seit v4.0.5 R11700 kann der String auch ein Dateipfad sein (was in den meisten Fällen auch viel einfacher ist.) Leider scheint das aber nicht zu klappen - ich erhalte immer den Fehler 538632 (Malformed XML).

Jetzt geht es :-)

Nach dem Ausführen der Seitenadaption in der Palette „priint:adjust“ wird nicht nur das Format angepasst, sondern die Montagefläche zieht sich auf die Spreadgröße zusammen.

Das Problem ist beim Aufräumen von überflüßigem und zeitaufwendigem Quellcode in R12500 entstanden. Der Anweisungsblock zum Ermitteln der Ausgangsgröße der Montagefläche ist dabei versehentlich verloren gegangen. Wir haben die entsprechenden Anweisungen wieder eingefügt und damit behält die Montagefläche wieder ihre korrekte Größe.

Ich habe einen Textrahmen mit einem Platzhalter. Der Platzhalter setzt ein Inline ein, das aus einem Template geladen wird. Liegt der Textrahmen auf einer Dokumentseite, kann der Inline richtig eingefügt werden. Liegt der Textrahmen aber vollständig auf der Montagefläche, wird kein Inline eingefügt. Im Logfile erscheint die Meldung:

# Invalid frame found at DataLinkUtils::IterateStories line 1621
# Cannot insert page item 4, error 1112.

Bevor der Rahmen aus dem Template zu einem Inline gemacht werden kann, muß er zuerst einmal ins Dokument geladen werden. Dazu wird eine Zielseite benötigt. Dazu wird die Seite verwendet, auf der der Textrahmen liegt - aber die hat, wenn sie ganz auf der Montagefläche liegt, gar keine Seite. Daher der Fehler. Es ist aber möglich, die dem Rahmen am nächsten liegende Seite zu ermitteln. Damit ist das Problem gelöst.

Folgende Ausgangssituation: Ein Rahmen auf der linken Seite, ein Rahmen auf der rechten Seite. Keine Gruppierung.

Fügt man diese beide Rahmen in eine ItemList und führt itemlist::bbox() aus, werden NUR die Koordinaten des linken Rahmens zurückgegeben. Unabhängig davon, ob bei der itemlist::bbox() der Parameter spreadRelative auf false oder true ist.

Wären beide Rahmen gruppiert, würde es mit der Referenz auf die Rahmengruppe funktionieren. Jedoch kann in unseren Fällen nicht immer davon ausgegangen werden, dass die Elemente gruppiert sind.

Dies ist vor allem sehr ungünstig, wenn Rahmen eines Templates über die Mitte der Doppelseite bzw. rechts auf die Montagefläche ragen, weil der Rahmen automatisch zur nächsten Seite zählt, wenn 50% der Fläche auf der nächsten Seite sind obwohl die linke Kante auf der anderen Seite ist.

Ja, das ist so gewollt. Warum das so ist, erkennt man leicht, wenn man mal ein Dokument nimmt, das auf mehreren Spreads Rahmen enthält: Die Boundingbox würde dann eine Größe bekommen, die mit der Wirklichkeit nichts mehr zu tun hat.

Ich habe der Funktion itemlist::bbox trotzdem zwei weitere Parameter mitgegeben, mit denen gesteuert werden kann, ob man bei Listen mit Rahmen von verschiedenen Seiten festlegen kann, ob

1. Die Rahmen der ersten oder letzten Seite (oder des Spreads) verwendet werden sollen
2. Die Rahmen von der ersten/letzte Seite oder dem ersten/letzten Spread verwendet werden sollen.

Das sollte das Problem lösen.

Kann es sein, dass frame::fit_image Skalierungen nur bis max. 100% der Bildgröße macht?

Ja, das ist so gewollt. Ich habe der Funktion trotzdem einen weiteren (optionalen) Parameter gegönnt, mit der maximale Skalierung auch über 100% möglich sind.

Nach Ausführung von document::schwarzfilmtausch haben manche Tabellen immer noch variable Zeilenhöhen.

fxd

Beim Setzen von Textplatzhaltern gehen die Textgestaltungsreglen verloren.

Jetzt nicht mehr :-)

Negative globale Float-Variablen werden in der Palette 'Einstellungen' falsch angezeigt.

Es handelt sic hier lediglich um einen kleinen Fehler bei der Darstellung. Für Berechnungen werden die richtigen Werte verwendet. Der Fehler ist gefixt.

Können die Gestaltungsregeln eines Rahmens auch über cScript bearbeitet werden?

Bisher ging das nicht.

Aber ab jetzt kennen die Funktionen placeholder::sget_value und placeholder::change_tags auch den Slotnamen "LayoutRules". Damit können nun auch Getsaltungsregeln von Rahmen und Textplatzhaltern bearbeitet werden.

Leider ist die Suche nach Funktionen mit der neuen Navigation sehr sehr mühsam. Zuvor war die Navigation bzw. das Menü an der linken Seite fixiert. Dadurch, dass es nun ein Popup ist, funktioniert die Browser-Suchfunktion dort nicht mehr bzw. ist es sehr umständlich.

2 Anwendungsfälle

1. Suche nach der Funktion file::path()
   Da das Wort "path" in der file.html über 100 Mal vorkommt, muss man die Funktionen im Menü der Reihen nach durchschauen. Das Menü ist aber auch nicht alphabetisch sortiert.
2. Suche nach einer Funktion, welche mir die Info gibt, ob ein Rahmen ein Bild enthält. Vermutlich schaut man in der Klasse "frame" unter den image-Funktionen. Die tatsächliche Funktion lautet aber frame::has_image(). Die Funktion steht jedoch nicht direkt bei den Image-Funktionen und eine alphabetische Sortierung würde auch nichts helfen.

Daher war die Browser-Suche immer am besten.

Ich fasse das mal als (verspätetes) Lob für das alte Design auf, zu dem nie jemand irgendwas gesagt hat. (Außer so einem allgemeinen Grundrauschen, dass das alles - na, muß ich hier vielleicht nicht wiedergeben ...).

Ich habe die seitlichen Überschriften so gemacht, wie sie auch Eclipse für dessen Java-Doku erzeugt. Dort ist das ja offenbar allgemein anerkannt. Die Schwierigkeiten, die sich bei der HTML-Suche ergeben, verstehe ich. Ich habe deshalb den Index der cScript-Doku so erweitert, dass dort jetzt auch die einzelnen Methoden-Funkionen enthalten sind. Sieht etwa so aus.

Das Tutorial für den Produktaufbau ist in einer aktualisierten HTML-Fassung verfügbar.

In der Produkte des Dokumentes kann man ja in den Seitentemplate-Einträgen den Seitentyp einstellen - das kleine Seiten-Icon am Anfang der Zeile. Kann es sein, dass das genau verkehrt herum ist. Bild links für rechte Seite, Bild rechts für linke Seiten?

Offenbar ja. Merkwürdig, dass das noch niemand bemerkt hat.

fxd

Wenn ich ein Seitentemplate per Drag&Drop in die Produkte des Dokumentes - Palette ziehe (ProductType 4) und dann den (erzwungenen) Seitentyp umstellen will, scheitere ich. :-( Das ging vorher mal mit einfachem Doppelklick.

Wenn ich versuche das Icon so wild per Drag&Drop "hin und her" zu ziehen, schaffe ich es (zumindest beim ersten Eintrag) den Seitentyp umzustellen. o_O

Hallo, du hast gleich zwei Bugs auf einmal entdeckt: Als erstes kann man den Seitentyp nur umstellen, wenn man auch gleichzeitig die Selektion in der Liste ändert, zweitens funktioniert das Umstellen selbst dann nur im ersten Eintrag der Liste.

fxd

die cScript Funktion page::set_masterpage gibt immer Fehler 1 (interner Fehler) zurück, auch wenn der Skriptbefehl alles richtig gemacht hat.

fxd

Ecknägel arbeiten bei Verkleinerungen falsch und Rahmen mit relativen Ecknägeln erreichen ihre originale Größe nicht wieder.

fxd

Gedrehte Rahmen werden bei Seitenadaptionen sehr komisch verzerrt. Es sieht aus, als hätte der Rahmen eine Zerrung (skew) bekommen - aber die ist 0.

fxd - Mehr dazu siehe hier.

Mein Dokument enthält eine einzige Seite mit einem einzigen Rahmen. Der Rahmen geht über die ganze Seitenbreite und hat links und rechts Nägel. Das Dokument ist so eingestellt, dass die Adaptionen auch auf Seitengrößenänderungen (Menü Datei -> Dokument einrichten ...) ausgeführt werden sollen. Ich adaptiere auf drei Arten:

1. manuell mit den Testbuttons : funktioniert reibungslos
2. Button unten in der Palette : falsche Rahmenposition
3. Menü Datei -> Dokument einrichten ... : funktioniert manchmal, aber ich kann nicht reproduzieren, wann und wann nicht.

Gefixt.

Das Problem wurde durch die Unterstützung der automatischen Adaption nach Seitengrößen-Änderungen (Menü Datei -> Dokument einrichten ... oder Javascript doc.documentPreferences.pageWidth / Height) verursacht. Wir haben die automatische Adaption daher wieder abgeschaltet.

Die in R9900 eingeführte automatische Seitenadaption nach Änderungen der Dokument-Seitengröße wird nicht mehr unterstützt! Verwenden Sie zum Ändern der Dokumentseitengröße mit gleichzeitiger Adaption das Button unten in der Palette priint:adjust oder die Javascipt-Anweisungen doc.adapt / adaptBy.

Die Erläuterung des Problem ist ziemlich technisch:

1. Wenn InDesign®nbsp;die Seitengrößen eines Dokumentes verändert, werden teilweise Rahmen verschoben, landen auf anderen Seiten oder verlieren sogar ihre Seite. Das können Sie leicht selbst nachstellen.
2. Wir merken uns daher vor dem Ändern der Seitengrößen die aktuellen Rahmenpositionen und -seiten und stellen sie danach wieder her.
3. Im automatischen Fall bekommen wir aber leider keine Vorankündigung über die Änderung der Seitengröße sondern werden vor vollendete Tatsachen gestellt. Waren von einer vorangegangen Adaption die Rahmenpositionen noch richtig gespeichert, funktioniert die Adaption, sonst eher nicht. Und dieser fehlende Notifier ist das Problem, das wir nicht lösen können - das könnte nur Adobe.

Die Felder mit den Parameterwerten von Gestaltungsregeln sind recht schmal. Könnte man die nicht etwas verbreitern? 

Getan. Die Felder sind jetzt statt 150 Punkten 225 Punkte breit.

In der Palette Gestaltungsregeln wird als erste Regel immer "Rahmen anpassen (DEPRECATED)" angeboten. Könnte man diese Regeln nicht etwas weniger prominent in die Auswahl einfügen?

Man kann. Die Regel steht jetzt erst an zweiter Stelle. Als erstes angezeigt wird jetzt immer die Regel Rahmen anpassen.

Wenn man einen Rahmen mit vertikalem Texten in InDesign® an seinen Inhalt anpasst, wird der Rahmen rechts festgehalten und verändert seine Größe links. Die Gestaltiungsregel Rahmen anpassen und der Skriptbefehl frame::fit(_better) verändert die Größe aber nach unten.

Das ist gefixt. Rahmen mit vertikalem Text werden jetzt von frame::fit_better und er der Gestaltungsregel Rahmen anpassen automatisch nach links vergrößert. Ist in der Gestaltungsregl Rahmen anpassen wird bei Festhalten X links bei vertikalen Texten automatisch rechts festgehalten und umgekehrt. Damit keine Verwirrungen entstehen, sind die Angaben im Popup angepasst:

    links (vertikaler Text rechts)
    mitte
    rechts (vertikaler Text links)

Achtung : Die vertikale Rahmenanpassung wird nur bei frame::fit_better und in der Gesstaltungsregel Rahmen anpassen gemacht. frame::fit und Rahmen anpassen (DEPRECATED) bleiben unverändert und unterstützen das Feature nicht.

Auch wenn Ihr InDesign® keine Palette und Einstellungsmöglichkeiten für CJK (Chinese/Japanese/Korean) hat, jedes InDesign® kann mit diesen Texten umgehen und wird einen vertikal gesetzten Text mit japanschen Schriftzeichen, Tatechyokos auch richtig darstellen.

Es ist relativ einfach, ein japanisches InDesign® zu bekommen: Einfach die Sprache in Crative Cloud auf Japanisch stellen und InDesign® neu installieren. Das de

Ich habe ein Dokument neu geöffnet und die Palette Platzhalterwerte geöffnet. Wenn ich jetzt ein bisschen in Platzhaltern in Tabellenzellen herum klicke, bekommt das Dokument plötzlich einen Änderungsstatus. In normalen Platzhaltern kann ich klicken wie ich will, das Dokument bleibt weiter "unverändert". Das Ganze ist nicht weiter tragisch, ich wollte sowieso ändern. Aber das Gleiche passiert auch, wenn linklist::text_collect auf einem gesicherten Dokument ausgeführt wird - auch hier ist das Dokument danach verändert und muß neu gesichert werden. Da der Aufruf aber in einem AfterSave-Skript ausgeführt wird ... Auffällig sind diese Meldungen im Log:

# Broke place holder [12, 25] into two at 24

Ja, das ist in der Tat doof. Beim Durchwandern der Platzhalter wird automatisch geprüft, ob Platzhalter über Tabellenzellen hinausragen. Das ist sehr schlecht, weil dann beim Laden der Platzhalter die Zelltrenner verloren gehen würden, was das Dokument unrettbar zerstört. Deshalb teilen wir soclche Platzhalter an der Zellgrenze. Zusätzlich löschen wir den Platzhalter auf der Zellgrenze jetzt auch. Damit ist das Problem in Zukunft behoben.

Seite CC2015.4 wird, wenn die Seitentemplates im Seitehintergrund gezeigt werden soll, die ganze Seite ziemlich kräftig blau. Die Seitenelemente sieht man vor diesem Hintergrund kaum noch:

fxd

Obwohl ich gar nichts mit einer Tabelle gemacht habe, liefert cScript den Fehler tableRefErr. Früher hieß die Beschreibung von serror dazu "Tabelle nicht gefunden", inzwischen heißt es "interner Fehler".

Ja, die cScript-Funktionen geben häufig den Returncode der verwendeten InDesign® Funkionen zurück. Leider ist das ziemlich häufig das etwas allgemeine kFailure (=1). Und das überschneidet sich auch noch mit unserem Fehler "Tabelle nicht gefunden". Wir beginnen mit unseren Fehlern daher jetzt erst ab Nummer 11.

Mir ist aufgefallen, dass bei Einsatz eines SOAP-Servers, die w2ml-Dateien beim Löschen eines Templates nicht gelöscht werden. Die indd-, shape und auch die Vorschaudatei werden dagegen gelöscht. Eigentlich sollte dann auch die w2ml-Datei gelöscht werden.

Die w2ml-Dateien wurden auch plugin-seitig bisher nicht gelöscht. Das wird jetzt getan. Bei SOAP-Verbindungen bekommt der Server, wie auch bei den anderen Dateien, die zu einem Template gehören, jetzt als Lösch-Signal eine leere leere Datei geschickt:

File-ID : pageitems/data/NNN.w2ml
Kommentar : Removed page item w2ml NNN

Diese Nachricht sollte der SOAP-Service dann genauso behandeln, wie die analogen Nachrichten für shapes (pageitems/data/NNN.shapes) und Previews (pageitems/preview/NNN.gif).

In normalen Seitenelementen, die nur ein Produkt aufnehmen können, werden Rahmen, die Fortsetzungen haben, bei Reorganisationen immer auf ihre Höhe im Template zurückgesetzt, nicht auf die Höhe, die das Element erlaubt.

fxd

Hat eine Seitenelement eine Ausrichtung ungleich links/oben, wird das dort platzierte Produkt trotzdem links oben platziert. Das passiert immer dann, wenn das Produkt Fortsetzungen hat. Immer nur die letzte Fortsetzung ist richtig platziert.

... und das auch schon mind. seit R8000 (was immerhin fast 1,5 Jahre zurückliegt).

fxd

Es reicht schon, wenn 2 User am PubServer gleichzeitig arbeiten. Zum Testablauf:

• User1 erstellt ein Seitentemplate und läd dieses per Palette auf den PubServer hoch. Danach macht er ein Refresh der Template Palette und sieht auch das von Ihm angelegte Seitentemplate.
• User2 geht danach auch hin und erstellt und speichert ein Seitentemplate auf dem PubServer. Nach Refresh der Palette sieht dieser ebenfalls das von Ihm erstellte Template auf dem Server, jedoch sieht er nicht das Template von User1. Umgekehrt ist es genauso. Nach einem neuen Refresh von User1 sieht dieser immer noch lediglich das von Ihm erstellte Template.
• Beide User melden sich danach vom PubServer ab und loggen sich erneut ein. Nach Öffnen und Laden der Seitentemplatepalette sehen User1 und User2 lediglich noch das Template das User2 erstellt hatte. Das Template von User1 scheint verschwunden. Auch eine Überprüfung im Repository ergab, dass das Template von User1 komplett weg ist.

fxd

Während InDesign® an einer Datenbank eingeloggt ist, geht die Server-Verbindung verloren, z.B. dadurch, dass man den Server einfach abschaltet. Wenn später die Verbindung wieder hergestellt werden kann, stürzt InDesign® ab.

Der Absturz passiert beim Aufräumen einer Datenbankabfrage. Ich kann das reproduzieren, wenn ich bei mir unterwegs mal den mySQL Server abschalte. Dann passiert genau das Gleiche - allerdings nicht nur in Platzhalterwerte - es können auch die Schmerzschreie anderer Paletten sein. Irgendwie ist ja auch klar, was da passiert

1. Eine DB-Abfrage wird gestellt
2. Die Verbindung geht verloren.
3. Die DB-Abfrage wird abschlägig beantwortet
4. Die DB-Abfrage wird von uns zurückgezogen

"Zurückziehen" heißt in diesem Fall, alle erzeugten Abfrage-Daten wieder zu löschen. Nur leider sind diese Daten nur noch leere Hüllen, die der ODBC-Connector offenbar nicht mehr behandeln kann. Denn der Absturz passiert ja laut Crash-Log im ODBC-Konnektor (org.iodbc.core... SQLCloseCursor), zu dem wir ein viel entfernteres Verhältnis haben als jetzt z.B. Sie, die Sie ihn käuflich (oder wie auch immer) erworben haben. Wir rufen den Connector lediglich auf - dass das Verhältnis so enden muss, finden wir auch -- enttäuschend? Dabei sind wir sogar noch ziemlich gesprächsbereit und versuchen mehrere Reconnects. Die sollten eigentlich mind. im Log vermerkt sein:

* ODBC: connection gone away, try reconnect [ 26. Juli 2016 03:49:48 ] ...  

Eigentlich ein feiner Zug von uns, dass wir sogar für so was noch eine Lösung finden: Zumindest mein Test, einfach mal den mySQL-Server abzuschalten, funktioniert jetzt und die Plugins kommen nach einen Re-Connect wieder problemlos weiter.

Grundsätzlich sollte die Doku-Sprache der InDesign® Sprache entsprechen. Da wir zwar (teilweise) französische und japanische Plugins haben, aber keine passende Doku dazu, weichen die Plugin ab jetzt automatisch auf Doku_enEN aus, wenn der Doku-Ordner nicht in der passenden Sprache vorhanden ist.

Ich habe einen Textrahmen, über dem ein Bild mit Textverdrängung (text wrap) liegt. Auf den Textrahmen wird ein fitframe angewendet. Beim Aufbau der Produkte ist alles gut - der Textrahmen bekommt genau die richtige Größe. Wenn ich aber reorganisiere, hat der Text danach einen Übersatz - und zwar genauso viel, als hätte das Bild KEINE Textverdrängung.

Textverdrägnungen sind ganz schädlich für die Reorganisation: Beim Verschieben der Rahmen können Rahmen in den Bereich einer Textverdrängung geraten. In dieser Situation in ihrer Größe angepasst, werden sie falsch, sobald sie selbst oder die Textverdrängung bewegt werden. 
Vor der Reorganisation einer Seite werden deshalb alle Textverdrängungen abgeschaltet - und erst zum Schluß wieder aktiviert. Um das beschriebene Problem zu lösen, werden jetzt die Textverdrängungen, die zur gerade bewegten Cometgruppe gehören, für die Dauer der Bewegung wieder aktiviert. Damit ist das Problem gelöst.

internal note : see calm+ in ImportFocus

Ich habe ein 1:N-Seitenelement mit drei breiten Produkten. Allen drei Produkten wird beim einem Templatetausch ein sehr viel schmaleres Template zugewiesen. Reorganisiere ich die Seite, klappt das auch - alle drei Produkte haben wie erwartet das neue Template. Nur könnten die Produkte jetzt auch nebeneinander stehen - aber sie werden untereinander platziert. Erst wenn ich die Seite noch einmal reorganisiere, stehen die Produkte dann auch nebeneinander. Es scheint, als würden die Rahmen des alten Templates die neuen Rahmen noch verdrängen.

Das scheint nicht nur so - so war es auch. fxd

internal note : see calm+ in ImportFocus

Das Problem wird durch ein PageItemScript hervorgerufen: Aufgebaut wurde mit Template 28. Dessen PageItemScript sagt, nimm doch die 29. Also wird 29 aufgebaut. Bei der Reorganisation werden Orignal-Template (immer noch 28) und verwendetes Template (29) verglichen. Und weil die unterschiedlich sind, wird neu geladen. Aber die Prüfung gegen das Original ist wichtig, weil das PageitemScript ja durchaus auch komplexer  sein kann und z.B. schaut, ob ein Produkt das erste Produkt eines Kapitels ist und erst dann den Templatewechsel veranlasst.).

Das Problem ist gelöst. Die Rahmen werden jetzt einfach verschoben und nicht mehr neu geladen.

internal note : see calm+ in ImportFocus

An error message occurs when pushing the synch button of product panel in whiteboard. I changed the revision of the IDS plug-ins from 12021 to 11201 (last sprint version) and the error message doesnt come up anymore.

fxd

Was wir schon immer mal sagen wollten:

Mit cScript haben Sie immer einen Trumpf in der Hand.

Ich habe in einem Dokument drei Produkte aufgebaut und in der Produktrecherche vier Produkte ausgewählt. Beim Synchronisieren der Produkte (Button << der Produkte des Dokumentes) erscheint das zusätzliche Produkt aber nicht als neues Produkt in der Liste. 

Nach längerer Suche konnten wir den Fehler finden: Der Fehler tritt immer dann auf, wenn das Seitentemplate die gleiche ID wie das zusätzliche Produkt hat. Dann wurde die ID zwar in der Liste des Dokumentes gefunden. Aber es wurde nicht erkannt, dass beide Objekte von unterschiedlichem Typ sind.

Der Fehler betrifft auch die Javascript-Funktion app.comet.matchItems.

fxd.

Wie kann ich denn die Hintergrundfarbe eines Rahmens entfernen, so dass der Rahmen die "Farbe" [Ohne] verwendet?

Das geht mit dem Farbfeldname "None" (in genau dieser Schreibweise). Ich habe die Doku entsprechend erweitert, siehe dazu frame::color.

Ich habe versucht, mit color::redefine_swatch die Standardfarbe "Papier" zu ändern. Dabei entsteht das neue Farbfeld "Paper Kopie" - und ist schwarz.

Na, das ist ja immerhin was, oder? Ich habe die Funktion so geändert, dass die Standardfarben None, Registration, Black und Paper (ja, auch Paper!) jetzt nicht mehr geändert werden können.

Wenn ich color::get_colors mit der Farbe "None" aufrufe, erhalte ich zwar eine Antwort. Die Farbwerte sind aber eher zufällig und ich kann an ihnen nichts erkennen.

Was ein Luxusproblem. Man sollte zumindest Farbbereich eigentlich vorher schon kennen - sonst kann man ja die Ergebnisse gar nicht richtig auswerten. Wie auch immer, bei "None" werden jetzt alle Farbanteile auf -1.0 gesetzt.

Obwohl in einem Bild ein Freistellpfad verwendet wird, liefert Funktion image::clipindex manchmal den Wert -1.

Ja, das ist richtig. InDesign® will uns mit dieser Angabe sagen, dass der Default-Freistellpfad verwendet wird. Das war nur leider aus der mageren Doku der InDesign® C++-API nicht so recht ersichtlich und wurde deshalb von den Plugins mißverstanden als "Kein Pfad verwendet".

Das ist gefixt. Wird der Default-Freistellpfad verwendet, liefert image::clipindex jetzt den Wert kDefaultClipIndex (-4). Diese Angabe wird auch von der Funktion image::clipindex verstanden und richtig angewendet.

In-Tags, die einen Rahmen definieren und den mit einem Platzhalter versehen werden nicht geladen.

Der Platzhalter 50 sollte eigentlich ein Bild in den Rahmen laden, statt dessen erscheint nur der Text Dummy Text.

<in: 100.0,100.0, 50, 1, 0, 0, 'abc'>Dummy Text</in>

In R10301 hat das noch funktioniert.

Das Problem ist ein unerwarteter Seiteneffekt des Fixes von Fall 16910: Der Bildplatzhalter wurde geladen - und kurz darauf durch den Text des Inlines (hier 'Dummy Text') wieder ersetzt.

fxd

Workaround

Lässt man den Text zwischen den Tags weg, funktioniert alles, also

<in: 100.0,100.0, 50, 1, 0, 0, 'abc'></in>

frame::release_inline verwendet die aktuelle Dukumentauswahl und ist deshalb nicht für InDesign® Server zu verwenden.

fxd - Die Funktion kann jetzt auch unter InDesign® Server verwendet werden.

InDesign® CC 2015.4 - GUI-Problem macht Gestaltungsregel-Palette unbenutzbar.

Das Problem betrifft, soweit wir das jetzt übersehen, ALLE unsere Paletten (und so ganz nebenbei auch alle Paletten von allen InDesign® Plugin-Entwicklern weltweit). Und nicht, dass Adobe vielleicht im Prerelase-Forum da mal drüber geredet hätte ...

Wir versuchen, das so schnell wie möglich zu korrigieren. Aber klar, wir haben natürlich, wie jeder andere auch, schon immer versucht, Paletten so klein wie möglich zu halten. Und wenige Palette sind das auch nicht gerade. Das wird wohl schon einen Moment dauern.

Alle Paletten sind jetzt für CC 2015 v4 angepasst. In Vorgängerversionen sind die Paletten unverändert.

Achtung : Die von Adobe verwendete größere Schrift schlägt auch auf Listen in den Paletten durch. Das erfordert höhere Tabellenzeilen in allen Paletten. Es können also ingesamt weniger Zeilen auf dem Bildschirm dargestellt werden.

Derzeit habe ich das Problem, dass das Speichern von Comet-Templates extrem lange dauert (ca. 5min!).

Das ist kein Problem der Plugins. Im Logfile ist ja eigentlich ziemlich klar zu sehen, wo die Zeit bleibt : Der Upload der geänderten pageitems.xml dauert jeweils ungefähr zwei Minuten! Für die 10-mal größere INDD-Datei werden dagegen nur 0,03 Sekunden benötigt! Der Pubserver ist also offenbar sehr beschäftigt mit dem Auswerten der neuen/geänderten Templates.

Dieses Problem ist mit Fall FogBugx 17516 aber bereits gelöst. Die Installation eines neuen PubServers (9.6., Versionen 4.0.5 und 4.1) sollte das Problem also lösen. Alternativ kann das Problem dadurch gelöst werden, dass allen Templates eine Domain zugewiesen wird. (Das war der Fehler in Case 17516).

Beim Logout oder auch beim Beenden des Programmes kommt es immer mal wieder vor, dass InDesign® abstürzt. Der Crashlog erwähnt als letztes das Pluign PlaceholderValues.

fxd

Immer mal wieder fragt jemand, was das soll, das Menü Zusatzmodule -> Verbinden mit Internet? Da der entsprechende Service lokal läuft, is ja gar nichts mit Internet.

Wir haben das mal umbenannt von Verbinden mit Internet in

    Verbinden mit Publikationsserver...

Die Gestaltungsregel "Spaltenbreiten anpassen" funktioniert immer dann nicht, wenn 

• Die Tabelle zuerst auf Rahmenbreite gebracht werden soll
• Die Tabelle breiter als der Rahmen ist
• Die erste Spalte schmaler ist als der Tabellenteil, der rechts über den Rahmen hinausragt.

Ja, die Tabelle wird zuerst auf die gewünschte Breite gebracht, danach werden die Spalten angepasst. Der erste Schritt ging dabei voll zu Lasten der ersten Spalte. Das ist gefixt.

In mehrspaltigen Texten bewirkt die Gestaltungsregel, dass die Tabelle auf Rahmenbreite angepasst wird. Sollte man da nicht eigentlich die Spaltenbreite nehmen?

Die Regel "Tabellenbreite anpassen" hat jetzt einen zusätzlichen Parameter, mit dem das eingestellt werden kann. Default ist die alte Verhalten - also die RAHMENbreite als Referenz für die Tabellenbreite.

Bei dünnen Linien sieht man es kaum. Aber hat eine Tabelle links und/oder rechts dickere Außenkanten, dann wird die Tabelle um die Stärke dieser Kanten zu breit.

InDesign® platziert Tabellen links immer so, dass die stärkste linke Zellenkante genau an der linken Rahmenkante (oder der inneren Rahmenkante oder dem linken Inset) anstößt. Dadurch verbreitert sich die Tabelle schon mal um die halbe Breite der stärksten linken Zellkante. Das ist gefixt. Analog werden jetzt auch die rechten Zellkanten ausgewertet und die Tabelle noch weiter verkleinert, dass auch rechts an der Rahmenkante angestoßen wird. Hier ein Vorher/Nachher-Screenshot:

Seit sich InDesign® auf die neue Version CC 2015.4 aktualisiert hat, lässt sich die Gestaltungsregel-Palette nicht mehr korrekt bedienen. Die zugewiesenen Regeln sind nicht mehr sichtbar.

Einerseits

Ganz so schlimm ist es nicht. Die erste Regel ist mehr sichtbar.

Andererseits

Es ist noch viel schlimmer. Adobe schreibt in dein Hinweisen zu den Neuerungen in CC2015 v4 folgendes:

Mehr als 500 Dialogfelder wurden neu gestaltet, indem die Höhe der Steuerelemente der Benutzeroberfläche vergrößert wurde. (https://helpx.adobe.com/de/indesign/using/whats-new.html#june_2016)

Adobe hat das auf die harte Tour gemacht und einfach die Standardschriften für die Paletten vergrößert. Das bedeutet für uns (und ALLE, die Plugins mit Paletten) entwicklen : ALLE PALETTEN müssen neu gestaltet werden. Teilweise sind die Änderungen so gravierend, dass Kontrollfelder sich überlagern und damit auch Funktionalität verloren geht. Wir haben zwar nicht 500 Paletten und Dialoge, aber gute 30 sindws auch.

Das Sammeln der Links für Packages wurde gefixt. Hintergrund war folgendes:

1. InDesign® stürzt sowohl beim Javascript-Befehl document.packageForPrint als auch bei der entsprechenden C++-API-Funktion ab, sobald man da die Forderung stellt, dass die Links (also die Bilder) kopiert werden sollen. Das ist natürlich ziemlich blöd. Deshalb haben wir das selbst implementieren müssen.
2. Wir bekommen die Dateipfade als URIs. Dabei haben wir übersehen, dass der Laufwerksname in UNC-Pfaden nicht Teil des Pfades der URI ist, sondern zum sog. authority-Teil der URI gehört.

Wenn man bei geöffneter Platzhalterwerte-Info Palette einem ausgewählten Rahmen einen Rahmenplatzhalter zuweist, aktualisiert sich die Palette nicht, die Platzhalterwerte-Palette hingegen schon.

Bei der ersten Zuweisung eines Platzhalters funktioniert es noch, danach nicht mehr.

fxd

Bei Gestaltungsregeln die auf Geometrieänderungen reagieren, gibt es die globalen Variablen gFrameTopBefore, gFrameBottomBefore, etc.. Neuerdings enthalten diese aber die Koordinaten des Rahmens nach der Geometrieänderung und nicht die davor.

fxd

In der Doku (cscript/TaggedText.html) steht, dass in-Tags geschachtelt werden können. Das klappt aber offenbar doch nicht richtig.

fxd

Ich habe eine TaggedText, der von InDesign® mit der Option "Platzhalter nicht in den TaggedText übernehmen" erzeugt wurde. Dieser Text enthält anstelle der Platzhalter jede Menge <dps:>-Tags und kann nicht wieder importiert werden.

Die <dps:>-Tags entstehen beim Export von TaggedText ohne Come-Platzhalter. Aus technischen Gründen ist es leider nicht möglich, die Comet-Platzhalter einfach nicht zu exportieren - irgendeinen nichtleeren Export erwartet InDesign® hier leider. Und leider stimmt auch "irgendeinen nichtleeren Text" nicht - es muss schon ein definiertes Tag sein. Sonst erscheint das Tag als Text im Dokument. das <dps:> bot sich dafür an : InDesign® kennt es und ignoriert es.

Wie wir hier sehen, kann InDesign® aber leider nicht an jeder Stelle (oder in beliebiger Anzahl) damit umgehen: Ich habe den TaggedText mal mit

prefs::set_logstate (1, 1);

ins Log geschrieben und den Log-Text in einen Datei kopiert. Auch dieser direkte Import führt zum Absturz von InDesign,reg; auch wenn die Comet-Plugins gar nicht installiert sind. Das ist natürlich mißlich. Wir haben deshalb unseren Import so geändert, dass vor dem Import alle <dps:> aus dem Text gelöscht werden. Damit ist das Problem gefixt.

Ich habe einen TaggedText mit in-Tags. Der Import dieses Textes funktioniert mit CS6 Desktop. InDesign® Server (CS6, Windows!) stürzt mit dem gleichen Text ab. Der gleiche Server unter Wndows funktioniert. Nach längerer Suche habe ich rausgefunden, dass mein Text falsch ist - es fehlt ein schliessendes in-Tag (</in>). So einfach kann man den Server zum Absturz bringen? 

Das betraf nur den Windows-Server, weil der ein 64-bit-Programm ist - und das Ganze ein 64-Bit-Problem war. fxd.

Im Falle einer SQL Datenbank Verbindung scheinen die in der 'messages' Tabelle hinterlegen Übersetzungen nicht zu funktionieren.

fxd

In der Platzhalterpalette können beim aktivieren der Suche mit der Lupe mit gedrückter Alt-Taste im Falle einer SOAP Verbindung alle Platzhalterdaten vom Datenbestand neu eingelesen werden. Das sollte auch die Domains neu laden, nach denen man die ganze Suche filtern kann (das drop down menu). Tut es aber nicht :-(

Es wird jetzt immer versucht die Domain Auswahl wieder herzustellen. Wenn das nicht möglich ist (z.B. weil die Domain nicht mehr existiert) wird "Beliebiger Bereich" auswählt und alles geladen.

fxd

Die Bildpfade in in-Tags sind offenbar nicht system-unabhängig. Ich habe ein in-Tag

<in:64.0, 64.0, "/Users/paul/Desktop/aaa.png", 1><in:>

Auf dem Mac bekommt der Inline das Bild aaa.png. Unter Windows, wo ich die selbe Datei auch auf dem Desktop liegen habe, bleibt der Inline leer.

fxd

Enthält ein Dokument Barcodes, die mit image::barcode erzeugt wurden, kann es nicht mehr fehlerfrei in IDML exportiert und danach aus diesem IDML wiederhergestellt werden. U.U. stürzt InDesign® beim Öffnen der IDML gleich ganz ab.

Ich konnte das Problem auf ein überraschendes Verhalten des IDML-Imports reduzieren: Bei direkt eingebetteten Postscript-Dateien versucht der Import (oder vielleicht auch schon der Export, wer weiß das schon?), das Postscript-Bild in ein Pixel-Bild (unbekannter Auflösung) zu konvertieren - und das auch noch grottenfalsch und manchmal scheitert scheitert es daran völlig. Das Pixelbild wird dann auch noch ein einen neuen Rahmen eingefügt - der zu allem Überfluß noch gruppiert wird. Das schliesslich wird dann im Originalrahmen platziert - als Unterobjekt! Das kann man mit Bormitteln gar nicht machen. Das sieht dann nicht nur anders aus - das ist auch noch ganz anders. 

Da ist der ehrliche Absturz geradezu ein Segen. Die einzige Entschuldigung ist, dass man mit Bordmitteln Postscript auch gar nicht direkt einbinden kann (über den Link geht das schon, aber das ist was anderes). Aber genau dieses direkte Einbinden wollten wir bei dem Barcode ja haben (um uns den Stress mit den Einzeldateien zu ersparen).

Das Problem kann von image::barcode jetzt umgangen werden, mehr zu siehe hier. Die Funktionen frame::embed_image und frame::embed_file, die ebenfalls Postscript direkt einbetten können, sind in der Doku mit einer deutlichen Warnung versehen, dass Postscript-einbetten und IDML keine Freunde sind.

Ich habe einen String, der Klammern enthält. Aus diesem String soll mit image::barcode ein QRCode erzeugt werden. Das funktioniert aber leider nicht. Es wird eine Meldung "EPS-Importfehler" angezeigt.

fxd

Ich wollte mit frame::embed_file ein Postscript-Bild in ein Dokument einbetten. Der Befehl liefert zwar den Fehlercode 0 (alles gut) zurück, importiert wird aber leider nichts.

fxd

Wie ist denn der Referenzpunkt von frame::rotate gemeint? In der Doku steht, die sind relativ zur linken oberen Ecke des Rahmens. Aber die Ergebnisse, die ich bei bereits gedrehten Rahmen erhalte, sind immer wieder überraschend.

Ja, die Werte sind ein bisschen InDesign® typisch. Also, es ist so: Der Referenzpunkt ergibt sich aus der linke oberen Ecke des Rahmens - und zwar wirklich die Ecke, da wo auch der Anfasspunkt der Ecke ist. Von dort geht man waagerecht (!) in X-Richtung und senkrecht in Y-Richtung - jeweils soviel Punkte, wie die Referenzangaben sagen. Bei gedrehten Rahmen ist der Referenzpunkt damit direkt von der Drehung abhängig.

Wenn man jetzt z.B. immer über die Mitte des Rahmens drehen will, ist da natürlich ziemlich mißlich - in diesem Fall muss der Referenzpunkt jeweils für die alte Rahmendrehung bestimmt werden. Das können wir natürlich auch selbst machen. Daher hat die Funktion frame::rotate jetzt den weiteren (optionalen) Parameter refPointInInnerCoordinates. Ist der 1, wird der Referenzpunkt relativ im Koordinatensystem des Rahmens verwendet. Mehr dazu wie immer in der Offline-Doku.  

Wir haben ein Problem mit dem Platzieren von INDD Dateien via Comet am Adobe Indesign Server 2014: Es wird immer nur ein einziges Produkt aufgebaut. Der Rest des Dokumentes bleibt leer. Laut Logfile werden aber alle Produkte problemslos aufgebaut. Mit InDesign® Desktop funktioniert der Aufbau fehlerfrei.

Testfall

Ich kann das Problem inzwischen ziemlich einfach bei uns reproduzieren: Es genügt ein Template, das genau einen Bildrahmen enthält. Das Load-Skript des Bildrahmen macht nichts weiter als ein

frame::image (gFrame, "$DESKTOP/Federkern_D.indd");

Mit einem kurzen Javascript werden dann mit

app.comet.build

ein paar Produkte mit dem kleinen Template aufgebaut. Mit InDesign® (Desktop) klappt das. Mit InDesign® Server nicht - hier erscheint immer nur das erste Produkt im Ergebnis. Welchen InDesign® Server man verwendet, ist dabei egal. Das Problem tritt bei ALLEN Server-Versionen auf. Die InDesign® Version von Federkern_D ist unerheblich. Auch an der importieren INDD-Datei selbst liegt es nicht. Hier das Javascript (mit Seitentemplate 8 und Template-ID 142):

// login mit hinterlegten Verbindungsdaten
app.comet.setEnvironment (
 	"/Users/paul/Desktop/fifo/priint 5.5/xmldata",
 	1,				// InstanceID
 	"", "");

app.comet.use (
 	"printday5.5",	// dataset name in connections.xml
 	"", "",			// unused
 	false,			// force reconnect, should be false
 	"");

// WICHTIG! Benoetigt fuer die meisten der folgenden Aufrufe!
var gOptions 		= app.comet.ping() + ";-1;";
var gDocumentPath 	= "/Users/paul/Desktop/aaa.indd";

// Seitenaufbau
app.comet.documentOpen (
 	gDocumentPath,	// documentPath
 	true,			// open original
 	gOptions);
  
// Seitentemplate zuweisen
app.comet.setTemplateID (
 	gDocumentPath,	// document path 
 	Scope.PAGE,		// Scope.SPREAD | Scope.PAGE
 	0,				// spread or page index
 	8,				// page template ID
 	gOptions);
   
var gItemsXML = "<items>\
<item><ID>1</ID><ID2>0</ID2><ID3>0</ID3><stringID></stringID>
	<pageitemID>142</pageitemID></item>\<item><ID>1</ID><ID2>0</ID2><ID3>0</ID3><stringID></stringID>
	<pageitemID>142</pageitemID></item>\<item><ID>1</ID><ID2>0</ID2><ID3>0</ID3><stringID></stringID>
	<pageitemID>142</pageitemID></item>\<item><ID>1</ID><ID2>0</ID2><ID3>0</ID3><stringID></stringID>
	<pageitemID>142</pageitemID></item>\
</items>";

// Seitenaufbau
app.comet.build (
 	gDocumentPath,	// document path 
 	Scope.SPREAD,	// Scope.SPREAD | Scope.PAGE
 	0,				// spread or page index
 	gItemsXML,		// items xml
 	0.0, 0.0,		// define page in spread by x position
 	gOptions);

// save & close
app.comet.documentSave (gDocumentPath, gOptions);
app.comet.documentClose (gDocumentPath, gOptions);

Ich habe einen Rahmen-Platzhalter, der TaggedText mit mehreren Absätzen einfügt. Leider gelingt es mir nicht, diesen Text so einzusetzen, dass er aus nur einem einzigen Platzhalter besteht. Ich hätte gedacht, dass das geht. Das Problem hierbei ist, dass beim Aktualisieren dann der Text vervielfacht wird.

KORREKTUR : Die in R11700 eingeführte Lösung führt zu Problemen bei der Verwendung von Inlines und wurde dehalb korrigiert. Lösung siehe hier.

Die Javascriptbefehle app.comet.eval/exec stürzen leder immer ab, wenn der Parameter gOutput in den Skripten mit einem String länger als 4095 Zeichen gefüllt wird.

Der für den Parameter reservierte Speicher von 4096 Bytes ist vielleicht doch etwas zu klein. Aber irgendeinen Wert müssen wir nehmen. Der ist jetzt bei 32 MB (32*1024*1024).

Der Javascriptbefehl _app.comet.eval_ liefert kein Ergebnis; der return-Wert der Funktion ist immer leer.

fxd

Ich habe einen Rahmen-Platzhalter, der TaggedText mit mehreren Absätzen einfügt. Leider gelingt es mir nicht, diesen Text so einzusetzen, dass er aus nur einem einzigen Platzhalter besteht. Ich hätte gedacht, dass das geht. Das Problem hierbei ist, dass beim Aktualisieren dann der Text vervielfacht wird.

Das geht natürlich grundsätzlich auch - bei TEXT-Platzhaltern. Bei Rahmenplatzhaltern wird davon ausgegangen, dass die zwar langen Text einsetzen, aber eben ohne Plazthalter - weil, die Aktualisierungen der Textplatzhalter würde ja eh wieder verloren gehen, wenn der Rahmenplatzhalter neu geladen wird. Es handelt sich also hier doch eher um ein recht exotisches Problem.

Für eine Lösung siehe hier.

image::setclip unter InDesign® Server geht nicht für neue, ungesicherte Dokumente.

Die Anweisung funktioniert jetzt auch bei InDesign® Server für neue, ungesicherte Dokumente.

Die Aufbauverfolgung ist eine gute Hilfe bei der Fehlersuche im Produktaufbau. Wäre es möglich, hier auch eigene Bilder per cScript einzufügen?

Ja, mit dem neuen Befehl productlist::trace_build geht das jetzt.

Für den Javascript-Aufruf von app.comet.modifyCometGroup kann man als Wert für den Parameter "command" die Angabe "join" wählen. Die im Parameter targetElements angebenenen Rahmen werden dann an die Cometgruppe des ersten Rahmens dieser Liste angefügt. Das scheint aber immer dann nicht zu funktionieren, wenn einer der beteiligten Rahmen noch gar keine Cometgruppe hat.

Fxd, see here for more informations.

Für den Javascript-Aufruf von app.comet.modifyCometGroup kann man als Wert für den Parameter "command" die Angabe "resolve" wählen. Dann wird die Comet-Gruppe des im Parameter "parent" angegebenen Rahmens aufgelöst. Das klappt aber leider nur dann, wenn die Gruppen-ID gleich der Rahmen-UID ist. Das ist aber z.B. nach einem Template-Wechsel der Cometgruppe nicht mehr Fall.

Die Anweisung funktioniert jetzt auch für Rahmen, bei denen Cometgruppen-ID und Rahmen-UID unterschiedlich sind.

Fxd, see here for more informations.

Javascript function setTemplateID option apply-following is mis-interpreted

Fxd, see here for more informations.

Javascript function elementSetImage ignores option image-scale:fitcontent

Fxd, see here for more informations.

Beim Erzeugen von Hyprerlinks über cScript bin ich auf die folgenden beiden Probleme gestoßen:

• Problem A: Existiert bereits ein Link, so gibt hyperlink::create_urldest() den Fehler 79111 (unbekannter Fehler lt. serror) zurück und InDeisgn stürzt ab.
• Problem B: Beim Löschen von Links mit hyperlink::delete_() wird der Link "nicht richtig" gelöscht.

Beide Probleme lassen sich auf Fehlverhalten in InDesign® zurückführen, für das es aber zum Glück Workarounds gibt.

Ja, so ist es leider, nach einem W2ML-Import wird in allen Rahmen der Text immer oben dargestellt.

fxd

Platzhalter in über InTag geladenen Templates werden mehrfach geladen.

fxd

Der Logindialog (Verbinden mit Datenbank/Internet) setzt jedesmal mein eingegebenes Passwort zurück, wenn der login fehlgeschlagen ist. Möglicherweise waren ja die Logindaten richtig und nur der Service offline - das Passwortfeld sollte nicht geleert werden.

fxd

Platzhalter, die mit einem der neuen Präfixe wie %!PP beginnen, werden von der Aufgabenpalette immer als 'Geändert' erkannt.

fxd

ACHTUNG: Das Feature ist offiziell erst ab 4.1 verfügbar!

Die Gestaltungsmethode "Spaltenbreite anpassen" funktioniert leider nicht richtig, wenn die Tabellenspalte Zellen enthält, die in einer vorhergehenden Spalte mit einer anderen Zelle verbunden wurden.

Zellen werden jetzt auch dann angepasst, wenn sie in den Zellbereich einer anderen Zelle fallen. Die Änderungen betreffen auch die Funkrtion table::fit_col.

ACHTUNG : Bei einer unterschiedlichen Reihenfolge von Spaltenbreitenanpassungen können unterschiedliche Ergebnisse entstehen!

fxd

Beim Export von Lab-Farbwerten wird die vierte Farbkomponente mit einem riesenhaften Wert, z.T. 50-stelligen Wert angegeben. Das macht eigentlich nichts, weil hier ja nur drei Komponenten benötigt werden - sieht aber trotzdem komisch aus.

fxd

Die Einstellung "Nach Seitengrößeä,nderungen anwenden" von priint:adjust ist derzeit eine applikationsweite Einstellung. Wäre es nicht sinnvoller das als Dokumenteinstellung zu sichern?

Natürlich macht das mehr Sinn. Die Option wurde aus den (Kontext)Menus entfernt und findet sich jetzt als Checkbox im priint:adjust panel.

Mir ist schön öfters aufgefallen, dass Gestaltungsregeln beim Laden oder auch bei Positions-/Größenänderung mehrfach ausgeführt werden.

Tatsächlich wurden in einigen Fällen die Gestaltungsregeln "OnUpdate" (bei Platzhalteraktualisierungen) zweifach aufgerufen. Das wurde gefixt.

Dass Gestaltungsregeln bei "OnGeometryChanged" (bei Geometrieänderungen) auch mehrfach ausgeführt werden ist eine andere Baustelle. Das ganze ist auf ein InDesign® Verhalten zurückzuführen. Es gibt an dieser Stelle Verbesserungen um dieses Verhalten zu umgehen, trotzdem gibt es einige Fälle in denen das leider nicht möglich ist.

Zudem gab es in 4.0.5 R10943 die Korrektur, dass Gestaltungsregeln die auf Geometrieänderungen hören jetzt beim Produktaufbau nicht mehr ausgeführt werden (so wie es sein sollte).

Die Funktion textmodel::position_visible scheint seit R10101 nicht mehr zu funktionieren.

fxd (Seiteneffekt von FogBugx 16471)

Ich habe einen Comet Test bei dem es nötig wäre beim Export der Bilder die Funktion "Überdrucken simulieren" zu aktivieren. Geht das irgendwie?

In dem Dialog in dem die Tests editiert werden gibt es jetzt eine Checkbox dafür. Zudem hat sich die Struktur der Testdefinitionen etwas geändert. Mehr unter der Dokumentation zu Comet Tests.

Wenn man die Option "Comet-Gruppen anzeigen" aktiviert hat wird diese Anzeige bei gedrehten Rahmen komisch dargestellt. Sie ist größer als sie sein sollte und außerdem werden die Gruppennummern- und Texte schwer zu lesen, weil diese sich auch mitdrehen. Sollte man nicht lieber nur die BoundbingBox der Rahmen anzeigen und den Text nicht mitdrehen?

fdx

Voher

Nachher

Gestaltungsregeln "Nach Geometrieänderung" werden auch  beim Produktaufbau ausgeführt - das ist doch sicher nicht richtig, oder?

Nein, natürlich nicht.

fxd

In der Produktrecherche werden nicht alle Elemente korrekt aufgeklappt, wenn die Palette selbst nicht hoch genug ist. (tritt eventuell erst bei einer Suche mit min. 3 Ebenen auf) Der Pfeil zeigt dann zwar nach unten, aber die Untereinträge fehlen.

1. Produktrecherche so klein wie möglich gemacht
2. Suche gestartet à 1 Eintrag
3. Klick auf "Alle Einträge öffnen" à 25 Untereinträge (korrektes Verhalten)
4. Zweiter Klick auf "Alle Einträge öffnen" à Nur 1 Untereintrag, obwohl es 23 sein müssten.
   

Wenn ich dasselbe mit einer "normal großen" Palette mache, erhalte ich mehr Ergebnisse. Bedingt durch meine Bildschirmgröße, kann ich jedoch niemals alle auf einmal aufklappen. Ich muss immer die letzten Einträge zu- und wieder aufklappen, damit es angezeigt wird.

fxd

Wenn die StringID einen Umlaut enthält, können die Bildpositionen des Rahmens nicht wiederhergestellt werden.

fxd

Ist es irgendwie möglich, die Adapterregeln eines Rahmens direkt (und ohne vorherige Adaption oder durch frame::apply_magnets) auszuführen?

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

Bei Aufrufen der Funktion der Funktion frame::apply_magnets werden leider die in den Rahmen hinterlegten Adapter-Regeln nicht ausgeführt. Kann man es irgendwie triggern, dass die Regeln ausgeführt werden?

Die Funktion hat jetzt zwei neue (optionale) Parameter, mit denen das gesteuert werden kann. Mehr dazu in der Ofline-Doku OFFLINE_DOKU/cscripts/frame.html#apply_magnets.

Prinzipiell sollte das eigentlich klappen. Im vorliegenden Fall wurde aber eine Schrift verwendet (Futura Std), bei der das aktuelle Verfahren zum Suchen der internen Repräsentation der Schrift nicht funktioniert hat. Das haben wir angepasst.

fxd

Beim Löschen der Proof Daten eines Comet Tests (über den Knopf auf dem Panel) werden scheinbar von allen andereren Tests auf der selben Ebene auch die Proof Daten gelöscht.

fxd

Der cScript Befehl document::export_styles legt einige temporäre Ordner an. Wenn diese noch nicht existieren schlägt der Befehl fehl.

fxd

Die temporären Ordner werden jetzt immer angelegt.

Die cScript Funktion document::saveas ignoriert Token wie "$DOCUMENTS" im Zielpfad und macht garnichts wenn ein solcher Pfad eingegeben wird.

fxd

Der cScript Befehl document::open öffnet zweimal das gleiche Dokument wenn man ein .w2ml als Eingabedatei verwendet.

fxd

Die Gestaltungsregel "Auf Ebene verschieben" kann neue Ebenen anlegen, wenn die Zielebene nicht existiert. Laut Dokumentation werden die neuen Ebenen als hinterste Ebene oder vor der benutzerdefinierten Hintergrundebene angelegt:

"Verschiebe den Rahmen auf die angegebene Ebene. Existiert die Ebene noch nicht, wird sie vor der im zweiten Paramter angegebenen Ebene angelegt. Fehlt der erste Ebenenname wird eine neue Ebene mit einem automatischen Namen generiert. Fehlt die zweite Angabe, werden neue Ebenen als hinterste Ebene angelegt."

In der Praxis werden die neuen Ebenen allerdings als vorderste Ebene (keine Hintergrundebene definiert) oder hinter der benutzerdefinierten Hintergrundebene.

Wir sollten die Doku an der Stelle ändern.

fxd

Scheinbar setzt die Gestaltungsregel "Rahmengrösse setzen" die Größe des Rahmens in pt und nicht in mm wie in der GUI angezeigt.

fxd

Inlines with missing images are shown with white background always.

fxd

...

Um das zu vermeiden, hat die Funktion frame::release_inline zwei neue optionale Parameter für die neue Rahmenposition.

Nachdem ein Inline mit frame::release_inline aus einem Text gelöst wurde, hat der Rahmen eine neue UID. Wie finde ich denn diesen Rahmen auf der Seite wieder?

Die Rahmenreferenz zeigt jetzt nach erfolgreicher Ausführung auf den geänderten Rahmen.

Hard to find ...

The error was caused by a ZERO WIDTH NO-BREAK SPACE inside the text. InDesign® does not support this letter into TaggedText! And, as a result of this, the w2ml-index of the inline points behind the text end - and isn't drawn therefor.

The only solution here is : Remove the ZERO WIDTH NO-BREAK SPACE from the InDesign® document and do not use this letter anymore!

To impede the use of this letter, we removed the Non-breakable zero Space menu from the InDesign® menü Font -> Spaces.

Die cScript Funktion page::duplicate kann zum Absturz führen, wenn der Parameter reconstructCometData gleich 1 ist. Beim Testen trat der Fehler nur mit rechten Seiten auf.

Gefixt.

Die cScript Funktion page::duplicate erzeugt für jede duplizierte Seite einen neuen Spread, selbst wenn die letzte Seite im Dokument eine linke ist und eine rechte Seite dupliziert wird. Jede duplizierte Seite steht also allein als linke Seite auf einem Spread.

Ändert man anschließend in der InDesign® GUI die Anordnung der Seiten des Dokumentes in irgendeiner Art und Weise, werden alle Seiten von InDesign® richtig aneinandergeheftet.

Gefixt.

Die Funktionen frame::export_html und textmodel::export_html unterstützen zwar Inlinerahmen, jedoch werden diese nicht exportiert wenn sie in Tabellen sind.

Der Hintergrund ist, dass wenn als Exportlänge -1 angegeben wird, Inlinerahmen in Tabellen nicht gefunden werden, da diese hinter der primären Länge des Textmodelles liegen. Die Exportlänge wird aber auf die primäre Länge beschränkt. Das gleiche gilt für Tabellen in Tabellen.

Gefixt.

Ich kämpfe nun schon seit einigen Wochen mit dem Problem, dass ein fit_frame eines per In-Tag platzierten Templates häufig mit dem Fehler "Cannot fit invisible inline..." fehlschlägt, der Rahmen aber eigentlich groß genug ist.

Das Problem ist gefixt.

Die cScript-Funktion itemlist::revert scheint die Liste zu sortieren statt sie umzukehren.

Der Eindruck ist richtig. Das ist gefixt - itemlist revert kehrt jetzt die Reihenfolge der Liste richtig um.

Der PDF-Renderer scheint die in InDesign® möglichen Farbtonfelder nicht zu unterstützen. Sei fehlen jedenfalls in den <swatches>-Einträgen der w2ml und in den erzeugten PDF wird statt des Farbtones die entsprechende mit 100% Deckkraft verwendet.

Sowohl Renderer als auch Comet-Plugins unterstützen jetzt auch Farbtonfelder. 

ACHTUNG: Um Farbtonfelder zu unterstützen, müssen die W2MLs mind. mit v4.0.5 R10600 erzeugt worden sein!

Bei der Ausgabe von Text über wlog wird offenbar nicht immer der ganze geschrieben. Kann das sein?

Das das ist richtig - allerdings nur bei formatierter Ausgabe. Dann wird die Ausgabe auf 32000 Zeichen beschränkt. Um das im Log deutlich zu machen, fügen wird an den abgeschnittenen Text jetzt zweimal ... an:

gleich wird der Text abge...
...

Ich rufe in einem Ladenplatzhalter die Funktion placeholder::change_tags zum Setzen der Infos1 des Platzhalters:

placeholder::change_tags (
 	gFrame, 3,
 	"Infos1","X",
 	kTextPlaceholder,
 	textmodel::start(), textmodel::length());

Später wird der Platzhalter mit seinem neuen Text gefüllt:

textmodel::replace (newText);

Nach dem Laden hat der Platzhalter seinen neuen Text, Infos1 aber den alten Wert von vor dem Ladenskript. 

Ein Fehler in dem guten, alten textmodel::replace :-)

Platzhalterskripte merken sich den aktuellen Platzhalter. Der Platzhalter wird benötigt, um Endlos-Rekursionen beim Laden zu verhindern. Ausserdem wird der Platzhalter benötigt, um neu eingefügten Text ebenfalls zu verlinken.

Und genau hier liegt das Problem - der im Skript hinterlegte Platzhalter hat von dem placeholder::change_tags nichts mitbekommen und setzt die alten Platzhalterdefinitionen über den Text.

Für Genießer : Natürlich ist der im Skript hinterlegte Platzhalter ein Pointer - und Änderungen an anderer Stelle sollten dann auch im Ladenskript sichtbar sein. Leider, leider müssen Platzhalter aber bei jeder Änderung ihrer Definition komplett ausgetauscht werden - und unsere Referenz auf den Platzhalter steht dumm da. Dass sie überhaupt noch gültig ist, liegt daran, dass sie als sog. Referenz-Pointer kommt. Und der wird erst dann wirklich gelöscht, wenn die letzte Referenzierung ihn aufgibt - in unserem Fall am Ende des Ladenskriptes.

Der Fehler ist behoben. Das Gleiche betrifft die Funktionen textmodel::insert, frame::insert und frame::replace.

Bei der Reorganisation eines Dokumentes erhalte ich den Fehler 11265. Danach stürzt InDesign® ab.

Der Fehler 11265 ist ein Adobe-Fehler und bedeutet : Mit diesen Werten wird ein Objekt von der Montagefläche verdrängt. Danach kommt der Protective Shutdown.

Sieht man sich die Einstellungen der Template-Rahmen an, ist das Ganze vielleicht keine Überraschung mehr:

ALLE Rahmen der Cometgruppe haben die Einstellung "Rahmenfläche ignorieren" (das Minus in der zweiten Status-Spalte). Damit hat die Cometgruppe insgesamt keine Fläche mehr. Und das entspricht dann ungefähr der Division durch 0 (die ja auch noch nie so ganz geklappt hat).

Da das ganz offensichtlich ein Fehler ist, habe ich hab deshalb meinen Quellcode so geändert, dass, wenn alle Rahmen ignoriert werden sollen, alle Rahmen berücksichtigt werden - und sofort klappt das Aufräumen wieder.

Das wurde gefixt. Die Regeln werden jetzt auch bei Größenänderungen ausgeführt.

Gab es nicht mal die Möglichkeit, die Reihenfolge von Seitenelementen zum Pfeiltasten zu ändern?

Ja, doch, die gab es. Und gibt es noch. Unter der Liste der Seitenelemente sind die entsprechenden Buttons. In CC waren sie nur leider erst bei Mouse-Rollovers sichtbar. Das ist jetzt korrigiert - die Buttons sind jetzt auch in CC immer sichtbar.

Inlines aus Tabellen erhalten beim Export in w2ml falsche Angaben. Z-B. kann es passieren, das der y-Offset gigantische 122384263486234076230620386.0 pts groß wird - damit ist dann der Renderer überfordert.

Gefixt.

Irgendwas ist komisch an der Funktion document::revert. Ich hab die Funktion in einen einfaches Aufbauscript aufgenommen. Führe ich nun den Aufbau durch, funktioniert dieser. Führe ich das Script erneut aus bleibt die Seite Leer. Nach einem weiteren Versuch wird der Aufbau wieder ausgeführt.

Kann es sein das die Funktion wenn das Dokument verändert wurde Diese zwar auf Ursprung zurückstellt, jedoch alle Funktionen danach beendet? Dies würde erklären warum ist einmal funktioniert und einmal nicht.

Die Funktion hat das Dokument zwar sofort geschlossen, aber erst zur nächsten Idle-Time (also nach Skriptende) wieder geöffnet. Der Aufbau im Skript hatte deshalb kein Dokument mehr, auf dem er arbeiten konnte.

Der Fehler ist gefixt.

Aber ACHTUNG

Aufrufe der Funktion können das Dokument schliessen und neu öffnen. Verweise wie gFrame, gDocument, etc. zeigen nach dem Aufruf auf nicht mehr existierende Objekte und können bei Verwendung zum Absturz von InDesign® führen!

Die Gestaltungs-Bedingung "Wenn Übersatz" liefert falsche Ergebnisse, wenn:

1. Nicht die gesamte Textkette geprüft werden soll
2. Der Rahmen keinen Text anzeigt
3. Die Textkette aber einen Übersatz hat

In diesem Fall ist einfach schon die erste Zeile im Rahmen zu hoch (zu große Schrift, großes Inline, hohe Tabellenzeile) und der Rahmen kann überhaupt keinen Text zeigen. Dann sagt die Bedingung : Nein, der Rahmen hat keinen Übersatz.

Der Fehler wurde durch die hier verwendete fehlerhaftew Funktion frame::shows_textend verursacht und ist mit Fall 16686 gefixt.

Die Funktion frame::shows_textend liefert das falsche Ergebnis 2, wenn der Rahmen gar keinen Text enhält, aber im Overset noch Text enthalten ist. (Das Ergebnis 2 heisst eigentlich : Nein, ich zeige das Textende nicht an (was ja stimmt) UND der Text endete bereits in einem Rahmen vor mir.

Das wurde gefixt. 

Die Funktion frame::get_magnet_type benötigt als Eingabe eine Rahmen- und eine Magnetreferenz. Die Magnetreferenz verstehe ich. Aber wozu wird hier die Rahmenreferenz benötigt?

Das ist richtig, die Rahmenreferenz wird hier gar nicht benötigt. Die gewünschte Information kann allein über die Magnetreferenz ermittelt werden. Die Rahmenreferenz wird deshalb ab jetzt ignoriert (bleibt aber aus Gründen der Rückwärts-Kompatibilität erhalten). Das Gleiche gilt für die Funktionen:

• frame::get_magnet_is_white
• frame::get_magnet_is_rotation_only

Magnete über Spreads werden von den Plugins nicht angewendet (und beim Verschieben eines Rahmens auf einen anderen Spread werden solche Magnete auch automatisch entfernt). Trotzdem kann man solche Magnete über die Oberfläche setzen.

Das geht jetzt nicht mehr. Magnete können nur noch zwischen Rahmen gleicher Spreads gesetzt werden.

Gibt es einen Weg Magneten und Nägel beizubehalten, wenn man Rahmen austauscht bzw. gegen ein anderes Template austauscht?

Mit den neuen Funktionen

• frame::set_nail
• frame::set_magnet

sollte das Gewünschte machbar sein.

Werden in der Produktrecherche eigene Icons verwendet, die über eine URL geladen werden müssen, stürtzt InDesign® CC auf dem Mac reproduzierbar ab. Unter Windows tritt der Fehler nicht auf.

Das Problem entsteht beim Laden der extern definierten Icons der Produkte. Hier werden dazu Bilder verwendet, die über eine URL definiert sind, z.B:

http://www.hi13.de/tarantana.png

Nun ist es so, dass CC mind. ZWEI Bilder benötigt : Eins für den hellen Hintergrund und eins für den dunklen. Gibt es die entsprechende Bild-Variante nicht, wird das "Stamm"-Bild verwendet. Bildvarianten werden mit _L (light background) oder _D (dark background) als Namenszusatz gekennzeichnet. 

Für das oben gewünschte Bild tarantana.png wird also zuerst nach tarantana_D.png (oder, wenn die UI hell ist : tarantana_L.png) gesucht. An den angegebenen URLs sind aber leider keine Bildvarianten zu finden - und der Server liefert -- nein, nicht NICHTS. Er liefert eine HTML-Datei mit einem 404-Fehler. Sieht im Browser so aus:

Das war unerwartet. Und der Versuch, diesen HTML-Text als Bild zu interpretieren, kostet InDesign® das Leben. Wir filtern diese Ergebnisse jetzt aus - damit können dann die gewünschten Stammbilder zu Zuge kommen.

Im Feld 

elements.textflow.overset-chars

der Metadaten-Datei elements.xml wird jeweils der Übersatz bzw. der (geschätzte) Untersatz der Rahmen angegeben. Der Übersatz stimmt. Der Untersatz dagegen (also wieviele Zeichen noch ungefähr in den Rahmen passen könnten) ist mitunter falsch. Es ist klar, dass die Angabe nur eine ungefähre Rundung enthalten kann - aber negativ sollte sie eigentlich werden, oder? Das wäre ja dann ein Übersatz.

Das ist natürlich richtig und wurde gefixt.

Folgendes Javascript bringt InDesign® zum Absturz wenn die Comet-Plugins installiert sind. Ohne Comet-Plugins kann das Skript fehler- (und effekt-) -frei ausgeführt werden:

var	myDoc		= app.documents[0];
var textFrame 	= myDoc.pages.firstItem().textFrames.add();

textFrame.remove();

Der Fehler ist gefixt.

Wir versuchen, in einem Seitenaufbau überlappende Rahmen einzufügen und haben dafür den Rahmen in der Palette Template-Verhalten mit einem - (Rahmenfläche ignorieren) markiert. Wir hätten dann etwa folg. Ergebnis erwartet:

Tatsächlich erhalten wir aber:    

Vielleicht ist das jetzt in den Beschreibungen nicht so ganz rüberkommen. Ich hab das in der Doku jetzt mal so beschrieben:

und werden in 1:N-Elementen nicht unterstützt - der Aufbau prüft, ob ein Template eine Stelle belegen kann; er prüft nicht, wo es platziert werden kann. Das ist eine sehr selten gestellte Aufgabe von einiger mathematischer Komplexität, die wir aber auf Nachfrage gerne für Sie lösen.

Für Rahmen, die ignoriert werden sollen (Einstellung -) ist das einfacher - deshalb ist das für diesen Fall jetzt gelöst und der Aufbau erzeugt genau das Ergebnis, das gewünscht wird.

Ich habe zwei Rahmen auf einer Seite. Beide haben jeweils eine priint:adjust Regel mit unterschiedlichen Parametern gesetzt. Jetzt nehme ich das das ganz normale Auswahl-Werkzeug und wähle mal den ersten, mal den zweiten Rahmen aus. Bei einem der beiden Rahmen werden die Parameter richtig angezeigt, bei einem nicht. Verwirrend ist dabei auch noch folgendes: Verschiebe ich die Rahmen, kann es passieren, dass danach der zweite Rahmen richtig angezeigt aber der erste nicht mehr. 

Ja, das Problem ist immer dann aufgetreten, wenn die Palette priint:adjust Rahmenliste geöffnet war und der ausgewählte Rahmen nicht der erste in dieser Liste war. ich habe hier einfach den falschen Listenindex (den der Rahmenliste) verwendet, um die Methoden-Parameter anzuzeigen.

Ist gefixt.

Wir benötigen einen Skriptbefehl, mit dem die Ergebnisse von Preflights in einen String geschrieben werden.

Das geht jetzt mit document::preflight. Und, damit hier keine Verwirrungen entstehen, der Befehl benötigt die (neuen) Preflight-Plugins natürlich nicht!

Platzhalter-Preflight

Testversion! Release-Termin ist 4.1. In Testversionen werden diese Plugins demnächst auch für 4.0.5 verfügbar sein.

layer::copy mit exhaustive=1 funktioniert unter Windows nicht. Mit gleichem Dokument und gleichem Skript funktioniert es aber unter Mac.

... geht jetzt auch unter Windows.

ACHTUNG : Für beide Varianten gilt: Die Anweisung geht nicht bei neuen (und noch nie gesicherten) Dokumenten!

Harmlos ist er offenbar nicht - aber jetzt geht er auch bei InDesign® Server. Das gleiche betrifft übrigens document::set_bleed.

Es gibt einen kuriosen Fall in der Produktrecherche: Tritt nur in Kombination mit dem Button "Alle Einträge öffnen" auf!:

1. Suche starten
2. Mindestens zweifaches Aufklappen der Ebenen mit "Alle Einträge öffnen"
3. Produktrecherche minimieren bzw. auf andere Palette wechseln
4. Produktrecherche wieder öffnen bzw. zurückwechseln
5. ---> Mehrfache Einträge! Die Ebene darüber hat doppelte Einträge und noch eine Ebene darüber entstehen dreifache Einträge.

Lustiges Verhalten - ist gefixt

int 	stVar 	= gVar;
						
int main ()
{
	showmessage ("%d", stVar);
	
	return 0;
}

Das Problem besteht dabei offenbar in der fehldenen Definition von gVar.

Gefixt.