"BilderKatalog", ein JavaScript für CS2

Hans_Haesler

Hallo Thomas,

vielen Dank für Deine Hilfe. Ob es im JavaScript für InDesign
ein "do shell script" gibt weiss ich nicht.

Ich werde zuerst eine Liste der gängigsten Zeichen erstellen
und prüfen, welche davon nicht korrekt in einen Textrahmen
gebracht werden können.

Aber meine Hoffnung ist, dass mit 'decode()' oder sowas, alle –
auch die unmöglichen – abgedeckt werden können. Damit man
auf das Suchen/Ersetzen verzichten kann.

Gruss, Hans

Thomas_Kaiser

Hallo Hans,

Antwort auf: Aber meine Hoffnung ist, dass mit 'decode()' oder sowas, alle –
auch die unmöglichen – abgedeckt werden können. Damit man
auf das Suchen/Ersetzen verzichten kann.

Da wir aber eh nur von einem recht begrenzten Zeichenvorrat sprechen, der in InDesign-Textrahmen abgebildet werden kann (US ASCII, das kein Problem darstellt, und die weiteren 127 Zeichen, die eben in MacRoman abgebildet werden können -- mehr ist es ja nicht, oder?) könnte die vorhin von mir erstellte Liste durchaus schon alle möglichen Fälle abdecken. Alle anderen Unicode-Zeichen gehören dann eben durch einen Underscore oder sowas ersetzt, weil sowieso nicht per MacRoman darstellbar...

Aber ich checke nicht, wie hexadezimal kodierte Zeichen in der Replace-Funktion kodiert gehören. Ein "\x" scheint es nicht zu sein. Wie lautet denn da die Quoting-Konvention für hexadezimal oder oktal kodierte Zeichen in Adobes Javascript-Implementierung?

Gruss,

Thomas

Hans_Haesler

Hallo Thomas,

auch da bin ich überfragt. Ich weiss nur, dass für Unicode-Werte
entweder '\u1234' oder '<1234>' verwendet werden kann.

Doch möchte ich wirklich vermeiden, dass gesucht und ersetzt
werden muss. Und schon gar nicht 127 Mal pro String.
Denn der OP lässt das Script für 2000 Bilder pro Sitzung laufen ...

Gruss, Hans

Klaus79

Hallo Hans,

habe heute morgen dein neues Script getestet und es
funktioniert fehlerfrei mit allen Umlauten. Echt super!
Noch einmal ein herzliches Dankeschön ...

Gruß
Klaus

Hans_Haesler

Hallo Klaus,

bitteschön.

Danke für die Rückmeldung. In der Version 03 werden nur
die Zeichen "ä ö ü Ä Ö Ü" speziell behandelt.

Aber im Gegensatz zur Version 02 werden immerhin
Problemzeichen wie der Leerraum oder das "ß" nun ohne
zusätzlichen Eingriff richtig dargestellt.

Ich habe leider noch nicht Zeit gefunden, um zu prüfen,
welche weiteren Zeichen in den Suchen/Ersetzen-Befehl
aufgenommen werden sollten. Und auch nicht, ob es nicht
eine einfachere Lösung gibt.

Die Version 04 wird sicher nächstens kommen, aber
nicht sofort, denn manchmal muss ich die Priorität von
philantropischen Projekten etwas hinuntersetzen ...

Gruss, Hans

Thomas_Kaiser

Hallo Hans,

Antwort auf: auch da bin ich überfragt. Ich weiss nur, dass für Unicode-Werte
entweder '\u1234' oder '<1234>' verwendet werden kann.

Ich hab da jetzt auch keinen anderen Weg gefunden und das daher schnell durch die Unicode-Bezeichner ersetzen lassen. Wie gehabt unter

    http://kaiser-edv.de/tmp/UTF2MacRoman.txt

und parallel noch aufgeteilt in drei Brocken, d.h.

    http://kaiser-edv.de/tmp/UTF2MacRoman_Set_1.txt
    http://kaiser-edv.de/tmp/UTF2MacRoman_Set_2.txt
    http://kaiser-edv.de/tmp/UTF2MacRoman_Set_3.txt

Wie gehabt alles als MacRoman zu interpretieren...

Antwort auf: Doch möchte ich wirklich vermeiden, dass gesucht und ersetzt
werden muss. Und schon gar nicht 127 Mal pro String.
Denn der OP lässt das Script für 2000 Bilder pro Sitzung laufen ...

Oha, das ist heftig, zumal wenn die Suchen/Ersetzen-Funktion in JS nicht wirklich performant ablaufen sollte... Naja, vielleicht als Notnagel obiges plus zus. Checkboxen (Umlaute konvertieren [ ], Sämtliche Sonderzeichen konvertieren [ ])?

Scheint aber allgemein nur ein Problem der JavaScript-Implementierung in InDesign zu sein, oder? Mit AppleScript habe ich ja die Chance das Encoding zu wählen bzw. brav coercen zu lassen...

Gruss,

Thomas

Hans_Haesler

Hallo Thomas,

vielen Dank für die neuen Dateien. Ich habe sie alle
abgespeichert. Vielleicht werden sie mir mal bei einem
anderen Projekt aus der Patsche helfen.

Weil: Bei vorliegenden ist das Problem, dass gewisse
Zeichen zerlegt daherkommen. Aus einem "ä" wird "a\u0308",
aus einem "é" wird "e\u301", "à" wird zu "a\u0300".

Obwohl die Suchen/Ersetzen-Funktion in JS sehr performant
abläuft, werde ich versuchen, herauszubekommen, wie gross
die Bremswirkung ist.

Vielleicht bringt es etwas, wenn vorgängig jedes Mal
getestet wird, welche von den 0300, 0301 und 0308
vorkommen und – falls notwendig – die entsprechende
Funktion aufrufen (z.B. 0301/0308 oder nur 0300 usw.)

Vielleicht kostet dieses Prüfen auch genau diese Zeit,
deren Verschwendung ich vermeiden möchte.

Es ist ein Problem von JavaScript für InDesign unter
Mac OS X. Unter Windows werden die Zeichen nicht zerlegt.

Wie schon erwähnt, werde ich auch versuchen, mit dem
Zuweisen eines Encodings etwas zu erreichen.

Aber alle diese Untersuchungen sind sehr zeitaufwendig
und ich werde mich nicht vor Samstagabend damit
befassen können.

Gruss, Hans

Martin_Fischer

Hallo Hans,

> Vielleicht bringt es etwas, wenn vorgängig jedes Mal
> getestet wird, welche von den 0300, 0301 und 0308
> vorkommen und – falls notwendig – die entsprechende
> Funktion aufrufen (z.B. 0301/0308 oder nur 0300 usw.)

Das müßte mit match() zu machen sein, oder?

> Vielleicht kostet dieses Prüfen auch genau diese Zeit,
> deren Verschwendung ich vermeiden möchte.

Vielleicht sind Dir die Funktionen documentContents() und arrayCompress() von Peter Kahrel, die ich in dem Skript URL_withCharStyle.jsx verwendet habe, eine Hilfe.

Hans_Haesler

Hallo Martin,

>Das müßte mit match() zu machen sein, oder?

Stimmt. Aber kürzlich hatte ich damit Ergebnisse,
welche nicht zuverlässig waren. Das heisst, es wurden
nicht vorhandene Übereinstimmungen gemeldet.

Deshalb werde ich eher auf 'indexOf()' setzen.

>Vielleicht sind Dir die Funktionen documentContents()
>und arrayCompress() von Peter Kahrel, die ich in dem
>Skript URL_withCharStyle.jsx verwendet habe, eine Hilfe.

Ich hoffe es sehr ;-). Danke für den Hinweis.

Gruss, Hans

Thomas_Kaiser

Servus Hans,

Antwort auf: Bei vorliegenden ist das Problem, dass gewisse
Zeichen zerlegt daherkommen. Aus einem "ä" wird "a\u0308",
aus einem "é" wird "e\u301", "à" wird zu "a\u0300".

Klar, UTF-8 decomposed. Witzigerweise haben wir ja bei Unicode deren vier verschiedene Normalisierungsformen. Apple war wohl (fast schon leider) seiner Zeit ein wenig voraus, als sie HFS+ zu Zeiten von MacOS 8.1 vorstellten, das intern auf UTF-8 aufsetzte. Jedenfalls entschied sich Apple damals für UTF-8 decomposed (was auch die empfohlene Normalisierungsform war, wenn ich das alles richtig verstanden habe)... der Rest der Branche schwenkte dann aber im Großen und Ganzen zu UTF-8 precomposed um...

Antwort auf: Obwohl die Suchen/Ersetzen-Funktion in JS sehr performant
abläuft, werde ich versuchen, herauszubekommen, wie gross
die Bremswirkung ist.

Ich hab das mit den 128 Einträgen nicht mal zur Ausführung bringen können. Da hat der JS-Interpreter gleich den kompletten Suchen-/Ersetzen-Block angemeckert. Ansonsten wäre ja ein Vergleich schnell geschehen... aber nicht meine Baustelle, bin nur in Shell- und AppleScripting firm...

Antwort auf: Es ist ein Problem von JavaScript für InDesign unter
Mac OS X. Unter Windows werden die Zeichen nicht zerlegt.

Naja, das ist klar, da die UTF-8 precomposed Variante bei dem beschränkten Zeichenvorrat von ISO 8859-1 bzw. Codepage 1252 eh identisch ausfällt... D.h. man unter Windows wohl gar nicht in die Unicode-Problematik an sich rennt, weil die Zeichen identisch ausfallen...

Ich spielte eher darauf an, daß es in AppleScript spielend möglich ist, einen String als UTF-8 interpretieren zu lassen und dann auch sauber in "International Text" bzw. eben MacRoman konvertieren zu lassen...

Gruss,

Thomas

Hans_Haesler

Hallo Leute,

die Scripts, welche ich bei meinen Tests verwendet hatte, sind
im Premium-Member-Bereich gepostet:
http://www.hilfdirselbst.ch/gforum/gforum.cgi?post=292395#292395

Zuerst benutzte ich ein AppleScript, welches die Mac-Roman-Zeichen
von 128 bis 255 aufreiht, abgegrenzt mit einem normalen Buchstaben
und unterteilt in 16 handliche Absätze. So sieht der erste aus:
01sÄsÅsÇsÉsÑsÖsÜsás

Mit diesen Textketten benannte ich 16 Bilddateien und startete die
Version 03 des BilderKatalog-Scripts (mit deaktiviertem Suchen/Ersetzen).
Im Gegensatz zur Ergebnis mit der Version 02 (und dem Originalscript) wo
128 Zeichen hexadezimal codiert zurückkommen, sind 76 Zeichen in Ordnung.

Die restlichen 52 Buchstaben sind ausnahmslos diakritische, d.h. mit
einem Akzentzeichen versehen. Man kann sie grob in drei Gruppen
unterteilen: deutsch (D), französisch (F), andere (A).

D = ÄÖÜäöü
F = ÇÉàâçéèêëîïôùûÀÂÊËÈÎÏÔÛÙ
A = ÅÑáãåíìñóòõùÃÕÿŸÁÍÌÓÒÚ

Die Anzahl Suchen/Ersetzen-Läufe könnte man einschränken, indem in
der deutschen Version nur die sechs Buchstaben behandelt werden.
Aber was ist, wenn ein Bildname "Dalí.jpg" lautet?

Denkbar ist eine Unterteilung in Funktionen, entsprechend dem
Unicode-Wert der Zusatzzeichen:
\u0300 = àèìòùÀÈÌÒÙ
\u0301 = áéíóúÁÉÍÓÚ
\u0302 = âêîôûÂÊÎÔÛ
\u0303 = ãñõÃÑÕ
\u0308 = äëïöüÄËÏÖÜÿŸ
\u030A = åÅ
\u0327 = çÇ

Im JavaScript-Testscript setzte ich nach dem Worst-Case-Prinzip einen
Dateinamen mit je einem Buchstaben jeder Sorte, setzte die Aufrufe
in eine Schleife mit 1000 Durchgängen und stoppte die Zeit (siehe
das Script im Member-Bereich).

Es erwies sich als nützlich, Tests einzubauen, um zu prüfen, ob die
Sorte im String vorkommt, um nicht die entsprechende Funktion vergebens
aufzurufen.

Jetzt hab ich das Script BilderKatalog_04d.js mit diesen Funktionen
ergänzt und auf http://www.fachhefte.ch zum Download bereitgestellt.

Damit werden alle Zeichen richtig in die Textrahmen gesetzt.

Noch nicht untersucht habe ich, ob es eine Möglichkeit gibt, die
Namen direkt korrekt zu erhalten, damit das Suchen/Ersetzen vermieden
werden kann.

Gruss, Hans

Thomas_Kaiser

Hallo Hans,

Scusa wegen meiner Hartnäckigkeit aber mir ging das nicht mehr aus dem Kopf. Immerhin scheint die Aufgabenstellung darauf hinzudeuten, daß die JavaScript-Implementation innerhalb ID insofern beschränkt ist, als hier echte Unicode-Fähigkeit fehlen würde.

Denn "eigentlich" sollte man einem Unicode-fähigen Programm (Stichwort "mehrsprachiger Satz") auch per Scripting Text, der in UTF-8 vorliegt, einflössen können bzw. kann man es ja auch -- mit AppleScript ist das kein Problem.

Insofern zweifle ich an der Aufgabenstellung an sich, also an der Notwendigkeit, Unicode-Text erst wieder nach MacRoman zu wandeln bevor er in einen Textrahmen geladen werden kann. Falls das wirklich nicht gehen sollte, wäre es meines Erachtens ein klarer Bug bzw. eine ziemlich häßliche Limitation von Adobes JS-Implementation.

Durch das Nachdenken da drüber hab ich jetzt vielleicht die richtigen Suchbegriffe verwendet und bin hier gelandet:

http://www.indesignscriptingreference.com/javascript/TextImportPreference.aspx

Ist "TextImportCharacterSet" nicht das, was es dann analog auch für das einfache Setzen von Buchstaben in Textrahmen ohne Import einer (temporären) Textdatei bräuchte?

Ich frag eigentlich nur deshalb, weil ich als reiner Apple- und Unix-Scripter wegen potentieller Cross-Plattform-Fähigkeit über das Erlernen von JavaScript nachdenke -- ein nur mangelhafter Unicode-Support der Adobe-Implementierung mir diese Idee aber sofort wieder austreiben würde :-)

Gruss,

Thomas

Hans_Haesler

Hallo Thomas,

gut, dass Du so hartnäckig bist. Das schätze ich. :-)

Aber beim vorliegenden Problem, hilft das Bestimmen eines
TextImportCharacterSets nichs. Die Bildlegenden liegen nicht
als Datei vor. Man müsste für jede extra eine schreiben.

Diese Lösung habe ich auch schon in Betracht gezogen, aber
mangels Zeit noch nicht ausprobiert.

Abgesehen davon hüte ich mich, von Bug zu sprechen, weil
meine bescheidenen Kenntnisse nicht ausreichen, um das
Problem aus jedem Winkel zu betrachten.

Gruss, Hans

Thomas_Kaiser

Hallo Hans,

Antwort auf: Aber beim vorliegenden Problem, hilft das Bestimmen eines
TextImportCharacterSets nichs. Die Bildlegenden liegen nicht
als Datei vor. Man müsste für jede extra eine schreiben.

Völlig klar -- das wäre nichts weiter als ein häßlicher Workaround. Aber... wenn Adobe schon daran gedacht hat, beim Import einer Textdatei ein Quell-Encoding bestimmen zu können, dann muß das auch für das Setzen von Text per Skripting gehen -- außer in JavaScript würde von vornherein schon alles als UTF-8 interpretiert. Das scheint aber nicht der Fall zu sein, denn Deine Skripte sind immer MacRoman-kodiert.

Das als "default" empfinde ich angesichts des Zeitpunkts (2007) und der generellen Unicode-Fähigkeit von ID als einen argen Anachronismus. Und daß es "irgendwie" geht beweist ja AppleScript. Wenn ich dort mit Textrahmen von InDesign interagiere, gelingt das als UTF-8 (was meines Erachtens das einzig Richtige ist, denn wie sonst wollte man denn bspw. in einem Dokument lateinische Glyphen und kyrillische mischen?)

Ich bin jetzt kurz davor, bei Adobe eine Anfrage zu stellen, trau mich nur nicht so recht, weil ich eben von JavaScript an sich gar keinen Plan habe :-)

Jedenfalls hab ich auch per http://www.google.com/search?q=javascript+indesign+string+unicode+site:adobeforums.com nichts Erhellendes herausgefunden und fange langsam an zu zweifeln (ob an mir bzw. meinen Suchkünsten oder an ID weiß ich noch nicht so recht ;-)

Gruss,

Thomas

JoyZ

Ganz lieben Dank für den WIRKLICH guten Script.
Genau dies hab ich immer vermisst, direkt, ohne
Bridge. Super!

Auch die Anderen Scripts sind 1. Sahne. Nur z.B.
der "SpracheWechseln"-Script ist ebenfalls Gold
wert. Bis jetzt hatte ich keinen, der diese Aufgabe
eleganter und einfacher löste.

Also, keep up the good work und merci vielmals
Nik

manne

Ganz lieben Dank für den WIRKLICH guten Script.

Ich habe in den letzten Tagen die Weiterentwicklung des Bilderkatalog-Skripts mit Wonne beobachtet. Dieses Skript hat sich unter Hans Fittichen enorm weiterentwickelt.

Ein ganz dickes Lob und Dankeschön an Hans für dieses uneigennützige Engagement.

Was ist das nur, was Dich immer wieder zu Anonymus’ Vorteil so bei der Stange hält?

Hans_Haesler

Hallo Nik, hallo Manne,

bitteschön.

Danke für Eure Rückmeldungen! Geschieht sehr selten.

Leider musste ich mich – wie schon oft – herantasten und
konnte die jetzige Lösung nicht auf Anhieb hinzaubern.

>Was ist das nur, was Dich immer wieder zu Anonymus’ Vorteil
>so bei der Stange hält?

Das habe ich ... noch nicht herausgefunden ... :-)

Gruss, Hans

« Vorherige Seite