FrameMaker

Vor gut einem Jahr habe meine Meinung zu diesem schon einmal? kund getan.Aktuell läuft im Adobe FrameMaker Forum eine Diskussion zu diesem Thema. Wird sicherlich spannend. Viel Spass.

Immer wieder erhalte ich in verschiedenen Projekten beim Öffnen von FrameMaker-Dokumenten die Meldung, dass der Font Symbol Bolded nicht verfügbar ist. Selbst mit einem „MIF-Wash“ (Speichern als MIF und erneutes öffnen) ist die Meldung nicht wegzubekommen. Im gesamten Dokument wird nirgendwo ein der Font Symbolauf Bold eingestellt, weder auf den Vorgabeseiten noch im Textfluss. Und jetzt geht die Fehlersuche los.
Im Dokument ist ein Zeichenformat Symbol definiert. Bekanntlich unterstützt der Font Symbol keine Fettauszeichnung. Verwende ich nun dieses Zeichenformat in meinem Textfluss, sind zunächst keine Fehler erkennbar, auch FrameMaker meldet zunächst keine Probleme.
Erst wenn ich eine Überschrift, die fett dargestellt ist, erstelle und dort ein Zeichen aus dem Symbolzeichensatz einfüge und mittels dem Zeichenformat Symbol auszeichne, erhalte ich die lästige Fehlermeldung.
Dem Absatz wird also eine Fettmarkierung zugewiesen und das wirkt sich scheinbar auch auf den Symbolbereich aus. Grund dafür ist, dass die Schriftstärke auf Beibehalten eingestellt ist. Dadurch wird die Schriftstärke des Absatzformats auf den Symbolbereich „vererbt“. Deshalb muss die Schriftstärke speziell beim Symbolfont explizit auf Regular eingestellt werden. Nach dieser Änderung, war dann auch die Meldung über fehlende Schriftarten beseitigt.

Seit der Unterstützung von Unicode mit Adobe FrameMaker 8, können bei der Dokumenterstellung auch sogenannte "Global Fonts" wie "Arial Unicode MS" eingesetzt werden. Diese Fonts decken einen weiteren Bereich des Unicode-Standards ab. Der Einsatz eines solchen Fonts ist aus qualitativen Gründen durchaus fraglich, wie die Ausarbeitung von Michael Müller-Hillebrand aufzeigt, und im Regelfall besser auf sprachspezifische Fonts, gerade für ostasiatische Sprachen, zurückgegriffen wird. Dennoch können Gründe, die sich aus Prozessüberlegungen heraus ergeben können, durchaus für den Einsatz eines allgemeinen, globalen Fonts sprechen. Obwohl Editoren wie MS Word und Adobe Indesign diese Fonts mit einer korrekten Silbentrennung unterstützen, unterstützt FrameMaker diese Fonts zwar, unterdrückt allerdings die Silbentrennung. Grund dafür ist, dass FrameMaker die verwendeten Fonts auf das Vorkommen von ostasiatischen Schriftzeichen prüft, und einen globalen Font als ostasiatische Schriftart einstuft. Dies führt dazu, dass Wörter in westlichen Sprachen, die Umlaute oder besser Zeichen oberhalb des ASCII-Bereichs beinhalten, nicht getrennt werden. Ein versteckter Konfigurationseintrag bietet ab FrameMaker 10 Abhilfe: Wenn Sie diesen Eintrag in der maker.ini in der Sektion "Preferences" hinzufügen, wird die Silbentrennung auch für diese Schriftarten aktiviert.

Mit FrameMaker 9 bietet FrameMaker eine neue Struktur der Toolbar-Konfiguration an. Klaus Daube hat dies in seinem Dokument hinsichtlich der Konfiguration für die Standardmenüs sehr eindrücklich beschrieben. Auch FrameMaker Engineer Amit Agarwal hat in seinem Blog diesen Punkt etwas näher beleuchtet. Was ist aber mit unseren geliebten Menüs und Kommandos, die verschiede FDK-Clients und FrameScripts liefern. Versucht man die Namen der Befehle in den entsprechenden XML-Konfigurationsdateien zu hinterlegen, wird man schwer enttäuscht. Schade es könnte doch so einfach sein. Wieso funktioniert das nicht? FrameMaker lädt die Toolbarkonfiguration bevor alle weiteren Plugins und Scripts geladen werden. Somit sind die Befehle (Fcodes) zu diesem Zeitpunkt noch nicht bekannt. Befehle die konfiguriert aber noch nicht bekannt sind, ignoriert FrameMaker einfach. Ich würde diesen Beitrag nicht schreiben, wenn es nicht doch irgendwie möglich wäre, FrameMaker an dieser Stelle "auszutricksen". Beginnen wir von vorne. Wir schreiben einen FDK-client, der nichts weiter macht als einen Befehl (command) in FrameMaker anzulegen. Er benötigt dafür nicht mal ein Menü, denn er könnte beispielsweise über einen Shortcut oder jetzt dann über einen Toolbar-Button aufgerufen werden. Den Code welcher der Befehl bei Auslösen ausführt, sparen wir uns dabei. Als nächstes spendieren wir diesem Befehl ein Icon, welches in der Toolbar erscheinen soll. Es hat idealerweise eine Größe von 18x18px. Diese Grafik nennen wir MyCommand.png und legen diese im Verzeichnis $FMHome\fminit\toolbar\ ab.

In meinem Beitrag vom 20.06.2010 habe ich die Silent-Installation zu FrameMaker und zur TCS 2.0 beschrieben bzw. auf die Seiten bei Adobe verwiesen. Wie sich herausgestellt ist die Beschreibung zur TCS2.0 etwas daneben, um nicht zu sagen, nicht zu gebrauchen. Etwas tricky war es schon dahinter zukommen, da auch Hinweise im Forum nicht korrekt waren oder vielleicht ein anderer Installer vorlag. Wer weiß. Hier in jedem Fall eine kurze Anleitung, wie das Paket zur Softwareverteilung vorbereitet werden kann.

Setup vorbereiten

Wenn Sie die TCS als DVDs vorliegen haben, verteilt sich die Installation auf 2-3 DVDs. Diese Inhalte müssen auf die Festplatte oder ein Netzlaufwerk (würde sich anbieten) kopiert werden, wobei darauf zu achten ist, dass der TCS-Ordner überschrieben wird, und so alle Abhängigen im selben Verzeichnis vorliegen. Bei der manuellen Installation wird nach der 2. oder 3. DVD gefragt. Im Silentmode bricht der Installer einfach ab, wenn die Ressourcen nicht gefunden werden.

Deployment vorbereiten

Mittels des Aufrufs kann über die Setup-Oberfläche das Deployment.xml erstellt werden (Pretty cool wie RJ Jacques allgemein zu sagen pflegt). Sie werden wie bei der manuellen Installation durch das Setup geführt und können, die zu installierenden Komponenten auswählen. Im Anschluss wird dann nicht installiert sondern nach einem Ordner für die XML-Datei gefragt. Dies ermöglicht sogar die Erstellungen unterschiedlicher Deployment-Pakete, wenn zuvor die erstellte Deployment.xml umbenannt wird. Für die Deinstallation der TCS gehen Sie genau gleich vor. Allerdings müssen die Pakete dann bereits installiert sein, bevor Sie das XML für die Deinstallation erstellen können. Auch ein Reparieren der Software ist über diesen möglich. Also nochmals: Pretty cool.

Kommandozeile

Wichtig sind, warum auch immer, die ungewohnten zwei führenden Bindestriche vor den Parametern und das Leerzeichen nach --silentinstall. Den Pfad zum deployment.xml würde ich zudem immer mit Anführungszeichen umschließen. Der Dateiname muss nicht zwingend als deployment.xml benannt sein. Gerade dann nicht wenn unterschiedliche Rollouts oder Deinstallationen gefahren werden müssen. So und jetzt frohes installieren!

In meinen Projekten und Aufgaben stellt sich in der letzten Zeit für mich vermehrt die Frage, ob ich bei der EDD-Entwicklung in Adobe FrameMaker in der Absatzformatsteuerung mit Absatzformaten oder mit Formatänderungslisten arbeite. Ehrlich gesagt habe ich sie seit geraumer Zeit für mich beantwortet. Immer mehr komme ich zur Überzeugung, dass die Verwendung von Absatzformaten zwar dem Redakteur oder auch dem Template-Entwickler mehr Freiheiten gibt, auf der anderen Seite aber teilweise zu unnötig und höllisch komplexen und damit überfrachteten Element-Definitions-Dokumenten (EDDs) führt. Aber nicht nur die überfrachteten EDDs auch die Sinnhaftigkeit der Anforderung, Templates durch Redakteure oder "Template-Designer" individuell außerhalb der Steuerung durch die EDD anpassbar zu halten, stelle ich in Frage. Im folgenden möchte ich meine Gedanken in einem, zur Illustration der Problemstellung, etwas idealisierten Szenario darstellen. Natürlich kann man das in der Praxis insgesamt noch vereinfachen. Das soll aber nicht das Ziel dieses Beitrags sein.

Ausgangssituation des Szenarios

• Dokumentation in einem Format (A4) wird in 5 Sprachen erstellt (deutsch, englisch, französisch, russisch, chinesisch)
• Strukturierter FrameMaker. Struktur bereits definiert und produktiv eingesetzt
• Absatzformatzuweisung innerhalb der EDD
• Keine sprachabhängige Steuerung von Fonts und den jeweiligen Spracheinstellungen
• Je Sprache ein Template zur Font und Sprachsteuerung (Silbentrennung, Rechtschreibprüfung etc.)

Neue Anforderungen

• 3 weitere Formate (A3, A5, A6)
• Spracherweiterung auf 30 Sprachen
• Basis ist die selbe Strukturdefinition (DTD), welche auch für die neuen Formate passt.

Das folgende Beispiel soll in den folgenden Lösungsszenarien, den Unterschied der unterschiedlichen Ansätze illustrieren: Beispiel: Eine Überschrift soll fett und nummeriert mit einer Schriftgröße von 14pt dargestellt werden. Es wird das Absatzformat oder die Formatänderungsliste "Heading1" im Template bzw. der EDD definiert und dem Element Head zugewiesen. Im Japanischen soll der Font MS Gothic verwendet werden.

Lösungszenario 1

Die Umsetzung erfolgt auf die bisher umgesetzte Weise. Dies hat dann zur Folge, dass keine Anpassungen an der EDD notwendig werden. Es werden die Templates für die 3 neuen Dokumentformate erstellt und anschließend die Templates für alle Sprachen kopiert, so dass in diesen die entsprechenden Schriften und Spracheinstellungen vorgenommen werden können. Dies führt somit zu 4x30=120 Templates, die vom Redakteur oder "Template-Designer" erstellt und im weiteren auch gepflegt werden müssen (in der Praxis sind das natürlich etwas weniger). Der Vor- oder Nachteil (abhängig vom Standpunkt des Betrachters) ist weiterhin: Redakteure haben bei der Erstellung Ihrer Dokumentation weiterhin die Möglichkeit Absatzformate individuell anzupassen und somit Einfluss auf das jeweilige Layout. Ob dies weiterhin CI-konform ist, liegt in der Verantwortung des jeweiligen Redakteurs. Der Nachteil dieser Herangehensweise ist aber aus meiner Sicht ganz klar. Eine Pflege und Konsistenz dieser Templates wird zwar nicht unmöglich (FrameMaker unterstützt durch entsprechend Importfunktionen) aber sehr aufwändig und aus meiner Sicht nicht wirklich handhabbar. Erläuterung am obigen Beispiel In 120 Templates wird das Absatzformat Heading1 definiert, in dem abhängig von der jeweiligen Sprachgültigkeit die Schrift- und Spracheinstellungen gesetzt werden.

Lösungsszenario 2

Die Schrift- und Spracheinstellung werden abhängig von einem Attribut Language am Root-Element der Dokumentationsstruktur gesteuert. In den Templates definierte Absatzformate steuern aber weiterhin das Layout der Dokumentation. Erläuterung am obigen Beispiel Wird im obigen Beispiel eine japanische Dokumentation erstellt (Attribut language=JA), wird der Font "MS Gothic" und die Sprache "Japanese" eingestellt und die Definition des Absatzformats überschrieben. Hierdurch reduziert sich natürlich die Anzahl der Templates erheblich, nämlich von den erwähnten 120 auf genau 4. Die Möglichkeit der individuellen Steuerung des Layouts durch den Redakteur bleiben - mit den beschriebenen Vor- und Nachteilen - weiterhin erhalten. Durch dieses Vorgehen stellt sich für mich aber ein weiteres Problem. Es ist zwar kein technisches Problem, aber ein Problem hinsichtlich der Gestaltung und unnötigen Überfrachtung und somit der Wartbarkeit der EDD: Bei jedem Element, bei dem sich Absatz oder Zeichenformat ändern, muss für 30 Sprachen, die Schrift und die Spracheinstellung abhängig vom Attribut Language des Root-Element angepasst werden. Also jedes Mal 30 Kontextregeln, die die Einstellungen aus dem Absatz-/Zeichenformat entsprechend wieder überschreiben. Die folgende Regel wird also bei jeder Änderung des Absatzformats benötigt: Das Ergebnis: Eine EDD von mehreren 100 Seiten (abhängig natürlich von der Komplexität der jeweiligen Strukturdefinition und den Ansprüchen an das Layout), welche die Layout- und Strukturengine in FrameMaker erst einmal verarbeiten muss. Eine Erweiterung der EDD um eine zusätzliche benötigte Sprache bedarf der Anpassung fast aller Textformatregeln und ist entsprechend aufwändig.

Lösungsszenario 3

Nicht nur die Schrift- und Spracheinstellungen sondern sämtliche Absatz- und Zeichenformatierungen werden kontextabhängig in der EDD über Formatänderungslisten und nicht mehr über in Templates definierten Absatzformaten gesteuert. Erläuterung am obigen Beispiel Durch dieses Vorgehen bleibt die Anzahl der notwendigen FrameMaker-Templates bei 4 und die EDD verfügt nur über die absolut notwendigen Formatanweisungen. Der Nachteil (meine Sichtweise), dass Redakteure individuelle Formatänderungen in der konkreten Dokumentation vornehmen können und so ggf. vom definierten CI abweichen ist nicht mehr gegeben. Denn durch das Nachladen der EDD können manuell vorgenommene Formatänderungen jederzeit wieder zurückgesetzt werden. Bei der Verwendung von Absatzformaten ist dies nicht möglich. Durch diese Herangehensweise wird nicht nur die EDD schlanker, sie wird auch wartbarer, denn man benötigt die sprachabhängige Überschreibung von Formaten nur an den in der Struktur zulässigen Root-Elementen (Highest-Level-Elementen und an Elementen vom Typ Tabellen. Eine Erweiterung um eine zusätzliche Sprache ist dann eine Sache von wenige Minuten und nicht fehleranfällig.

Wo liegt also der Unterschied von Absatzformaten zu Formatänderungslisten

Der Unterschied ist eigentlich ganz einfach zu erklären. Weise ich über die EDD Absatzformate zu, werden immer sämtliche Einstellungen der Absatzformate dem jeweiligen Absatz zugewiesen. Eine Vererbung von Einstellungen aus übergeordneten Formatzuweisungen wird an dieser Stelle ausgehoben. Alles was über Absatzformate (und Zeichenformate) definiert werden kann, kann in der EDD über Formatänderungslisten abgebildet werden. Absatzformate werden somit in den Templates überflüssig, ausgenommen, den von FrameMaker selbst vorausgesetzten. Diese können aber bei einer konsequenten Umsetzung des letzten Lösungsszenarios getrost ignoriert werden. Verwendet man Formatänderungslisten, wird es möglich nur ausgewählte Einstellungen an einem Absatz zu ändern; sei es nun in diesem Fall die zu verwendende Schrift oder z.B. das Einschalten der Nummerierung in Listen oder Überschriften. Alle anderen Einstellungen der Absatzformate werden im Dokument nach unten vererbt und bleiben somit vollständig erhalten.

Auswirkung des konsequenten Einsatzes von Formatänderungslisten

Durch den konsequent umgesetzten Ansatz auf Basis von Formatänderungslisten wird das gesamte Layout der Dokumentationen über die EDD gesteuert. Eine Änderung von Absatz- und Zeichenformaten durch den Redakteur wirkt sich nicht mehr auf das Layout aus, da bei jedem nachladen der EDD, wieder das definierte Format zugewiesen wird. Sicherlich schränkt das die Freiheit des Redakteurs ein und bei Änderungen des Layouts wird etwas mehr Know-how in der Entwicklung von EDDs benötigt. Aber ist das schlimm? Nein!!! Ich denke, die Vorteile im Änderungsmanagement hinsichtlich Wartbarkeit der Templates gleichen diese minimale Einschränkung bei weitem aus. Zudem wird dem schon lange propagierten Ziel beim Einsatz strukturierter FrameMaker-Dokumente (also von XML), dass sich Redakteure nicht mehr um das Layout kümmern sollen/müssen, Rechnung getragen. Der Fokus der Arbeit eines Redakteurs liegt für ihn auf der Erstellung von Inhalten und nicht auf deren Formatierung. Zudem sollen Dokumente immer gleich formatiert sein und somit dem CI des jeweiligen Unternehmens genügen. Freiheiten des Redakteurs in der Gestaltung von Dokumenten sind in dieser Hinsicht gefährlich. Sicherlich lassen sich nicht alle Besonderheiten und Eventualitäten über die EDD steuern. Das gelingt aber auch nicht beim konsequenten Arbeiten mit Absatzformaten. Im Finishing-Prozess können hier gerne manuelle Zeilen- und Seitenumbrüche eingefügt werden. Die Layoutvorgaben sollten aber unberührt bleiben und durch ein finales Nachladen der EDD sichergestellt werden.

Das würde ich mir jetzt noch Wünschen

Das Konzept welches hinter EDD liegt finde ich Klasse und hat sich über Jahre und Versionen hinweg mehr bewährt. Hinsichtlich der Steuerung von Absatz- und Zeichenformaten gibt es recht wenig auszusetzen. Aber das sind nicht alle Formate die im Template definiert werden können. Variablen-, Querverweis- und Tabellenformate sowie die Einstellungen für Grafiken und deren Positionierung können derzeit über die EDD nicht gesteuert werden. Gerade eine weitere Unterstützung auf dieser Ebene wäre in vielen Projekten aus meiner Sicht eine elegante Lösung, um dem Anwender auch an dieser Stelle manuelle Layout-Arbeiten abzunehmen. Heute muss dies recht aufwendig über die Attributierung der entsprechenden Elemente durch den Redakteur und über einen nachgeschalteten, mittels FrameScript oder FDK-Plugins automatisierten Prozess gelöst werden. Das könnte FrameMaker noch eleganter lösen. Ich freue mich auf eine rege Diskussion!

Seit FrameMaker 7.2 steht mit der automatischen Vorgabeseitenzuweisung ein Feature zur Verfügung, auf das ich in meinen Projekten nicht mehr verzichten möchte. Nachdem ein Dokument automatisch über XML-Import-Prozesse aufgebaut und layoutiert wurde, werden abschließend durch den Aufruf der Vorgabeseitenzuweisungsfunktionalität - abhängig von definierten Regeln - die richtigen Vorgabeseiten für die Umschlagsseiten, das Inhaltsverzeichnis und verschiedenste Inhaltsseiten zugewiesen. Was den bisherigen automatischen Prozess aber immer wieder etwas stört, ist die Meldung, ob die Vorgabeseiten auch wirklich zugewiesen werden sollen. An dieser Stelle muss der Anwender nochmals eingreifen. Ich habe ein kleines Plugin geschrieben, welches frei verfügbar ist und zum kostenlosen Download für Sie bereit steht. Das Plugin bestätigt automatisch folgende lästigen Meldungen:

• Automatische Vorgabeseitenzuweisung
• fehlende Grafiken können nicht dargestellt werden
• Fontinformationen haben sich geändert

Die Funktionaltität wurde mit Adobe FrameMaker 9 getestet und mittels Visual Studio 2010 entwickelt. Die Installation des VC Redistibutable Package (x86 x64 ia64) ist Voraussetzung dafür, dass das Plugin in FrameMaker geladen werden kann. Hinweise zur Installation des Plugins finden Sie nach dem Download in der Readme.txt, welche Teil des Zip-Pakets ist. Bei Bedarf erweitere ich die Funktionalität gerne, um weitere lästige FrameMaker-Meldungen automatisch zu bestätigen. Schicken Sie mir einfach eine eMail An dieser Stelle recht herzlichen Dank an Rick Quatro von Carmen Publishing Inc. für den hilfreichen Input im "Frame developer forum".

Im wieder kommt die Frage auf: "Wie können wir mit einer automatischen Softwareverteilung (z.B. NetInstall) zentralisiert FrameMaker installieren?". Hierzu ist ein parametrisierter Aufruf des Setups notwendig und teilweise eine Konfigurationsdatei dem Setup zu übergeben. Auf den Adobe Technotes sind für die unterschiedlichen FrameMaker-Versionen entsprechende Szenarien beschrieben: FrameMaker 8 FrameMaker 9 Technical Communication Suite Um eine Anleitung für andere Adobe Produkte zu finden: "silent install produktname" im Suchfeld auf einer der oben verlinkten Seiten eingeben und die Suche starten.

Linker-Fehler mit struct.lib

Das FrameMaker Development Kit ist noch mit der Visual Studio Version 2005 kompiliert. Dennoch ist es möglich, FrameMaker Plugins mit höheren Visual Studio Versionen zu erstellen. Mit Visual Studio 2010 bin ich auf einen Linker-Fehler gestoßen, wenn ich die struct.lib zur Erstellung von strukturierten Export- und Import-Clients in mein FDK-Projekte einbinde: linker fatal error: unresolved external symbol __set_sbh_threshold Der Linker-Fehler kommt daher, dass die Funktion ''_set_sbh_threshold" in den aktuellen MSDN-Bibliotheken nicht mehr implementiert wird, da die Funktion nicht mehr benötigt wird. Eine Abwärtskompatibilität ist damit nicht mehr gegeben, weshalb die FDK seitens Adobe für VS2010 speziell zur Verfügung gestellt werden muss. Ich hoffe, dass dies mit der nächsten FrameMaker-(FDK)-Version gegeben ist. Bis dahin, kann der folgende Workaround, das Problem lösen. Wird die folgende Zeile in den Quellcode eingebunden, lässt sich auch ein FDK-Client mit eingebundener struct.lib erfolgreich kompilieren. int __cdecl _set_sbh_threshold(size_t _NewValue) {return 1;} Ausser, dass der return Wert '1' zurückgeliefert wird, macht diese Funktion nichts. Nach den Ausführungen von Microsoft, ist das ab Windows 2000 nicht notwendig, da eben der Small Block Heap standardmäßig nicht benutzt wird. Ich konnte bislang keine Seiteneffekte feststellen. Den Workaround verwendet aber bitte jeder auf eigenes Risiko.

Immer häufiger wird gefordert, dass auf den Umschlagsseiten von Betriebsanleitungen oder anderer Dokumentation, die Artikelnummer des Dokuments als Barcode aufgebracht wird, um die Logistik in Verbindung mit dem eingesetzten ERP-System zu beschleunigen und die Dokumentation on demand zu liefern. Oft werden hierzu Barcode-Generatoren eingesetzt, welche die Artikelnummer in einen Barcode transformieren. Dieser Barcode wird als Grafik (z.B. im EPS-Format) in die Dokumentation eingebunden. Gerade aber in automatisierten Publikationsprozessen gestaltet sich die Integration der Generatoren in den Publikationsprozess etwas schwieriger, insbesondere dann, wenn die Artikelnummer, welche hinter dem Barcode liegt, im Publikationsprozess automatisiert ermittelt wird. Eine Alternative ist der Einsatz spezieller Barcode-Fonts. Durch die Verwendung eines Fonts ist es möglich, die Artikelnummer in den Textfluss einzufügen, und die Darstellung dem jeweiligen Font zu überlassen. Im Falle von Adobe FrameMaker, kann eine FrameMaker-Variable "Barcode" angelegt werden, welche mit dem jeweiligen String im Publikationsprozess gefüllt wird. Die Variable wird dann einfach auf der Vorgabeseite platziert, auf welcher der Barcode erscheinen soll. Im Publikationsprozess sind der Artikelnummer dann lediglich die Start- und Stop-Zeichen sowie die zu berechnende Prüfzimmer vor- bzw. nachzustellen. Die entsprechende Logik muss dann selbstverständlich in den Publikationsprozess integriert werden. In den Projekten, in welchem das Thema Barcode zu den grundlegenden Anforderungen gehören, wird auf Fonts von www.will-software.de gesetzt. Das Font-Paket unterstützt die verschiedensten Barcode-Formate, und somit auch die häufig genutzten Standards Code 39 und Code 128.

Start- / Stopzeichen, Prüfziffer

Der Artikelnummer, welche als Barcode angezeigt werden, sind zusätzlich zum Text Start- und Stopzeichen vor- und nachzustellen. Zudem erwarten einige Barcodes Prüfziffern, welche im Publikationsprozess zu berechnen ist. Weitere Informationen zu den Start- und Stopzeichen sowie zur Berechnung der Prüfziffern liefern die unten verlinkten Webseiten. Für Fragen stehen wir selbstverständlich auch zur Verfügung. Weiter führende Links http://www.barcodeman.com/info/c39_1.php http://www.barcodeman.com/info/c128.php3 http://www.adams1.com/39code.html http://www.adams1.com/128code.html http://www.hi-tier.de/Entwicklung/Technik/barcode_Code128.html http://www.directtools.de/wissen/barcode/barcode.htm http://de.wikipedia.org/wiki/Strichcode