InDesign und JavaScript: Schön gedacht, nur nicht zuende.

Ich habe mich gestern Abend und heute MIttag recht ausführlich mit der Datenzusammenfügungsfunktion von InDesign auseinandergesetzt. Dabei habe ich festgestellt, dass die zwar praktisch ist, dass die große Einschränkung aber ist, dass Zeilenumbrüche in der Quell-CSV nicht vernünftig verarbeitet werden. Ich habe dann die CSV mittels GREP und Textwrangler soweit bearbeitet dass alle Umbrüche außer die am Ende jeder Zeile gelöscht wurden. Dann hat der Import geklappt, aber schön ist das ja bei längeren Texten nicht.

Ich habe auch versucht mittels JavaScript qr-codes während des Importprozesses automatisch zu erzeugen, bin aber daran gescheitert, dass es zwischen den einzelnen Datenzeilen keinen Event gibt auf den ich mit einem EventListener im JavaScript hören und mit einem zwischengeschobenen Script reagieren hätte können. Da muss Adobe nachbessern. Und auch bei der Dokumentation muss Adobe nachbessern. Selbst liefern sie keine wirkliche Dokumentation zu den eingebauten Funktionen. Das MIT hat aber da mal was zusammengeschrieben…

Also habe ich versucht ein eigenes Script zu schreiben das durch alle Seiten durchfliegt die richtigen Elemente auswählt dort die Daten ausliest (ein Textfeld mit der URL) und das an das Element mit dem qr-Code drin übergibt auf dass ein neuer qr-code generiert wird. Soweit müsste(!) es funktionieren: Nur leider sagt mir InDesign immer dass das TextFeld mit der URL inValid ist. Bisher habe ich den Fehler nicht gefunden.

Und dann war ich unzufrieden damit, dass die Zeilenumbrüche im Import gelöscht werden müssen und dachte mir, dass man dann wohl die Daten mit Umbrüchen in einem csv-Datenfeld kodieren müsste. klassisches wäre urlencode() im JavaScript gewesen, aber dann müsste ich irgendein Script schreiben, das mir die CSV einliest, kodiert und wieder ausgibt. Ich habe jQuery.csv gefunden was das einlesen und kodieren, aber leider nicht wieder ausgeben kann. In Entwicklung 🙁 – Diese verdammten CSVs immer 🙁

Dann dachte ich, dass ich vielleicht einfach die Datenbank zum kodieren verwende. MySQL in dem die Daten vorliegen unterstützt aber keine native Codierung, d.h. ich müsste auf die Daten über Python&Co zugreifen, auslesen, kodieren und wieder abspeichern. Würde gehen, dauert aber das Python-Script zu schreiben. So geübt bin ich zur Zeit nicht.

Jetzt habe ich herausgefunden, dass ein netter Mensch für googleDocs ein Script geschrieben hat, das base64-encoding als google.calc-Funktion zur Verfügung stellt. base64 wird genutzt um emails durch den Äther zu schicken. Und dann habe ich crypto-js gefunden, was das im InDesign wieder rückgängig machen könnte.

Und dann stelle ich fest, dass ich ja auch einfach im google.calc ein eigenes Script schreiben könnte, dass mir mit der JavaScript-Standardfunktion urlencode() meine Daten kodieren könnte. Und urldecode() müsste auch in InDesign einfach so möglich sein. *Handvornkopfklatsch*

So viel rumgegoogle, wenn man auch es einfach einfach machen hätte können 😉 Statt mit blöden intermediate-csv-daten einfach in den Originaldaten arbeiten und gut ist!

Nur muss ich dann immer noch herausfinden wie ich die Daten in den verdammten Textfeldern anfasse und verändere. Das ist aber ein Projekt für später, jetzt muss ich mal was sinnvolles machen.

Prokrastination des Tages: Standalone-Monitoring

In meinem Bestreben, eine Software zu basteln, die sich unter Umständen mal vermarkten lässt hatte ich ja zuletzt untersucht inwiefern dies als QGIS-Plugin möglich ist.

Darauf aufbauen habe ich nun mal einfach angefangen was zu basteln (bisher nur GUI-rumgeschiebe…) und bin darauf gestoßen, dass ich eigentlich Quantum-GIS ausschließlich dazu brauche, Karten zu stylen. Und selbst dafür gäbe es andere Lösungen. Für die Datenberechnung, brauche ich also ausschließlich PostGIS. Und PostGIS als externes Programm, selbst wenn es GPL-Software ist, zu nutzen, hindert mich nicht daran meine GUI als Closed Source zu verhökern. (An diesem Punkt muss ich nochmal genauer in mich gehen, ob ich das ethisch-moralisch machen möchte und ob ich das politisch verantworten kann; aber das ist ein anderes Thema)

Dementsprechend feile ich jetzt daran ein eigenständiges Programm zu schreiben, das ausschließlich über die Schnittstellen des Betriebssystems (und nicht über fremde [GPL-]Bibliotheken) auf PostGIS zugreift (“auf Armeslänge”). Ist garnicht mal so kompliziert.

Nachtrag: Ich stelle fest, dass psycopg, was ich auch bisher aus QGIS heraus aufrufe, unter der LGPL-Lizenz steht und diese auch in proprietärer Software genutzt werden darf [en detail muss ich das noch recherchieren]. Schön. So muss ich also gar nicht so viel neu lernen. Eine Python-Bibliothek einzubinden hat den Vorteil, dass ich nicht für jedes einzelne Betriebssystem eine Lösung schreiben muss, sondern Python (und die Bibliothek) für mich die Connection übernimmt.

Nachtrag 2: Eine kommerzielle Lizenz für Qt (was meine GUI liefert) kostet schlanke 5500€ (plattformübergreifend) – Aber auch hier lese ich, dass Qt unter der LGPL zur Verfügung steht (oder stehen wird, das ist mir noch unklar).

Nachtrag 3: Bisher haben wir im Projekt Excel verwendet um Altersdöner herzustellen. In Zukunft würde ich das gerne automatisiert machen. R eignet sich. Auch für R gibt es eine Python-Bibliothek die durch proprietäre Software genutzt werden kann. Das weit verbreitetste RPy2 leider nicht (oder nur über einen Umweg), aber andere wie z.B. “R/SPlus – Python Interface” (BSD-Lizenz)