Forenindex » Programme » Print/Bildbearbeitung » Adobe InDesign Skriptwerkstatt » Dt. Sprachen über ihre Namen adressieren

Dt. Sprachen über ihre Namen adressieren

Martin Fischer
  
Beiträge gesamt: 12783

1. Mär 2014, 10:16
Bewertung:

gelesen: 7995

Beitrag als Lesezeichen
Liebe Kollegen,

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.

Code
$.writeln( app.languagesWithVendors.everyItem().name.join('\n')); 

var lan_arr = ['Deutsch: 2006 Rechtschreibreform', 'German: 2006 Reform', '$ID/de_DE_2006', 'Englisch: Großbritannien', 'English: UK', '$ID/English: UK', 'French']
for (var i = 0; i < lan_arr.length; i++)
$.writeln( lan_arr[i] + ':\t' + app.languagesWithVendors.itemByName(lan_arr[i]).isValid);


Kann mir jemand sagen, wie ich 'Deutsch: 2006 Rechtschreibreform' als app.languagesWithVendors-Objekt korrekt adressieren kann?

Viele Grüße
Martin


Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

1. Mär 2014, 10:22
Bewertung:

gelesen: 7930

Beitrag als Lesezeichen
Hallo, Martin!

Ich schätze mal über deren ID.
Einen Hinweis hier:

Pierre Lef
Changing language preferences (dictionary) in all the documents in an Incopy assignement?
02.01.2014 06:39

Beitrag #3
Jump_Over (Jarek)
http://forums.adobe.com/message/5976161#5976161
*****
Mit herzlichem Gruß,
Uwe Laubender

Dt. Sprachen über ihre Namen adressieren

Martin Fischer
  
Beiträge gesamt: 12783

1. Mär 2014, 10:33
Bewertung:

gelesen: 7924

Beitrag als Lesezeichen
Hallo Uwe,

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. :-(

Viele Grüße
Martin


Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

1. Mär 2014, 10:45
Bewertung:

gelesen: 7912

Beitrag als Lesezeichen
Hallo, Martin!

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:

Code
app.documents[0].pageItems.itemByID(1).getElements(); 


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

Dt. Sprachen über ihre Namen adressieren

Martin Fischer
  
Beiträge gesamt: 12783

1. Mär 2014, 10:59
Bewertung:

gelesen: 7888

Beitrag als Lesezeichen
Uwe,

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?

Viele Grüße
Martin


Dt. Sprachen über ihre Namen adressieren

Martin Fischer
  
Beiträge gesamt: 12783

1. Mär 2014, 11:32
Bewertung:

gelesen: 7848

Beitrag als Lesezeichen
Hallo Uwe,

mit einer Behelfsfunktion funktioniert's über die id.

Code
var lan_id = get_lanID('Deutsch: 2006 Rechtschreibreform'); 
var lan = app.languagesWithVendors.itemByID( lan_id );
$.writeln( lan.isValid);

function get_lanID(str)
{
var id = null;
for (var i = 0; i < app.languagesWithVendors.length; i++)
if (app.languagesWithVendors.item(i).name == str)
{
id = app.languagesWithVendors.item(i).id;
break;
}
return id;
}


Danke nochmals für den Hinweis mit der id.

Viele Grüße
Martin



(Dieser Beitrag wurde von Martin Fischer am 1. Mär 2014, 11:35 geändert)

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

1. Mär 2014, 11:51
Bewertung:

gelesen: 7842

Beitrag als Lesezeichen
/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.

Code
var newDoc = app.documents.add(); 
var limit = newDoc.rectangles.add().id;

for(var n=1;n<limit;n++){
try{

var myObject = newDoc.pageItems.itemByID(n);

for(x in myObject){
$.writeln(x+"\t"+myObject[x]);
};

$.writeln("*********");


}catch(e){};
};


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):

Code
name 
hyphenationVendor
spellingVendor
isValid
index


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.

Code
//Deutsches InDesign CS5.5 
//OSX 10.6.8
//Proximity

var newDoc = app.documents.add();
var limit = newDoc.rectangles.add().id;

for(var n=1;n<limit;n++){
try{
$.writeln(n+"\t"+newDoc.pageItems.itemByID(n).icuLocaleName);
}catch(e){};
};

/*
RESULTS:

69 en_US_POSIX
70 en_US
71 en_US
72 en_US
73 fr_FR
74 es_ES
75 it_IT
76 en_GB
77 sv_SE
78 da_DK
79 nb_NO
80 pt_PT
81 pt_BR
82 fr_CA
83 nn_NO
84 fi_FI
85 ca_ES
86 ru_RU
87 bg_BG
88 cs_CZ
89 pl_PL
90 ro_RO
91 el_GR
92 tr_TR
93 hu_HU
94 en_CA
95 sk_SK
96 hr_HR
97 et_EE
98 lv_LV
99 lt_LT
100 sl_SI
101 de_DE
102 de_DE
103 de_DE
104 nl_NL
105 nl_NL
106 de_CH
107 de_CH
108 pt_BR
109 uk_UA

*/

*****
Mit herzlichem Gruß,
Uwe Laubender

(Dieser Beitrag wurde von Uwe Laubender am 1. Mär 2014, 11:53 geändert)

Dt. Sprachen über ihre Namen adressieren

WernerPerplies
Beiträge gesamt: 2762

1. Mär 2014, 15:04
Bewertung:

gelesen: 7777

Beitrag als Lesezeichen
Hallo Herr Fischer,

Zitat Aber ist die ID denn immer zuverlässig?


Ich habe jetzt hier nur ein wenig mitgelesen und nichts selbst überprüft, aber ich finde, die Doku ist doch ganz eindeutig:

Zitat The unique ID of the LanguageWithVendors.


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.

Einen schönen Tag wünscht

Werner Perplies
Praxisnahe Skript-Lösungen und Skript-Programmierung für Adobe InDesign
Aktuelles (Stand: 14.02.2024)
Kundenstimmen

Dt. Sprachen über ihre Namen adressieren

Martin Fischer
  
Beiträge gesamt: 12783

1. Mär 2014, 16:16
Bewertung:

gelesen: 7748

Beitrag als Lesezeichen
Hallo Herr Perplies,

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.

Code
var lan = app.languagesWithVendors; 
for (var i = 0; i < lan.length; i++)
$.writeln( lan[i].id + ':\t' + lan[i].name);


Ergebnis:
Code
58:	[Keine Sprache] 
59: Deutsch: Alte Rechtschreibung
60: Deutsch: 1996 Rechtschreibreform
61: Deutsch: 2006 Rechtschreibreform
62: Deutsch: Schweiz
63: Deutsch: Schweiz 2006 Rechtschreibreform
64: Lateinisch
65: Bengalisch (Indien)
66: Gujarati (Indien)
67: Hindi (Indien)
68: Kannada (Indien)
69: Malayalam (Indie)
70: Marathi (Indien)
71: Oriya (Indie)
72: Pandschabisch (Indien)
73: Tamilisch (Indien)
74: Telugu (Indien)
75: Bulgarisch
76: Katalanisch
77: Tschechisch
78: Dänisch
79: Griechisch
80: Englisch: Kanada
81: Englisch: Großbritannien
82: Englisch: USA
83: Englisch: USA Medizin
84: Spanisch
85: Estnisch
86: Finnisch
87: Französisch: Kanada
88: Französisch
89: Kroatisch
90: Ungarisch
91: Italienisch
92: Litauisch
93: Lettisch
94: Norwegisch: Bokmål
95: Niederländisch: Alte Rechtschreibung
96: Niederländisch: 2005 Rechtschreibreform
97: Norwegisch: Nynorsk
98: Polnisch
99: Portugiesisch: Brasilien
100: Portugiesisch: Rechtschreibreform
101: Portugiesisch
102: Rumänisch
103: Russisch
104: Slowakisch
105: Slowenisch
106: Schwedisch
107: Türkisch
108: Ukrainisch
109: Englisch: USA Recht
110: Hebräisch
111: Arabisch
579: Deutsch: Österreich
698: Farsi


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)

Dt. Sprachen über ihre Namen adressieren

Martin Fischer
  
Beiträge gesamt: 12783

1. Mär 2014, 16:33
Bewertung:

gelesen: 7738

Beitrag als Lesezeichen
InDesign CS4 (Mac):
Code
58:	[Keine Sprache] 
59: Deutsch: Alte Rechtschreibung
60: Deutsch: Rechtschreibreform 1996
61: Deutsch: Rechtschreibreform 2006
62: Deutsch: Schweiz
63: Deutsch: Schweiz Rechtschreibreform 2006
64: Lateinisch
65: Deutsch: Österreich
66: Englisch: USA
67: Englisch: USA Medizin
68: Englisch: USA Recht
69: Französisch
70: Spanisch
71: Italienisch
72: Englisch: Großbritannien
73: Schwedisch
74: Dänisch
75: Norwegisch: Bokmål
76: Portugiesisch
77: Portugiesisch: Brasilien
78: Französisch: Kanada
79: Norwegisch: Nynorsk
80: Finnisch
81: Katalanisch
82: Russisch
83: Bulgarisch
84: Tschechisch
85: Polnisch
86: Rumänisch
87: Griechisch
88: Türkisch
89: Ungarisch
90: Englisch: Kanada
91: Slowakisch
92: Kroatisch
93: Estnisch
94: Lettisch
95: Litauisch
96: Slowenisch
97: Niederländisch: Alte Rechtschreibung
98: Niederländisch: Rechtschreibreform 2005
99: Ukrainisch
100: Hebräisch
101: Arabisch
Execution finished.


InDesign CS4 (Win):
Code
58:	[No Language] 
59: English: USA
60: English: USA Medical
61: English: USA Legal
62: French
63: Spanish
64: Italian
65: English: UK
66: Swedish
67: Danish
68: Norwegian: Bokmål
69: Portuguese
70: Portuguese: Brazilian
71: French: Canadian
72: Norwegian: Nynorsk
73: Finnish
74: Catalan
75: Russian
76: Bulgarian
77: Czech
78: Polish
79: Romanian
80: Greek
81: Turkish
82: Hungarian
83: English: Canadian
84: Slovak
85: Croatian
86: Estonian
87: Hebrew
88: Latvian
89: Lithuanian
90: Slovenian
91: German: Old Rules
92: German: 1996 Reform
93: German: 2006 Reform
94: Dutch: Old Rules
95: Dutch: 2005 Reform
96: German: Swiss
97: German: Swiss 2006 Reform
98: Ukrainian
99: Arabic
100: Farsi


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)

Dt. Sprachen über ihre Namen adressieren

WernerPerplies
Beiträge gesamt: 2762

1. Mär 2014, 16:45
Bewertung:

gelesen: 7733

Beitrag als Lesezeichen
Hallo Herr Fischer,

Zitat 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.


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.

Einen schönen Tag wünscht

Werner Perplies
Praxisnahe Skript-Lösungen und Skript-Programmierung für Adobe InDesign
Aktuelles (Stand: 14.02.2024)
Kundenstimmen

Dt. Sprachen über ihre Namen adressieren

WernerPerplies
Beiträge gesamt: 2762

1. Mär 2014, 17:11
Bewertung:

gelesen: 7702

Beitrag als Lesezeichen
Hallo Herr Fischer,

was halten von dieser Funktion für den Zugriff?

Code
alert(getBy(app.languagesWithVendors, "name", "Deutsch: Schweiz 2006 Rechtschreibreform").name); 
function getBy(/*objectCollection*/oc, /*String*/property, /*Any*/what)
{
for (var i = 0; i<oc.length; i++)
{
if (property in oc[i])
{
if ((oc[i][property] != null) && (oc[i][property]==what))
return oc[i];
}
}
return null;
}


Diese Funktion sollte das jeweils erste übereinstimmende Objekt für eine beliebige Eigenschaft finden.

Einen schönen Tag wünscht

Werner Perplies
Praxisnahe Skript-Lösungen und Skript-Programmierung für Adobe InDesign
Aktuelles (Stand: 14.02.2024)
Kundenstimmen

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

1. Mär 2014, 18:36
Bewertung:

gelesen: 7670

Beitrag als Lesezeichen
Zitat von Martin Fischer Aber wie kommt er von den PageItems auf die icuLocaleNames?
Ist da beim Kopieren was durcheinandergeraten?


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

Dt. Sprachen über ihre Namen adressieren

Martin Fischer
  
Beiträge gesamt: 12783

1. Mär 2014, 19:01
Bewertung:

gelesen: 7662

Beitrag als Lesezeichen
Hallo Herr Perplies,

Antwort auf: was halten von dieser Funktion für den Zugriff?


Das sieht auch interessant aus.
Bin mobil unterwegs und dann's im Moment leider nicht testen.

Viele Grüße
Martin


Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

1. Mär 2014, 19:04
Bewertung:

gelesen: 7659

Beitrag als Lesezeichen
Zitat von Werner Für mich bedeutet das, das die ID eindeutig ist, und anders, als die ID sonst in InDesign, unveränderlich ist.


Hallo, Werner!

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

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

1. Mär 2014, 19:25
Bewertung:

gelesen: 6389

Beitrag als Lesezeichen
Hallo, Martin!

Um jetzt mal keine Äpfel mit Birnen zu vergleichen, hier mal meine Ergebnisse mit Deiner Methode in CS6 v8.0.2:

Code
//app.languagesWithVendors_CS6_v8.0.2.jsx 
//Uwe Laubender

var lan = app.languagesWithVendors;
for(var n=0;n<lan.length;n++){
$.writeln( lan[n].id+":\t"+lan[n].name );
};

/*
58: [Keine Sprache]
59: Bengalisch (Indien)
60: Gujarati (Indien)
61: Hindi (Indien)
62: Kannada (Indien)
63: Malayalam (Indie)
64: Marathi (Indien)
65: Oriya (Indie)
66: Pandschabisch (Indien)
67: Tamilisch (Indien)
68: Telugu (Indien)
69: Bulgarisch
70: Katalanisch
71: Tschechisch
72: Dänisch
73: Deutsch: Schweiz
74: Deutsch: Schweiz 2006 Rechtschreibreform
75: Deutsch: 1996 Rechtschreibreform
76: Deutsch: 2006 Rechtschreibreform
77: Griechisch
78: Englisch: Kanada
79: Englisch: Großbritannien
80: Englisch: USA
81: Englisch: USA Medizin
82: Spanisch
83: Estnisch
84: Finnisch
85: Französisch: Kanada
86: Französisch
87: Kroatisch
88: Ungarisch
89: Italienisch
90: Litauisch
91: Lettisch
92: Norwegisch: Bokmål
93: Niederländisch: Alte Rechtschreibung
94: Niederländisch: 2005 Rechtschreibreform
95: Norwegisch: Nynorsk
96: Polnisch
97: Portugiesisch: Brasilien
98: Portugiesisch: Rechtschreibreform
99: Portugiesisch
100: Rumänisch
101: Russisch
102: Slowakisch
103: Slowenisch
104: Schwedisch
105: Türkisch
106: Ukrainisch
107: Englisch: USA Recht
108: Deutsch: Alte Rechtschreibung
109: Hebräisch
110: Arabisch

*/


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

Dt. Sprachen über ihre Namen adressieren

Dirk Becker
Beiträge gesamt: 193

1. Mär 2014, 20:59
Bewertung:

gelesen: 6364

Beitrag als Lesezeichen
Moin,

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:

Code
$.writeln(app.languagesWithVendors.itemByName("German: Traditional").name); 
$.writeln(app.languagesWithVendors.itemByName("German: Reformed").name);
$.writeln(app.languagesWithVendors.itemByName("de_DE_2006").name);
$.writeln(app.languagesWithVendors.itemByName("German: Swiss").name);
$.writeln(app.languagesWithVendors.itemByName("de_CH_2006").name);


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:

Code
$.writeln(app.findKeyStrings(app.languagesWithVendors.itemByName("de_CH_2006").name)); 


Grüße,
Dirk

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

2. Mär 2014, 09:21
Bewertung:

gelesen: 6316

Beitrag als Lesezeichen
Zitat von Dirk 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.


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

Dt. Sprachen über ihre Namen adressieren

WernerPerplies
Beiträge gesamt: 2762

2. Mär 2014, 09:49
Bewertung:

gelesen: 6309

Beitrag als Lesezeichen
Hallo Uwe,

Zitat 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?


Das hat wenig mit Adobe zu tun.

Ganze Zahlen können vorzeichenbehafted(signed) oder nicht vorzeichenbehaftet (unsigned) sein.

Für vorzeichenbehaftete Zahlen wird die obere Hälfte der Variablenbreite verwendet.

siehe z. B.:
Integer (Datentyp)

Einen schönen Tag wünscht

Werner Perplies
Praxisnahe Skript-Lösungen und Skript-Programmierung für Adobe InDesign
Aktuelles (Stand: 14.02.2024)
Kundenstimmen

Dt. Sprachen über ihre Namen adressieren

Dirk Becker
Beiträge gesamt: 193

2. Mär 2014, 10:31
Bewertung:

gelesen: 6287

Beitrag als Lesezeichen
Hallo Uwe,

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:

Code
Number(app.scriptMenuActions.add("Bla").id+0x100000000).toString(16) 
Ergebnis: ff002004


Mein Beispiel addiert 2^32, weil JavaScript Number.toString(16) mehr als 32 Bit kann und das Vorzeichen weiter separat behandelt.

Dt. Sprachen über ihre Namen adressieren

Dirk Becker
Beiträge gesamt: 193

2. Mär 2014, 11:06
Bewertung:

gelesen: 6277

Beitrag als Lesezeichen
Zitat 64 Bit Fließkommazahlen

Kleine Korrektur: wahrscheinlich eher 80 Bit, hab' da gerade nicht nachgezählt.

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

2. Mär 2014, 11:07
Bewertung:

gelesen: 6277

Beitrag als Lesezeichen
Hallo, Dirk!
Danke für die ausführliche Erklärung…
Jetzt ist mir das klarer. :-)
*****
Mit herzlichem Gruß,
Uwe Laubender

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

9. Mai 2014, 08:41
Bewertung:

gelesen: 6017

Beitrag als Lesezeichen
Guten Morgen, zusammen!

Ich will noch mal die Methode von Dirk Becker aufgreifen, die die internationalen Keystrings für die Sprachen unter app.languagesWithVendors ermittelt.

Beitrag #17 hier in diesem Thread:

http://www.hilfdirselbst.ch/..._P524319.html#524319

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:

Code
app.languagesWithVendors.itemByName("$ID/de_DE_2006"); //Returns [object LanguageWithVendors] 


Jedoch scheint das Ergebnis zweifelhaft, da sich keine Werte zu den angesprochenen Eigenschaften dieses Objekts ermitteln lassen:

Code
//TEST_InternationalKeyStrings_languagesWithVendors.itemByName.jsx 
//Uwe Laubender

//DA SCHEINT EIN BUG VORZULIEGEN: InDesign CS6 v8.0.2 OSX 10.6.8

var myLanguage = app.languagesWithVendors.itemByName("$ID/de_DE_2006"); //Returns [object LanguageWithVendors]

for(x in myLanguage){

try{
$.writeln(x+"\t"+myLanguage[x]);
}catch(e){$.writeln(x+"\t"+e.message)};

};
/*
ERGEBNISSE:

name Objekt ist ungültig
singleQuotes Objekt ist ungültig
doubleQuotes Objekt ist ungültig
hyphenationVendor Objekt ist ungültig
spellingVendor Objekt ist ungültig
thesaurusVendor Objekt ist ungültig
dictionaryPaths Objekt ist ungültig
icuLocaleName Objekt ist ungültig
spellingVendorList Objekt ist ungültig
hyphenationVendorList Objekt ist ungültig
id Objekt ist ungültig
label Objekt ist ungültig
isValid false
parent Objekt ist ungültig
index Objekt ist ungültig
properties Objekt ist ungültig
events Objekt ist ungültig
eventListeners Objekt ist ungültig
isValid false
*/


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?

Code
var myLanguages = app.languagesWithVendors; 

for(var n=0;n<myLanguages.length;n++){
if(myLanguages[n].name === "Deutsch: 2006 Rechtschreibreform"){
myLanguages[n].singleQuotes = "›‹";
$.writeln(n+"\t"+myLanguages[n].singleQuotes); //18 ›‹
};
};



Abschließend noch:

Hier mein Testcode, um alle Keystrings zu ermitteln, den ich auf InDesign CS6 vom ESTK aus angewendet habe:

Code
var myLanguages = app.languagesWithVendors; 

for(var n=0;n<myLanguages.length;n++){

$.writeln(n+"\t"+myLanguages[n].name+"\t"+app.findKeyStrings(myLanguages[n].name));

};


Ein paar ausgewählte Ergebnisse (den Rest könnt ihr ja selbst mit eueren Installationen von InDesign ermitteln):

Keine Ergebnisse gab es für:

Code
1	Bengalisch (Indien)	 
2 Gujarati (Indien)
3 Hindi (Indien)
4 Kannada (Indien)
5 Malayalam (Indie)
6 Marathi (Indien)
7 Oriya (Indie)
8 Pandschabisch (Indien)
9 Tamilisch (Indien)
10 Telugu (Indien)


Zuviele Ergebniss:
gab es beispielsweise bei "Griechisch". Wobei das Ergebnis hochinteressant ist: der korrekte Keystring dürfte der zweite String sein, "$ID/Greek".

Code
19	Griechisch	$ID/PlaceHolder_Greek,$ID/Greek,$ID/kWRIndexGroup_GreekAlphabet,$ID/Greek Mode 


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

Dt. Sprachen über ihre Namen adressieren

Hans Haesler
  
Beiträge gesamt: 5826

9. Mai 2014, 09:52
Bewertung:

gelesen: 5985

Beitrag als Lesezeichen
Hallo, Uwe!

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).

Dann habe ich den Namen geändert ...

Code
 
var myLanguage = app.languagesWithVendors.itemByName("de_DE_2006");

... und das Script nochmals gestartet. Ergebnis:

Zitat name Deutsch: Rechtschreibreform 2006
singleQuotes ‚‘
doubleQuotes „“
hyphenationVendor Proximity
spellingVendor Proximity
thesaurusVendor LILO
dictionaryPaths
icuLocaleName de_DE
spellingVendorList Proximity
hyphenationVendorList Proximity
id 92
label
isValid true
parent [object Application]
index 34
properties [object Object]
events [object Events]
eventListeners [object EventListeners]
isValid true

Gruss, Hans

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

9. Mai 2014, 09:57
Bewertung:

gelesen: 5978

Beitrag als Lesezeichen
Hallo, Hans!

Vielen Dank! Aha!

Ohne die $ID/ -Notation scheint's bei Dir zu klappen.
Ist ja sehr ungewöhnlich. Aber gut…

Werde ich gleich mal hier bei mir versuchen.
*****
Mit herzlichem Gruß,
Uwe Laubender

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

9. Mai 2014, 10:09
Bewertung:

gelesen: 5966

Beitrag als Lesezeichen
Gerade getestet:

Code
var myLanguage = app.languagesWithVendors.itemByName("de_DE_2006"); //Returns [object LanguageWithVendors] 

for(x in myLanguage){

try{
$.writeln(x+"\t"+myLanguage[x]);
}catch(e){$.writeln(x+"\t"+e.message)};

};



Code
/* 
ERGEBNIS:
name Deutsch: 2006 Rechtschreibreform
singleQuotes ›‹
doubleQuotes „“
hyphenationVendor Hunspell
spellingVendor Hunspell
thesaurusVendor LILO
dictionaryPaths
icuLocaleName de_DE
spellingVendorList Hunspell,Proximity,User Dictionary Only
hyphenationVendorList Hunspell,Proximity,User Dictionary Only
id 76
label
isValid true
parent [object Application]
index 18
properties [object Object]
events [object Events]
eventListeners [object EventListeners]
isValid true
*/


"Lustigerweise" wird bei den Werten für singleQuotes das hier zurückgegeben:
"›‹"

"Un-lustigerweise" steht im GUI jedoch was anderes drin!
Siehe Screenshot hier angehängt: "LanguageWithSingleQuotes.png"

Ich starte mal mein System neu und berichte dann noch mal…
*****
Mit herzlichem Gruß,
Uwe Laubender

Anhang:
LanguageWithSingleQuotes.png (27.0 KB)

Dt. Sprachen über ihre Namen adressieren

Uwe Laubender
Beiträge gesamt: 5316

9. Mai 2014, 11:01
Bewertung:

gelesen: 5932

Beitrag als Lesezeichen
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