im Moment habe ich Probleme, die deutschen Sprachen, welche die app zur Verfügung stellt, über ihre Namen anzusprechen. Auch die englischsprachige Notation und die lokalisierungs-unabhängige Variante wollen nicht funktionieren. Bei anderen Sprachen ist es mir gelungen, sie über die englische Notation (nicht aber über die lokalisierungs-unabhängige '$ID/...') zu adressieren.
Kann mir jemand sagen, wie ich 'Deutsch: 2006 Rechtschreibreform' als app.languagesWithVendors-Objekt korrekt adressieren kann?
das könnte tatsächlich eine Lösung für meine Zwecke sein. Aber ist die ID denn immer zuverlässig? Angenommen der Entwickler und der Kunde haben unterschiedliche Sprachmodule zur Verfügung (z.B. zusätzlich für 'Deutsch: Österreich', wie im Duden-Plugin oder 'Lateinisch' als zusätzliches Modul). Hat dann auf ENGLISH in beiden Umgebungen garantiert dieselbe ID oder können die IDs bei unterschiedlicher Sprachen-Zahl unterschiedlich sein?
Ich hatte gehofft, durch die Adressierung über die Namen (englisch oder locale-independent) mich diesem Risiko nicht aussetzen zu müssen.
Weshalb sind gerade die dt. Sprachen gegenüber der Adressierung über den Namen so sperrig? Liegt es eventuell daran, dass bei mir ein anderer Sprachanbieter (InDihyph/InDitect) installiert ist?
Hab's auch mit InDesign CS4 ME unter Windows getestet. Auch dort lassen sich die nicht-deutschen Sprachen über ihre englische Namen adressieren. Die deutschen Sprachen bleiben außen vor. :-(
Ja, das wäre eine Untersuchung wert… Die ID-Nummern könnten da flexibel sein.
Für eine Standardinstallation von InDesign liegt der Nummern-Bereich für die Sprachen jedenfalls in den ersten Zahlen von 2 bis schätzungsweise 100.
Die 1 ist immer dem geöffneten InDesign-Dokument zugeordnet. Das läuft dann über die pageItems-Klasse:
Ob auch negative Zahlen als Wert von ID vorkommen können? Könnte ich mir vorstellen. Das ist mir jedenfalls bei den menuActions nach ID aufgefallen… ***** Mit herzlichem Gruß, Uwe Laubender
hast Du denn auch eine einleuchtende Erklärung, warum ausgerechnet bei den dt. Sprachen (vielleicht sogar nur bei diesen) die Adressierung über die Namen nicht funktioniert?
Oder funktioniert das bei Dir/anderen und nur bei mir nicht, wie da ein Plugin-Anbieter dazwischenfunkt?
/EDIT: AH. Sehe gerade, Du bist bereits fündig geworden…
Hallo, Martin!
Nö. Ne Erkärung habe ich (noch) nicht…
Aber Du kannst ja mal Folgende Abfrage auswerten. Vielleicht findet sich was Brauchbares.
Bei einer ersten Durchsicht bin ich u.a. auf die Property icuLocaleName gestoßen.
Außerdem gäbe es daneben auch noch (Liste unvollständig):
Für folgendes Snippet das Resultat für mein deutsches InDesign CS5.5 unten am Code angehängt (ist ne lange Liste). Zusammen mit den IDs der pageItems-Klasse.
Die IDs 101-103 beinhalten die drei deutschen Sprachvarianten.
***** Mit herzlichem Gruß, Uwe Laubender
(Dieser Beitrag wurde von Uwe Laubender am 1. Mär 2014, 11:53 geändert)
Ich habe jetzt hier nur ein wenig mitgelesen und nichts selbst überprüft, aber ich finde, die Doku ist doch ganz eindeutig:
Für mich bedeutet das, das die ID eindeutig ist, und anders, als die ID sonst in InDesign, unveränderlich ist.
Anders ausgedrückt, es ist m. E. möglich, und vermutlich auch wahrscheinlich, dass Namen nicht eindeutig sind, aber jede ID in diesem Fall in irgendeiner Formm bei Adobe registriert werden muss und nur einmal vergeben wird.
es ist die Frage, auf was sich der Begriff "unique" bezieht. Auf alle ID-Installationen und -Versionen weltweit? Oder auf die aktuell, lokal ausgeführte Version.
Spontan vermute ich, dass sich zumindest meine IDs von denjenigen von Uwe unterscheiden.
Ergebnis:
Freilich arbeiten wir mit unterschiedlichen InDesign-Versionen. ;-) Wer wagt den Vergleich mit seinen InDesign CS6-Sprachen gegen die meinigen?
---- edit: Gerade sehe ich, Uwe interessiert sich mehr für die IDs von PageItems als für die von Sprachen. Aber wie kommt er von den PageItems auf die icuLocaleNames? Ist da beim Kopieren was durcheinandergeraten?
Viele Grüße Martin
(Dieser Beitrag wurde von Martin Fischer am 1. Mär 2014, 16:19 geändert)
Das schafft bei mir nicht die nötige Vertrauensgrundlage, dass die IDs der Sprachen bei meinem Nachbarn mit denjenigen von meinem Arbeitsplatz korrespondieren. ;-)
Aber sei's drum. Wer interessiert sich jetzt noch für IDs, wo eine - zumindest für mich – bequemere Methode zur Adressierung der Sprache über den Namen gefunden ist.
Viele Grüße Martin
(Dieser Beitrag wurde von Martin Fischer am 1. Mär 2014, 16:35 geändert)
Meine Vermutung war falsch, uniqe ist für InDesign nicht eindeutig, meine IDs unterscheiden sich von Ihren, jetzt vermute ich, dass Sie vielleicht vom Hersteller der Module abhängig sind.
Hallo, Martin! Nein, da ist nichts durcheinandergeraten. Ich untersuchte eben die document.pageItems.itemByID(n) nach fortlaufenden Zahlen.
Und nicht die unter app.languageWithVendors. Das darf man nicht verwechseln. Das sind unterschiedliche Indices…
Ich habe dann einfach bei jeder Drehung der Hauptschleife eine for x in object-Schleife gedreht und mir im ESTK alle property/value-Paare geben lassen. Und dabei war dann eben auch unter vielen anderen icuLocalNames. ***** Mit herzlichem Gruß, Uwe Laubender
Für mich bedeutet das "nur", dass die ID innerhalb einer bestimmten Klasse unique, also einzigartig ist. Also z.B. innerhalb aller IDs der Klasse pageItems.
Ein schöner Fall ist zum Beispiel die ID einer Tabellenzelle, die ausschließlich innerhalb einer bestimmten Tabelle einzigartig ist. Anderen Tabellenzellen aus anderen Tabellen können selbstverständlich die gleiche ID haben. ***** Mit herzlichem Gruß, Uwe Laubender
Um jetzt mal keine Äpfel mit Birnen zu vergleichen, hier mal meine Ergebnisse mit Deiner Methode in CS6 v8.0.2:
Und da ergeben sich, selbst innerhalb gleicher Bedingungen, unterschiedliche Ergebnisse. Mein verwendetes deutsches InDesign CS6 v8.0.2, diesmal unter OSX 10.7.5 kommt völlig ohne Plugins von Drittherstellern aus… ***** Mit herzlichem Gruß, Uwe Laubender
die Kennzeichnung "unique ID" ist ein starker Hinweis darauf, dass es sich um eine ID innerhalb einer InDesign Datenbank handelt, und dass die ID auch nur dort unique ist.
Das prominenteste Beispiel für so eine Datenbank ist das normale InDesign Dokument mit UIDs für PageItems, Stories, Styles usw. Es gibt auch welche für Books, dann die sogenannte Session mit Widgets (Paletten, Fenster etc.) in "InDesign SavedData", eine weitere für temporäre Daten im Clipboard und eine für die Applikations-Preferences "InDesign Defaults".
Die Objekte vom Typ LanguageWithVendors liegen in den Applikations-Preferences (gerade überprüft), und die beobachteten IDs werden dynamisch vergeben wenn die Preferences neu aufgebaut werden. Unterschiedliche Plugin-Konstellationen führen so zu unterschiedlichen IDs - first come, first serve. Objekte aus den Voreinstellungen sollten sich eigentlich auch im Dokument finden, aber von der gleiche LanguageList werden dort nur die normalen "Languages" verwaltet.
Die auch angesprochenen Menü-Action IDs sind eine seltene Ausnahme von den sonst üblichen UIDs, sie entsprechen direkt privaten Konstanten des implementierenden Plugins. IDs im hohen 32 Bit Bereich (entsprechend negativ) sind dynamisch vergeben, wohl für Script-Actions oder sonstige Daten-basierte Menüs. Eine weitere Ausnahme von den UIDs sind XML Objekte, aber das schweift zu sehr ab.
Hier noch die Lösung der ursprünglichen Frage:
Das funktioniert bei mir auch ohne "$$ID/", fragt mich nicht warum. Ich habe obige Strings aus einem Dump der englischen CS5 Defaults zu Fuss (Copy-Paste) übertragen, und mit meiner deutschen CS6 überprüft.
Danach habe ich bemerkt, dass man mit dem Namen auch ganz normal einen $$ID String bestimmen kann, wie für die anderen lokalisierten Strings auch:
Hallo, Dirk! Ich bin ja kein Informatiker, aber danke für die Erklärung mit den negativen Zahlen im hohen 32-Bit-Bereich. So ganz habe ich das noch nicht verstanden ;-)
Hat das mit einer Begrenzung der Darstellbarkeit von Zahlen zu tun? Und Adobe weicht dann einfach in den Minus-Bereich aus, um auch diese darzustellen?
Also ähnlich der Begrenzung in ExtendScript oder JavaScript für die beiden Konstanten MAX_VALUE (1.7976931348623158e+308) und MIN_VALUE ( 2.2250738585072014e-308)? ***** Mit herzlichem Gruß, Uwe Laubender
bei "vorzeichenbehafteten" ganzen Zahlen wird das Vorzeichen im höchstwertigen Bit gespeichert, also im 32 Bit Wort statt der 2^31 Stelle. Die von Dir angesprochenen Werte sind 64 Bit Fließkommazahlen, weil JavaScript alle Zahlen (Number) intern so behandelt.
Ganze Zahlen werden gerne auch in "Hex" dargestellt mit Ziffern von 0 bis (dezimal) 15, also 0-9A-F, da so zwei Stellen für ein Byte / 8 Bit ausreichen. Die größte positive 32Bit (4 Byte) Zahl wäre dann $7F FF FF FF, alles von der $80 00 00 00 an ist negativ bis hin zu $FF FF FF FF, uns bekannt als -1 .
Adobe vergibt externe Plugin-PrefixIDs fortlaufend in 256er Gruppen, was einem Hex-Wert mit 00 am Ende entspricht. Als ich im Jahr 2002 mit InDesign 2 (also vor CS) angefangen habe, war meine erste ID $00067200, irgendwann Ende 2013 ist man bei $001a0d00 angelangt. Relativ zu so einer ID kann ich pro Plugin 256 Menü-Aktionen definieren, 256 Klassen, 256 UI-Elemente usw.
Ich darf dann voraussetzen, dass niemand sonst die gleiche ID verwendet. Es wäre ja doof, wenn ein Script eine neue Action anlegt, irgendwo ins Menü hängt und mein Plugin sich dafür zuständig fühlt, oder wenn eines meiner Objekte im Dokument auf einmal von einem fremden Plugin interpretiert wird. Um solche Kollisionen auszuschliessen, legt InDesign ScriptMenuActions und andere dynamische (nicht fest verdrahtete) Actions mit extrem hohen IDs an:
Mein Beispiel addiert 2^32, weil JavaScript Number.toString(16) mehr als 32 Bit kann und das Vorzeichen weiter separat behandelt.
Ich will noch mal die Methode von Dirk Becker aufgreifen, die die internationalen Keystrings für die Sprachen unter app.languagesWithVendors ermittelt.
Funktioniert soweit gut. Die internationalen Keystrings werden ausgeworfen.
Jedoch:
1. Bei meinem Test mit dem deutschen InDesign CS6 v8.0.2 musste ich feststellen, dass es über app.findKeyStrings(app.languagesWithVendors[n].name) für manche Sprachen keine international einsetzbaren Keystrings zu geben scheint.
2. Diese Methode (lustigerweise) oft bis zu 4 Ergebnisse liefert. Da muss man dann den korrekten erst mal raussuchen.
3. Die direkte Ansprache mit itemByName() mit den internationaln Keystrings nicht zum Ergebnis führt. Eine Sprache wird zwar zurückgeworfen:
Jedoch scheint das Ergebnis zweifelhaft, da sich keine Werte zu den angesprochenen Eigenschaften dieses Objekts ermitteln lassen:
Eine Schleife durch die Sprachen hingegen, die den Vergleich anstellt: deutscher String "Deutsch: 2006 Rechtschreibreform" mit dem String des Namens einer Sprache kann zum Erfolg führen. Muss aber nicht.
Hat sie jedenfalls noch gestern Abend bei mir. Kai Rübsamen hat das mal bei seiner CS6-Installation getestet und damit Probleme gehabt. Ich stelle gerade fest, dass dies heute Morgen bei mir auch so ist. Als Ergebnis wird zwar die korrekte Eigenschaftsänderung ausgeworfen (ESTK), aber wenn ich dann im GUI von InDesign CS6 nachschaue, ist noch der alte Wert drin.
Scheint also auch Bug-belastet zu sein.
Hier mein Test-Code für die Änderung der Einfachen Anführungszeichen für "Deutsch: 2006 Rechtschreibreform" nach "›‹". Hat gestern Abend noch funktioniert. Ich schwör! Heute nicht mehr. Vielleicht hilft ja ein Neustart des Rechners?
Abschließend noch:
Hier mein Testcode, um alle Keystrings zu ermitteln, den ich auf InDesign CS6 vom ESTK aus angewendet habe:
Ein paar ausgewählte Ergebnisse (den Rest könnt ihr ja selbst mit eueren Installationen von InDesign ermitteln):
Keine Ergebnisse gab es für:
Zuviele Ergebniss: gab es beispielsweise bei "Griechisch". Wobei das Ergebnis hochinteressant ist: der korrekte Keystring dürfte der zweite String sein, "$ID/Greek".
Meine Bitte nun also:
1. Könntet ihr mal die itemByName()-Methode mit den internationalen Keystrings testen und darüber berichten? Deutsche Version, Internationale Versionen, vielleicht auch mit der CC oder mit CS5.5 oder CS5?
2. Eine Schleife durch die Sprachen testen, um die Singlequotes zu ändern. Wie gesagt: mal funktionierts, mal nicht!
3. Könnte mal jemand mit einer internationalen Version von inDesign die fehlenden Sprachen mit den englischen Keystrings ergänzen? Möglicherweise funktioniert die direkte Zuweisung mit itemByName() damit ja auch in einer deutschen InDesign-Version.
Danke für's Mitlesen. War ein langer Beitrag; ich weiss…
Ach ja: und kann mal jemand die Funkion im Foreneditor Texte fett zu formatieren bugfrei machen? Danke. ***** Mit herzlichem Gruß, Uwe Laubender
weil ich sie gerade benutze, habe ich die deutschen Version von CS5 verwendet. Und Dein 'itemByName'-Script ausgeführt. Ergebnis: "Objekt ungültig" (bei fast allen Eigenschaften).
Nach einem Systemneustart, behauptet das ESTK immer noch, dass der Wert für die singleQuotes ›‹ ist. Hatte ich ja auch per Skript vor dem Neustart so gesetzt. Das GUI ist, siehe Screenshot im letzten Beitrag, immer noch der Ansicht, es seien die ursprünglich eingestellten ‚‘ aktiv.
Na gut. Dann testen wir das eben mal an einem Dokument. Ergebnis: die per Skript eingestellten werden verwendet!
Textrahmen aufgezogen, ein wenig Text getippt, ein "Apostrophe" als Single Quotation gesetzt (Unicode 0027).
Dann kopiert und wieder eingefügt. Beim Einfügen VOR einem Wort wurde es gewandelt. Beim Einfügen nach der Wortgrenze auch.
Und zwar in "›" an der linken Wortgrenze und in "‹" an der rechten Wortgrenze.
Ich diagnostiziere also einen Bug in der Darstellung bei den "Voreinstellungen" / "Wörterbuch" => "Einfache Anführungszeichen", wenn diese per Skript geändert werden.
Puh. "What a drag…" ***** Mit herzlichem Gruß, Uwe Laubender