Dieses Jahr werde ich mich also wieder einmal auf die CeBit begeben. Der SNAP-Stand  wird in Halle 6 (Stand J 042) stehen, als Teil des CoreMedia-Gemeinschaftsstandes.

Was stellen wir auf der CeBit vor?

Auf der CeBit werden wir die Lösung vorstellen, die wir im Projekt mit der Technischen Universität Dortmund entwickelt haben:  Den Unified Newsroom.

Was bedeutet das konkret?

Immer häufiger hört man ja die Frage, wie das sich denn nun mit Online und Print verhielte, bzw. ob es sinnvoll sei, Redakteure beider Bereiche irgendwie zu integrieren. Und das ist eine Frage, die natürlich nicht nur technisch, sondern auch organisatorisch gelöst werden kann.

In Dortmund geht man einen Schritt weiter. Die Journalistenausbildung dort erfolgt kanal-unabhängig, d.h. es werden in der Redaktionskonferenz zunächst einmal Themen geplant. Nicht Ausgabekanäle.

Bei der Recherche wird dem Redakteur angezeigt, welche Inhalte es zu dem Thema, an dem er schreibt, bereits gibt: Fernsehbeiträge, Radiosendungen, Bilder, Artikel. Er kann auf all diese Objekte zugreifen, um beispielsweise einen TV-Stream in seinen Online-Artikel einzubauen, Bilder aus dem Archiv zu seinem Print-Artikel hinzuzufügen, bereits geschriebene Artikel als Basis zur Vertonung im Radio sichten.

Auf der CeBit werden wir also gemeinsam mit unserem Partner Digital Collections zeigen, wie eine gemeinsame Themenplanung funktioniert. Wir werden demonstrieren, wie Artikel mit Adobe-Clients und dem Redaktionssystem K4 von vjoon für Web und Print gleichermaßen aufbereitet werden können. Auf Basis des CoreMedia-Starter-Kits zeigen wir die Auslieferung der  Inhalte im Web, komplett mit Bewertungs- und Kommentarfunktion.

Kurz gesagt: Wir wollen Ihnen zeigen, wie die Zukunft des Publizierens aussieht. Wenn Sie sich das anschauen wollen, nehmen Sie mit uns Kontakt auf. Gerne laden wir Sie zu uns auf den Stand ein.

Wir sitzen bei CoreMedia und diskutieren über Metadaten. Natürlich nicht auf diese philosophische Art, wie man das zumeist auch erst nach Feierabend macht. Sondern haben ein grundlegendes Problem beim Verwenden von Metainformationen besprochen:

Werke jeglicher Art, seien es Videos, Bilder oder Texte, werden mit Metadaten versehen. Völlig klar.

So werden beim Erstellen von Artikeln innerhalb eines Redaktionssystems Informationen wie der Name des Autors, Länge des Textes, und viele weitere Informationen gespeichert, damit dieser Artikel leichter verwaltet werden kann. Diese Informationen liegen meist in einer zentralen Datenbank. Ein an sich vernünftiges Prinzip. Aber was passiert, wenn diese Daten dann an ein anderes System übergeben werden? Oder an mehrere?

Beispielsweise soll der oben erwähnte Artikel nun auch im Web publiziert werden. Also wird er an ein Content-Management-System übergeben. Dabei werden einige Metainformationen ebenfalls übergeben, aber natürlich nicht alle.

In der Zwischenzeit ist die gedruckte Ausgabe abgeschlossen und soll nun aus dem Produktionssystem gelöscht werden. Dazu wird der Artikel aus dem System exportiert und archiviert, denn er soll natürlich weiterhin gefunden werden.

Ein halbes Jahr später. Gegen den Artikel wurde juristisch vorgegangen und dummerweise auch noch zu recht. Das kann vorkommen. Wer weiß jetzt noch, an welche Systeme er denken muß, wenn er den Artikel unternehmensweit sperren möchte?

Er muß in unserem einfachen Beispiel „nur” an das CMS und ans Archivsystem. Vielleicht gibt es aber auch noch eine Bilddatenbank, in der ein zum Artikel gehörendes Bild liegt, welches ebenfalls gesperrt werden muß? Und was passiert, wenn dieser Artikel nun in mehreren Publikationen im Konzern benutzt wurde?

Mir kam bei der Diskussion so der Gedanke, daß das Problem eigentlich sehr ähnlich dem der Benutzerrechte vor Einführung von LDAP sein könnte. Es fehlt eine zentrale Unternehmensdatenbank, in der solche Informationen, die über Systemgrenzen hinweg wichtig sind, gespeichert werden können. In der jede Anwendung Informationen darüber findet, ob Artikel juristisch unbedenklich sind, welche Rechte an Bildern das Unternehmen eigentlich hat, wann diese Rechte auslaufen und so weiter.

Damit ein Administrator wirklich nur noch in einem System den Vermerk „Artikel darf nicht mehr verwendet werden” oder „Bildrechte abgelaufen” setzen muß und sicher sein kann, daß diese Inhalte dann auch wirklich nicht mehr verwendet werden.

Seit der IFRA 2008 bin ich überzeugt, dass mein lieber Kollege Ralf etwas tolles geschaffen hat. Zahara. Vor einigen Jahren begann er eine Idee umzusetzen. Er entwickelte so nach und nach eine Blattplanungslösung. In seiner Freizeit selbstverständlich. Ist ja Hobby, oder Arbeit, oder was? Egal, man merkt das er stolz darauf ist. Kann er auch sein. Was der Name Zahara bedeutet, das ist ein Ort in Portugal, da machte Ralf „Urlaub“ als alles begann.

Und damit alle erfahren was er da geschaffen hat, wird er es demnächst bestimmt mal kurz beschreiben, im Urlaub oder am Wochenende, oder….

Ein wichtiges Hilfsmittel bei der täglichen Arbeit sind „Foren”. Zu vielen Gebieten existieren virtuelle Marktplätze, auf denen sich Benutzer austauschen. Je enger das Fachgebiet, desto nützlicher sind sie. Ein Forum, das ich häufig besuche, ist das Adobe-InDesign-Scripting-Forum. Sehr häufig werden da Fragen diskutiert, die mich auch gerade interessieren. Hier kann ich Fragen stellen und erhalte erstaunlich oft genau die Antwort, die mir bei einem Script weiterhilft. Und natürlich ist es auch befriedigend einem „Fellow Scripter” zu helfen, der sich mit einem Problem herumschlägt, das man zufällig gerade gelöst hat.
Heute rief mich ein Kollege an, der ein Problem mit einem meiner Scripte hatte. Es handelte sich um eines meiner ersten Javascripts, das ein InDesign-Dokument automatisch „tagt” und so für einen XML-Export vorbereitet. Das Script war noch für CS1 geschrieben und sollte nun unter CS3 laufen. Ich hatte noch vage in Erinnerung, dass ein Scriptbefehl unter CS3 nicht mehr funktionierte und zwar der Befehl „autoTag()”. (Damit wurden die auf Tags „gemappten” Stilvorlagen auf das Dokument angewendet.) Irgendwas hatte sich da mit CS3 geändert. (Die InDesign-Scriptsprache ist meistens rückwärtskompatibel, aber eben nicht immer.)
Nun hätte ich natürlich in der Dokumentation nach dem neuen Befehl suchen können, aber ich dachte, über das Forum geht es schneller.
Also den Suchbegriff „autoTag” eingegeben und auf Suche geklickt. Und tatsächlich, der zweite zu diesem Begriff gefundene Treffer war ein Beitrag mit dem Titel: „[CS3] What happend to autoTag?”
Sehr gut, und es war genau meine Frage. Kein Wunder, denn der Autor des Beitrags war - ich.
Aber noch besser, es gab auch eine Antwort auf die Frage. Der Befehl heisst jetzt: mapStylesToXMLTags(). Und wer war der gute Mann, der die Antwort gegeben hat? Auch ich! Hatte ich total vergessen. Manchmal muss man sich doch selbst helfen.

Bis zur Version 5.9.0.1 des SoftCare K4-Redaktionssystems wurden die Seriennummern für Adobe InDesign CS2/3 und Adobe InCopy CS2/3 zur Lizensierung der Plug-Ins benötigt. Mit der Veröffentlichung des Updates auf die Version 5.9.1 hat SoftCare dieses Lizensierungs-Verfahren geändert.

Die Plug-Ins werden nun auf den Namen des Unternehmens lizensiert, das SoftCare K4 verwendet. Damit können die K4- und SoftCare-Plug-Ins zukünftig wesentlich flexiber eingesetzt werden. Eine Angabe von kundenbezogenen Seriennummern ist nur noch für den Adobe InDesign CS2/3 Server notwendig.

Die Lizenzinformationen werden zukünftig in “Über…-Dialogen” und Paletten angezeigt, die mit SoftCare oder K4 in Verbindung stehen:

K4 Plug-In

Abfrage-Palette:
Das K4 Plug-In ist auf den Kundennamen lizensiert. Dieser wird unten rechts in der Abfrage-Palette angezeigt.

Über K4… (K4Layout/Edit-Menü):
Zeigt ebenfalls den Lizenznehmer an. Darüber hinaus werden die Anzahl der Lizenzen aus der Lizenzdatenbank, die Datenbank- und Client-Treiberversionen sowie die Namen der verwendeten Datenbanken angezeigt.

K4 Revision Manager 5.9.1

Über Revision Manager… (Hilfe/Über Zusatzmodule/SoftCare…):
Der K4 Revision Manager ist auf den Kundennamen lizensiert. Dieser wird im Über…-Dialog angezeigt. Ebenfalls wird dort die Anzahl der erworbenen Lizenzen angezeigt.

Die Lizensierungs-Information ab den Versionen SC Notes Manager 3.1 und SC Overset Manager 5.1 können wie folgt ermittelt werden:

Palette:
Das SC Notes Manager und das SC Overset Manager Plug-In ist auf den Kundennamen lizensiert. Dieser wird unten rechts in der jeweiligen Palette angezeigt.

Über…-Dialog:
Zeigt ebenfalls den Lizenznehmer an. Darüber hinaus wird die Anzahl der erworbenen Lizenzen angezeigt.

Für die Plug-Ins, die zur Anbindung des Adobe InDesign CS2/3 Servers benötigt werden, hat SoftCare das bestehende Lizensierungs-Verfahren beibehalten. Hierfür werden die Seriennummern weiterhin in die Plug-Ins eingetragen und diese damit an eine bestimmt Applikation gebunden.

InDesign CS 3 und das K4-System ab Version 5.7 kamen mit neuen Funktionen heraus, die das Leben von uns Systemintegratoren einschneidend veränderten. InDesign unterstützt „EventScripting” und K4 erlaubt erstmals, K4-Funktionen über Scripts auszulösen. Nahezu jede Funktion in K4, die bisher manuell über Auswahl von Menüs und Ausfüllen von Dialogen angestoßen wurde, lässt sich jetzt „scripten”. Scripts können zum Beispiel alle Bilder eines Layouts einchecken oder Artikel aus einer Ausgabe ausschneiden und in eine andere einfügen.

Während bisher ein Script ausschließlich über das Klicken auf das Script in der Scripts-Palette aufgerufen wurde, so bedeutet EventScripting, dass ein Script über ein InDesign-„Event” ausgelöst wird. Ein solches Ereignis kann beispielsweise das Drucken einer Seite sein. Wird eine Seite gedruckt, kann ein Script eine zusätzliche Ebene mit Informationen anlegen und nach dem Drucken wieder löschen. Ein „Event” ist auch der Aufbau des Menüs beim Starten des Programms. Das lässt sich abfangen und der Scripter hat die Möglichkeit, eigene Menüs hinzuzufügen. (Übrigens sage ich absichtlich Script und nicht Skript und Scripts und nicht Skripten, obwohl das so im deutschen InDesign heißt - aber das wäre ein Thema für ein anderes Mal.)

Die Möglichkeiten sind nahezu unbegrenzt. In der Praxis stößt man aber doch auf Grenzen, die es zu überwinden gilt.

Letzte Woche wollte ich ein Script schreiben, das dafür sorgt, dass ich beim Start von InDesign automatisch am K4-System angemeldet werde. Natürlich hat das Anmelden und die Eingabe eines Kennwortes seinen guten Sinn, aber lästig ist es doch, und besonders in den Fällen, wo ein Rechner mit einem K4-System ohne Benutzer arbeitet (MadeToPrint), sollte ein Neustart dazu führen, dass alles wieder funktioniert.

Das Anmelden per Script ist einfach genug:

         app.k4LogIn(”rf”,”meinGeheimesKennwort”);

Das ist JavaScript-Syntax. (Auch AppleScript und VBScript sind möglich.) Kopieren Sie die Zeile in Textdatei, fügen Sie dabei Ihren Namen und Ihr Kennwort ein, sichern Sie die Datei als „autologin.jsx” und legen Sie die im Scripts/Scipts-Panel-Verzeichnis ihres InDesign-Programms (funktioniert auch mit InCopy) ab.

Klicken Sie in der „Skripten”-Palette auf autologin.jsx und Sie sind angemeldet. So weit, so gut. (Tatsächlich gehört noch zusätzlicher „Fehlerabfangcode” in das Script, denn Sie wollen keine hässliche Fehlermeldung sehen, wenn Sie schon angemeldet waren. Aber das führt zu weit.)

Aber damit sind wir nicht am Ziel, denn wir wollen ja sofort angemeldet sein, wenn InDesign startet. Nun gibt es im Scripts-Verzeichnis auch noch einen Ordner Startup-Scripts. Und tatsächlich, wie der Name vermuten lässt, werden Scripts in diesem Ordner von InDesign beim Start ausgeführt. Leider funktioniert das mit unserem Script nicht. Es sieht so aus, als wäre das K4-Plug-in noch nicht vollständig geladen, wenn InDesign die Startup-Scripts ausführt. Was tun? 

Könnte man das Script an ein Event hängen? Auch hier blieben zunächst alle Versuche fruchtlos. Egal ob ich Menuaufbau-Event (des K4-Layout-Menüs) oder Menuaction-Event abfing, ob „onInvoke” oder „beforeDisplay”, immer bekam ich die K4-Meldung, dass eine Anmeldung nicht möglich sei. 

Schließlich versuchte ich es mit einem „AfterNew”-Event. Das bedeutet, dass ein Script aufgerufen wird, wenn in InDesign ein neues Dokument angelegt wird. Und siehe da, ich bin angemeldet!

Die Lösung ist nicht besonders schön, funktioniert aber: Ein AppleScript-Programm startet InDesign, erzeugt ein neues Dokument und schließt es, ohne zu sichern.

activate “Adobe Indesign CS3″
tell application “Adobe InDesign CS3″
  set temp to make document with properties {showing window:false}
  close temp saving no
end tell

Voila. Dieses Programm liegt jetzt unter Startprogramme. Mit dem Einschalten des Rechners startet InDesign und meldet mich an. War doch gar nicht so schwierig.

Das AfterNew-Script (wie gesagt, gehört ins Startup Scripts-Verzeichnis) sieht so aus:


/***************************************************************************/
/* Projekt:              */
/* Datei:  AfterNew.jsx        */
/***************************************************************************/
/* Datum: Wer: Was:                                       */
/* 12.06.2008 RF Start                     */
/* © Snap Innovation
/* Script erzeugt “EventListener” für die Session.
/* Script soll im Start up Verzeichnis des Scripts-Ordner liegen
/********************************************************************/

#targetengine “session”
main();
function main(){
var myEventListener = app.addEventListener(”afterNew”, TryLogIn, false);
}
function TryLogIn(myEvent)
{
try
{
app.k4LogIn(”Name”,”password”);
}
catch(e){};
}