("foo" + + "bar") === "fooNaN" // Ergebnis: true
Auch als Programmierer kann man Sonntags Nachmittag Spaß haben :-/
Ein schöne Sammlung merkwürdigen JavaScript Verhaltens, die auch in Adobes JS Implementation brav umgesetzt wurde. Nur bei einigen window und web-spezifischen Sachen dürfen wir nicht mitmachen.
Letztlich wird wieder mal deutlich, dass der Versuch Programmieren möglichst einfach zu machen zum scheitern verurteilt ist. Die meisten Sachen ergeben sich aus der automatischen Casting und Annahmen bzw. Vermutungen über die vermeintliche Aussage des Programmieres.
Schön wärs! Für sehr einfache und lineare Titel ist das denkbar. Sobald Informationen durch das Layout gegliedert werden scheitert jede Lösung, die versucht seitenbasierte Druckdaten automatsiert in ein strukturiertes Format zu überführen. Ohne eine akzeptable Implementierung künstlicher Intelligenz oder sorgfältige Vorbereitung der Daten kann das auch gar nicht anders sein.
Aus kaufmännischer Sicht ist der Wunsch kostenneutral E-Books zu generieren nachvollziehbar. Auf technischer Seite zeigt sich schnell wer sich ernsthaft mit dem Thema beschäftigt hat.
In diesem Beitrag geht es natürlich um den EPub-Export von InDesign. Der Export über Datei -> Export for Digital Editions ist erstaunlich gut. Wer ein paar Punkte beachtet kann bei einfachen Titeln zu sehr guten Ergebnissen kommen.
Zunächst ist wichtig, das alle Seitenelemente die nicht ins E-Book übernommen werden sollen auf Musterseiten angelegt werden – ein per Hand erstellter Kolumnentitel oder eine versehentlich gelöste Seitenzahl wird höchstwahrscheinlich an einer völlig falschen Stelle im Ebook auftauchen.
Beim Textaufbau ist auf die richtige Textverkettung der Rahmen zu achten – Textabschnitte werden immer vollständig exportiert.
Die größten Probleme in klassischen InDesign-Datein dürften jedoch per Hand platzierte Bilder verursachen. Diese werden ganz am Ende, bzw. erst nach dem Textabschnitt zu dem sie zugeordnet sind platziert. Abhilfe schafft die Verankerung der Bilder an den entsprechenden Stellen im Text. Dies dürfte in klassischen Workflows fast immer zu Nacharbeiten führen.
Ein weiteres Problem sind Bilder mit Legenden, diese müssen zunächst gruppiert werden, damit sie beim Export zusammengehalten werden.
Das Einbetten von Schriften ist gleich dopplet Problematisch: InDesign bettet nur Schriften mit entsprechender Erlaubnis ein. Dazu ergibt sich ein rechtlicher Problem bei der Weitergabe von Schriften in epub-Daten, da diese lediglich kopiert durch einfaches entpacken extrahiert werden können. Mit der Verwendung von freien Schriften kann man sich entsprechenden Ärger ersparen.
Selbstverständlich können keine strukturellen oder semantischen Informationen – wobei die Frage offen bleibt inwieweit die semantischen Auszeichnung von Informationen in naher Zukunft an realer Bedeutung gewinnt – exportiert werden.
Wer dann alles richtig gemacht hat wird trotzdem in den meisten Fällen das erstellt EPub öffnen und einzelne Teile nacharbeiten. Es bietet sich an ein eigenes CSS für alle Publikationen festzulegen, in diesem können dann auch ganz elegant freie Schriftarten zugewiesen werden. Zur Nacharbeit bieten sich die Technologien Java, XSLT udn CSS an. Bei einem höheren Datenvolumen sollten diese Schritte natürlich automatisiert werden.
Zusammenfassend würde ich sagen das ein EPub-Export gelingen kann. Jedoch sollte man sich vom automatischen Traum schnell verabschieden:
- Es werden detaillierte Bearbeitungskonventionen für die Arbeit in InDesign benötigt.
- Ein »EBook-Preflight« per Skript oder Abhakliste sollte entwickelt werden.
- Eine Nachbearbeitung des EBooks im Bereich Metadaten, Titelei
Seit dem 23. September hat Adobe die Feautre-Liste für InDesign CS4 veröffentlicht, der Auslieferungstermin steht noch nicht fest wird aber noch vor Ende des Jahres sein.
Grund genug sich das ganze mal näher anzugucken und insbesondere auch die InDesign Großmeister und deren Blogs quer zu lesen: Die beste Übersicht hab ich bei indesignsecrets.com gefunden (englisch).
Aus Marketingsicht verständlich wird die Fusion von Online – (insbesondere Flash) und Printproduktion als Neuheit schlechthin beworben. Sofort stellt sich auch die Erinnerung an Quark 5 ein, wo schon 2002 ein ähnlicher Versuch unternommen worden war. Quark 5 konnte damals sein Versprechen nicht einlösen, was wohl primär daran lag das Printprodukte und Webseiten doch verschiedenere Medien sind als man auf den ersten Blick glauben würde. Ob demnächst dank CS4 Printproduktionen reihenweise als kleine Flash-Filmchen ins Internet gestellt werden oder nicht, einen wahren Mehrwert zu PDF sehe ich aus Crossmedia-Sicht (noch) nicht. Immerhin hat Adobe darauf verzichtet uns ein konsequentes Crossmedia-Konzept aufzuzwingen – das dann wahrscheinlich ähnlich dem von Quark Schiffbruch erlitten hätte!
Meine Vermutung für CS4 war ja ein GUI für XML-Rules. XML-Rules sind seit CS3 dafür zuständig bestimmte XML-Nodes anhand von XPath ausdrücken zu adressieren und diese dann mit kleinen Skripten weiterzuverarbeiten/formatieren. Die erhoffte Funktion wird dem Anwender aber noch nicht zugetraut – wahrscheinlich wegen der Komplexität der XPath Adressierung die den durschnittlichen Designer ratlos zurücklässt. Grund genug sich selber mal Gedanken über eine GUI zu machen – so schwierig kann das ja eigentlich nicht sein.
Stattdessen wird mit IDML geworben ob es sich einfach nur um das InDesign Interchange Format mit neuem Namen handelt und vorallem ob es jetzt wirklich übersichtlich genug ist um damit zu arbeiten ist mir noch unklar. Seit Microsofts Office Open XML steht allerdings fest, das ein in XML definiertes Austauschformat trotzdem vollkommen unübersichtlich und unbenutzbar sein kann.
Ich hoffe einfach auf weitere Verbesserungen im Handling mit XML, fürchte aber das in diesem Bereich kaum Weiterentwicklungen gemacht wurden.
Der Live-Preflight wird für Laien und Grafiker, die nicht so wirklich viel Ahnung von druckbaren Daten haben, sicherlich einige Probleme schon früher in den Vordergrund rücken. Im wirklich professionellen Umfeld sehe ich da inzwischen zum Glück weniger Probleme.
Zwei wirklich tolle Funktioneb sind auch für mich dabei: Zu echten Querverweisen muss ich nicht mehr viel sagen. Die Möglichkeit mit GREP-Styles anhand von Regulären Ausdrücken Text zu formatieren wird einige Bereich, die vorher mühsam geplant werden mussten stark vereinfachen. Dazu kommen da dann einige Spezialitäten der Regulären Ausdrücke voll zum trage: Z.B. Verweispfeile innerhalb von Klammen die mit look-around assertions sehr schön erfasst werden können.
Spannend bleibt es bis zum Release allemal!
Und noch ein Blog zu InDesign. Ich werde hier in loser Folge von meiner Arbeit mit InDesign in halb- und vollautomatisierten Publishing-Workflows berichten. Die meisten Projekte sind eine Kombination aus XML, InDesign-Scripten und manchmal InCopy. Die vielen Randthemen von Content-Generation über XSLT bis hin zu Roundtripping werde ich des öfteren streifen.
Die üblichen FAQ sind meiner Ansicht nach schon recht gut im Netz zu finden – dazu werde ich wohl eher das Connect-Widget ein wenig pflegen.
Jetzt Alleinstellungsmerkmale zu definieren wäre in Anbetracht des (noch nicht vorhandenen) Contents ein wenig vermessen. Da die Beschreibung von ganzen Workflows ein wenig lang wäre (und ich schon genug vorm Rechner sitze) werde ich mich auf Interessante Aspekte und Herangehensweisen beschränken. Weiterhin werde ich für mich und die Nachwelt interessante Diskussionen aus dem Adobe InDesign Scripting Forum zusammenfassen. as ganze dann gesprenkelt mit Code Stückchen und Scripten.
Fangen wir mal an:
Das klassische hello world Skript ist in InDesign etwas länger:
// helloworld.jsx // Neues Dokument erstellen var _dokument = app.documents.add(); // Textframe mit Text Hallo Welt befüllen var tf = _dokument.pages[0].textFrames.add(); tf.geometricBounds = [10,10,100,100]; tf.insertionPoints[0].contents = "Hallo Welt!";
Ich vergaß zu erwähnen: Alle Skripte werden in JavaScript veröffentlicht und laufen auf der Mac und Windows Version von InDesign.
