Testdaten folgen gleich; zum Testen einfach den Rahmen mit der Tabelle per Rahmenwerkzeug auswählen und ein Produkt aus der zweiten Ebene zuweisen.

Das ganze passiert bei CS3, Rev 821, vorher funktioniert es.

Das ist ein recht heikler Fehler, der mir da unterlaufen ist. Er betrifft alle Umgebungen, die Platzhalter in Tabellen und TaggedText in Platzhaltern verwenden - also fast alle. Der Fehler hat sich bei Bugfix 1190 eingeschlichen und ist jetzt behoben.

Unter SOAP wurde hier auch ein SOAP-Aufruf erwartet. Im vorliegenden Fall handelte es sich aber um eine XML-Query-Abfrage. Ich habe die Funktion so erweitert, dass unter SOAP beide Möglichkeiten unterstützt werden.

Und Thorsten setzt noch eins drauf : Die Variablen sollten sowohl im Script als auch direkt im Platzhalter ausgelesen werden können - sowohl für Text- als auch für Rahmenplatzhalter.

In Skripten können die Eigenschaften von Platzhaltern für Rahmen gelesen und geschrieben werden (placeholder::(s)get_value, placeholder::change_tags). Die Eigenschaften von Textplatzhaltern können nur gesetzt werden.

In Queries von Platzhaltern kann prinzipiell nur gelesen werden. Da werden bisher keine Platzhaltereigenschaften (ausser <placeholderID>) unterstützt.

Lösung

In Skripten können jetzt auch die Eigenschaften von Text-Platzhaltern geholt werden. placeholder::defined, placeholder::get_value und placeholder::sget_value haben entsprechende Parameter erhalten. Mehr dazu in der aktuellen Online-Doku.

in den Action-Skripten der Platzhalter können die Platzhalterwerte mit den gleichen Namen wie bei placeholder::get_value verwendet werden, also etwa "select 'Kindergeburtstag : ' || <Infos1> from ...

Funktioniert (richtig) ab R805.

Ist in R730 behoben, bei Problemen mit dieser Version (im Zusammenhang mit OCI Verbindung) bitte Rückmeldung.

Erledigt.

Reading LIC! "#2100"

Trial License "#2100" bla bla... (siehe Anhang)

Letztlich werden die Plug-Ins nicht geladen. Die Lizenzdatei habe ich sicherheitshalber mal mit der neuesten Version des Lizenznummern-Programms (vom 2. Juni) neu erzeugt, was aber auch nichts ändert.

Der Fehler ist wieder behoben.

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

int main ()
{
    int 	result = -3;
    
    result = textmodel::justify(
    		gFrame,
    		kBegin,
    		kEnd,
    		-1,
    		"",0,"AbstandTabellen",
			0.0);
   showmessage("%d",result);
   return 0;
}

Der Fehler ist behoben :-))

In diesem Fall war der Platzhalter der letzte in einem Text ohne Tabellen. Der Fehler lag nun daran, dass die Tabellenzellen den aktuellen Textplatzhalter übernommen haben. Dann kam nach dem TT-Import das Autoload. Der Text der Zelle wurde also durch eine Tabelle ersetzt, danach das Autoload für diese Tabelle, usw.. Das konnte gar nicht aufhören.

Der Fehler ist behoben.

itemlist::sort

Auch hier kann zeilen- und spaltenweise und nach der Z-Order sortiert werden.

• Wesentlich schneller
• Zwei Bildausschnitte statt wie bisher nur einen
• Bild-Magnet
• Automatische Grössenanpassung der Dokument-Arbeitsfläche
• Bearbeitung gesperrter Rahmen
• Ecken-Werkzeug für min./max. proportionale Grössenänderung
• Schriftgrössenanpassung überarbeitet (min./max. Schriftgrösse, ganzzahlige Schriftgrössen)
• Preview-Funktion mit Schrittweite, Undo möglich
• Ausrichten von Rahmen (Skriptbefehl)

err_code = document::set_startpage(2, 4);

Das geht jetzt wieder. Ab CS2 gibt es noch einige Möglichkeiten mehr :

   5 : 01, 02, 03, ...
   6 : 001, 002, 003, ...
   7 : 0001, 0002, 0003, ...
   8 : Fullwidth (? Was auch immer das bedeutet)
   9 : Kanji

Dass das noch niemandem aufgefallen ist - der Fehler ist jetzt behoben.

frame::apply_display_details macht das Gewünschte.

Der neue Befehl itemlist::align tut das Gewünschte.

Den Befehl textmodel::scale_font gibt es schon eine ganze Weile. Ich hab ihn aber noch ein bisschen erweitert und die vergessene Doku nachgeschrieben. Man kann den Befehl jetzt auch mit Minimum und Maximum der Schriftgrösse verwenden, nur ganzzahlige Schriftgrössen erlauben und Textoversets verbieten. Ausserdem kann der Befahl als eine Art FitContentToFrame verwenden - in diesem Fall wird die Skalierung selbst gesucht und der Text so verändert, daß er den Rahmen möglichst genau ausfüllt.

Beim Neuladen von Texten über den Cometen wurden bisher Hyperlinks im alten Text nicht gelöscht. Und InDesign® macht das von alleine schon mal gar nicht. Dadurch entstanden Hunderte unbenutzter Hyperlinks.

Zusätzlich vergibt InDesign® Neuanlegen von Hyperlinks automatisch eindeutige Namen (Name, Name 2, Name 3, ...). Das ist zwar nett, aber wenn man Hyperlinks gerade erst gelöscht hat (wie es der neuen Comet tut), kommt da zum Teil falsches raus - und dann stürzts ab.

Und wie kriegt man die überflüssigen Hyperlinks aus den Dokumenten wieder raus?

Die InDesign®-Bordmittel (Hyperlink-Palette und dort der Papierkorb) führen leider zum Absturz von InDesign®. Deshalb gibt es jetzt den neuen Skriptbefehl hyperlink::delete_all. Damit werden alle Hyperlinks aus dem Dokument entfernt. Der Befehl kann wahlweise direkt und ohne irgendwelche Tests und Updates einfach die blöden Hyperlinks löschen, sichert dann das Dokument und öffnet es neu.

Wenn man das machen will, ist es am besten, ein Palettenskript für die Produktrecherche zu machen (Eintrag in actions.xml) mit folgendem Inhalt für das harte, direkte Löschen mit Sichern und Neuladen

int main ()
{
    hyperlink::delete_all (
        0,		// Aktuelles Dokument
        1);		// Direkt löschen
    return 0;
}

Der Fehler ist behoben. Das Konvertieren dauert jetzt bei mir (Mac DualCore mit 2,33GHz) etwa 80-90 Sekunden - find ich eigentlich ganz flott für eine 60 MB CSV-Datei mit über 170.000 Datensätzen.

FYI

Das Problem lag an einer geänderten Implementierung der verwendeten STL-Klasse std::list. Offensichtlich ist die von Apples XCode verwendete GNU-STL nicht ganz so der Brüller.

     <w2: 123469, 100, 1299, 1, 'stringid', infos1 'aaaaa', infos2 'bbbbb'>dummy</w2>

Zusätzlich werden Infos1 und und Infos2 jetzt auch in der Platzhalterpalette angezeigt.

Productlist::build_list ist eigentlich für den Aufbau von Produkten unabhängig von der Produktpalette (InDesign® Server und Spezialfälle) gedacht. In allen anderen Fällen ist document::build_products die bessere Wahl. Ich hab eine entsprechende Bemerkung in die Doku eingefügt.

Tja, und ansonsten : Stimmt, der Aufbau ist unterschiedlich. Auf dem langen Weg zwischen den einzelnen Plugins (die programmiertechnisch verschiedene Applikationen darstellen) ist die kleine Info "Raster-ID" der einzelnen Produkte verloren gegangen. Diesen Fehler hab ich gefixt - jetzt stimmt auch das.

Das versteh ich gut, dass das nicht funktioniert : list::reload lädt nur die einzelnen Einträge, nicht die Liste der Einträge der neu. Das ist in der Doku nicht eindeutig genug beschrieben - und ehrlich gesagt fällt mir auch für die Funktionsaufrufe kein eindeutiger Name ein.

List::reload hat jetzt nach der KlassenID für die Zielpaletteeinen den weiteren Parameter reloadList. Dieser Parameter gibt an, ob die Liste komplett neu geladen werden soll oder nur die einzelnen Einträge.

Ich habe die Funktion frame::resize erweitert. Dort wird jetzt geprüft, ob die Zielgrösse des Rahmens mit der gesetzten Rahmenbreite vereinbar ist. Ist das nicht so, wird die Rahmenbreite automatisch entsprechend verkleinert.

Die Farbangabe ist jetzt optional und kann mit "" angegeben werden. Damit sind alle Parameter des Aufrufes ausser dem Rahmen selbst optional. Fehlen alle Werte oder haben ihre Defaultwerte, tut die Funktion nichts.

In den anderen Datenpools ist zwar keine neue Datenverbindung nötig, aber die Vorlagenpalette muss neu geladen werden.

Der Export/Import von ist immens aufwendig. Diesen kleinen Punkt habe ich übersehen. Jetzt verhält sich alles so wie es soll.

Ja, meine lieben Freunde, man kann. Die drei Funktionen sind erweitert, so dass die neun üblichen Rahmenpunkte als Referenzpunkte verwendet werden können. Und zusätzlich, weil ich so lieb bin kann, kann man darüber hinaus noch einen Offset von diesen Punkten aus setzen.

• frame::resize
• frame::image_size
• frame::image_scale

Na, da kommt Freude auf. Dieser Fehler ist jetzt behoben.

Zeigt ein Rahmen der übergebenen Liste auf den selben Text, wird er ab jetzt nur einmal durchsucht. Dann ist alles richtig.

linklist::collect und linklist::collect_any können jetzt auch mit der Sortierangabe kSortByZOrder aufgerufen werden. Weiter hinten liegende Rahmen sind dann auch weiter hinten in der Ergebnisliste.

Das ist leider richtig. fit_col versucht in kleiner werdenden Schritten die jeweilige Spalte anzupassen bis kein Zellen-Overset mehr auftritt. Leider benötigen die Zellen ein Re-Rendering des Textes, damit der nötige Overset-Anzeiger aktiviert wird. Diese Malerei dauert natürlich immer länger, je weiter unten man im Text ist. Und compress_colwise verwendet fit_col ziemlich oft.

Soweit ist das einsehbar.

Trotzdem ist es jetzt schneller, weil, nun ja, wir können ja auch rumtricksen. Im Stresstest habe ich 50 Tabellen in 30 Seiten Text. Es macht jetzt keinen Unterschied mehr, die erste oder letzte Tabelle zu bearbeiten. Ich habe jeweils 10 mal compress_colwise auf eine ziemlich breite Tabelle gemacht. Hier die Ergebnisse :

frame::duplicate tut das Gewünschte. Kopiert können Rahmen innerhalb eines Dokumentes oder zwischen (geöffneten) Dokumenten.

Zumindest rudimentäre Unterstützung geht ab R612: mit dem neuen Skriptbefehl

frame::set_objectstyle (ItemRef frame, char * stylename, int applyEmptyCat = 0)

kann einem Rahmen ein Objektstil zugewiesen werden. "frame" und "stylename" sind selbsterklärend, der dritte Parameter gibt an, ob leere (= unchecked / nicht aktivierte) Kategorien des Stils angewandt werden sollen.

Ab R563
Für Produkte per product::set gesetzte
- kPreRuleid
- kPreRuleparams
- kPostRuleid
- kPostRuleparams
- kGridid
- kElementid
- kAdparams

werden beim automatischen Produktaufbau durch die entsprechende Werte des PageItems überschrieben.

Ab R603 so gelöst:

Der für das Produkt gesetzte Wert wird nur überschrieben, wenn für das PageItem ein Wert != 0 bzw. nicht leer (für Strings) angegeben ist.
Weichen die beiden Werte (Produkt und PageItem) voneinander ab und sind beide != 0 bzw. nicht leer, wird im Logfile eine Warnung ausgegeben.

Ab R592 (mit Soap Cache)
Wenn der File-Delimiter des Systems von dem in den SOAP fileId's verwendeten abweicht, kann das PlugIn keine sinnvolle ID zur Identifizierung der gecachten Skripte bilden.

Typischerweise tritt das Problem unter Windows auf und äußert sich z.B. mit Fehler 403 beim der Ausführung von Batch-Jobs.

Dieser Fehler ist seit R610 behoben.

Punkrock im Autocometen: für die Start- und Endzeiten (dmn_ScheduledJobs.started und dmn_ScheduledJobs.ended) wird das Jahr 1977 angegeben. Auf dem Rechner ist es 2008.

CS3 Server R603 auf OS-X Server 10.4.11

Behoben ab R668

Stimmt so nicht ganz: nach demselben Prinzip wie für XML Offline Projekte konnte die Publikationspalette auch über SOAP verwendet werden, allerdings war das nicht praktikabel.

Jetzt werden die Daten statt aus der Konfigurationsdatei über SOAP::getList geladen, siehe dazu die aktualisierte Dokumentation der Publikationen-Palette.

(InDesign® Server CS2 / CS3)

Der Fehler lag in der Farbverwaltung auf InDesign® Server, ab R610 werden Farben richtig verwaltet.

(InDesign® CServer CS2 / CS3)

Funktioniert ab R606

Ursache war leider ein genereller Fehler im SOAP Framework bei der Verarbeitung numerischer Entities (HEX oder dezimal) >= 255. Der (zunächst korrekt) ermittelte Zahlenwert wird einfach auf einen char verkürzt.

Numerische Entities in SOAP werden jetzt beim Lesen generell in InDesign® Tags umgewandelt, fehlerfrei funktoniert dies ab R672

• Shift
• Ctrl
• Cmd
• Opt

Mehr dazu siehe auch hier und in der Online-Doku.

Unter SQL werden die Shortcuts leider nicht ausgewertet. Da steht dann hinter dem Menü immer ",, Cmd+Shift+W" oder so was.

Oops, das geht jetzt.

Trotzdem noch mal laut : Die Shortcuts werden nur gesetzt, wenn sie in InDesign® noch nicht verwendet werden. Cmd+Irgendwas geht kaum noch, vielleicht noch Ö, Ü, ß oder so was. Bevor ihr Fehler eintragt, also bitte erst mal im Menü Edit:Keyboard Shortcuts ... probieren. Danke.

Der Schlagschatten an den Adornments der Platzhalter wird jetzt nicht mehr mitgedruckt.

int main ()
{
	frame::insert (gFrame, "abc", 0);
	textmodel::replace ("AAAAA");

	return 0;
}

Bis zu drei Zeichen (die Länge des eingefügten Textes vor dem Platzhalter) vom Ende des alten Platzhalters bleiben nämlich im Dokument stehen. Zum Ausgleich dafür werden vor dem Platzhalter eben so viele Zeichen entfernt. Mit frame::replace kann man noch bessere Dinge provozieren.

Au Schreck! Das hab ich aber jetzt sofort repariert!

Enthalten die Buchdokumente Comet-Crossreferenzen, werden auch diese aktualisiert.

Das stimmt. link::textlen gibt die Länge des exportierten Textes an, der ist aber erst nach einem link::content verfügbar (also auch dessen Länge). Das war in der Doku nicht so gut beschrieben. link::length dagegen gibt an, wie lang der Text im Dokument ist. Das sind (ganz klar) zwei verschiedene Werte, wenn man nur mal bedenkt, wie lang ein TaggedText so werden kann.

Damit es keine Verwechslungen mehr gibt, habe ich die Funktion link::textlen umbenannt in text::content_length. link::textlen erzeugt ab sofort einen Skriptfehler und muss ersetzt werden.

Lösung

Mit einer Kombination aus InDesign®-Hyperlinks mit Zielverweisen und dem (neuen) Werk II Platzhaltertyp "Querverweis" ist das jetzt möglich : Die Hyperlinks definieren dabei das Querverweis-Ziel, die Querverweis-Platzhalter können dann auf diese Ziele verweisen. Zum Anlegen von Querverweis-Zielen und suchen dieser Ziele gibt es diverse Skriptfunktionen und Menübefehle.

Das Ganze funktioniert innerhalb von Dokumenten und, wenn ein Buch geöffnet ist, das dieses Dokument enthält, auch über das ganze Buch.

Die Querverweise werden aktualisiert, wenn ALLE Rahmen eines Dokuemtes neu geladen werden oder über den (neuen) Menübefehl "Aktualisiere Seitennummern und Querverweise" in der Buchpalette. Ausserdem gibt es einen Skriptbefehl dazu (document::update_crossrefs).

Mehr dazu in der Online-Doku (InDesign/Plugins/crossref.html).

Neue Skriptfunktionen

• textmodel::insert_crossref
• frame::insert_crossref
• document::update_crossrefs
• hyperlink::find
• hyperlink::find1
• link::crossref::document
• link::crossref::page
• link::crossref::pagename
• link::crossref::name
• link::crossref::x
• link::crossref::y
• link::crossref::left
• link::crossref::top
• link::crossref::right
• link::crossref::bottom
• link::crossref::pos
• strword

Erweiterte Skriptfunktionen

• book::repaginate
• book::insert
• book::moveto
• book::remove
• textmodel::gettext
• frame::gettext

Neue Skriptglobale

• gRepagination

Workaround:

Im Laden-Skript placeholder::set_sync (1); einbauen.

Dieser Fehler ist behoben.

Das geht jetzt. Die Tabelle wird so weit kompromiert, wie das möglich ist - dabei steht sie dann aber über den Rahmenrand hinaus. In diesem Fall wird der Fehlercode wrongColumnsForCompressErr (1266) zurückgegeben, obwohl die Tabelle komprimiert wurde.

Ausserdem (juhu!) dürfen Tabellen jetzt mehrfach komprimiert werden - das Ergebnis ist immer fein. Zusätzlich gibt es die neue Funktion table::decompress_colwise.

Achtung : Auch die CS- und CS2-Versionen der Comet-Plug-Ins haben jetzt Versionsnummer 2.1. Beim Austausch mit den bisherigen Plug-Ins (Version 1.4.x) ist gleichzeitig ein neuer Lizenzschlüssel erforderlich.

    # Text [370, 424] contains 4 tables.

Und wenn man mal schaut, enthält so ein Textteil dann gar keine Platzhalter.

Das war ein schwerer Fehler, er ist jetzt behoben.

Das ist leider richtig. Eine klitzekleine Änderung an R644 in letzter Minute hat diesen Fehler bewirkt. Er ist jetzt behoben und Bilder können auch über eine URL geladen werden. Sollte der Import trotzdem nicht klappen : Bitte erstmal im Internet-Browser versuchen, ob die URL auch richtig ist und tatsächlich ein Ergebnis liefert

Zwei weitere kleine Fehler wurden gefixt :

1. Ein im Rahmen bestehendes Bild wird jetzt vor dem Einbetten entfernt.
2. Hat der Rahmen ein XML-Element im Dokument, wird dieses Element nach dem Import wieder hergestellt.

• In der Vorlagenpalette ist Mehrfachselektion möglich.
• Beim Export werden nur die selektierten Vorlagen exportiert.
• Es gibt zwei Import-Menüs
  • Importieren ohne Überschreiben Bestehende Vorlagen des aktuellen Datenpool werden nicht verändert.
  • Importieren Überschreiben bestehender Vorlage und Einfügen neuer Vorlagen aus dem Importordner
• Das Konvertieren-Button () ist entfernt. Konvertieren läuft jetzt immer über Export-Import.
• Beim Import wird automatisch ein Upgrade aller Platzhalter auf die aktuelle Plugin-Version gemacht. Der Upgrade der Vorlagen wird über Snippets gemacht. Da unter CS noch keine Snippets definiert sind, kann unter CS auch kein Upgrade gemacht werden!

    # Magnets & Nails : off

Dieser Fehler ist behoben.

Ja, man kann. Ich verwende dort jetzt statt 8-Punkt Verdana die 9-Punkt-Verdana.

Workaround

Leere Zellen mit Platzhaltern kann man sich leicht "einfangen", sie einstehen beim Anlegen neuer Tabellenzeilen oder -spalten, wenn der Vorgänger Platzhalter enthält. Das passiert sowohl beim Anlegen von Zeilen und Spalten über InDesign® als auch über die Skriptsprache. In der Skriptsprache sollte man in diesem Fall immer ein textmodel::clear_placeholders über die erzeugten Zellen laufen lassen.

Lösung

Das ist in der Tat ein übles Verhalten. Durch die Ersetzung des Platzhalters wird in diesem Fall der intern bitter benötigte Zellentrenner (\r) aus dem Dokument gelöscht und InDesign® kann die Zuordnung von Tabellenzellen zu ihrem Text nicht nicht mehr ordentlich machen und denkt sich halt was aus.

Der Fehler ist jetzt behoben. Vor JEDEM Einfügen von Text in Tabellenzellen wird jetzt in einer aufwendigen Rechnerei sichergestellt, dass die gewünschten Textpositionen nicht über den Zellenrand hinaus reichen und bei Bedarf eingeschränkt.

Zusätzllch haben die beiden Funkionen table::insert_rows und table::insert_cols einen neuen Parameter bekommen, mit dem die Platzhalter automatisch aus den neuen Zellen entfernt werden. Dann kann man sich das mühevolle Ausrechnen der Zellentextindexe für textmodel::clear_placeholders ersparen.

Dieser Fehler ist behoben.

Die Funktionen gibt es jetzt. Mehr dazu in der aktuellen Doku (textmodel::cut, textmodel::copy, textmodel::paste).

img     = image::alloc(imagePath); // imagePath ist eine URL
					
printf (imageName, "/tmp/iquest/%s.jpg", barCodeName);
image::save(img, imageName);
image::release(img);
frame::image(gFrame, imageName, kPlaceTopLeft, 0.0);

Im Windows wird das Bild nicht gesetzt.

Tja, weil immer wieder Leute nicht wollen, dass Quicktime auf ihrer Dose installiert wird - dabei - was kann ihr denn besseres passieren? Also dann : image::alloc akzeptiert jetzt auch unter Windows URLs. Damit geht das dann.

Wäre schön, wenn das mal gehen würde.

frame::embed_file und frame::embed_image tun das Gewünschte. Näheres dazu wie Immer in der Doku. embed_file akzeptiert auch URL - auch unter Windows! Und auch unter CS3!! Und da auch image::alloc jetzt unter Windows und Mac und CS und CS2 und CS3 URLs akzeptiert, kann man auch die Version embed_image des Befehles verwenden (wers mag).

Das geht jetzt. Und es geht auch mit CS2 und CS und mit CS unter Windows und mit CS2 unter Windows und auch mit CS3 unter Windows.

Also - jetzt brauchts nur noch richtige URLs.

Aah, die Genießer! Diese Funktionen gibts jetzt zusätzlich :

• fval, float-Wert eines String (mit Komma oder Punkt, aber ohne Tausender-Trenner!)
• ftoa, String das float-Wertes, als 2. Parameter ist ein printf-Format (wie "%.2f") erlaubt

Mit query::output (qu,kImage,img,image::bytes (im)-1) scheint man ja den Blob in eine Image-Variable holen zu können.

Image img = image::alloc ();
						
:
:
query::output (qu, kImage, img);

Mit der neuen Funktion textmodel::get_table kann das jetzt gemacht werden. Mehr dazu siehe hier.

Wo er Recht hat, hat er Recht. Es wurde immer nur bestimmt, ob im ersten Rahmen ein Overset ist. Das ist natürlich nicht ganz richtig, es muss der letzte Rahmen der Kette sein. So wird es jetzt gemacht und der Fehler ist damit behoben.

Leider war das Erstellen des Schnappschusses der Seite nicht ganz richtig -image::save konnte in diesem Fall nur fehlerhafte Dateien schreiben. Jetzt geht alles wieder.

file::uncurtain macht das. Ein Beispiel befindet sich im Bug 1048.

    "Doc.indd" kann nicht unter einem neuen Namen gespeichert werden. Die Datei
    "Doc.indd" ist beschädigt (Fehlercode: 1).

Okay, das geht jetzt. Hier ein Beispielskript, das den Text des aktuellen Rahmens als neuen Pfad nimmt (uncurtain ist neu und ersetzt $DESKTOP und so was, siehe Bug 1071) :

int main ()
{
	String    s = string::alloc ();
	int       res;

	textmodel::gettext (s);
	res = document::saveas (0, file::uncurtain (string::get (s)));
	wlog ("", "Save as (%d) : '%s'\n",
			  res,
			  file::uncurtain (string::get (s)));

	return 0;
}

Bug 1047 - frame::image_getpath liefert nur Pfade von vorhandenen Dateien

Das sollte jetzt gehen. Eigentlich nur für den Mac wurde aus dem erhaltenen Pfad intern ein Dateiobjekt erzeugt, von dem dann noch mal der Pfad ermittelt wurde. So was ist leider nötig, weil Adobe immer noch die alten MacOS 9- Pfade (Laufwerk:Users:paul:...) verwendet und nicht die neuen MacOS X-Pfade (/Users/paul/...). Wenn eine Datei nicht mehr verfügbar war, ist dieser Zwischenschritt fehlgeschlagen.

Nun, unter Windows braucht man diese Konvertierung gar nicht. Und unter MacOS X ist es auch nicht so schwer, den führenden Laufwerksnamen zu entfernen und alle : durch / zu ersetzen.

textmodel::get_frame tut das Gewünschte.

Das geht jetzt auch unter CS3

1. Bei Snippets stürzt InDesign® unter Windows ab.
2. TIFF-Bilder nicht gezeigt werden. Von diesen Dateien kann offensichtlich kein Preview erzeugt werden.
3. Die Previews-Palette erstellt sich die Previews entweder jeweils aus der entsprechenden Datei selbst oder zeigt Snippets an (die dann keinen Pfad haben). Beides zusammen, also ein Dateieintrag, der einen Datenbankpreview zeigt, geht leider nicht.

Lösung

1. Snippets führen jetzt auch unter Windows nicht mehr zum Absturz.
2. TIFF-Bilder können jetzt gezeigt werden.
3. Previews können jetzt auch von der Datenbank geladen werden. Die Auswahl der Blobs erfolgt über eine Erweiterung im Pfad-Attribut (siehe oben). Hier alle drei Möglichkeiten für diesen Wert:

   Name	Syntax	Bemerkungen
   Datei	path	Dateiverweis, das Preview wird automatisch erzeugt.
   Snippet	snippet@select BLOB from ....
   Datei mit Preview	image@select BLOB, path from ...	Dateiverweis mit eigenem Preview. Previews sollten JPG, PNG oder GIF vorliegen

Das stimmt zwar - aber in diesem Showcase sind ausschließlich EPS-Bilder enthalten. Und DIE gingen nicht. Jetzt geht auch EPS wieder.

Das geht jetzt mit dem neuen Skriptbefehl run_applescript - natürlich nur unter Mac! Der Aufruf erwartet als Eingabe ein vollständiges AppleScript, nicht den Verweis auf irgendeine Skriptdatei. In einem zusätzlichen char*-Parameter kann der return-Wert des Skriptes abgegriffen werden. Ein Beispiel befindet sich in der Doku.

Workaround : Vor fit_cols einmal resize_cols auf der entsprechende Spalte ausführen und die Spaltenbreite größer 13 setzen.

Es stimmt, fit_cols hat tatsächlich negative Spaltenbreiten gesetzt. Das Selbe konnte man mit resize_cols erreichen. fit_cols funktioniert jetzt auch bei sehr schmalen Spalten und resize_cols setzt keine negativen Spaltenbreiten mehr.

Der Fehler trat tatsächlich nur bei Gestaltungsmethoden vom Typ Skript auf. Und auch dort ist er jetzt behoben.

   CoreService Error...
   "Error 6 - undeclared identifier :document::page"

SCHADE, war eigentlich 'ne nette Sache.

Die Funktion ist jetzt wieder verfügbar.

Das stimmt leider. Vor dem Einfügen von TT-Text muss der Comet sehr penibel und aufwendig ausrechnen, an welche Textposition welches importiertes Zeichen kommen wird. Leider ist das von Tabellen nicht vorhersehbar. InDesign® verteilt in den Text pro Tabelle einen Tabellen-Anker, der jeweils genau die genannten 2-8 Zeichen lang ist und es gibt keine Möglichkeit, von aussen festzustellen, wieviel Ankerzeichen eine Tabelle einnehmen wird.

Wie auch immer - mit einigen kleinen Tricks, die wir so darauf haben und nicht weitererzählen, gehts aber trotzdem, die Platzhalterpositionen richtig zu bestimmen.

Der Fehler ist jetzt behoben.

    <clStart:1,1>Normal<clEnd:>
    <clStart:1,1><cstyle:Bold>Fett<cstyle:><clEnd:>

bringt InDesign® durcheinander. In der ersten Zelle steht "NormalFett", die zweite bleibt leer. Ein TaggedText-Export zeigt, dass InDesign® zusätzlich ein (leeres) Absatzformat angibt:

    <clStart:1,1>Normal<clEnd:>
    <clStart:1,1><pstyle:><cstyle:Bold>Fett<cstyle:><clEnd:>

Das funktioniert beim normalen Import, der Comet macht allerdings eine zusätzliche Leerzeile in die Zelle mit dem fetten Text. Anscheinend geht der Comet davon aus, dass <pstyle:> immer mit einer Zeilenschaltung verbunden ist und übernimmt die dann automatisch.

Ein Workaround ist, vor dem <cstyle:> ein unsichtbares Leerzeichen einzufügen:

    <clStart:1,1>Normal<clEnd:>
    <clStart:1,1><0x200B><cstyle:Bold>Fett<cstyle:><clEnd:>

Es geht ganz einfach : Man muss sich nur an die (bisher) ungeschriebene Regel halten :

Im TaggedText die langen Tags verwenden, also statt clStart CellStart, statt clEnd CellEnd usw.. Ich habe das jetzt extra nochmal in die Doku geschrieben. Und außerdem hab ich das entsprechende Plugin mit den Kurzformen der TabellenTags bekannt gemacht (aber nur die!!!!!). Comet wird NICHT vor jedem TT-Import alle 278 Kurzformen in Langformen übersetzen.

Was ist mit Absatz-Stilen am Anfang einer Tabellenzelle? Der comet ersetzt ja jeden <ParaStyle:...> durch ein Absatz-Ende und den ParaStyle. Auch den ersten ParaStyle in einer Tabellenzelle??? Es war jedenfalls mal so, und da funktionierte dann der Workaround, das Tag <pstyle:...> zu verwenden. Hast Du Deine neue Lösung mal mit einer TaggedText-Tabelle getestet, in der Absatz-Stile gesetzt werden? Wenn nicht, mach das bitte noch. Wenn das klappt, ohne Extra-Return, kannst Du den Bug gerne wieder schließen.

Auch das funktioniert.

Das funktioniert jetzt wieder. Eine neue Resource wurde aus Versehen doppelt ins Reader-Plugin eingesetzt.

Mit SOAP-Server und InDesign® auf dem PC tritt das Problem genauso auf.

Das funktioniert jetzt.

Typischerweise tritt das Problem unter Windows auf und äußert sich z.B. mit Fehler 403 beim der Ausführung von Batch-Jobs.

Der Fehler ist behoben.

Der Fehler ist behoben.

Der Fehler ist behoben.

• Gibt man den Tag ParaStyle mit, wird dieser durch 3-5 Returns ersetzt statt nur einem.
• Gibt man eine Platzhalter mit dem w2 Tag aus, bleibt nach dem Laden des Platzhalters immer der letzte Buchstabe des Dummy-Textes stehen.
• Gibt man nur Text mit Paragraphen-Stilvorlage aus (auch <pstyle>) kommt immer ein einfaches weiches Return am Anfang
• Wenn ich unter ID 5.0.2 einen TaggedText mit einem CharStyle ausgeben will (%!TT<CharStyle:W2_Stattpreis>text oder %!TT<cstyle:W2_Stattpreis>text) bekommen ich ebenfalls jede Menge Returns.

Der Fehler ist behoben. Er trat tatsächlich nur nach einem Update auf 5.0.2 und nur auf Intel-Macs auf.

FYI:

Das Problem ist ein offensichtlich verändertes Verhalten des InDesign®-Importes. Bisher musste TaggedText immer im Format <ASCII-WIN> vorliegen und Windows-Zeilentrenner haben. Bei Bedarf hat der Comet die nötigen Umwandlungen selbst gemacht. Alle anderen Angaben führten zum Absturz. Ab 5.0.2 muss auf dem Mac <ASCII-MAC> mit Mac-Zeilentrennern verwendet werden.

Der Fehler trat nur dann auf, wenn ein Produkt wiederholende Elemente enthielt und ist jetzt behoben.

Zum Einfügen der wiederholenden Elemente musste zuvor die aktuelle Seite ermittelt werden - um nach dem Einfügen wieder dorthin zurückspringen zu können. Diese Berechnung war leider falsch.

Für Rahmen mit Beschneidungen können jetzt Referenzpunkte gesetzt werden (). Der Rahmen wird dann (ausgehend vom neuen Rahmen) entsprechend positioniert. Der Referenzpunkt wird nur angewendet, wenn Bidlbeschneidungen nötig waren.

Der Fehler ist behoben, Includes werden jetzt einmal geladen und dann im Cache (~/Documents/XCache) gehalten. Ein Produktaufbau kann dadurch bis zu 4 Mal schneller werden!

Du musst die Datei framerules.xml anlegen und deine Vorlage 6 (kl. Bild + Seitenwechsel) noch mal sichern, dann wird die entsprechende Info dort abgelegt. Beim Aufbau kann diese Info noch nicht ermittelt werden, weil die Vorlage ja noch gar nicht geladen ist und es zu lange dauert, jede Vorlage vorzuladen. Wie framerules aussehen muss, steht hier.

Es ist doch ein Fehler. Er tritt aber nur dann auf, wenn die Produktrecherche geschlossen ist. In diesem Fall sind die framerules nicht geladen und können also auch nicht angewendet werden. Dieser Fehler ist behoben.

Und wenn es dann immer noch nicht geht : Die Comet-Gruppen müssen aktiviert sein

Zusatzmodule:Produktrecherche:Comet Rahmengruppierungen verwenden

Diese Einschränkung hab ich rausgemacht.

productlist::build_list(prods, 0, 0, 0, 0, -1, "", "", 1, 0, 0, 0.0, 0.0, 0.0, 0.0, 1, "build_seq");

Wenn man die Fehlermeldung mit "Abbrechen" wegklickt, ist das Dokument wieder (fast) leer.

Dass das Dokument nach "Abbrechen" wieder in den Ursprungszustand zurückgespielt wird, ist okay. Auch wenns schwerfällt, anderen zuzustimmen, in diesem Fall sollte man Okay wählen.

Was nicht ging war, den Aufbau pro Produkt in einer eigenen Sequenz zu machen
(die hoffentlich kurz genug ist, dass die obige Meldung nicht kommt) vorletzter Parameter des zitierten Aufrufes. Da bin ich mit der Reihenfolge der vielen Parameter durcheinander gekommen.

Jetzt gehts jedenfalls.

Außerdem wäre es vielleicht hilfreich, die Meldungen mit einem einheitlichen Präfix zu versehen, damit man sie im Logfile auch alle finden kann.

Die Konfiguration eines Datenpools wird jetzt zusammengefasst ins Logfile geschrieben :

# Configuration for 'Verbindungsname'
        StringIDs               : supported | off
        Pageitem scripts        : supported | off
        Table placeholders      : supported | off
        Preview snippets        : supported | off
        Magnets & Nails         : supported | off
        Mirrored pageitems      : supported | off
        Grids direction         : supported | off
        Framerules              : supported | off

Der Verbindungsname ist auch bei SOAP richtig.

Zusatzmodule -> Produkte|Platzhalter|... ->

die ersten acht Palettenskripte der jeweiligen Palette angegeben. Leider sind diese Einträge erst erreichbar, wenn das zugehörige Menü der Palette einmal aufgeklappt wurde. Und das nach jeder Änderung der Datenverbindung.

Die Menüeinträge sind jetzt auch ohne Palette verfügbar. Sie werden nach jeder Änderung der Datenverbindung aktualisiert. Außerdem enthält das Programmmenü jetzt nicht mehr nur die ersten 8 Einträge sondern die komplette Menüstruktur, wie in der Palette mit allen Submenüs, Shortcuts und den entsprechenden Kontexten.

Siehe auch hier.

Shortcuts können jetzt hinter dem Namen der Aktion durch zwei Kommas getrennt angegeben werden. Ist ein Shortcut in InDesign® bereits definiert, wird die Angabe aus actions ignoriert.

Siehe auch hier.

Key-Definition

Die Buchstaben werden normal verwendet, auch die Tag-Schreibweise wie z.B. <0x00D5> für Ö ist erlaubt. Die Funktionstasten heißen F1 - F12. Folgende Schlüsselworte bezeichnen die einzelnen Modifier-Tasten

    Shift Ctrl Cmd Opt

Alle Teile werden mit + getrennt. Also etwa

    ,, Shift+Ctrl+W

InDesign®-Kontext

Vor der Tastenkombination kann ein InDesign®-Kontext definiert werden. Dieser Kontext beeinflusst nur den Shortcut, nicht den Menüeintrag selbst und legt fest, in welchem Kontext der Shortcut sichtbar ist. Folgende Kontexte (und keine weitere mehr!!) sind verfügbar :

    Dialog Default Ever Table XML Text

Ist die Angabe leer, ist der Shortcut immer sichtbar. Die Angabe

    ,, Text Shift+Ctrl+W

erzeugt (wenn nicht schon woanders definiert!), den entsprechende Shortcut dann nur, wenn es eine aktuelle Textauswahl gibt.

Comet-Kontext

Für die automatische (De)aktivierung von Menüeinträgen können folgende Angaben gemacht werden :

    Panel Document

Ist Panel eingeschaltet, ist das Menü deaktiviert, wenn die entsprechende Palette der ClassID geschlossen ist. Ist Document eingestellt, muss ein Dokument geöffnet sein. Fehlt die Angabe, ist der Menüeintrag immer aktiviert. Die folgende Angabe bewirkt also, dass das zugehörige Menü nur dann aktiv ist, wenn die Palette und ein Dokument geöffnet sind :

,, Panel Document Shift+Ctrl+W

Tastaturbefehle ...

Da die Shortcuts immer automatisch gesetzt werden, macht es keinen Sinn mehr, Shortcuts über "Tastaturbefehle ..." zu setzen. Die Menüeinträge der Paletten-Aktionen (nur der Palettenaktionen) finden sich also nicht mehr in diesem Dialog.

Das geht jetzt. Das Verfahren ist sehr einfach : Vor dem Namen der entsprechenden Aktion wird der Submenü-Pfad mit ^ (Dach) als Trenner angegeben. Der Rest geschieht automatisch.

Ein gültiger Name einer Aktion wäre also

aaa^bbb^Testskript

Die Reihenfolge in den Untermenüs wird ebenfalls über die Sequenznummer festgelegt.

Vorlagen werden automatisch mit der Dokument-ID

     -1, PageitemID, 0, Benutzername

versehen.

Zum Holen und Setzen der Dokument-ID gibt es die beiden neuen Skriptfunktionen document::getid und document::setid.

    # WARNING! Some characters in "<your string>" have been substituted with '-'

Ein '-' wird nicht zwar im String eingefügt, der String wird aber einfach abgebrochen.

Eigentlich sollten solche Zeichen ja mit <0xBEEF> kodiert werden. Ich versuche jetzt trotzdem, so viele Teilstücke des Strings zu dekodieren wie möglich.

Dieser Fehler ist jetzt behoben.

Die Cache-Datei des Skriptes wird jetzt ebenfalls angepasst. Das Arbeiten macht jetzt wieder Spaß.

Der Fehler lag daran, dass die interne Repräsentation der MAC-IDs der Ethernet-Karten nicht fortlaufend von 1-n ist, sondern dass in der Liste "Löcher" sind. Die Prüfung der Lizenz gegen die verfügbaren Mac-IDs wurde aber bisher abgebrochen, wenn keine MAC-ID gefunden wurde.

Diese "Löcher" werden jetzt übersprungen. Der Fehler sollte damit behoben sein.

ACHTUNG : Auf dem Mac funktioniert der Oracle-Client nur für Power-Mac, nicht für Intel-Macs. Das heißt, CS3 geht auf einem Intel-Mac nicht. Das Problem ist die Bibliothek, die für die Verbindung benötigt wird und die von Oracle nur für PPC erstellt wurde. Oracle ist seit 24 Monaten (!!!) dabei, das zu ändern - aber so Oracle "... nobody is going to do this on their lunch hour and then upload it to OTN after dessert". Andere fragen sich, ob bei Oracle 2 Jahre lange Mittagspausen gewährt werden und wollen zu Oracle wechseln. Wer sich bei Oracle beschweren/bedanken/beklagen machen will, hier ein Link.

Lesen Sie zur Installation und Einrichtung von OCI bitte unbedingt diese Beschreibung!

Der Fehler war ziemlich blöd : Jetzt werden die Produkte ja nicht mehr auf Seitengrößen sondern auf die BoundingBox des Rasters getestet. Leider ist die ID-API-Funktion Rectangle::Union der Meinung dass z.B. die beiden Rechtecke

    42.519684, 53.858269, 552.7559, 170.07874
    42.519684, 67.619186, 552.7559, 183.83966

die BoundingBox

    42.519684, 53.858269, 552.75589, 183.83966

haben. Was zwar fast stimmt, aber eben nicht ganz.

Weiß auch nicht, warum an der entscheidenden Stelle im Quellcode ein #if (csversion_ < 3) stand. Jetzt gehts jedenfalls.

Ja, so sind die Fehler inzwischen, wenn-wenn-wenn-DANN. Dieser Fehler ist jetzt jedenfalls behoben.

Platzhalter gesperrter Ebenen werden jetzt beim Aktualisieren und Synchronisieren nicht mehr bearbeitet. In den Store-Skripten kann man die Platzhalterinhalte weiterhin verändern. Auch die Skriptbefehle itemlist::allframes, ... nehmen keine Rücksicht auf gesperrte Ebenen. Wenn das speziell gebraucht wird, bitte diesen Bug wieder öffnen - oder einen neuen.

(11.01.2008) Es hat sich gezeigt, dass es oft so gewollt ist, die Inhalte gesperrter Ebenen zu ändern. Die Sperre ist deshalb wieder aufgehoben.

Dieser Fehler ist behoben, die Funktion prüft jetzt, ob Ausgangs- oder Zielebene gesperrt sind und liefert in diesem Fall einen Fehlercode zurück.

Ein möglicher Workaround ist, bei MySQL die Option lower_case_table_names = 1 zu setzen. Das funktioniert allerdings spätestens dann nicht mehr, wenn jemand wirklich Großbuchstaben in MySQL benutzt. Deshalb sollten wir bei Gelegenheit alle SQL-Abfragen auf durchgehende Kleinschreibung umstellen.

Die folgenden Schreibweisen habe ich im gesamten (!!) Quelltext aller (!!) Plugins ersetzt durch Kleinschreibungen. Sollten sich immer noch falsch geschriebene Tabellennamen finden, schaut bitte zuerst in den Panelstatements nach, ob die dort stehen. Wenn nicht, den Bug nochmal öffnen - in dem Fall wäre es schön, wenn ihr den Tabellennamen und vielleicht die Fehlersituation angebt.

• Actions
• CharacterStyles
• ConditionMenues
• Conditions
• Domain
• iq_Colors
• iUser
• PageItems
• PageItemTypes
• PlaceHolder
• PreviewStatements
• RelatedTo
• States
• UserXDomain

Eigentlich sollte die Tabelle ja grid_elements (mit _) heißen. Damit es auch ohne _ funktioniert, wird jetzt vorher getestet, ob grid_elements überhaut existiert. Wenn nicht, wird die Tabelle gridelements verwendet.

In <link>, <linkfolder>, <linknameN> werden jetzt auch unter Windows / statt \ als Pfadtrenner verwendet. In den Pfaden zum Bildeinfügen dürfen schon seit längerem auch unter Windows / als Pfadtrenner verwendet werden - besser gesagt : Alle Pfade sollten als Pfadtrenner nur noch / verwenden!

Das stimmt, es gibt ein Limit, 100. Ich habe das mal hochgesetzt auf 3000. Genug?

Schön wäre es jetzt, wenn der ID-Tupel auch an die Platzhalter in der Vorlage weitergegeben werden würde. Das Skript muss sonst durch alle Rahmen gehen, und jeweils ein Verlinken und Laden anstoßen. Die Performance ist sicher besser, wenn das das PlugIn direkt tut.

Die Funktionen haben zwei neue Parameter bekommen :

    autoLoad und classID

Ist autoLoad != 0 werden alle Platzhalter mit der ClassID classID (oder alle überhaupt, wenn *classID* = 0 ist), verknüpft, geladen und bei Bedarf aufgebaut (wiederholende Elemente).

Wenn man eine Farbe einstellt, klappt das Anlegen - das ist natürlich ein Workaround, daher niedrige Priorität.

Der Absturz ist nicht immer passiert. Ich glaube, der Fehler lag daran, dass
bei neuen Platzhaltern die Farbauswahl nicht initialisiert war. Das wird jetzt gemacht. Ich hab dann keinen Absturz mehr hingekriegt.

Offensichtlich wird die Konturführung in CS und CS2 unterschiedlich gehandhabt : CS kennt nur den Standard "Objekt überspringen", die Palette "Konturführung" ist bei Inline-Rahmen deaktiviert. Unter CS2 kann die Konturführung eingestellt werden.

Sie können 3 Dinge tun :

1. Die ID-Standardeinstellung für die Konturführung von Inlines ändern (Nach dem Start von ID und OHNE GEÖFFNETES DOKUMENT)
2. Die Kontur im Skript setzen (frame::wrap, frame::wrap_ignore, frame::wrap_invert, ...)
3. (Erst ab Release 528 (heute :-) )) Die Kontur im in-Tag mit wrap ... setzen

Dieser Fehler ist behoben.

Ich wäre dafür, dass wir hier NICHT die C-Notation verwenden, sondern dass die oberste Zeile einer Tabelle Zeile eins ist, genauso natürlich auch für Spalten.

Ja, das war ein blöder Fehler. Wenn ich jetzt ab 1 zähle, werden zwar alle Gestaltungen, die bis jetzt gemacht wurden, anders, dafür kann man dann aber auch ab 1 zählen. Und die erste Zeile/Spalte auch einschließen

Übrigens schlage ich als Palettenname Raster-Assistent bzw. Grid-Wizard vor. Der jetzige Name verwirrt die Leute immer heftig.

Ach herrje. Die Palette hat jetzt einen neuen Namen und kann 999 x 999 Rasterplätze anlegen - was dann auch entsprechend lange dauert - und beim Produktaufbau auch ordentlich Speicher zieht (Minimum 10 MB für linkes und rechtes Raster).

• Comet
  • Einstellungen
  • Previews
  • Produktrecherche
  • Publikationen
  • Publikationsinfos
• Comet Admin
  • Arbeitsvorbereitung
  • Aufbauregeln
  • Comet
  • Platzhalter
  • Platzhalterwerte
  • Raster
  • Rastervorlagen
  • Vorlagen
  • Seitenadaptionen
  • Tabellenaufbau
• Sudoku
• XCell
• Seitenadaptionen

Das geht jetzt - wie alle Comet-Menübefehle im Produktbereich IQuest.comet.

p = productlist::first (gProducts);
productlist::remove_pos (gProducts, 0);
product::release (p, kGlobalStack);

stürzt Indesign beim Gridaufbau ab. Verwendet man an Stelle von remove_pos die Funktion remove, funktioniert es:

p = productlist::first (gProducts);
productlist::remove (gProducts, p);
product::release (p, kGlobalStack);

Sorry, das stimmt leider. War ein kleiner Indexfehler der Parameter von productlist::remove_pos, der jetzt behoben ist.

    *gSyncChanged=1;
    placeholder::set_sync(-1);

bewirken, dass auch in Load-Skripten das entsprechende Sync-Symbol angezeigt wird. Dem ist aber nicht so (Plugin-Version 1.4.2 R451).

Ooops, das stimmt. Im Quellcode fehlte ein kleines "else". Jetzt funktioniert es wie in der Doku beschrieben. Zusätzlich wird der Wert von gSyncChanged jetzt auch in Textplatzhaltern unterstützt, siehe auch placeholder::sync_state.

Deshalb wird zur Prüfung jetzt die BoundingBox um alle aktuellen Rasterplätze verwendet. Das kann zu Problemen führen, wenn die Rasterplätze zu klein sind. Sollte das passieren (Fehler -3334), behebt folgendes den Fehler :

•    
  Ist diese Option eingeschaltet, wird die Seitengröße (inkl. Margins) zum Test verwendet und nicht mehr die BoundingBox.
• oder eben die Rasterplätze entsprechend vergrößern.

Es gibt jetzt die Funktionen

    system::version
    system::language

Die ALT-Taste muss jetzt sowohl bei Vorlagen als auch bei Rastern gehalten werden, wenn diese geändert werden sollen. ... Und, ääh, bitte keine Anrufe, man könne keine Vorlagen mehr ändern ...

Seit Einführung von InDesign® Server geht das für den Produktaufbau mit der Anweisung produclist::build_list. Seit heute geht es auch für den Textfluss - hier gibt es jetzt die Funktion textmodel::insert_list. In der Online-Hilfe sind auch Beispiele zur Verwendung der Funktionen zu finden.

Das geht jetzt. Die Aufbauregeln werden in der neuen Tabelle/Datei framerules gespeichert wenn eine Vorlage gesichert oder geändert wird.

Ist ein Produkt einmal aufgebaut, werden die im Rahmen hinterlegten Regeln verwendet. Um zu verhindern, dass in Vorlagen mehrere (widersprüchliche) Regeln hinterlegt sind, zeigt die Vorlagenpalette beim Anlegen und Ändern von Vorlagen mit mehreren Regeln einen Dialog, in dem angegeben werden kann, welcher Rahmen für die Regeln verwendet werden soll.

Achtung

Diese Prüfung kann natürlich nicht im faceless-Betrieb (Server, Skripte) gemacht werden. Hier werden die Regeln des ersten Rahmen verwendet. Der erste Rahmen ist der, der im Dokument zuerst angelegt wurde. Da man das natürlich meistens nicht mehr weiß, sollten Vorlagen mit mehreren Rahmen nur angelegt werden, wenn die Regeldefinition dort eindeutig ist. Hilfreich dazu sind die Funktionen placeholder::(s)get_value und placeholder::change_tags mit den Slots PreRule, PostRule, PreRuleParams, PostRuleParams, AdParams, Grid und GridElement.

XML-Struktur von framerule.xml

<?xml version="1.0"?>

<framerules>
  <framerule>
	<pageitemid>0</pageitemid>
	<prerule>
	  <id>0</id>
	  <params></params>
	</prerule>
	<postrule>
	  <id>0</id>
	  <params></params>
	</postrule>
	<banner>
	  <gridid>0</gridid>
	  <elementid>0</elementid>
	  <pagerelative>0</pagerelative>
	  <intersection>0</intersection>
	  <distance>0.0</distance>
	</banner>
  </framerule>
</framerules>

Attribute von framerules

  id (int)
  pageitemid (int)
  prerule_id (int)
  prerule_params (varchar(4000))
  postrule_id (int)
  postrule_params (varchar(4000))
  grid_id (int)
  element_id (int)
  pagerelative (int)
  intersection (int)
  distance (float)

Zusätzlich zu den Eigenschaften für den Textfluss kann jetzt festgelegt werden, ob ein Rahmen beim normalen Einfügen der Vorlage ignoriert werden soll oder nicht. Ignorierbare Rahmen werden beim Einfügen von Vorlagen ins Dokument (Drag'n Drop, Vorlage einsetzen, Produktaufbau, insert_macro, ...) übergangen.

Der Parameter hstate in hyperlink::appearance ändert nicht die Sichtbarkeit eines Verweisrahmens. Er regelt nur das Aussehen des Verweises, wenn die Datei als PDF exportiert wird (Obwohl ich sie da gar nicht sehe.). Die Sichtbarkeit kann entweder mit show/hide gesetzt werden oder mit dem (neuen) Parameter visible in hyperlink::appearance.

Tja, da ist mir ein kleiner Fehler unterlaufen. Das Tag liefert jetzt wieder richtig den DokumentNAMEN - und nicht den ganzen Pfad.

• <document>  : Dokumentname
• <folder>       : Ordner des Dokumentes
• <path>         : Kompletter Pfad des Dokumentes

Da war noch mehr falsch :

• Auch kExportTT hat die StringID nicht exportiert
• Die Definition des Tags war falsch. Sie muss lauten <w2: ...., definition classID relatedToID, selectID ... >

Diese Fehler sind jetzt behoben.

Adobe verwendet seit CS2 als Basisformat für die Bibliotheken nicht mehr die Binärdaten sondern INX. Das kennt natürlich unsere Platzhalter nicht. Um INX unsere Platzhalter bekannt zu machen, muss man - naheliegend - die entsprechenden Plugins skriptfähig machen. Das geht jetzt. Sowohl Text- als auch Rahmenplatzhalter werden von INX (und damit von Bibliotheken) unterstützt.

    w2fr : Kennung eines Rahmenplatzhalters
   w2tt : Kennung eines Textplatzhalters

Die Werte des Platzhalters sind als String angegeben. Sie beginnen also INX-konform mit k_, dann kommen die Werte des Paltzhalters als leerzeichen-getrennte Liste von Parameter-Name=Wert - Paaren. Als Parameternamen werden die auch in placeholder::change_tags definierten Namen und ihre zugehörigen Datentypen verwendet. Paramenternamen, die mit My beginnen, dürfen nicht geändert werden, reserved~-Werte werden ignoriert. Der Wert von table darf nur geändert werden, wenn er nicht internal ist, er darf nicht den Wert internal zugewiesen bekommen.

if(app.documents.length != 0)
{
  if(app.selection.length != 0)
  {
    for(var i = 0;i < app.selection.length; i++)
    {
 		var txt;      

		switch(app.selection[i].constructor.name)
		{
			case "GraphicLine"	:
			case "Oval"    		:
			case "Polygon"    	:
			case "Rectangle"    	:
			case "TextFrame"    	:
			  txt  = "Placeholder=101";
			  txt  += " ID=1 ID2=11 ID3=111 StringID='<0x00FC>'";
			  app.selection[i].framePlaceHolder = txt;
			  break;
   
			case "Text"      		:
			case "Character"    	:
			case "Word"      		:
			case "Line"      		:
			case "TextStyleRange"	:
			case "Paragraph"    	:
			  txt  = "Placeholder=60";
			  txt  += " ID=1 ID2 = 0 ID3=0 StringID='hallo'";
			  app.selection[i].textPlaceHolder = txt;
			  break;

			case "TextColumn"		:
			  break;

			case "InsertionPoint"	:
			  break;
  
			case "Cell"  			:
				txt  = " ColGroupPrefix1='alpha'";
				txt  += " ColGroupPrefixN='omega'";
				app.selection[i].tableModuleData = txt;
				break;
  
			case "Table"  		:
			   txt	= "OjectName='Hologramm'";
			   txt	+= " Groups='\"qwertzu\" \"Moleskine\"'";
			   app.selection[i].tableModuleData = txt;
			   break;
		}    
    }
  }
}

Diese Punkte sind geholt. Die Liste hat jetzt einen vertikalen Scrollbalken.

• Neues Buch anlegen
• Dokumente einfügen
• PDF-Export

Mit viel Mühe habe ich das Modul book gemacht. Dort gibt es die folgenden Funktionen :

• book::create
• book::open
• book::close
• book::insert
• book::save
• book::position
• book::is_valid
• book::set_master
• book::get_master
• book::remove
• book::moveto
• book::export_
• book::count_docs
• book::nth_doc
• book::repaginate

27.11.2007

Comet-Gruppierungen können auch in der Palette Aufbauregeln festgelegt () und gelöst () werden. Mit Hilfe des Buttons können Comet-Gruppen im Dokument sichtbar gemacht werden.

Achtung

• Wird der Hauptrahmen einer Gruppe () aus dem Dokument entfernt, wird die Gruppe aufgelöst. Sie müssen die restlichen Rahmen dann neu comet-gruppieren.
• Die Gruppenzuordnungen werden beim Einfügen von Vorlagen nicht übernommen - dort werden alle Rahmen der Vorlage zu einer (neuen) Gruppe zusammengefügt.

      Shift-Alt Klick

Allerdings funktioniert 'get_stroke' nicht. Egal welche der Seiten-Konstanten (eLeftSide, etc.) man übergibt, als Resultat wird immer der Wert '1' (internal error) zurückgegeben. Sowohl 'linetype' als auch 'weight' sind immer '0'.

Da muss ich wohl ein bißchen geschlafen haben. Der Fehler ist jetzt behoben.

FYI

Alles war eigentlich richtig, nur hat die innere Funktion den Fehlerstatus nicht auf "Erfolg" gesetzt, so dass die Skriptfunktion von einem Fehler ausgegangen ist. ...

Das ist kein Problem - page::get funktioniert jetzt auch nicht mehr. Spaaass, page::getstr funktioniert jetzt richtig

document::table_of_content macht das Gewünschte.

Beispiele:

table::font(...) 		⇒ table::get_font(...)
table::colorize(...) 	⇒ table::get_colorize(...)
table::stroke(...)		⇒ table::get_stroke(...)
...

Zu den Funktionen, die Zelleigenschaften setzen, gibt es jetzt die dazugehörigen Get-Methoden. Alle Zell-Methoden können jetzt auch mit

    table::cell::func_name

gerufen werden. Getter haben das Präfix "get_", Setter beginnen in der Regel mit "set_". Bisherige Funktionennamen behalten ihre Gültigkeit, sind aber zum Teil aus der Dokumentation entfernt wurden.

Achtung

Nicht alle table-Funktionen, die auf Zellbereichen bearbeiten, ändern auch Zell-Eigenschaften. So setzen etwa die o.g. Funktion table::font aber auch table::style, table::font, table::align u.ä. nicht Zelleneigenschaften sondern Texteigenschaften - in diesem Fall jeweils für den Text der angegebenen Zellbereiche. Für diese Funktionen wurden keine Get-Methoden implementiert.

Folgende Get-Methoden sind implementiert :

• table::get_rows
• table::get_columns
• table::get_parent
• tabel::get_id
• table::get_style (Tabellenstil ab CS3)

• table::cell::get_textpos
• table::cell::get_text
• table::cell::get_size
• table::cell::get_box
• table::cell::get_rowid
• table::cell::get_colid
• table::cell::get_cellid
• table::cell::get_style (Zellenstil ab CS3)
• table::cell::get_fillcolor_rgb
• table::cell::get_fillcolor_cmyk
• table::cell::get_fillcolor_lab
• table::cell::get_strokecolor_rgb
• table::cell::get_strokecolor_cmyk
• table::cell::get_strokecolor_lab
• table::cell::get_insets
• table::cell::get_rotate
• table::cell::get_stroke

” ("99" oben) - <0x201D>
’ ("9" oben) - <0x2019>
« (franz. Anführung) - <0x00AB>
» (franz. Abführung) - <0x00BB>

Der Rest (insbesondere die Anführung) funktioniert.

Der Fehler ist behoben. Die folgenden Anführungszeichen werden jetzt ersetzt. Dabei werden Doppelzeichen durch ", und einfache Zeichen durch ' ersetzt. Die Primes werden jeweils durch die entsprechende Anzahl von ' ersetzt.

Das Problem ist zumindest für unsere Umlaute und die geläufigen europäischen Kringerl gelöst. Đ (die vietnamesische Währung Dong) oder eine Schüssel über dem ă (Wer braucht wohl so was?) gehen noch nicht richtig. Hier ist das Problem, dass die Strings in unseren Plugins unterwegs in 8-Bit umgewandelt werden. Eine vollständige Lösung kann hier nur bringen, dass wir intern auch mit Unicode oder UTF8 arbeiten. Aber dazu sind größere Änderungen nötig.

FYI

Pfade werden auf dem Mac intern inzwischen anders codiert. Apple verwendet hier jetzt sog. combining characters. Umlaute und andere Zeichen mit irgendwelchen Kringeln über/unter/vor/hinter/mittendrin werden danach so codiert :

    Erst das Basiszeichen, dann der Unicode des Kringels.

Super Idee - und schön, dass sie so einmalig ist. Um das Ganze noch ein bißchen aufzulockern, wird dann aber nicht der Unicode verwendet, sondern das Ganze noch in UTF8 umgeformt. Das rauszufinden und Strings entsprechend zu kodieren, kostet schon mal ein Wochenende. Und das auch noch mit der tollen Entwicklungumgebung XCode von Apple (die auch noch toller werden soll. Apple sagt ja, da macht man dann extra Fehler, nur um den tollen Debugger bei der Arbeit zu sehen. Höhöhö.)

siehe auch hier

<RootTableRecordID>        = gRootTableRecordID
<RootTableRecordID2>       = gRootTableRecordID2

Genaue Beschreibungen finden sich hier : Beschreibung siehe gProduct und Skriptumgebung

Dieser Fehler ist behoben. Absatzmarken und aktuelle Seitennummern werden jetzt als Text Exportiert.

Achtungs

• Vorige und nächste Seite funktionieren nicht. Aber das scheint auch in InDesign® selbst nicht so richtig zu funktionieren.
• Die Ersetzung der Marken wird ausschließlich in der Funktion xmlexport::export_ gemacht. textmodel::gettext liefert wie bisher die Sonderzeichen. Sollte das hier auch nötig sein, müssen wir das dort gesondert ändern.

Mit den neuen Funkionen

    table::apply_tablestyle
    table::apply_cellstyle

geht das jetzt. Der jeweilige Stil muss im Dokument definiert sein und wird über seinen Namen identifiziert. Um einen Stil wieder entfernen, wird der Leerstring als Name angegeben.

Das Problem ist nicht die erste, zweite, dritte Tabelle. Das Problem sind Tabellen, die im unsichtbaren Bereich eines Textrahmens (Overset) liegen. Um festzustellen, ob eine Tabellenzelle einen Overset hat, muss InDesign® diese Zelle neu zeichnen. Das wird aber mit Tabellen im Overset nicht gemacht. Da dadurch ein bestehender Zellen-Overset erstmal weiter besteht, kam die Funktion an ihr Abbruchkriterium von 5000 Pixeln.

Ich habe 2 Dinge getan :

1. Tabellen, die (teilweise) im Overset liegen, werden nicht mehr bearbeitet (Fehler 1259)
2. Abbruch ist jetzt bei 1000 Pixeln - aber der wird ja jetzt eigentlich nicht mehr erreicht.

Es ist ziemlich wichtig, den Fehlercode der Funktion abzufragen :

result = table::fit_col (0, 1);
if (result) showmessage (serror (result));

Dieser Fehler ist behoben. Die Platzhalter werden jetzt vollständig entfernt. Zusätzlich wurde die Funktion tabele::get_textpos erweitert : Lässt man die Angaben für die Tabellenzelle weg, werden Startposition und Textlänge der gesamten Tabelle berechnet :

      table::get_textpos (T, &start, &len);

Dies passiert anscheinend dann, wenn kein gültiger xml-offline-Pfad gesetzt ist. Das normale Auslog-Verhalten schient dann zu fehlen.

... dabei hat das so viel Arbeit gemacht, die Paletten alle wieder ordentlich zurückzusetzen.

Der Fehler resultiert aus dem Fix von Bug 764. Ist der Pfad leer oder falsch, wird seither die Initialisierung der Verbindung unterbrochen. Dadurch wurden auch die Paletten nicht mehr zurück gesetzt.

Der Fehler ist jetzt behoben.

Die Zuordnung zwischen Menü und Skript wird natürlich über den Menütitel gemacht. Da hier die Umlaute falsch dargestellt waren, hat diese Zurordnung nicht funktioniert. Das sollte jetzt behoben sein.

Der Fehler ist inzwischen behoben. Ich habe mit einem Befehl, der über 4000 Zeichen lang ist, getestet. Eine Begrenzung gibt es aber nach wie vor : Sie liegt bei

                                8191

Das Auslesen der Attachments ist jetzt wie gewünscht (und sinnvoll!) resistenter, Windows Version mit dem Hybris-Testservice getestet, jeweils ein auf PHP / NuSOAP sowie Axis basierender SOAP-Service funktionieren auch noch :-)

Platzhalter sind eine Texteigenschaft wie Font oder Textfarbe. Diese Eigenschaften bleiben an der Einfügestelle erhalten - auch dann, wenn der gesamte Text gelöscht wird. Ich glaube, in vielen Fällen ist dieses Verhalten sogar erwünscht.

Wird ein neuer Platzhalter (oder "Kein Platzhalter") in der Platzhalterpalette geklickt, wird dieser Platzhalter jetzt aber auch in leeren Texten gesetzt.

Der Fehler ist beim Fix Bug 784 (R 427)von hereingekommen. Er ist behoben, StringIDs unter SOAP werden wieder geholt.

"ERROR: XML file '/path/to/blah.xml' not found or valid."

Wäre es möglich, das bei Gelegenheit aufzuteilen in:

    "ERROR: XML file '/path/to/blah.xml' not found." und
    "ERROR: XML file '/path/to/blah.xml' not valid."?

- Sagt Puh der Bär zu Blah der Datei : Musst du mal im Logfile schauen.
- Sagt Blah die Datei zu Puh dem Bär : Da bin aber zu schön dafür

Okay, sagt daraufhin Puh der Bär, dann zeig ich also allen, was mir an dir nicht gefällt - in einem Dialog. Und bei dem darfst du nicht mal mitreden, nur bestätigen.

Hat ein Rahmen z.B. bisher den Abstand 100 zu einer Seite und wird die Seite doppelt so groß, sollte der Abstand dann 200 betragen.

Zusätzlich zu den Werkzeugen "Nägel" und "Magneten" gibt es jetzt noch die "Prozent-Nägel" und die "Prozent-Magneten" (Die Menübeschriftung im InDesign® ist ein bißchen anders - länger). Diese Werkzeuge machen genau das Gewünschte.

Die Prozentwerkzeuge sind rot eingefärbt, die normalen Werkzeuge haben eine grüne Färbung.

Ist eine Seite mit unterschiedlichen Nägeln fixiert, wird der Prozentnagel angewendet.

Hat ein Rahmen z.B. oben ein normalen Nagel und unten ein Prozent-Nagel, passiert folgendes :

1. Der Abstand zur Seitenoberkante wird prozentual angepasst.
2. Der Abstand zur Seitenunterkante wird wieder hergestellt. Dadurch verändert der Rahmen seine Höhe
3. Der Abstand zur linken Seitenkante wird prozental angepasst.

Um solche Situationen zu vermeiden, sollten in diesen Fällen besser die Nägel in die Kantenmitte geschlagen werden.

Neu geladen werden soll die Liste auch nicht, aber sie muss bei Bedarf geleert werden. Das wird jetzt gemacht.

Das geht jetzt. War ein Fehler in der Adobe-SelectionSuite - die man hier aber gar nicht unbedingt benötigt.

Geht jetzt mit den neuen Funktionen hyperlink::frame_create_pagedest und hyperlink::frame_create_urldest.

char * t = "%!TTbla bla bla<0x003C>blub blub blub";
textmodel::replace(t);

bricht das EInsetzen des Textes bei <0x003C> ab, man erhält im Beispiel nur: bla bla bla. Allerdings wenn ein schließendes > vorkommt, klappt es:

char * t = "%!TTbla bla bla<0x003C>blub> blub blub";
textmodel::replace(t);

liefert bla bla bla<blub> blub blub. Dieser Fehler ist leider SEHR schlimm, da wir bei Beckhoff Cats-SOAP immer <0x003C> bekommen, wenn ein < im Text auftritt und zur Zeit der Text in den Platzhaltern (über 100 Stück) dann abbricht. <0x003E> macht auch Probleme. Anscheinend werden beide Zeichen wie ihre literale Entsprechung interpretiert: <0x003C>cTypeface:Italic<0x003E> wird nämlich als gültiges Tag erkannt.

Lösung

Vor dem Einsetzen von TaggedText (der ja in aller Regel vorher doch mit den <0xXXXX>-Tags aufgebaut wird) werden jetzt die folgenden Ersetzungen gemacht :

<0x003C> in \<
<0x003E> in \>

Das dürfte das Problem lösen. Heißt jetzt z.B. ein Produkt "<:-)", dann könnte in der XML-Datei

<:)

stehen. Der Name wird dann in der Palette richtig angezeigt. Soll der Name eventuell auch als TaggedText ins Dokument eingefügt werden, sollte aber besser folgende Schreibweise gewählt werden :

<0x003C>:)

Dann funktioniert es als Palettenname, Plaintext und TaggedText.

ACHTUNG

Beim Zurückschreiben in XML-Dateien werden die spitzen Klammern nicht automatisch in &lt;0x003C&gt; konvertiert. Das muss das entsprechende Skript selbst tun!

Der tolle Knopf lädt jetzt auch die Aktionen (Aufbau und Gestaltung) des Tabellenmoduls neu.

Der Aufbau sollte eigentlich inzwischen über die Einstellung im Platzhalter unterdrückt werden. Die Variable existierte nur noch, weil ich vergessen hatte, sie zu entfernen. Sie ist jetzt wieder aktiviert.

Erlaubt der Tabellenplatzhalter den Aufbau, hat gBuildTable beim Skriptaufruf den Wert 1, sonst 0. Wird der Wert im Skript geändert, wird der Aufbau damit unterdrückt (resp. erlaubt).

Die Comet-Plugins unterstützen jetzt auch Unicode-Datenbanken. Dazu müssen die entsprechenden ODBC-Treiber installiert sein (siehe unten). Beim Einloggen in die Datenbank muss die Checkbox Unicode aktiviert sein.

Aktuelle Einschränkungen

• Bisher nur Windows. Die Mac-Version folgt Ende August.
• Zur Zeit sind nur die Paletten Produktrecherche und Vorlagen angepasst. Weitere Paletten folgen bis Ende August.
• Im Logfile werden keine Unicode-Zeichen geschrieben. Auch hier wird die Form <0x00FC> verwendet.

Known bugs

Der Skriptbefehl query::output (qu, kString, str, 4000) erwartet im vierten Parameter die Länge in Bytes, die geholt werden dürfen. Das ist unter Unicode die Anzahl der Zeichen, die geholt werden dürfen. Aber jedes dieser Zeichen muss evtl. noch in die Form <0x00FC> gebracht werden. Das Ergebnis kann also bis zu 8 mal länger werden. Deshalb darf beim query::output höchsten (Bytelänge-1)/8 stehen. Also etwa :

char str[8001];

query::output (qu, kString, str, 1000)

Liste der getesteten ODBC-Treiber

UTF8 in XML-Dateien wird jetzt richtig gelesen. Die Paletten zeigen die richtigen Zeichen :

Strings im Speicher

Intern werden die Unicode-Zeichen in der Form <0x00FC> aufbewahrt. Für den Import in InDesign® ist das schon die richtige Darstellung. Für xmlquery müssen Zeichen mit einem Unicode größer 127 in den folgenden Fällen ebenfalls in der Form <0x00FC> geschrieben werden:

• In Panelstatements wenn panelstatements.xml nicht UTF8 ist
• in CScripten
• in xmlquery-Actions

Aktuelle Einschränkungen

• Leider klappt das UTF8 bisher nur unter Mac. Die Windowsversion wird folgen.
• Zur Zeit sind nur die Paletten Produktrecherche und Vorlagen angepasst. Weitere Paletten folgen bis Ende August.
• Beim Zurückschreiben von Daten in die XML-Datei wird kein UTF8 geschrieben. Zeichen mit einem Unicode größer 127 werden in der Form <0x00FC> geschrieben. Auch hier wird bis Ende August angepasst und in Dateien mit dem Encoding UTF8 wieder UTF8 geschrieben.
• Im Logfile werden keine Unicode-Zeichen geschrieben. Auch hier wird die Form <0x00FC> verwendet.

Testphase

Die Einführung von Unicode betrifft weite Teile des Quellcodes der Plugins. Zur Sicherheit gibt es daher vom aktuellen Release noch eine Unicode-freie Version (_Unicode_Off).

Fehler bei der Unicode-Darstellung und Verarbeitung bitte im Bug 788 eintragen.

Leider ist die Abkürzung der Texte mit "..." ein absoluter (im wahrsten Sinne des Wortes) Showblocker : InDesign® versucht den angezeigten Text an der angegebenen Stelle zu kürzen, zeichnet dann offscreen, schaut ob der String passt, und kürzt dann bei Bedarf weiter. Und (zumindest unter Windows) dauert das bei längeren String (um dies ja gerade geht) auch lange - pro Zeile bis zu 30 Sekunden. Das ist völlig indiskutabel. Die Abkürzungen werden daher bis auf weiteres entfernt und lange Texte einfach abgeschnitten.

Der Hilfetext bleibt.

Bis auf weiteres heißt : Wir werden demnächst ein eigenes Control für diese Texte einfügen. Aber das dauert noch ein bißchen - bleibt aber in meiner ToDo-Liste stehen.

Im Moment müsste man da als Workaround vermutlich im Tabellenplatzhalter erstmal abfragen, ob die Tabelle Inhalte bekommt und dann die Tabelle einfügen oder auch nicht, da wäre es schon praktischer und schneller (da die Daten nicht zweimal geprüft werden müssen) wenn das automatisch passiert.

Im Moment ist das Verhalten halt so, dass die Vorlage über den Tabellenplatzhalter so eingefügt wird und stehen bleibt.

Lösung

In der Palette "Tabellenaufbau" gibt es jetzt unter den Spalteneinstellungen (Woanders war kein Platz mehr) eine Checkbox, mit der dieses Verhalten eingestellt werden kann.

Der Fehler ist behoben.

FYI

Die Sache war eigentlich recht ?lustig?. Kommt die Palette in den Vordergrund, werden alle Daten (Aktionen, Gestaltungsmethoden, ...) neu geladen und alle Controls wieder mit ihren nötigen Notifiern versehen. (Notifier sind Funktionen, die ausgeführt werden, wenn sich der Wert eines Controls ändert. Wenn z.B. ein anderer Popup-Eintrag gewählt wird.)

In der Initialisierungsphase sollen die Notifier meist unterdrückt werden. Die entsprechenden Methoden haben dafür ein Flag. Leider ist aber bei den Enable/Disable-Methode für Menüeinträge dieser Parameter an verschiedenen Stellen und so kam es, dass bei Enable der Popup-Notifier gerufen wurde.

Das an sich ist nun nicht so schlimm - in diesem Fall wurde aber in der Initialisierung in einer Schleife über die Aktionen gelaufen und unglücklicherweise hat auch der Notifier diese Liste verwendet und den Listenindex dadurch zurückgesetzt. Wodurch dann die Initialisierung nicht weiterkam --> Endlosschleife.

Dieses Verhalten ist schlecht, wenn ich z.B. nach einem Namen mit Wildcards suchen kann:<statement>getProductList&#xA;productname like &lt;searchvalue1&gt;%</statement>

Wenn dann die Suche bei der Auswahl ausgeführt wird, dann wird nach '%' gesucht und damit alle Einträge gefunden, was zu einem recht langen Ergebnis führen kann. Selbst ohne Wildcards werden von unserer Suche alle Elemente gefunden, da productname like "" immer 'true' ist.

Inzwischen habe ich das mal richtig ausprobiert. Das Problem ist nicht, dass die Suche direkt ausgeführt wird, sondern, dass durch das Benutzen des DropDowns für die Such-Auswahl die vier Textfelder GELÖSCHT werden! So schreibt der Benutzer da zwar zuerst etwas rein, wenn die Suche dann aber die Felder ausliest, sind sie schon wieder leer - und die Suche nicht eingeschränkt! Wenn Ihr das in Aktion sehen wollt, verwendet den allseits bekannten Beckhoff-Entwicklungs-SOAP-Server 212.100.45.120. Die drei Findstatements sind so gestaltet, dass sie auch bei leeren Textfeldern nur je ein Produkt zurückliefern. Sie enthalten trotzdem <searchvalue1> bis <searchvalue4>. Aber im logfile kann man sehen, dass die Abfrage, die abgeschickt wird, für die searchvalues jeweils nur ein % enthält.

Antworten

Die Tags <searchvalue1>, ... bekommen den aktuell im Suchfeld enthaltenen Text mit % am Ende und in Anführungszeichen Bei reinen Zahlen werden Anführungszeichen weggelassen. Bei den Findstatements kann man die Suchfelder vorbelegen mit den Werten value1, ... . Mit der (neuen) Angabe --- in den Values kann das Überschrieben der Suchelder verhindert werden.

Die automatische Suche bei den Findstatements bleibt erhalten. Bei diesen Suchen werden auch die Suchfelder (Beschriftung und Wert) neu belegt. Dazu werden die im Findstatement für value1, ..., label1, ... angegeben Werte verwendet. (Und nochmals : Steht in valueX ein "---", bleibt das entsprechende Suchfeld unverändert.

NEU : Mit der Angabe --- als Suchwert (value1, ...) wird verhindert, dass das entsprechende Suchfeld verändert wird.

Die Standardsuche wird weiterhin nicht automatisch ausgeführt. Aber : Bei Auswahl der Standardmethode werden jetzt die Suchfelder nicht mehr gelöscht.

Der Fehler tritt nur dann auf, wenn der Ordner "Eigene Dateien" wie folgt ausgewählt ist :

1. Ordner im Netzwerk
2. Freistellung dieses Ordners
3. Freigestellten Ordner mit einem Laufwerksbuchstaben verbinden
4. "Eigene Dateien" auf diesen Laufwerksbuchstaben zeigen lassen.
5. Und schließlich muss man Vorlagen über eine Datenbankverbindung einsetzen.

In diesem Fall wird von Windows als Ordner für "Eigene Dateien" ein Pfad wie z.B. Y:\ ermittelt. Der Backslash am Ende war zu viel. Dann entstand ein Pfad der Art Y:\\_werkii_pit26.indd. Und bei dem gingen dann einige Sicherheitstests vor dem Anlegen der temporären Datei für die Vorlage schief.

Der Fehler ist behoben.

Bei der zweiten kopierten Zeile werden die Spalten richtigkopiert allerdings werden ab der zweiten Zeile (die erste Kopie) die Platzhalter nicht aktualisiert. Die IDs der einzelnen Zellen sind korrekt, aber die Werte nicht. Wenn in den Zellen die Platzhalter dann manuell aktualisiert ist alles ok.

Nachtrag

Auch das manuelle Aktualisieren klappt nur dann, wenn es in einer bestimmten Reihenfolge gemacht wird.

Problem

Das Problem bestand darin, dass in zwei hintereinanderfolgenden Zellen die gleiche Zell-ID gesetzt wird. Comet hat die beiden in den Zellen enthaltenen Platzhalter nicht als unterschiedliche Platzhalter erkannt.

Das Problem ist gelöst.

Das Tag <StringID> wird jetzt nicht mehr gequoted. Das ist die einzige Ausnahme bei den Tags mit Stringwerten. Neuere Projekte sollten das Tag <STRINGID> verwenden.

Die Kurzbegründung lautet : Verflucht!

Die lange Begründung ist : InDesigns® TaggedText-Import ist immer absatzgeführt. Bei unserem %!TT-Import soll aber um den Einfügetext nicht jedesmal ein neuer Absatz entstehen. Mit einiger (!) Mühe kann das ja auch verhindert werden. Aber was soll mit den Absatzstilen passieren? Soll der erste Absatzstil im TT-Text den aktuellen Absatzstil ersetzen? Manchmal vielleicht - aber gewiss nicht immer. Oder soll das der letzte Absatzstil des TT-Textes machen? Oder lieber doch nicht?

Aus diesem Grund gibt es jetzt verschiedene TT-Derivate :

• %!DD
• %!DN
• %!ND
• %!NN

D steht dabei für "Dokumentstil verwenden", N steht für "Neuen Stil anwenden". Die Position gibt an, ob der Absatzteil vor oder nach dem eingefügten Text gemeint ist.

Wird der alte Absatzstil beibehalten, wird über die neuen Textteile, die in den alten Absatz fallen, der neue Absatzstil als Zeichenstil gezogen. Dieser Text sieht dann also so aus, als hätte er den neuen Stil - er hat aber noch den im Dokument gültigen Absatzstil.

Eine Besonderheit ist !%ND mit einem Import ohne Absatz (es gibt also höchstens am Anfang ein <ParaStyle:>). Die Angaben widersprechen sich in diesem Fall und die erste Angabe bekommt den Vorrang : Der Absatz bekommt also den neuen Absatzstil. Im Anhang zu Bug 786 gibt es eine Testumgebung mit Testdatei für die TT-Derivate.

%!TT bleibt unverändert bestehen.

Aktueller Fall

Im aktuellen Fall war das Problem aber ein anderes. Da wird immer an der Textstelle 0 eingefügt und %!DN und so werden gar nicht benötigt.

Hier waren im Stilnamen \s enthalten (etwa Copy\_text\_headline). InDesign®-TaggedText braucht die wohl, aber wenn man intern mit der API einen Absatz- oder Zeichenstil sucht, gibt es Fehler. In der nächsten Version geht der TT-Import mit diesen Namen.

Ist in der Datei oem.xml nichts anderes angegeben, ist das jetzt so.

Lange Namen in der Palette werden jetzt nicht mehr hinten sondern in der Mitte abgekürzt. Die Namen unterscheiden sich meist erst am Ende und nicht in der Mitte. Abgekürzte Namen erzeugen außerdem einen Yellow-Text, wenn man mit der Maus drüber fährt. Der Yellow-Text enthält den vollständigen Text (allerdings unter Mac nur bis zu 255 Zeichen).

Wenn man sich mit einem anderen Projekt verbindet und dann wieder mit diesem, geht es wieder.

Leider ist der Effekt nicht wirklich reproduzierbar; manchmal tritt er halt auf. Dass aber sogar ein Neustart nichts bringt, lässt vermuten, dass HasStringIDs irgendwo in Bezug aufs Projekt zwischengespeichert wird?

Jedenfalls haben die Panelstatements alle StringIDs.

Lösung?

Ich kann den Fehler zwar auch nicht wiederholen. Aber ich hatte das Phänomen auch schon mal. Und ich kann nichts finden, was den Fehler verursacht. Da der Fehler aber nur bei der Standardsuche auftritt, habe ich dort jetzt noch mal eine Extra-Nachfrage eingebaut, ob es eine StringID gibt - was das Problem hoffentlich behebt.

<pageitem>
    <id>0</id>
    <name></name>
    <description>0</description>
    <data>
      <src></src>
    </data>
    <preview>
      <src></src>
    </preview>
    <type>
      <id>0</id>
      <name></name>
    </type>
    <state>
      <id>0</id>
      <value>ohne Statusangabe</value>
    </state>
    <domain>
      <id>0</id>
      <name></name>
    </domain>
    <placeholder>
      <id>0</id>
      <name></name>
    </placeholder>
    <leftpos>0.0</leftpos>
    <toppos>0.0</toppos>
    <rightpos>0.0</rightpos>
    <bottompos>0.0</bottompos>
    <spread>
      <position></position>
      <leftitem>0</leftitem>
      <middleitem>0</middleitem>
      <rightitem>0</rightitem>
      <scriptid>0</scriptid>
    </spread>
    <record>
      <id>0</id>
      <id2>0</id2>
      <id3>0</id3>
      <stringid>0</stringid>
    </record>
  </pageitem>

Alle Tags mit Stringwerten können jetzt mit den folgenden Präfixen versehen werden :

Bitte beachten Sie, dass die Angaben Unquoted_ und Content_ immer vor dem letzten Wort des Tags angegeben werden!

Oops, interne falsche Zuordnung zwischen Funktionsname und Funktion. Diese Fehler sind behoben.

Ooops, ich dachte, das funktioniert. Offensichtlich ist das nicht immer so. Typecasts von int in float und umgekehrt sollten ab sofort immer mit den neuen Funktionen

    toint
    tofloat

gemacht werden.

Die neuen Funktionen page::get_masterpage und page::set_masterpage machen das Gewünschte.

Kommentar

Ich habe das genauer untersucht. Das Problem ist, dass die Gruppenzuweisung aus der Table-Insert-Action nicht korrekt auf die Zellen übertragen wird. Nur das letzte Auftreten einer Gruppe wird wirklich auf die Zellen übernommen. Nach dem Aufbau ist die letzte Zeile der Tabelle die einzige, die zur Gruppe product gehört, und nur die letzte Zwischenüberschrift gehört zur Gruppe groupby. Die Design-Methode wird dann konsequenterweise nur auf diese Zellen angewendet. Ich habe in einem Extra-Skript die Table-Insert-Action getestet, sie scheint mir tadellos zu sein.

Lösung

Das Problem mit dem MoreGroups ist, dass nicht unterschieden werden kann, ob eine Gruppe über die Palette oder als MoreGroup gesetzt wurde. Ich kann also vor dem Aufbau nicht mal hergehen und alle Gruppen aus den Zellen entfernen. Andrerseits werden Gruppen beim Kopieren von Zeilen und Spalten weitergegeben - also auch MoreGroups, die während des Aufbaus gesetzt wurden. Das Ganze erst nach dem Einfügen aller Zeilen/Spalten einer Zelle zu machen, funktioniert auch nicht, weil ja in dieser Zelle vom letzten Aufbau noch MoreGroups stehen können ... siehe Anfang.

In der Tabelle werden die MoreGroups jetzt getrennt aufbewahrt. So kann die Tabelle vor dem Aufbau gefixt werden. Die MoreGroups stimmen jetzt - auch nach wiederholtem Aufbau.

Tipp

Einen schnellen Überblick über Gruppenzugehörigkeiten kann man mit einem Klick in das kleine Farbquadrat neben dem Gruppennamen bekommen. Alle Zellen, die zu dieser Gruppe gehören, werden dann in dieser Farbe hinterlegt.

Achtung, diese Farbe wird mitgedruckt. Die Markierung ist nur ein Ersatz für die fehlende Möglichkeit, übe die InDesign®-API eigene CellAdornments zu implementieren. Also : Am besten nach dem Überprüfen der Gruppen gleich noch mal auf das Farbquadrat klicken.

Da war die Doku nicht vollständig - über Treeviews stand da kein Wort. Der Treeview selbst klappt, wenn er richtig konfiguriert ist. Die Doku für die Publikationen ist jetzt aktuell und man sollt ein der Lage sein, einen Treeview selbst zu konfigurieren.

In der Palette gibt es jetzt die gleichen Icons mit den gleiche IDs wie in der Produktrecherche, siehe Doku für die Publikationen.

Das war ein kleiner Indexfehler der jetzt behoben ist. An dieser Stelle will ich nochmals auf den Importdialog des Textfluss-Aufbaus hinweisen : -Shift öffnet einen Importdialog.

    Vorher    : [Titel]
    Nachher  : T[itel]

Oder auch :

    Vorher : [Bestell-Nummer]
    Nachher : [Bestell]-[Nummer]

Beides führt natürlich beim Neuladen zu falschen Texten.

Problem

Werden in einem Textplatzhalter Textattribute (Font, Farbe, Großes, ...) geändert, werden die Platzhalter intern in verschiedende sogenannte Runs getrennt. Die Comet-Plugins stellen sicher, dass alle zusammengehörigen Runs richtig erkannt werden. Offensichtlich werden einige dieser redundanten Runs von InDesign® aber nicht richtig kopiert.

Lösung

Drei Dinge gibt zur Lösung des Problemes :

1. Die Skriptbefehle textmodel::gremove_redundant_tags, textmodel::remove_redundant_tags, frame::remove_redundant_tags und document::remove_redundant_tags. Mit diesen Anweisungen können an ausgewählten Dokumentteilen (oder im gesamten Dokument) die redundanten Platzhalter entfernt werden.
2. Über das neue Menü Zusatzmodule::PLatzhalter:Platzhalter vor dem Sichern aufräumen kann eingestellt werden, dass vor jedem Sichern eines Dokumentes die redundanten Platzhalter im gesamten Dokument automatisch entfernt werden. Das Menü ist als Toggle-Menü implementiert - man kann das Verhalten also an- und ausschalten.
3. Das Menü Zusatzmodule::PLatzhalter:Platzhalter jetzt aufräumen räumt die aktuelle Datei auf.

Als Minimalforderung wird jetzt die Existenz der Datei panelstatements.xml geprüft. Wer die in einen Ordner legt und diesen dann auswählt, handeltgewissermassen vorsätzlich - und bekommt weiterhin die Höchstwarnstufe.

Der Fehler lag daran, dass beim Verlinken nur direkte Tabellen von Texten bearbeitet werden. Untertabellen werden dabei übergangen. Da damit alles andere im Comet funktioniert, habe ich nicht diese Stelle sondern das Setzen der Zell-IDs geändert : Dort werden jetzt auch Untertabellen richtig verlinkt.

Ausserdem werden diese Tabellen jetzt automatisch auch neu aufgebaut. Um in Skripten unterscheiden zu können, ob eine Tabelle automatscih von einer äusseren Tabelle aufgebaut wird oder nicht, gibt es die neuen Skriptbefehle

    table::get_parent (T);
    table::has_parent (T);

Das Ladenskript 12345785 des Platzhalters 117 bei Beckhoff habe ich entsprechend geändert : In der while-Schleife, die alle Tabellen neu aufbaut, steht jetzt noch der Test :

   if (!table::has_parent (tab))
   {
       ...
   } 

Geht jetzt. Beschreibung siehe gProducts.html, idtype.html und idtypelist.html der Online-Doku.

Mit dieser neuen Variante lassen sich jetzt auch Tabellen mit der aktuellen Produktauswahl aufbauen (productlist::get).

Ich vertausche jetzt Icon- und ClassID, wenn sie offensichlich falsch sind :

   if (classID > 1999 && imageID < 2000)

Damit sollte das Problem behoben sein.

Anmerkung für Paul : Suche nach "QWE" im SourceCode!

Wird kein Block angelegt, erhalten die Zellen dieses Blockes jetzt beide Gruppen, first und last. Jede Zelle des Blockes (also nicht nur die inneren) wird ausserdem der Basisgruppe zugewiesen.

• Innere Zellen werden jetzt also eindeutig daran erkannt, dass sie weder in first noch in last last sind.
• Zellen, die sowohl in first als auch last liegen, weisen darauf hin, dass keine weiteren Tabellenzellen angelegt wurden.

Bei einer Blockgrösse > 1 gilt die Gruppenzugehörigkeit jeweils für alle Zellen des Blockes. Mit einer Blockgrösse von 3 ergibt sich also

1 Produkt gefunden

2 Produkte gefunden

3 Produkte gefunden

Die entsprechenden Tags können jetzt auch in den Aktionen des Tabellenmodules verwendet werden. Siehe dazu auch hier.

Hier ein Beispiel :

select
    x.sonid, 0, 0,
    CONCAT('Seite ',<pagestr>,', Ebene ',<layer>),
    ''
from pdb_productlink x
where x.fatherid = <RootTableRecordID>
    and x.kind = 'Variante'
    and x.active = 1
order by x.sort

Beachtet aber unbedingt : Die Informationen über Ebene, Seite, Zelleninhalte (<text>, ...) beziehen sich natürlich immer auf die auslösende Zelle, NICHT AUF DIE NEU ANGELEGTEN Zellen.

Beide Fehler sind behoben : Der SyncStatus wird nicht mehr gezeigt, wenn das nicht gewollt ist und in den Platzhalterwerten wird der richtige Wert von SynStateInvisible gezeigt.

Dazu gibt es jetzt die Funktion hyperlink::create_urldest. Damits einheitlich ist, gibt es jetzt auch die Funktion hyperlink::create_pagedest, die wie hyperlink::create aber mit geringfügig geänderter Parameterreihenfolge ist.

Das stimmt so nicht. Der Textaufbau fügt aber den Text immer an der aktuellen Einfügeposition an. Das kann auch mitten im Absatz sein. Der erste Absatzstil des eingesetzten Textes wird dabei durch den im Dokument geltenden Absatzstil ersetzt.

Um das Problem zu lösen, kann jetzt vor und nach jedem eingefügten Produkt ein beliebiger Text ins Dokument eingefügt werden :

• Der Skriptbefehl textmodel::insert_products hat zwei weitere Parameter (prefix, postfix). Mit der Angabe <para> wird ein neuer Absatz eingefügt.
• Der Aufbau über das Button der Produktrecherche öffnet mit Shift-Click einen Importdialog. Dort können Prefix und Postfix (und anderes) ebenfalls eingestellt werden.

Auffällig daran ist, dass die Auswahl dann richtig gesetzt wird, wenn der Textcursor am Anfang des Textplatzhalters steht. Und das ist auch die Lösung des Problems. Platzhalter können intern aus verschiedenen Teilstücken bestehen. Ändert sich der Textstil, wird der Platzhalter intern unternbrochen. Zum Vergleich mit der ToDo-Liste wird aber immer das erste Teilstück benötigt.

Der Fehler ist jetzt behoben.

Der Fehler kommt daher, dass mind. ein Rahmen eine Aufbauregel enthält, die im aktuellen Datenpool nicht verfügbar oder leer ist. Aber das war -zugegebenermassen - nicht so einfach zu erkennen, eigentlich gar nicht. Denn leider hat das Plugin Aufbauregeln in dieser Situation einen falschen Wert (nämlich Leer) angezeigt. Das ist jetzt geändert. In den Aufbauregeln werden jetzt Unbekannt und die ID der Regel angezeigt. Ausserdem ist die Fehlermeldung beim Seitenaufräumen ein bisschen informativer.

Die Menüs sind auch in der Reader-Version enthalten

Dies muss in der CS3 Version behoben werden. Am besten mit einem Menüpunkt comet Aktivieren / Deaktivieren.

Lösung

Die Meldung über fehlende Plugins hat zwei verschiedene Auslöser :

1. Im Dokument sind Text- und/oder Rahmenplatzhalter enthalten.
2. Ein Plugin hat eine dokumentbezogene Voreinstellung geändert (z.B. die Darstellung der Platzhalter oder einen Produktaufbau [der merkt sich nämlich das verwendete Raster])

Alle damit zusammenhängenden Daten werden jetzt als "ignorierbar" ins Dokument eingetragen. Dadurch wird die Warnung unterdrückt. Da die entsprechenden Daten ohne ihre zugehörigen Plugins natürlich auch nicht mehr geschrieben werden können, können Änderungen im Dokument auftreten :

• Dokumentbezogene Voreinstellungen bleiben erhalten
• Rahmenplatzhalter bleiben erhalten. Beim Duplizieren von Rahmen gehen die Platzhalter verloren. Änderungen an Rahmeneinstellungen oder enthaltenen Bildern erhalten den Rahmenplatzhalter.
• Textplatzhalter bleiben zwar erhalten, neu eingefügter Text bekommt aber keinen Platzhalter (auch dann nicht, wenn in einen Platzhalter geschrieben wird.) Platzhalter werden nicht kopiert.
• Einstellungen des Tabellenmoduls gehen verloren, wenn die Tabelle geändert wird (auch wenn lediglich Text in der Tabelle geändert wird).

Grundsätzlich gilt :

1. Werden Dokumente ohne Comet-Plugins geöffnet, erscheint keine Fehlermeldung mehr.
2. Werden die Dokumente ohne Änderungen geschlossen, gehen (natürlich) auch keine Daten verloren.
3. Änderungen von Dokumenten können Comet-Daten (Platzhalter) entfernen.
4. Sind die sog. Comet-Reader Plugins installiert, bleiben Comet-Daten erhalten. In einem Workflow, in dem Dateien von einem Comet-lizenzfreien InDesign® zwischenbearbeitet werden, sollte grundsätzlich geprüft werden, ob die dort vorgesehenen Änderungen platzhaltersicher sind!

Im Reader sollten die folgenden Plugins enthalten sein :

• Comet
• CoreServlett
• CoreSelection
• EmbeddedLink
• FrameLink
• PlainCopy

Nach der Willkommensmeldung im Logfile kommt jetzt eine Meldung, die den erwarteten Pfad der Lizenzdatei zeigt :

    # Searching license file at '/Applications/Adobe InDesign® CS2/Plug-Ins/Werk [2]/w2.lic'

Danach wird das Ergebnis des Lesens dieser Datei notiert :

# License file not found.
Die Datei wurde am angegebenen Pfad nicht gefunden. Bitte Pfad und
Zugriffsrechte prüfen.

# w2.lic must not be a directory. Cannot open file.
Ein Objekt w2.lic wurde zwar gefunden aber als Ordner identifiziert.

# Cannot open license file for reading.
Die Lizenzdatei wurde zwar gefunden, kann aber nicht zum Lesen geöffnet werden. Bitte Zugriffsrechte prüfen.

# Error __ERRNUM__ while reading license file.
Die Datei konnte zwar geöffnet werden. Aber das Lesen der Datei schlug fehl. (Zur weiteren Bearbeitung als Bugfix bitte die Fehlernummer __ERRNUM__ angeben.

# License file successfully read.
Die Lizenzdatei konnte erfolgreich gelesen werden. Treten jetzt noch Probleme mit der Lizenznummer auf, kann das folgende Ursachen haben (Darüber werden aus naheliegenden Gründen keine Meldungen ins Logfile geschrieben.) :

1. Die Lizenzdatei ist überhaupt falsch
2. Für das Plugin ist kein Lizenzschlüssel verfügbar (Die Namen vor den Schlüsseln dürfen nicht verändert werden!)
3. Die Lizenzangabe kann nicht entschlüsselt werden.
4. Der Schlüssel enthält falsche Nummern (InDesign®-ID und MAC-ID müssen stimmen. Die Lizenzdatei funktioniert nur auf dem Rechner, der die Bestelldatei erzeugt hat oder dessen Angaben enthält.)
5. Und schliesslich kann auch die Versionsnummer der Lizenz abgelaufen sein. Eine Lizenznummer gilt immer für drei Versionen (z.B. 1.1 - 1.4, 1.9-2.1)

Soll das Tabellenmodul nicht benutzt werden, kann es abgeschaltet werden mit dem folgenden Eintrag in der Lizenzdatei :

   Tabellenaufb "UNUSED"

mit einem Tab als Trenner.

Beispiele:
kExportUnitext \\00ae // zwingend kleingeschrieben
kExportXMLUnitext &#x00AE; // Groß- / Kleinschreibung wurst
(dezimal): &#0174;

Die Dezimale Schreibweise finde ich überflüssig - aber wenn es noch einfacher zu implementieren ist...

Es gibt jetzt folgende Möglichkeiten

kExportUnitext (<unitext>) \\00ae
kExportXUnitext (<xunitext>) <0x00AE>
kExportXMLUnitext (<xmlunitext>) &#x00AE;

Die Angaben in den Klammern können in Aktionen von Textplatzhaltern verwendet werden, um den aktuellen Platzhaltertext im entsprechenden Fomrat zu erhalten.

Der Fehler ist behoben.

Achtung

Die Bounding Box unsichtbarer Rahmen darf bloss zur Bestimmung der Rahmengrösse verwendet werden. Die Positionen selbst können natürlich nicht richtig bestimmt werden. Im Logfile steht für unsichtbare Rahmen die Meldung

# frame::bbox called for an invisible frame. Use bbox values only to get the frame size.

1.) Installation

Zur Neuinstallation oder Aktualisierung einer bestehenden MyOdbc Installation gibt es liegt jetzt ein ZIP-Paket auf dem FTP Server. Dieses enthält alle benötigten Bibliotheken sowie drei doppelklickbare Shell-Skripte:

• Install.command installiert die Treiber, prüft und korrigiert auf Wunsch alle vorhandenen DSN-Einträge, die MyOdbc verwenden und legt auf Wunsch einen neuen DSN an
• Add.command legt einen neuen MyOdbc DSN an.
• Sanity.command prüft und korrigiert auf Wunsch alle vorhandenen MyOdbc DSN Einträge

Die Treiber sind mit 10.3 und 10.4 PowerPC und 10.4 Intel getestet, somit also für derzeit weitgehend "alle" Macs einsetzbar. Beschwerden wegen schlechter Perfomance gab es bislang keine. Die vollständigen Treiber in Skripte sind hier zu finden.

2.) Erweitern der Panelstatements

Damit Umlaute richtig angezeigt werden wird für die MyOdbc DSN Einträge ein Initialisierungs-Statement angegeben, das für Konvertierung aller Daten nach bzw. von Macroman sorgt. Leider (ich halte das ja für einen Bug...) werden beim Einfügen / Aktualisieren auch Blob-Spalten konvertiert, was Previews und Vorlagen ziemlich unbrauchbar macht. Die Lösung hierfür ist, in den entsprechenden Statements explizit anzugeben, das Blob-Spalten den Zeichensatz "Latin1" verwenden. Das geht mittels eines "introducers", am Beispiel von Statement 29 (Eintragen der binären Daten von Vorlagen):

    update PageItems set
       data = _latin1?, preview = _latin1?,
       leftPos = ?, topPos = ?, rightPos = ?, bottomPos = ? 
    where id = ...

Neu sind die beiden "_latin1" vor den Platzhaltern für data und preview. Bemerkenswert daran ist, dass in der MySql-Dokumentation ausdrücklich vermerkt ist, dass der "introducer" keine Konvertierung bewirkt, offenbar aber (und das steht nicht da) eine unerwünschte Konvertierung verhindern kann

Entsprechend geändert werden müssen die Statements

• 29
• 64
• 80
• 103

3.) Neue PlugIns (R38x) installieren + Eintrag in Keywords

In der neuesten PlugIn-Version sind alle im PlugIn fest kodierten Statements erweitert; wenn in der Datenbank das Keyword LATIN1 definiert ist, wird dessen Wert allen Blob-Spalten vorangestellt. Für mySQL muss der Wert von LATIN1 auf _latin1 gesetzt werden.

Behoben

Für die verschiedenen Objekte, auf die ein ItemRef zeigen kann, gibt es jetzt jeweils eine is_valid Methode. Die Methoden prüfen, of die Referenz definert ist und auf ein existierendes Objekt vom entsprechenden Typ zeigt :

• bookmark::is_valid
• frame::is_valid
• table::is_valid
• document::is_valid
• hyperlink::is_valid

Das war eine ziemlich hinterhältige Sache : Nachdem der Platzhalter durch die Tabelle ersetzt wurde, muss die Tabellenliste durchsucht werden, ob eine der Tabellen an der Textposition des alten Textes steht. Aber diese Positionen stimmen erst nach einer Neuberechnung des Textes - zur nächsten Idle-Time oder nach einem expliziten (und komplizierten und langsamen) Repaint.

Da aber InDesign® neue Tabellen immer an die Tabellenliste anfügt, reicht es aus, die hinzugefügten Tabellen zu bearbeiten und alles wird gut. (D.h., ein Tabellenplatzhalter kann wie bisher beliebig viele -auch gar keine- Tabelle enthalten. Alle werden mit der ID des ersetzten Platzhalters verbunden.)

Achtung

Das Verfahren klappt bei CS und CS2. Ich weiss noch nicht, ob auch unter CS3 Tabellen in dieser Reihenfolge verwaltet werden.

Das geht jetzt.

Aber Achtung

Wenn jetzt in der Load-ID eine andere Action-ID eingetragen ist und im Dokument
ist ein Platzhalter ausgewählt, dann wird dieser Platzhalter geändert. Deshalb sollte zum Editieren von Aktionen immer das Skript-Feld im unteren Fensterbereich verwendet werden.

Geänderte Platzhalter können mit dem Reset-Button wieder aus dem Datenbestand geholt werden. Aber auch hier ein Achtung : Dazu muss natürlich die richtige Datenverbindung aktiv sein.

Der Fehler liegt wahrscheinlich, daran, dass die Farben im Range (0.0 - 255.0) definiert sind. Richtig sind aber Prozentangaben (0.0 - 100.0). Die Angabe 255.0 erzeugt dann einen Farbwert von 650 - was ja nicht geht.

Der Comet stellt jetzt alle Angaben, die grösser als 100.0 sind, automatisch auf 100.0. Die Klammern kommen dann. Aber die Farben an sich sind natürlich möglicherweise falsch.

Bei Schwarz werden die Klammern automatisch aufgehellt.

Nachbemerkung

Im Gegensatz zu anderen xml-Dateien, bei denen der Comet Änderungen registiert und entsprechend neu lädt, wird das für die Platzhalterfarben nicht gemacht - dann wird das Zeichnen des Dokumentes zu langsam.

Getestet mit CS 2 1.4.1 R380 und dem XMLTestprojekt vom 20-jun-07.

Das stimmt aber nicht. Folgendes passiert (beim Aufbau der ersten fünf Produkte [Der schwarze Incal, In tiefsten Tiefen, ...] und dem Raster Raster):

Rasterfixiert

Das dritte Objekt wird auf eine neue Seite gebaut. Eine neue Seite wird also angelegt. Aber Das ist gar nicht okay! Die neue Seite wird deshalb angelegt, weil die wiederholenden Elemente über den Seitenrand hinausragen. Eine Rasterzeile weiter unten wäre aber Platz gewesen. Dieser Platz wird jetzt ausgenutzt. Es werden also weniger Seiten als vorher angelegt.

Zu beachten ist noch : Die wiederholenden Elemente feuern erst dann einen Fehler, wenn ein Rahmen mehr als 40 Points über den Seitenrand hinausragt. Und zweitens : Werden keine wiederholenden Elemente verwendet, wird beliebig über den Seitenrand eingefügt - so wie eben das Raster ist.

Produktorientiert

Hier war eine der Kombinationen von "erlaube und ignoriere unvollständige Platzierungen" falsch. Das ist jetzt aber auch richtig. Der Unterschied ist :

• erlauben : Unvollständige Platzierungen DÜRFEN vorkommen. Wenn welche gefunden werden, wird der Aufbau gar nicht erst begonnen.
• ignorieren : Wenn unvollst. Platzierungen erlaubt sind und beim Aufbau eine gefunden wird, wird dieses Produkt nicht mit aufgebaut.

• für ObjectPath und TemplatePath der Wert /dev/null angegeben wird. In diesem Fall muß das Batch-Skript selbst dafür sorgen, daß - wenn erforderlich - ein Dokument geöffnet wird. Dieses Dokument darf in R38X vom Skript nicht wieder geschlossen werden!
  oder
• nur für ObjectPath /dev/null angegeben wird. In diesem Fall wird TemplatePath geöffnet, auf einer temporären Kopie gearbeitet und diese nach Skriptende wieder gelöscht.

Die Skriptfuntionen system::app_path und system::plugin_path sind entsprechend geändert.

Ich nehme an, du holst die StringID mit stringlist::gettext. Das funktioniert bei Listen ohne ClassID (stringlist::alloc () OHNE Clasds-ID) nicht. Hier muss stringlist::get verwendet werden. Dann funktioniert alles.

Da die Unterscheidung zwischen StringListen mit und ohne Class-ID aus der Doku bisher nicht so richtig hervorging, hab ich erstens die Doku erweitert und zweitens einen bypass für stringlist::gettext gelegt :

In Listen ohne Class-ID wird der entsprechende String aus der Liste geholt. Der Parameter "attribute" hat hier keine Bedeutung.

Nur ums noch mal zu sagen : Der große Unterschied ist, dass Listen ohne Class-ID tatsächlich Listen mit Inhalten sind. Listen mit ClassID dagegen greifen bei jeder Nachfrage auf die jeweilige Palette (oder wie die jetzt heissen sollen) zurück, haben aber eigentlich nicht wirklich eigene Objekte.

Das Problem triit erst seit Release R 368 auf und ist eine Folge des Bugfixes 685.

Das Problem war, dass in der API verlinkte Rahmen und Textspalten ununterscheidbar in der selben Liste gehalten werden. Bei mehrspaltigen Texten führte das dazu, dass Rahmen von mehrspaltigen Texten mit sich selbst verlinkt wurden - ist nachvollziehbar, dass das eine Weile dauern kann.

Nachdem das funktioniert hat, kam noch ein weiteres Problem : Die Verlinkung 1->2->3->4 muss auch in dieser Reihenfolge ausgeführt werden. 1->2, 3->4 und dann erst 2->3 führt dazu, dass die Verbindung 3->4 wieder gekappt wird. Das ist vielleicht der merkwürdige Humor der Adobe-Entwickler.

Ein letztes Problem noch : Im Text zwischen zwei Rahmen fehlte immer ein Zeichen. Das passiert jetzt nicht mehr (Lag daran, dass beim Kopieren von Tagged Text am Ende ein zusätzliches Return steht, was wieder weg muss - aber in diesem Fall hat man ja keinen Tagged Text. Siehe Humor.)

textmodel::insert (txt, kSelection);

Das schlägt leider fehl, wenn sich der Cursor im Übersatz eines Rahmens befindet.

Für die Verwendung von kSelection gilt:

• kSelection darf nur im ersten Aufruf einer Textfunktion (textmodel::insert, textmodel::replace, ...) verwendet werden.
• In Platzhalterhalterskripte darf die Konstante nicht verwendet werden.

Der folgende Beispielcode ersetzt die Konstante kSelection.

int  	selStart;

textmodel::selection (&selStart);
textmodel::insert ("Mein Text", selStart);

Sollen mehrere Textstücke hintereinander eingefügt werden, muss der Einfügepunkt im Skript jeweils neu berechnet werden:

int  	selStart;
int		oldLen 	= textmodel::fulllength ();

textmodel::selection (&selStart);
textmodel::insert ("Mein Text", selStart);

selStart 	= selStart + textmodel::fulllength () - oldLen;
oldLen 		= textmodel::fulllength ();

textmodel::insert ("Mein 2. Text", selStart);

1. Laden von Produktlisten aus CSV, XML oder Datenbank- / Soapverbindungen
2. automatischen Aufbau von Produkten aus anderen Quellen als der Produktrecherche-Palette
3. Parsen eines XML Strings
4. Herstellen / Ändern und Beenden der globalen Datenbankverbindung

• int eval (String scriptCode, String arguments = "")

  Evaluierung des Script-Codes in cscript. Argumente werden dem Skript als globale Variable gArgument übergeben.

• int exec (int actionID, String arguments = "")

  Wie eval, es wird die mit actionID bezeichnete Action ausgeführt

• String license ()

  Gibt einen String zurück, der für die Anforderung einer Lizenzdatei verwendet werden kann

• String about ()

  About iQuest.Comet (Version, Release etc.)

Der Aufruf von

qu = soap::call ("method");

entspricht

qu = sql::new_query ();
query::send (qu, "call method");

CDATA ist nicht das Problem, der RTF-Text im CDATA ist das Problem. Und da sagen wir doch mal wieder "Danke Microsoft!": Das Problem sind Sequenzen wie \r, \b, \f, \a usw.., die in RTF vorkommen. Wer diese Sequenzen anders als für Return, Backspace, Seitenvorschub, Piep, ... benutzt, der muss eigentlich mit Windows Vista nicht unter 3 Jahren bestraft werden. Und so ist es dann ja auch.

Für xmlquery ist das Problem gelöst. Aber ich bin sicher, dass wir damit noch viel Freude haben werden.

Damits rückwärts-kompatibel bleibt, bleibt StringID unverändert, es gibt aber das neue Tag STRINGID, und das wird dann gequoted.