Comet_pdf ist ein eigenständiges Programm zur Generierung von PDFs. Als Basis werden Dokumente verwendet, die mit Adobe® InDesign® und Comet-Plug-Ins erzeugt wurden. Für die Komposition der PDF-Dokumente können alle gängigen Comet-Technologien verwendet werden:

• Datenverbindungen zu ODBC-Datenbanken und SOAP
• Rahmen- und Text-Platzhalter
• Tabellenplatzhalter (seit v1.0 R7778)
• Gestaltungsregeln für Rahmen
• Tabellenaufbau
• cScript
• Nägel und Magnete
• Templates und Seitentemplates
• Produktaufbau
• DocWatch

Die Ausgabe des PDFs erfolgt mit Hilfe der PDFLib von PDFLib.com.

comet_pdf ist nicht InDesign®. Bevor Sie mit einem in InDesign® implementierten Projekt mit comet_pdf produktiv gehen, müssen das gesamte Projekt, alle Arbeitsschritte und alle Ergebnisse gründlich mit comet_pdf getestet werden. Eine Zusammenfassung bekannter Einschränkungen von comet_pdf finden Sie hier. Eine Liste der cScript-Funktionen und deren Verfügbarkeiten finden Sie hier.

Bitte prüfen Sie vor dem Druck Ihre PDFs sorgfältig! WERK II und Partnerfirmen übernehmen keinerlei Haftung für fehlerhafte Druckerzeugnisse oder Verzögerungen, die dadurch entstehen.

comet_pdf zeigt Ihnen die aktuelle Version und eine kurze Hilfe in den folgenden drei Situationen:

• Start ohne weitere Optionen
• Programm-Option -h
• Fehlerhafte oder unbekannte Programmoption

Version:
    comet_pdf v4.1.6 R27000, based on Comet 4.1.7 and PDFlib 9.2.0, 64bit

Usage:
    comet_pdf
        -c | --conn            path         [app_path]                   Path to connections.xml
        -l | --login           name         [empty]                      Entry for connection data in connections.xml
        -x | --cache           path         [app_path/XCache/Upid]       Path to XCache folder.
           | --config-cache                 [no]                         Cache downloaded config
        -v | --log             path         [empty]                      Write logfile
           | --logx            path         [empty]                      Write extra logfile for API calls
           | --logger          path         [empty]                      Logger configuration XML, full path or folder of log.xml
        -i | --in              path         [empty]                      Input file or template
        -o | --out             path         [empty]                      Output path for PDF
        -y | --layer           name         [Layer 1]                    Default layer for frames
        -u | --pdflog          name         [empty]                      Write log of PDFlib calls
        -p | --products        path         [empty]                      Path to products list (items.XML)
        -q | --product         string       [empty]                      One product id in format "1 0 0 ''"
        -t | --template        string       [empty]                      TemplateID (and position) in format "12 36.0 36.0"
        -e | --exec            ID           [0]                          Action to execute, keyword "place" or path to script
        -Q | --params          string       [empty]                      gParamN~ for script in option -e
        -g | --global          var=val      [empty]                      Temporary change a global variable of the pool
        -L | --launch                       [off]                        Auto launch resulting PDF
        -N | --nolaunch                     [off]                        Suppress auto launch resulting PDF
        -H | --config_path     path         [app_path]                   Folder with configuration files (change app_path)
        -H | --hyphens         path         [app_path/hyphenations]      Folder with hyphenation files
        -P | --psnames         path         [empty]                      XML file with font names
           | --fontfolders     path         [empty]                      XML file with more font folders
           | --fontfolder      path         [empty]                      Additional folder to search for fonts
        -E | --eps_esc         path         [empty]                      XML file with EPS escapes
        -V | --verbose         flags        [empty]                      Print internal infos, any of 'bcedioqrstw*X'
        -C | --crop                         [off]                        Crop pages, "l [t r b]", width of white strips in points
        -f | --folders         path         [empty]                      Additional image search path(s)
        -r | --xmlread         string       [classic]                    XML parser type : classic, optimized, fast
        -z | --pdfset          string       [empty]                      pdf preset
           | --pdfsets         string       [empty]                      list pdf presets into file
           | --compression     int          [9]                          0 (no compression), ..., 9 (best compression)
        -A | --annot                        [no]                         Draw annotations (Comet Notes)
        -a | --adorns          tofFuUepcih  [empty]                      Various kinds of adornments
           | --preview         string       [empty]                      Preview options (NOT USED FOR NOW)
           | --spreadwise                   [off]                        Spread wise export of pages
           | --autosave                     [off]                        Save the input w2ml to outpath.w2ml
           | --save            path         [empty]                      Save changes made on input W2ML to path
           | --metadata        int          [0]                          0  : Off,
                                                                         1  : Create
                                                                         2  : Preview groups
                                                                         4  : Zip
                                                                         8  : Next to w2ml
                                                                         16 : Next to PDF
                                                                         32 : Suppress
           | --docid           string       [empty]                      priint document id
           | --l_type          string       [empty]                      Login : type
           | --l_service       string       [empty]                      Login : service (path, name, or URL)
           | --l_user          string       [empty]                      Login : user name
           | --l_pwd           string       [empty]                      Login : password
           | --l_PWD           string       [empty]                      Login : password (crypted)
           | --l_db            string       [empty]                      Login : database
           | --l_client        string       [empty]                      Login : client
           | --crypto          string       [empty]                      Crypt password
        -m | --merge           path         [empty]                      path to xml to compose PDF file
           | --scriptin        path         [empty]                      path to script argument (gArgument) file
           | --scriptout       path         [empty]                      path to script result string (gOutput)
           | --pidstart        path         [empty]                      path to file indicating program start
           | --piddone         path         [empty]                      path to file indicating program end
        -j | --comet-api       path         [empty]                      path to XML with Comet API call
           | --interactive     string       [empty]                      Interactive PDF flags (1: on,2:tab order,4:article order)
           | --icc             string       [app_path/colorprofiles.xml] Path to colorprofiles.xml
           | --apply_icc       string       [off]                        Apply color profiles of document
           | --working_icc     string       [empty]                      name of working CMYK color profile for PDFX/4, 5 conform PDFs
           | --w2lic_path      string       [app_path/w2.lic]            path to priint:suite license (w2.lic)
           | --pdflic_path     string       [app_path/licensekeys.txt]   path to PDFlib license (licensekeys.txt)
           | --w2lic                        [no]                         Validate priint license : 0=DEMO, 1=Preview, 2=Okay
           | --pdflic                       [no]                         Validate PDFLib license : 0=Failed, 1=Watermark, 2=Okay
           | --no_bash_colors               [off]                        Suppress colored messages (usefull for output redirections)
           | --playback                     [off]                        Playback mode (off | record | on)
           | --playback_path   string       [empty]                      Path to playback data folder
           | --soaplog                      [off]                        if given, dump soap traffic to $DESKTOP/_soap*.log
           | --fontscale       float        [1.0]                        Scale text by the given amount (1.0 is 100%)
           | --urllink_update  keyword      [off]                        Update Web Images of input file (off | missing | all)
           | --update_path     string       [empty]                      Path to folder for update data -- since v4.1.5
           | --upr             string       [off]                        Write a Unix PostScript Resource (UPR) file only
           | --typographics                 [off]                        Use typographics quotas (on, off)
           | --awesome         path         [empty]                      Path to file with additional 'Awesome' icon names
           | --awesometest     fontname     [empty]                      Test this Awesome font (given by Postscript name)
           | --desttype        keyword      [pdf]                        Type of destination file (pdf, html)
           | --htmlhead        path         [empty]                      Path to additional html header stuff before </head>
           | --htmlfoot        path         [empty]                      Path to additional html footer stuff before </body>
           | --htmloptions     path         [empty]                      Path to file with html export options
           | --deepl           path         [empty]                      Path to file with deepl.com Authentication key
           | --lang            keyword      [empty]                      Destination language (EN, DE, FR, ES, PT, IT, NL, PL, RU)
           | --checkfonts      int          [0]                          Dump missing font definitions
                                                                         1 : psfonts C++
                                                                         2 : psfonts XML
                                                                         3 : fontdb C++
                                                                         4 : fontDB XML
           | --font-policy     int          [63]                         Allow / disallow font mapping, bitmap, see details below.
           | --report          path         [empty]                      Write document issues report to XML file.
           | --legalnotes                   [off]                        Show Legal Notes in browser
           | --lazyfit         int          [0]                          0 : Off, 1 : On - Avoid superflous FitFrames
           | --check-webimages int          [1]                          0 : Off, 1 : On - Should Web Images checked before use?
           | --unused-styles   int          [0]                          0 : Off, 1 : On - Show unused styles at the end
           | --linearize       int          [0]                          0 | no | off : Off, 1 | yes | on : On
           | --pdflayers       int          [0]                          0 | no | off : Off, 1 | yes | on : On
           | --debugpy         int          [0]                          Start the Python debuger server on this port.

           | --shorcuts        path         [app_path/shortcuts.xml]     Complete path to shortcuts XML (optionally with :name)
        -s | --shorcut         name         [empty]                      Name of shortcut in shortcuts XML

        -h | --help                         [no]                         Priints this help

Hints:
    Incomplete paths are resolved relative to the current application path.
    You may use the following abbreviations:

    \$DESKTOP             Your desktop folder
    \$HOME                Your home directory
    \$DOCUMENTS           Your documents folder
    \$CACHE               Current path to current XCache sub folder
    \$PLUGINS             Current path to comet_pd

Shortcuts:
    demo_build    Build some comics
    demo_place    Place one comic using action 120399
    demo_place2   Place one comic default placing

Examples:
    comet_pdf -s hello
    comet_pdf -s demo_build -L
    comet_pdf -s demo_place -L
    comet_pdf -s demo_place2 -L

Legal notes:
    Legal notes for used third party software see here:
    Path_To_Comet_Offline_Doku/enEN/legal_notes.html

Achtung: Unter Windows darf das $-Zeichen nicht \ maskiert werden!

Beachten zum Setzen der Programmparameter auch die Hinweise zu den Shortcuts.

Alle Programm-Optionen werden strikt in der Reihenfolge ihres Auftretens ausgewertet. Spätere Angaben überschreiben dabei vorangegangene. Einzige Ausnahme ist die Option -f. Hier werden alle Angaben addiert. Ebenso verhält sich die Shortcut-Option : Alle Optionen, die ein Shortcut enthält, überschreiben ältere Angaben. Leere Angaben im Shortcut setzen die entsprechende Option auf ihren Default zurück. Genauso ändern Optionen, die auf einen Shortcut folgen, die entsprechende Option erneut.

Verwende die im Shortcut test gemachten Einstellungen. Zum Schluß soll die erzeugte PDF-Datei gezeigt werden.

comet_pdf -s test -L

Als Connection-Name wird zuerst demo gewählt. Dann überschreibt der Shortcut test diese Einstellung möglicherweise. Die letzte Angabe setzt dann den Namen demo2. Und der wird dann verwendet.

comet_pdf -l demo -s test -l demo2

Eine weitere Ausnahme ist die Option -a. Diese Option ist additiv, d.h. mehrere Angaben werden addiert. Nur die Angabe <a></a> eines Shortcuts setzt den Wert zurück. Enthält ein Shortcut mehrere Definitionen zu <a></a> gewinnt auch hier die letzte.

Eine vollständige Liste der Änderungen am Programm finden Sie hier.

Produktlisten werden im gleichen Format wie für InDesign® Server übergeben. Sie können Produktlisten direkt in InDesign® erzeugen. Öffnen Sie dazu die Palette Produkte des Dokumentes und erstellen Sie dort die gewünschte Produktliste. Mit dem Button rechts unten in der Palette können Sie die erstellte Liste als XML sichern. Dabei öffnet sich zunächst der Dialog mit den Einstellungen für den Produktaufbau (ab v3.4 R5678). Hier sind fast alles Felder deaktiviert. Im oberen Bereich können die Optionen einstellen, die für den Produktaufbau relevant sind.

Natürlich können die Listen auch von einem externen Programm erstellt werden.

Hier eine Produktliste (items.xml) mit nur einem Produkt. Der erste Eintrag legt das zu verwendente Seitentemplate fest.

<?xml version="1.0" encoding="utf-8"?>
<items
	version="3.4"
	pluginRevision="5678"
	ref="document"
	documentID=""
	spreadID=""
	pageID=""
	groupID=""
	elementID=""
	importFlags="0x20000000"
	documentPath="/Users/paul/Desktop"
	documentName="aaa.indd"
	sMissingPlugIns="0"
	isConverted="0"
	isModified="0"
	isReadOnly="0">

	<item>
		<ID>1</ID>
		<ID2>0</ID2>
		<ID3>0</ID3>
		<stringID/>
		<pageitemID>0</pageitemID>
		<type>pagetemplate</type>
		<pageType>1</pageType>
		<layout_layers/>
		<document-position>-1</document-position>
		<groupID>0</groupID>
		<classID>3</classID>
		<status>normal</status>
		<elementID>0</elementID>
		<preruleID>0</preruleID>
		<preruleParams/>
		<postruleID>0</postruleID>
		<postruleParams/>
	</item>

	<item>
		<ID>1</ID>
		<ID2>1</ID2>
		<ID3>0</ID3>
		<stringID/>
		<pageitemID>1</pageitemID>
		<type>product</type>
		<pageType>-1</pageType>
		<layout_layers/>
		<document-position>-1</document-position>
		<groupID>0</groupID>
		<classID>3</classID>
		<status>inserted</status>
		<elementID>0</elementID>
		<preruleID>0</preruleID>
		<preruleParams/>
		<postruleID>0</postruleID>
		<postruleParams/>
	</item>
</items>

Optionen werden als Bitfelder erwartet. Die Werte können addiert werden.

Zur Unterstützung des Adobe Experiance Managers (AEM) können Produktlisten auch direkt aus dem Asset-Bestand eines AEM geladen werden. Kennzeichnen Sie den Pfad dazu durch mit dem Prefix aem@. Danach folgt die vollständige URL zur Produktliste. Ein Stern (*) am Ende der URL wird dabei automatisch durch documentId.txt ersetzt. documentId ist dabei die Dokument-ID der Eingabe-Datei.

Hier ein Beispiel für einen vollständigen Aufruf aus AEM:

comet_pdf
   -l demo
   -i ${file}
   -o${directory}\${basename}.pdf
   -p aem@http://admin:****@localhost:4502/content/dam/products-of-documents/*
   --metadata 16
   -v C:\Users\paul\Desktop\aaa.log

InDesign-Dokumente werden als Binärdateinen gesichert. Das Format dieser Dateien ist nicht öffentlich und kann (und darf) ausschließlich von InDesign^® gelesen und geschrieben werden. Wir haben deshalb als Austausch-Format das Format W2ML entwickelt.

Beachten Sie also bitte, dass InDesign-Dokumente von comet_pdf weder gelesen noch geschrieben werden können. Der Dokument-Austausch zwischen beiden Programmen erfolgt immer über W2ML.

Für Illustrator^® gibt es keine W2ML-Unterstützung.

W2ML enthält alle wichtigen Informationen eines InDesign^®-Dokumentes und kann von InDesign^® und comet_pdf gelesen und geschrieben werden. Eine Liste der bekannten Einschränkungen finden Sie hier.

So erzeugen Sie Dateien im Format W2ML:

Da comet_pdf die gleichen Datenverbindungen (und sogar die gleichen Implementierungen dafür) verwendet wie die Comet-Plugins (siehe auch hier), können Änderungen an Platzhaltern und anderen Aktionen direkt angewendet werden. Durch die Möglichkeit, beim Sichern von Templates auch die W2ML-Varianten der Templates zu aktualisieren, können auch Templates nach Änderungen in InDesign® direkt angewendet werden.

Das Format W2ML wird mit der Entwicklung von comet_pdf "mitwachsen". Es ist daher wichtig, dass die W2ML-Exporte mit einer genügend aktuellen Version der Comet-Plugins erstellt werden.

Version und Release der priint:comet Plugins, die ein W2ML erstellt haben, sind in der W2ML-Datei in den Attributen

    psc:elementlist.version und psc:elementlist.pluginRevision

in der ersten Zeile der Datei vermerkt.

Die Version von comet_pdf erhalten Sie, wenn Sie das Programm mit der Option -h oder ohne weitere Optionen aufrufen, siehe auch hier.

W2ML-Templates werden bei Plugin-Wechseln natürlich nicht automatisch aktualisiert. Alle Templates, die comet_pdf verwenden soll, müssen entsprechend aktualisiert werden.

Die folgende Tabelle enthält die neu hinzugekommenen XML-Attribute und das zugehörige Erscheinungsdatum:

W2ML kann (und wird auch nie) alle Features einer InDesign-Datei unterstützen. Hier eine Liste der bekannten Einschränkungen:

• Vektorbilder benötigen für comet_pdf eine besondere Behandlung. Mehr Informationen dazu finden Sie hier.
• comet_pdf verlangt benannte Freistellpfade. Die InDesign-Möglichkeit, Freistellpfade über ihren Index zu adressieren, wird von comet_pdf nicht unterstützt.
• InDesign^® kennt insgesamt über 300 Textattribute. Hier finden Sie eine Liste der von comet_pdf unterstützen Attribute.
• Interaktive Elemente in W2ML-Dateien können von InDesign^® nicht wiederhergestellt werden.
• InDesign-Dokumente mit Buttons der Palette Schaltflächen und Formulare -> Beispielschaltflächen und -formulare erzeugen W2ML-Dateien, aus denen comet_pdf keine PDFs mehr erzeugen kann. (Sie sollten diese Beispiele insgesamt sowieso eher nicht verwenden. Erstens sehen sie schrecklich aus. Und zweitens funktioniert auch der PDF-Export direkt aus InDesign nicht richtig.)

Basis formatierter Texte in comet_pdf ist verkürzter TaggedText (%!TT). Schriften werden dabei mit Hilfe des Schriftnamens und einem Stilnamen (Schriftschnitt) in zwei getrennten Tags festgelegt.

Typische Fonteinstellung für TaggedText

<cFont:WILO Plus Global><cTypeface:Italic>

Zur Darstellung der Schrift im PDF müssen beide Angaben zusammengefasst werden. Leider erwartet die verwendete PDFlib dabei systemabhängig unterschiedliche Schreibweisen:

• Mac : Postscriptname des Schriftschnittes einer Schriftfamilie
• Windows : Schriftname und -schnitt werden mit Leerzeichen und teilweise mit Komma getrennt
• Linux : Vollständiger Pfad der Font-Datei ohne Dateiendung

Es ist daher nötig, Zuordnungen zwischen den Schriftnamen für TaggedText und PDF festzulegen. Comet_pdf kann diese Zuordnungen an drei Stellen suchen. Spätere Zuordnungen überschreiben dabei frühere:

1. Fest eingebaute Standardliste : Comet_pdf enthält für Mac und Windows jeweils eine fest eingebaute Übersetzungliste mit den Namen der gebräuchlichsten Schriften und deren Stile. Linux verwendet die Mac-Definitionen. Die vollständigen Pfade zur Fontdatei werden dabei intern berechnet.
2. Defaults : Definitionen der Datei fontnames_default.xml im Ordner von comet_pdf.
3. Lokale Zuordnungen : Mit Hilfe der Programm-Option -P (--psnames) können weitere Zuordnungen für die aktuelle Ausführung des Programmes gemacht werden. Die Option erwartet den vollständigen (oder programm-relativen) Pfad zu einer XML-Datei.

Die XML-Dateien zum Beschreiben der Schriften müssen folgendes Format haben:

<?xml version="1.0" encoding="utf-8"?>
<fontnames>
	<!-- pswin, linux, asc and desc are optional -->
	<fontname
		id="ID_FONT ID_STYLE"
		ps="PDF_NAME"
		pswin="PDF_NAME_WINDOWS"
		linux="PDF_NAME_LINUX"
		asc="7.5" desc="2.05"
		/>
</fontnames>

Das Attribut id enthält den Schriftnamen bestehend aus Schriftfamilie und -schnitt. Beide Angaben werden dabei durch ein (!) Leerzeichen getrennt. Die Schriftfamilie ist der Inhalt des TaggedText-Tags cFont, der Schriftschnitt ist die Angabe aus cTypeface. Die Angaben sind identisch mit der Schriftanzeige in InDesign®.

Die Angaben pswin und linux werden jeweils nur unter Windows resp. Linux ausgewertet. Sie enthalten system-spezifischen Definitionen der Schrift. Fehlen die Angaben, wird der Wert des Attributes ps verwendet.

Die Angaben asc und desc sind ebenfalls optional. Fehlen die Angaben, werden von PDFlib ermittlete Werte verwendet. Mehr dazu siehe hier.

Ein Beispiel einer Font-Definition finden Sie hier.

[Seit v4.1.6 R26667] Schriften werden an den für das jeweilige Betriebsystem üblichen Stellen für Schriften gesucht : Fonts pulled from the Windows or OS X/macOS operating system (host fonts)., schreibt die PDFlib-Dokumentation dazu (PDFlib-Tutorial.pdf, Absatz Searching for Fonts). Etwas mehr Infos dazu finden Sie hier. Sie können Schriften aber auch an beliebig vielen anderen Orten suchen lassen. Verwenden Sie dazu die Option --fontfolders your_folders.xml.

Die XML-Datei muss folgendes Format haben:

<?xml version="1.0" encoding="utf-8"?>
<paths>
	<path name="$DESKTOP/folder1" intention='' />
	<path name="/Users/Du/MoreFonts" intention='' />
</paths>

Pfade müssen vollständig sein, dürfen aber mit den üblichen und definierten Alias-Namen beginnen. Die Suche nach Schriften wird in der Reihenfolge der Definitionen in der XML-Datei gemacht und ist nicht rekursiv.

Das Attribut intention wird seit v5.5 R37200 unterstützt. Das Attribut ist optional, aber wenn es verwendet wird, muß es in allen path-Elementen definiert sein! Folgende Angaben werden unterstützt:

• pdflib : Der Ordner wird nur für die Textausgabe des PDFs nach Schriften durchsucht.
• gs : Der Ordner wird nur bei der automatischen Konvertierung von (E)PS in PDF mit Hilfe von ghostscript verwendet.
• Leer oder Attribut fehlt: Der angegbenen Ordner wird für die Textausgabe und beim automatischen Konvertieren von (E)PS durchsucht.

In der Schreibweise --fontfolder fontfolder (ohne s) können Sie zusätzliche Schriftenordner auch ohne eine spezielle Konfigurations-XML festlegen. Auch hier sind Pfade mit Aliasnamen am Anfang erlaubt. (Achten Sie darauf, das $-Zeichen unter Mac und Linux mit \ zu maskieren!). Der Parameter kann beliebig oft angegeben werden. Die Ordner werden dann in der Reihenfoge der Parameter durchsucht und sowohl bei der Textausgabe als auch bei der automatischen Konvertierung von (E)PS in PDF durchsucht.

Generell finden Sie den richtigen Schriftnamen des Betriebsystemes so:

• Mac : 
  • Öffne das Programm Schriftsammlung
  • Schrift und Schriftschnitt auswählen
  • Menü Darstellung -> Schriftinformationen einblenden
  • Der Postkript-Name wird oben im Fenster angezeigt
• Windows Die Schriftschnitte werden an den Schriftnamen angefügt. Dabei gilt:
  • Bold und Italic werden durch Komma getrennt
  • Regular wird weggelassen
  • Alle anderen Schnitte werden durch Leerzeichen getrennt.
• Linux
  • Mit vi /etc/fonts/fonts.conf können Sie sehen, wo das System Schriften abglegt
  • Mit Doppelklick der Schriftdateien sehen Sie Schriften
  • Die Dateiennamen ohne Endung entsprechen den Postskript-Namen

Alternativ zu den oben beschriebenen Verfahren können Sie das Programm comet_pdf mit der Option --upr path starten. In diesem Fall werden alle verfügbaren Schriften des Rechners durchsucht und daraus eine sogenannte Unix PostScript Resource (UPR) Datei geschrieben. Dieser Datei können Sie den nötigen Namen der gesuchten Schrift entnehmen.

Schriften werden dafür an folgenden Orten gesucht:

• Mac : 
  • /Library/Fonts
  • /Users/name/Library/Fonts
• Windows
  • Der Font-Ordner des Systems, z.B. C:\Windows\Fonts
• Linux Wir werden demnächst die Angaben aus /etc/fonts/fonts.conf verwenden. Aktuell werden die beiden folgenden Ordner durchsucht:
  • /usr/share/fonts und alle Unterordner
  • /usr/share/texmf/fonts und alle Unterordner

Ist die Option --fontfolders gesetzt, wird ausserdem in allen Ordnern gesucht, die in der angegebenen XML-Datei festgelegt werden:

Hier ein Beispiel, bei dem auch in allen Ordnern, die in myfonfolders.xml defniert sind, nach Schriften gesucht wird:

comet_pdf --fontfolders myfontfolders.xml --upr uuu.txt

Bei Verwendung von PDFlib ab v9.0.6 können mit comet_pdf auch PDFs auf Chinesisch, Japanisch und in anderen sogenannten Multibyte-Schriften produziert werden. Mit PDFlib 9.0.4 funktioniert das Einbetten von Multi-Byte-Fonts leider nicht richtig - manche Zeichen werden gar nicht oder falsch dargestellt, und Acrobat gibt sogar eine Fehlermeldung aus.

Um zu überprüfen, ob eine Schrift richtig dargestellt werden kann, sollten Sie das PDF auf einem Rechner testen, auf dem die verwendeten Schriften nicht installiert sind. Es ist wichtig, die PDFs in verschiedenen Applikationen zu testen. Die Ergebnisse unterscheiden sich je nach Programm sehr stark, aber mindestens Acrobat Reader, Chrome, Firefox, Edge und Safari sollten richtige Ergebnisse zeigen.

Als Grundlinie für Texte wird, falls nichts anderes angegeben ist, die sog. Ascender Line der verwendeten Schrift(en) verwendet:

Merkwürdigerweise sind die von Werte für Ascender und Descender, die InDesign® und PDFLib aus den Schriften ermittlen aber icht immer gleich. Unterschiedliche Werte führen aber zu unterschiedlichen Zeilenhöhen in den Ausgaben von InDesign® und comet_pdf. Um diese Fehler zu verhindern, können den Schriften zusätzlich die Werte von Ascender und Descender mitgegeben werden.

Die Angaben erfolgen in den Attributen asc und desc der Fontname-XMLs und werden in Punkten relativ zur Schriftgröße 10.0 angegeben. Die Attribute asc und desc sind optional, fehlen die Angaben, berechnet comet_pdf Ascender und Descender mit Hilfe der PDFLib, sonst werden die festgelegten Werte verwendet.

Hier ein Beispiel:

<fontname
    id="WILO Plus Global Regular"
    ps="WILOPlusGlobal-Regular"
    asc="7.001953"
    desc="2.177582"
/>

Zum Bestimmen von Ascender und Descender können sie die Skriptfunktion system::font_info verwenden.

Das folgende Skript ermittelt Postscriptname, Ascender und Descender einer in InDesign®-Notation gegebenen Schrift.

int main ()
{
    char 	psname [512];
    float 	asc, desc;
 
    system::font_info ("WILO Plus Global Regular", 0, psname, &asc, &desc);
    printf ("%s, %f %f\n", psname, asc, desc);
    return 0;
}

Ab Comet 4.0.4 R7777 der Plugins können Sie dafür auch den InDesign®-Menübefehl

Plug-ins -> Produktrecherche -> Verschiedenes -> Fontinfo ... (Zusatzmodule statt Plug-ins in Versionen vor InDesign® 2025)

verwenden.

Wird der TaggedText-Name einer Schrift an den oben beschriebenen Stellen nicht gefunden, wird die Schrift Arial verwendet. Diese Einstellung kann überschrieben werden durch eine Definition des leeren ("") TaggedText Fontnamens.

Verwende die Schrift Geneva für alle TaggedText-Schriften, für die es keine Namensübersetzung gibt:

<fontname id="" ps="Geneva"/>

Mit der Angabe undef_ in ps (bzw. pswin oder linux) erzwingen Sie, dass keine Standardübersetzung verwendet wird:

<fontname id="" ps="undef_"/>

Nachdem Sie alle Schriftnamen von TaggedText in "PDF" übersetzt haben, kann es natürlich trotzdem sein, dass Sie die gewünschte Schrift gar nicht auf Ihrem Rechner haben. In diesem Fall verwendet comet_pdf ebenfalls automatisch die Schrift Arial. Sie können diese Einstellung ebenfalls in den fontnames ändern. Hier ein Beispiel:

Wird eine Schrift (nicht der Schriftname) nicht auf Ihrem Rechner gefunden, soll auf dem Mac automatisch die Schrift Desdemona verwendet werden. Unter Windows soll die Schrift Courier verwendet werden. Alle Texte, in denen diese Schriftersetzung verwendet wird, sollen rot eingefärbt sein.

<missing_font ps="Desdemona" pswin="Courier" color="red"/>

Auch hier ist die Angabe pswin optional. Fehlt sie, wird der Schrift aus dem Attribut ps verwendet.

Wenn Sie bei nicht verfügbaren Schriften die Bearbeitung abbrechen wollen, setzen Sie den Wert von missing_font.ps (bzw. pswin) auf leer ("") oder undef_. In diesem Fall wird keine PDF-Ausgabe erzeugt.

<missing_font ps="undef_" pswin="" color=""/>

Ist das Feld color leer ("") oder fehlt, wird die Textfarbe im PDF nicht verändert. Sonst wird Text in der angegebenen Farbe dargestellt. Für die Farbdefinition haben Sie vielfältige Möglichkeiten:

Falsche Farbangaben führen zum Abbruch der PDF-Generierung. Es wird keine Ausgabe erzeugt.

[seit R19501, 7.7.2017] Obwohl die Unterschiede in den Laufweiten der Texte zwischen InDesign® und comet_pdf nur sehr gering sind, können Textrahmen, die in InDesign® an ihren Inhalt angepasst wurden, in comet_pdf einen Textübersatz erzeugen. Rahmen, die mit frame::fit_better oder einer ähnlichen Methode in InDesign® . Mit der Option

--fontscale Kommazahl

können Sie erzwingen, dass im PDF sämtliche Schriften und Zeilenabstände so skaliert , dass keine Übersätze entstehen. Die Fontskalierung hat keinen Einfluß auf den Dokumentinhalt selbst.

Die Angabe der Skalierung muß eine punkt-getrennte reelle Zahl sein. 1.0 entspricht 100%.

Wichtiger Hinweis: Die folgenden Beschreibungen zur Behandlung von Schriften und der fontDB gelten für comet_pdf und priint:comet Plugins!

Die priint:comet Plug-ins und comet_pdf können neben TaggedText auch HTML-formatierten Text einfügen (html::to_tagged oder %!TT_html_). Besondere Behandlung benötigen dabei die (doch recht einfachen) Tags für Fettschrift (<b>, <strong>) und Italic-Schrift (<i>), die nur im Kontext einer Schrift aufgelöst werden können. Die Schrift ist aber in den meisten Fällen erst dann bekannt, wenn der Text ins Dokument eingesetzt wird.

Hier sehen sie einige Anwendungen von <b> und und <i> im Kontext verschiedener Schriften:

font-family:Helvetica Neue LT Std; font-stretch:condensed; font-weight:100;

Montage à base de 3 roulements, italicbolditalic corps trempé et rectifié , très haute précision de concentricité, défaut de concentricité maxi. 0,005, vitesse élevée, grande capacité de charge, graissée à vie, longue durée de vie.

font-family:Helvetica Neue LT Std; font-stretch:expanded; font-weight:100;

Montage à base de 3 roulements, italicbolditalic corps trempé et rectifié , très haute précision de concentricité, défaut de concentricité maxi. 0,005, vitesse élevée, grande capacité de charge, graissée à vie, longue durée de vie.

font-family:Helvetica Neue LT Std; font-stretch:normal; font-weight:400;

Montage à base de 3 roulements, italicbolditalic corps trempé et rectifié , très haute précision de concentricité, défaut de concentricité maxi. 0,005, vitesse élevée, grande capacité de charge, graissée à vie, longue durée de vie.

font-family:Courier;

Montage à base de 3 roulements, italicbolditalic corps trempé et rectifié , très haute précision de concentricité, défaut de concentricité maxi. 0,005, vitesse élevée, grande capacité de charge, graissée à vie, longue durée de vie.

Da die aktuellen Schrifteinstellungen erst zur Laufzeit bekannt sind, wird die Berechnung der richtigen Schrift für Bold und Italic erst direkt beim Einfügen ins Dokument gemacht. Neben der aktuellen Schrift muß man also auch die verfügbaren Schnitte einer Schriftfamilie und deren Eigenschaften kennen. Diese Informationen könnten direkt aus der Schriftdatei (ttf, otf, ttc, Type1, ...) gelesen werden. Wir haben das gemacht und mußten leider feststellen, dass rund 10% aller Fonts gravierende Fehler enthalten.

Da gibt es eigentlich nichts, was es nicht gibt: Mehrfache Weight-Angaben (nötig für <b>), fehlende Slants (nötig für <i>), falsche Stilnamen und manchmal fehlt die name-Table eines TrueType-Fonts ganz (z.B. verdana*.ttf auf Windows)

Wir haben uns deshalb entschieden, eine sogenannte fontDB zu integrieren. Diese "Datenbank" enhält zu jeder darin definierten Schriftfamilie eine Tabelle der verfügbaren Schriftschnitte:

Jede Zelle der Tabelle enthält dabei jeweils eine "Normal"schrift und eine Italic-Schrift.

Bei der Definition der fontD für eine Schriftfamilie werden zuerst die Einträge gefüllt, für die ein Schriftschnitt vorhanden ist. Da kaum eine Schrift (außer vielleicht einer NOTO-Schrift) alle 162 Schriftschnitte definiert hat, wird die Tabelle danach anhand der bereits eingetragenen Stile automatisch vervollständigt. Die fontDB wird automatisch eingelesen, wenn sie das erste Mal benötigt wird.

Vordefiniert für InDesign®-Plugins und comet_pdf sind etwa 350 Schriftfamilien mit knapp 1.000 Schritschnitten. Die Standard-FontDB verfügt also bereits über mehr als 55.000 Zuordnungen. Die aktuellen Inhalte der fontDB können mit Hilfe der Skript-Funktionen system::fontdb_~ gelesen werden. Mit Hilfe der Funktion text::find_styled_font kann der Schriftschnitt einer Schriftfamilie direkt bestimmt werden.

Die Standard-FontDB kann mit Hilfe der Dateien fontdb.xml beliebig erweitert und überschrieben werden. InDesign®-Plugins und comet_pdf suchen an folgenden Stellen (und in dieser Reihenfolge) nach dieser Datei. Spätere Definitionen überschreiben frühere:

1. Im aktuellen Ordner der InDesign®-Plug-Ins bzw. im aktuellen Programmordner von comet_pdf ($COMET/fontdb.xml). Definitionen dieser Datei können Standard-FontDB-Einträge überschreiben.
2. Im Ordner werkii der Benutzer-Prefs ($PREFS/werkii/fontdb.xml). Definitionen dieser Datei können Definitinen von $COMET/fontdb.xml und Standard-FontDB-Einträge überschreiben.
3. In der Konfigurationsdatei fontdb.xml ($COMETDATA/fontdb.xml). [seit v4.1 R23777 und nur bei XML-Offline und SOAP]

Die Datei muß folgendes Format haben:

<?xml version="1.0" encoding="utf-8"?>
<fontdb>
	<!--
		One variant corresponds to one font face.
		All information is case-sensitive!
	
		font : font family name, e.g Verdana
		face : existing font face of font family, e.g. Bold
		style : n | i
		weight : 100, 200, ..., 900
		stretch : -4, -3, ... , 3, 4
	-->
	<variant font="Verdana" face="Italic" style="i" weight="400" stretch="0" />
</fontdb>

In font geben Sie den Namen der Schriftfamilie ohne Zusatz an. Der Name der Schriffamilie ist das, was InDesign® als Schriftnamen anzeigt und was im cFont-Tag von TaggedText steht, siehe auch hier.

In face wird der Name des Schriftschnittes angegeben. In InDesign® wird der Schriftschnitt unter dem Schriftnamen angezeigt, im TaggedText steht er im Tag cTypeface., siehe auch hier.

Eine Beschreibung der gültigen Werte für weight und stretch finden Sie hier.

Bitte achten Sie darauf, dass immer mindestens der Defaulteintrag style="n" weight="400" stretch="0" defniert ist.

Das hört sich komplizierter an, als es ist. Hier ein Beispiel für die Windows-Schriftfamilie Corporate S.

Zuerst machen Sie die Schrift für das PDF verfügbar. Schreiben Sie in InDesign® ein wenig Text und geben Sie diesem Text die Schrift Corporate S. Unter der Schriftauswahl sehen Sie die verfügbaren Schriftschnitte. Zehn Stück sind definiert. Jeder dieser zehn Einträge benötigt einen Eintrag in fontnames_default.xml oder einer fontnames.xml:

<fontname id="Corporate S Regular"			ps="Corporate S"/>
<fontname id="Corporate S Regular Italic"	ps="Corporate S,Italic"/>
<fontname id="Corporate S Light"			ps="Corporate S Light"/>
<fontname id="Corporate S Light Italic"		ps="Corporate S Light,Italic"/>
<fontname id="Corporate S Medium"			ps="Corporate S Medium"/>
<fontname id="Corporate S Demi"				ps="Corporate S Demi"/>
<fontname id="Corporate S Bold"				ps="Corporate S,Bold"/>
<fontname id="Corporate S Bold Italic"		ps="Corporate S,Bold,Italic"/>
<fontname id="Corporate S ExtraBold"		ps="Corporate S ExtraBold"/>
<fontname id="Corporate S ExtraBold Italic"	ps="Corporate S ExtraBold,Italic"/>

Die obige Definition ist nur für Windows korrekt. Für eine Mac- oder Linux-kompatible Version müssen die Werte von ps jeweils in das Attribut pswin eingetragen werden. Die Postscriptnamen können Sie erfahren, wenn Sie die Schrift im System doppelklicken und sich die Schrift-Informationen anzeigen lassen.

Das Beispiel ist geeignet, wenn Sie nur wenige Schriften definieren müssen. Wenn Sie viele Schriften berabeiten müssen, lohnt es sich, vorher eine UPR-Datei zu erstellen.

Die Namen der Schriftschnitte sind ziemlich eindeutig. Die Erweiterung der fontdb.xml ist also ebenfalls einfach:

<variant font="Corporate S" face="Regular"			style="n" weight="400" stretch="0"/>
<variant font="Corporate S" face="Regular Italic"	style="i" weight="400" stretch="0"/>
<variant font="Corporate S" face="Light"			style="n" weight="300" stretch="0"/>
<variant font="Corporate S" face="Light Italic"		style="i" weight="300" stretch="0"/>
<variant font="Corporate S" face="Medium"			style="n" weight="500" stretch="0"/>
<variant font="Corporate S" face="Demi"				style="n" weight="600" stretch="0"/>
<variant font="Corporate S" face="Bold"				style="n" weight="700" stretch="0"/>
<variant font="Corporate S" face="Bold Italic"		style="i" weight="700" stretch="0"/>
<variant font="Corporate S" face="ExtraBold"		style="n" weight="800" stretch="0"/>
<variant font="Corporate S" face="ExtraBold Italic"	style="i" weight="800" stretch="0"/>

Beachten Sie bitte: Die Eingträge der fontDB werden nur benötigt, wenn HTML-Text verarbeitet werden soll. Werden keine HTML-formatierten Texte ins Dokument eingefügt, sind sie nicht nötig!

[seit v4.1.7 R26929] Noch einfacher ist die Prüfung, ob Schriftnamen oder Einträge in FontDB fehlen nit der Option --checkfonts N. Die fehlenden Definitionen werden dabei als Programmausgabe in die Konsole geschrieben und können direkt in die entsprechenden XML-Konfigurationsdateien eingefügt werden. Aber bitte beachten Sie : Schriften sind mitunter recht nachlässig definiert - Sie sollten die angegebenen Definitionen aber insbesondere in Hinsicht auf den Schriftstil (normal, italic), die Schriftstärke (weight) und die Laufweite (stretch) überprüfen. Die Angaben für N entsprechen dem cScript-Aufruf system::fontdb_check.

[seit v4.2 R28457] Gewöhnlich wird nach dieser Rangfolge nach passenden Postscript-Schriften gesucht:

• benutzerdefinierte fontnames-Datei (mit -P bzw. --psnames angegeben)
• Default Fontmap-Datei (fontnames_default.xml im Anwendungsverzeichnis)
• Built-in Mapping für zahlreiche Standard-Schriften
• Fallback-Font aus benutzerdefinierer oder Default Fontnames Datei oder systemspezifisch (z.B. "Arial" auf Windows Systemen)
• "Missing Font", also in der benutzerdefinierten oder default fontnames Datei angegebene Schrift zur Kennzeichnung fehlender Schriften

Mittels --font-policy können einzelne Suchquellen deaktiviert oder aktiviert werden. Angegeben wird --font-policy als Ganzzahl, die Werte für die einzelnen Quellen werden dabei einfach addiert. Standardwert ist das bisherige Verhalten (63, in allen möglichen Quellen suchen).

• 1 erlaube das built-in Mapping
• 2 erlaube Werte aus fontnames_default.xml
• 4 erlaube Werte aus der benutzerdefinierten fontnames.xml Datei
• 8 erlaube Fallback-Schriften aus benutzerdefinierter oder fontnames_default.xml Datei
• 16 erlaube die Standard Fallback Schrift des Systems
• 32 erlaube "Missing Font" aus fontnames Datei

[seit v4.1.5 R24842] comet_pdf unterstützt die sogenannten Awesome-Fonts. Bedingung ist, dass der Postscriptname der verwendeten Awesome-Schrift mit FontAwesome beginnt. Von comet_pdf werden alle auf https://fontawesome.com/cheatsheet?from=io definierten Glyphen unterstützt.

Das bedeutet nicht, dass jede dieser Glyphen auch dargestellt werden kann. Es bedeutet lediglich, dass wir es ermöglichen, dass diese Zeichen dargestellt werden könnten! Damit ein Zeichen sichtbar wird, muss es natürlich auch in der Schrift definiert sein!

Die Liste der definierten Glyphen kann beliebig erweitert werden. Erstellen Sie dazu eine XML-Datei mit den Namen der Glyphen und ihrem jeweiligen Unicode. Die sehr einfache Syntax dieser Datei sehen Sie im folgenden Beispiel

<awesomes>
 	<awesome key="fa-glass-martini" value="0xf000" />
</awesomes>

Achten Sie darauf, dass die Unicode-Zeichen entweder mit 0x beginnen (und dann einen Hex-Wert haben) oder Dezimalzahlen sein müssen. Die so erstellte Datei können Sie mit Hilfe der Programm-Option --awesome einbinden:

--awesome path

Relative Pfadangaben werden dabei wie üblich relativ zum ausführenden comet_pdf aufgelöst.

Ich weiß nicht, wie es Ihnen geht, aber ich finde die Awesome-Fonts, nun ja - gewöhnungsbedürftig. Dabei ist das Problem gar nicht so sehr die unorthodoxe Behandlung von Eingabe, Schrift und Zeichen. Das ist ja sogar ganz hilfreich. Schlimmer ist eher, dass es so viele verschiedene Awesome-Fonts gibt, die jeweils einen nicht durchschaubaren, aber jedenfalls nie vollständigen Satz an Glyphen enthalten. Wir haben in den Renderer daher eine Option eingebaut, mit der Sie testen können, welche der von Ihnen definierten Glyphen in einem Awesome-Font tatsächlich definiert sind.

Verwenden Sie dazu die Programm-Option --awesometest.

--awesometest ps-fontname

Der Aufruf benötigt keine Eingabedatei, aber den Namen des Awesome-Fonts müssen Sie als Postscript-Namen angeben. Wenn Sie keine Ausgabedatei angeben, wird die Ausgabe-PDF auf Ihrem Desktop abgelegt. Hier ein Beispielaufruf:

./comet_pdf -L --awesometest FontAwesome5ProSolid

Sie erhalten eine Liste der Glyphen und deren Unicodes (in Hex) und die Glypnamen. Lokal mit --awesome definierte Glyphen werden dabei rot dargestellt:

Comet_pdf verfügt über eine eingebaute sprachabhängige Silbentrennung, die auf den Trennregeln von TeX basiert. Zur Implementierung verwenden wir die Bibliothek libhyphenate von Steve Wolter.

Trennregeln werden in Abhängikeit von der Spracheinstellung des Textes ausgewählt. Sprachdialekte (z.B Deutsch und Schweizer Deutsch) können durch eine zusätzliche Länderkennung unterstützt werden. Im TaggedText-Tag <cLanguage:> wird die Länderkennung durch "\: " (das Leerzeichen ist wichtig!) an den Sprachnamen angefügt. Bei der Suche nach der geeigneten Trennregeldatei wird immer zuerst nach Sprache\: Länderkennung gesucht. Wird der gesuchte Dialekt nicht gefunden, wird automatisch nach der Sprache ohne Länderkennung gesucht.

Die von InDesign® verwendeten Sprachnamen und Länderkennungen können Sie durch einen TaggedText-Export eines Textes der gesuchten Sprache ermitteln. Suchen Sie im exportierten Text dazu nach dem Tag <cLanguage:.

Für jede unterstützte Sprache muß dafür eine Trennregeldatei definiert sein und existieren. Ablageort für alle Trennregeldateien ist der Ordner hyphenations im gleichen Ordner wie comet_pdf. Mit der Option -H (--hyphens) darf dieser Ordner auch an eine andere Stelle verschoben werden.

Die folgenden Sprachen werden im Standard unterstützt:

Nicht unterstützte Sprachen verwenden die englischen Regeln zur Silbentrennung. Weitere in InDesign® verfügbare Einstellungen zur Silbentrennung werden von comet_pdf nicht unterstützt.

Sie können Regeln für weitere Sprachen hinzufügen. Dazu sind die folgenden zwei Schritte nötig:

1. Erstellen einer Trennregel-Datei
2. Verknüfung von Sprachname und Trennregel-Datei

Für die Erstellung einer Trennregel-Datei folgen Sie bitte den Anweisungen dieses Links. Die in der Beschreibung erwähnten TeX language files finden Sie leicht, wenn Sie im Internet nach "NNhyph tex" mit NN als Sprachkürzel (ru, it, pl, ...) suchen. Hier finden Sie ebenfalls Dateien mit sprachabhängigen Trennmustern.

Die so erstellte Datei wird im gleichen Ordner wie die Standard-Trennregeln abgelegt - also im Ordner hyphenations bzw. im mit --hyphens definierten Ordner.

Die Verbindung zwischen Sprache und Trennregeldatei wird in der Datei hyphenations/languages.xml gemacht. Die Datei enthält für jede zusätzlich unterstützte Sprache einen Eintrag mit dem InDesign®-Namen der Sprache und dem Namen der Trennregeldatei im Ordner hyphenations:

<?xml version="1.0" encoding="utf-8"?>
<languages>
	<language primary="name" sub="country" hyphens="file_name" />
</languages>

Soll die Definition für alle Dialekte einer Sprache gelten, lassen Sie die Länderkennung sub leer. Ist die Länderkennung nicht leer, wird die Definition ausschließlich für diesen Dialekt verwendet. Hier ein Beispiel:

Definiere pt als Trennregeldatei für alle portugiesischen Dialekte .

<language primary="Portuguese" sub="" hyphens="pt" />

Definiere pt als Trennregeldatei für brasilianisches Portugiesisch. Ist keine weitere Definition für portugisiesches Portugisiesch angegeben, wird portugisiesches Portugisiesch nach dem Default getrennt.

<language primary="Portuguese" sub="Brazilian" hyphens="pt" />

Wird in hyphens eine nicht-existierende Datei angegeben, wird die Silbentrennung für diese Sprache deaktiviert. Beim Versuch, die angegebene Trennregeldatei zu verwenden, wird aber eine Warnmeldung geschrieben. Um die Silbentrennung ohne Warnungmeldungen abzuschalten, verwenden Sie das Schlüsselwort _off_.

Abschalten der Silbentrennung für portugiesische Texte:

<language primary="" sub="" hyphens="_off_" />

Mit einer Leer-Definition für primary und sub legen Sie einen neuen Fallback für Texte nicht definierter Sprachnamen fest.

Verwende die Definitionen in pt als Trennregeln für alle Sprachen, für die keine eigenen Trennregeln definiert sind.

<language primary="" sub="" hyphens="pt" />

So schalten die Silbentrennung für alle Sprachen ab, für die keine Trennregeln definiert sind:

Abschalten des Fallbacks

<language primary="" sub="" hyphens="_off_" />

Mit den Elementen

• hyphenationLanguage
• hyphenationCountry

im Root-Element der Dokument-XML-Struktur können die Spracheinstellungen des gesamten Dokumentes überdeckt werden. Das ist insbesondere dann hilfreich, wenn ein Dokument in verschiedenen Sprachvarianten erstellt werden soll, ohne dass dafür jeweils neue Stildefinitionen mit den entsprechenden Sprachen gemacht werden müssen. Ist hyphenationLanguage nicht leer, wird für alle Texte mit aktivierter Silbentrennung die im Element angegebene Sprache für die Silbentrennung verwendet. Im Element hyphenationCountry kann zusätzlich die nötige Landesangabe gemacht werden.

Im Unterschied zu den Sprachnamen in Texten, die von InDesign® vorgegeben sind, sind Sie hier bei der Namenswahl vollkommen frei, können also die von Ihnen bevorzugten ISO- oder sonstige Kürzel wie deDE, itIT, enEN oder deu, iti, eng usw. verwenden. Mir doch egal.

Mit den beiden folgenden (kleinen) Schritten können alle Texte eines Dokumentes mit aktivierter Silbentrennung nach den Regeln der aktuellen deutschen Silbentrennung getrennt werden:

1. Definition von hyphenationLanguage=deu und hyphenationCountry= (leer) im Root-Element der XML-Struktur des Dokumentes
2. Einfügen der Zeile <language primary="deu" sub="" hyphens="de" /> in hyphenations/languages.xml.

Mit dem Vorsatz file:// kann die gewünschte Trennregeldatei kann auch direkt im Element hyphenationLanguage angegeben werden. Die Angabe im Element hyphenationCountry wird in diesem Fall ignoriert. Folgende Werte sind (gemäß den obigen Beschreibungen) also möglich:

• file:// : Verwende den aktuellen Fallback im gesamten Dokument
• file://_off_ : Silbentrennung im gesamten Dokument abschalten
• file:://name : Existiert im Ordner hyphenations eine Datei Namens name, werden alle Texte des Dokumentes nach diesen Regeln getrennt. Existiert die Datei name nicht, wird die Silbentrennung für das gesamte Dokument deaktiviert.

Hinweis : In InDesign® ist die Silbentrennung ein fest integrierter Bestandteil des Programmes. Um hier ein hier ein gleiches Verhalten wie in comet_pdf zu erreichen, müssen deshalb alle Absätze und Stile des Dokumentes auf die gewünschte Sprache gesetzt werden. Hier ein entsprechendes JavaScript für InDesign®:

Ändere die Spracheinstellung aller Absätze und Stile eines Dokumentes. ACHTUNG : Wenn die geänderten Spracheinstellungen nicht gesichert werden sollen, muß das Dokument ohne Sichern geschlossen werden.

var language = "";		// $ID/languageKey
var doc = app.documents[0]; 	// Choose your document here

var paraStyles = doc.allParagraphStyles;
for (var i = 1; i < paraStyles.length; i++)
{
	paraStyles[i].appliedLanguage = language;
}

var charStyles = doc.allCharacterStyles;
for (var i = 1; i < charStyles.length; i++)
{
	charStyles[i].appliedLanguage = language;
}

[ab v4.1.8 R30386] Eigene Wörterbücher können wie folgt definiert werden:

1. Legen Sie neben die Trennregel-Datei eine Datei gleichen Namens mit der Endung .dict. Hat die Trennregel-Datei bereits eine Endung, wird die Endung .dict an diese Endung angefügt!
2. Wörterbuchdateien müssen UTF-8 kodiert sein!
3. Tragen Sie in das Wörterbuch alle speziell zu trennenden Wörter wie folgt ein
   1. Verwenden Sie nur Kleinbuchstaben!
   2. Die gewünschten Trennungen werden mit - oder ~ markiert.
   3. Die einzelnen Wörter werden Zeilentrenner oder Leerzeichen getrennt.

Beachten Sie bitte, dass Silben, die breiter als der Textrahmen sind, trotz der Trennregeln automatisch an jeder beliebigen Stelle getrennt werden können. Dieses Verhalten ist zur Vermeidung unerwarteter Text-Übersätze alternativlos nötig!

So wird aus einer Stube für die Wache möglicherweise eine Tube Wachs:

wachs-tube

Hinweis: Einstellige Zahlen zwischen den Buchstaben sind erlaubt und werden als TeX-Regeln direkt übernommen. Wenn Sie sich also mit der Syntax der TeX-Trennregeln auskennen, z.B. aus dem Appendix H von TeX, können Sie die Worttrennung durch eigene Zahlenangaben zwischen den einzelnen Buchstaben auch selbst bewichten. Mit der Definition w1a1c1h1s1t1u1be definieren Sie also die niederschwellige Erlaubnis, das Wort Wachstube an beliebiger Stelle zu trennen.

Zur Installation folgen Sie bitte den Anweisungen der Datei 1 ReadMe.html des jeweiligen Installations-Ordners.

Die Installation enthält mglw. mehrere Varianten des Programmes. Varianten werden im Unterordner 3 bin der Installation mitgeliefert. Sie können comet_pdf bzw. comet_pdf.exe jeweils durch eine der entsprechenden Varianten ersetzen. Beachten Sie dabei bitte:

1. Unter Windows muss auch die zugehörige pdflib.dll ersetzt werden. Verwenden Sie auf keinen Fall andere Versionen der PDFlib!
2. Unterschiedliche Varianten benötigen mglw. unterschiedliche PDFlib-Lizenzen.

Ist das Programm installiert, kann es über Terminal bzw. die Eingabeaufforderung gestartet werden:

> cd /Pfad des Ordners mit comet_pdf
> comet_pdf -s hello

Da Sie wahrscheinlich bis jetzt noch keine Lizenz haben, reagiert das Programm mit der Mitteilung, dass die nötigen Lizenzen fehlen, siehe hier. Sie können das Programm uneingeschränkt verwenden. Über die erzeugten Seiten wird jedoch ein Wasserzeichen gelegt.

Das Programm benötigt zwei Lizenzen : Die WERK II-Lizenz für das eigentliche Programm und eine Lizenz für die verwendete PDF-Bibliothek.

Das Programm arbeitet ohne Einschränkungen auch ohne gültige WERK II - Lizenz. Alle erzeugten Dokumentseiten werden aber mit dem Wasserzeichen DEMO versehen.

Auch für die PDFLib ist keine Lizenz nötig. Sie können lt. PDFLib.com etwa 10 Seiten (bzw. 10 MB) große Dokumente erzeugen. Die Seiten werden mit dem Wasserzeichen www.pdflib.com versehen.

Falsche PDFlib-Lizenen führen zum Abruch des Programmes.

Das Wasserzeichen von comet_pdf wird dabei immer über die sichtbaren Rahmen der Seite gelegt. Das PDFLib-Wasserzeichen wird über die Seite selbst gelegt:

Die Lizenzdatei muss im gleichen Ordner wie comet_pdf abgelegt werden und w2.lic heißen. Ohne gültige WERK II-Lizenz antwortet comet_pdf mit der folgenden Nachricht

No valid license found. Application will run in DEMO mode!

To get a valid priint:pdf license, please send the green
text to license@priint.com. For a valid PDFLib license
please contact sales@pdflib.com.

//
// LICENSE ORDER DATA
// add your comments here
//
OrderBy        : "your name"
EMail          : "your email"
LicenseCode    : "xxxx ... xxxx"
TerminalServer : "0"
Comet          : "4.0.5"
Expired        : ""
Module         : priint:pdf

Schicken Sie den grünen Text an license@priint.com. Achtung: Bevor Sie den grünen Text absenden, setzen Sie bitte einen richtigen Namen und eine gültige Mailadresse ein - an diese Adresse erhalten Sie von uns eine gültige Lizenzdatei.

Zur Lizenzprüfung unter Linux wird das Standard-Programm dmidecode verwendet. Comet_pdf wird nicht freigeschaltet und bleibt im DEMO-Modus, wenn dmidecode nicht erfolgreich ausgeführt werden kann. Leider benötig dmidecode aber Admin-Rechte. Um zu vermeiden, dass deshalb auch comet_pdf immer mit Admin-Rechten ausgeführt werden muß, benötigt das Programm daher entweder das Admin-Passwort oder die Erlaubnis, dmidecode als Admin auszuführen. Beides wird über die Datei zpasswd im gleichen Ordner wie comet_pdf gesteuert:

Existiert die Datei zpasswd nicht, erfragt comet_pdf das Admin-Passwort. Nach der Eingabe wird das Passwort verschlüsselt in die Datei zpasswd geschrieben. Weitere Aufrufe von comet_pdf können das Passwort aus zpasswd entschlüsseln und wieder verwenden.

Wird das Admin-Passwort Ihres Rechners geändert, muss die Datei zpasswd entfernt werden und comet_pdf einmal ausgeführt werden, um das neue Passwort zu sichern.

Wenn Sie das Admin-Passwort nicht in zpasswd sichern wollen, geben Sie statt des Passwortes den Text (in genau dieser Schreibweise)

    $SUDOERS

an. Comet_pdf erwartet dann, dass Sie dem aktuellen Benutzer das Recht zur Ausführung von dmidecode erteilt haben. Solche Berechtigungen werden üblicherweise in der Datei /etc/sudoers erteilt.

ACHTUNG ACHTUNG ACHTUNG: Bitte lassen Sie Änderungen an der Datei sudoers ausschließlich von Fachleuten machen oder informieren Sie sich vorher ausreichend! Enthält die Datei syntaktische Fehler, funktioniert der Befehl sudo Ihres Rechners nicht mehr. Diesen Befehl benötigen Sie aber, um die Datei wieder zu berichtigen! Sie können sich also sehr viel Arbeit machen, wenn Sie einfach so an der Datei /etc/sudoers herumschreiben.

Die PDFLib-Lizenz muss sich im gleichen Ordner wie comet_pdf befinden und licensekeys.txt heißen. Eine gültige Lizenz für die verwendete PDF-Bibliothek können Sie bei PDFLib.com erhalten. Bitte geben Sie bei der Bestellung die gewünschte Lizenzart an:

Auf die Datei licensekeys.txt können Sie verzichten und die PDFlib-Lizenz mit in die w2lic schreiben. Fügen Sie dazu in die w2lic eine Zeile mit dem Schlüsselwort PDFLibKey gefolgt von der in Anführungszeichen eingeschlossen PDFlib-Lizenz ein. Hier ein Beispiel:

PDFLibKey "m900202-123456-123456-******-******"

Achten Sie bitte darauf, dass die PDFlib-Lizenz zur verwendeten PDFlib-Version passt. Die PDFlib-Version Ihres comet_pdf erfahren Sie mit Hilfe der Option -h.

Version:
comet_pdf v1.0 R24333, based on Comet 4.1 and PDFlib 9.0.6

Aktuell werden folgende PDFlib-Versionen unterstützt:

Mit Hilfe der Optionen --w2lic_path und --pdflic_path können die Ordner, in denen sich die Lizenzdateien befinden geändert werden. Das ist inbesondere dann sinnvoll, wenn bei Programm-Updates der Ordner mit dem Programm comet_pdf ersetzt wird. Geben Sie als Wert der Option einen vollständigen und gültigen Ordner-Pfad an. Der Pfad darf mit den definierten $-Abkürzungen wie $DESKTOP beginnen. Der Name der Lizenzdatei kann mit der Option nicht geändert werden!

Die WERK II - Lizenzdatei w2.lic befindet sich in den lokalen Voreinstellungen:

--w2lic_path \$PREFS/werkii

Mit Hilfe der Optionen --w2lic oder --pdflic können die verwendeten Lizenzen geprüft werden. Das Ergebnis wird in der Programmausgabe angezeigt und als Return-Wert des Programmes zurückgegeben:

Da das Ergebnis einer Lizenzprüfung der Rückgabewert des Programmes ist, kann jeweils nur eine Lizenzprüfung durchgeführt werden.

Die folgenden Lizenzen werden möglicherweise für Aufgaben des Programmes benötigt, die nicht zu den Kernaufgaben von comet_pdf gehören.

Postscript wird von PDFlib erwartungsgemäß nicht unterstützt (siehe dazu unter Bildformate) und die Einbindung von Bildern aus Postscript gehört nicht zum Standard-Leistungsumfang von comet_pdf. Das Programm sieht aber die Möglichkeit zur automatischen Konvertierung von Posrtscript in PDF vor. Weitere Informationen dazu finden Sie hier.

Unter Mac OS enthält die zum Konvertieren von Postscript in PDF nötige Software bereits standardmäßig.

Unter Windows verwenden wir das lizenzpflichtige Tool ps2pdf.exe von VeryDoc. Die Lizenz von ps2pdf.exe ist nicht im Leistungsumfang von comet_pdf enthalten. Ohne Lizenz erzeugt das Programm ein Wasserzeichen über den PDFs. Eine Installationsanleitung für die Lizenz finden Sie hier.

Alternativ können Sie auch andere Software zum Konvertieren von (E)PS nach PDF verwenden. Eine Beschreibung dazu finden Sie hier.

Sollen die erzeugten PDFs als Grundlage für die Metadaten eines PublishingServer verwendet werden, müssen PDFs in Rasterbilder (JPG oder PNG) umgewandelt werden. Das Erzeugen dieser Rasterbilder ist zwar nicht Kernaufgabe von comet_pdf, wird aber trotzdem unterstützt.

Unter Mac OS ist die dafür nötige Software bereits standardmäßig installiert.

Unter Windows wird pdf2image verwendet. Hier finden Sie Infos zur Lizenz von pdf2image, Das Programm ist aber leider so langsam, dass die Installation einer anderen, mglw. lizenzpflichtigen Software hier dringend geraten ist. Die Lizenz für einen PDF-Bild-Konverter ist nicht im Leistungsumfang von comet_pdf enthalten.

Alternativ können Sie auch andere Software zum Konvertieren PDF in Bilder verwenden. Informationen zur Verwendung eigener Konvertierungsoftware finden Sie hier.

Textvariablen können Bildinformationen und Angaben aus den XMP-Headern von Bildern zeigen. Zum Ermitteln dieser Informationen wird exiftool verwendet. Der Autor verlangt zwar keine Lizenzgebühr, eine Spende ist ihm aber willkommen.

Informationen und Copyright-Hinweise benutzter Software von Drittanbietern finden Sie hier.

Von den etwa 1.800 cScript-Befehlen sind in der aktuellen Version von comet_pdf etwa 1.400 implementiert. Fehlende Skriptfunktionen werden in der Standardausgabe mit dem Hinweis

Missing cScript function 'document::concat' called, returning -1199.

versehen. Wenden Sie sich in diesem Fall bitte an unsere Entwickler. (Ein isolierter Testfall wird die Bearbeitung ungemein beschleunigen.)

In der Online-Doku, die zu jedem Release der InDesign®-Plugins ausgeliefert wird, haben alle Funktionen einen Hinweis, ob sie für comet_pdf verfügbar sind:

    Available:
            Comet-Plug-Ins, comet_pdf

Auch sind bisher nicht alle Standardfunktionen der Comet-Plugins implementiert. In einigen Fällen generiert das Meldungen der Art:

IFrameLinkServiceUtils::build not implemented now in comet_pdf

Über Meldungen dieser Art brauchen Sie uns nicht zu informieren. Diese Funktionalitäten werden Schritt für Schritt implementiert.

Ebenso fehlen in der aktuellen Version von comet_pdf natürlich noch eine ganze Reihe von Features der Comet-Plugins. Hier eine kurze (und unvollständige) Liste der fehlenden Features:

• Textfluß-Aufbau
• in-tag (implementiert ab R4450)
• Inline-Rahmen (implementiert ab R4617)
• Tabellen und Tabellenmodul (implementiert ab 7222)
• Platzhalter-Prefix/Postfix (implementiert ab R8160). Achtung: Zur Zeit werden Prä/Postfixe nur eingefügt, aber nicht gelöscht!
• Mehrspaltige Textrahmen (implementiert ab 9900)
• Musterseiten (implementiert ab R6161)
• Seitennummern (seit R8122) und andere Variablen
• Unsichtbare Rahmen, unsichtbare Ebenen
• Verschachtelte Tabellen

Auch diese Funktionen werden, soweit sinnvoll und machbar, Schritt für Schritt implementiert.

Folgende Bildformate werden unterstützt :

• bmp
• ccitt
• g3, g4
• fax
• gif
• jbig2, jb2
• jpg, jpeg,
• jpx
• jp2
• jpf
• jpm
• png
• raw
• tif, tiff
• [Seit v5.0 R37090] svg Achtung: HSL- und HSL(A)-Farben werden nicht unterstützt!

Fehlende oder fehlerhafte Bilder werden mit einem diagonalen Kreuz im Rahmen dargestellt. Hat der Bildrahmen keine sichtbare Kontur, werden zusätzlich die Rahmenkanten (in der Ebenenfarbe) gezeigt.

Bitte prüfen Sie vor dem produktiven Einsatz unbedingt die richtige Darstellung ihrer Bilder. Die WERK II GmbH kann keine Garantie für die richtige Darstellung von Bildern jeglichen Formates übernehmen.

Wie Sie sehen, werden weder Postscript (ps und eps), noch Illustrator (ai), Photoshop (psd) oder WebP (webp) direkt unterstützt! Auch wenn im Folgenden Möglichkeiten zur automatischen Berechnung von Alternativbildern beschrieben werden: Aus Performance-Sicht ist die Bereitstellung von Alterntivbildern in einem der unterstützen Formate die beste Lösung. Hier deshalb einige Beispiele zur vorbereitenden Bildkonvertierung:

1. Vorschau : Eine sehr einfache Möglichkeit bietet das Mac-Programm Vorschau, das geöffnete Postscript-Dateien in eine Reihe von Rasterformaten sichern kann. Leider kann dieser Prozess aber nicht automatisiert werden, Vorschau ist nicht AppleScript-fähig.
2. pstopdf : Umwandeln von Postscript in PDF am Mac. Das Programm lässt sich aus Terminal starten.
3. ps2pdf : Umwandeln von Postscript in PDF. Das Programm lässt sich aus Terminal starten und ist auch für Windows erhältlich.
   ACHTUNG: Für die Nutzung dieses ghostscript-Programmes fallen möglichlicherweise Lizenzgebühren an.

Bilder in Postscript, Photoshop oder WebP können von comet_pdf nicht importiert werden. Comet_pdf sucht in diesen Fällen neben dem Original automatisch nach einer möglichen Alternative gleichen Namens mit den folgenden Dateiendungen. Die erste gefundene Alternative wird verwendet:

1. pdf
2. png
3. jpeg, jpg
4. tif, tiff
5. gif, giff

Das Bild abc.eps soll eingefügt werden. Neben dem Bild abc.eps liegen die Dateien abc.png und abc.gif.

Das Bild abc.png wird verwendet.

Verwendete Alternativen werden in der Programmausgabe angegeben:

'eps' substituted by 'png' : '/Users/paul/Desktop/abc.eps'

Reihenfolge und Verwendung von Alternativ-Bildern können eingestellt werden. Informationen dazu finden Sie hier.

Wird zu einem Postscript-Bild (ps, eps) kein Alternativbild gefunden, versucht comet_pdf automatisch, eine PDF-Variante des Bildes zu erstellen.

Die automatische Konvertierung in PDF kann deaktiviert werden. Informationen dazu finden Sie hier.

Die automatische Konvertierung erzeugt Dateien. Die Dateien werden im $CACHE-Ordner des aktuellen comet_pdf-Aufrufes abgelegt. ACHTUNG: Der $CACHE-Ordner wird beim Programmende automatisch gelöscht. Wenn Sie die berechneten Varianten weiter verwenden wollen, müssen sie vor Programmende mit geeigneten Methoden an anderer Stelle gesichert werden. Mit der Programmoption -VX wird das Löschen des $CACHE verhindert.

Vor der internen Konvertierung von Postscript in PDF wird das Standardskript imgconv/ps2pdf.cpp ausgeführt. In diesem Skript können Sie eine eigene Konvertierung ausführen lassen. Soll die interne Konvertierung verwendet werden, setzen Sie in diesem Skript die Variable *gResult auf den Wert -1. Das Skript wird dann nicht wieder aufgerufen und statt dessen immer die interne Konvertierung verwendet. Soll die interne Konvertierung nicht verwendet werden und es gibt keine ausdrücklich definierte Alternative, muss die Konvertierung in imgconv/ps2pdf.cpp gemacht werden!

Kann die Software zur internen Konvertierung von Postscript in PDF nicht gefunden werden, wird beim ersten Konvertierungsversuch eine Warnmeldung in die Ausgabe geschrieben.

Für die interne Generierung der PDFs wird folgende Software verwendet:

brew install ghostscript

sudo apt-get install ghostscript

https://ghostscript.com/releases/gsdnld.html

[Ab v5.0 R37142] In Postscript verwendete Schriften werden von Ghostscript an den üblichen Stellen im Betriebssystem gesucht. Kann eine Schrift nicht gefunden werden, verwendet Ghostscript eine möglichst passende Alternative. Was auch immer 'möglichst passend' heißt - die Schrift wird auf alle Fälle anders aussehen.

/Zulu findfont         % Search for the font
24 scalefont           % Size 24 pt
setfont                % Set as current font
72 700 moveto
(Hello World) show

Bitte achten Sie darauf, dass die zusätzlichen Schriftordner möglichst wenig Objekte enthalten. Ghostscript wird die angegebenen Ordner nämlich rekursiv durchsuchen - und das kann bei vielen Unterdateien recht lange dauern.

Für Photoshop-Bilder ist keine automatische Konvertierung integriert!

Nur Mac OS! Wird zu einem WebP-Bild kein Alternativbild gefunden, versucht comet_pdf automatisch, eine PDF-Variante des Bildes zu erstellen.

Unter Windows und Linux können Sie die erweiterte Bildkonvertierung zum Erzeugen einer passenden Alternative verwenden.

Die automatische Konvertierung erzeugt Dateien. Die Dateien werden im $CACHE-Ordner des aktuellen comet_pdf-Aufrufes abgelegt. ACHTUNG: Der $CACHE-Ordner wird beim Programmende automtisch gelöscht. Wenn Sie die berechneten Alternativen weiterverwenden wollen, müssen sie vor Programmende mit geeigneten Methoden an anderer Stelle gesichert werden. Mit der Programmoption -VX wird das Löschen des $CACHE verhindert.

Für die Generierung der PDFs aus WebP wird folgende Software verwendet:

Um die automatische Generierung von PDFs abzuschalten, siehe hier.

Kann für ein Bild weder eine Alternative gefunden noch ein temporäres PDF erstellt werden, können Sie das Bild mit eigener Software in eins der unterstützten Pixelformate umrechnen lassen. Hier werden folgende Formate unterstützt:

• ps, eps
• ai
• psd
• pdf
• webp

Zur Konvertierung wird für jedes dieser Bilder das lokale Skript pdf2image.cpp ausgeführt. Sie können eine beliebiege Konvertierung in eines der von PDFlib unterstützten Rasterformate in einer beliebigen Auflösung machen. Da PDFlib auch PDFs importieren kann, können Sie natürlich auch in PDF konvertieren oder große PDFs in kleinere PDFs umrechnen.

Im Unterschied zu den Aufrufen von pdf2image.cpp, die bei der Generierung der Metadaten nötig sind, sind in bei der Bildkonvertierung die globalen Variablen gFormat und gResolution leer:

gFormat = "";
gResolution = 0.0;

Die automatische Konvertierung erzeugt Dateien. Die Dateien werden im $CACHE-Ordner des aktuellen comet_pdf-Aufrufes abgelegt. ACHTUNG: Der $CACHE-Ordner wird beim Programmende automtisch gelöscht. Wenn Sie die berechneten Varianten weiterverwenden wollen, müssen sie vor Programmende mit geeigneten Methoden an anderer Stelle gesichert werden. Mit der Programmoption -VX wird das Löschen des $CACHE verhindert.

Weitere Informationen zum Skript finden Sie hier.

Verwendung, Reihenfolge und Neuberechnung von Alternativen können mit Hilfe einer XML-Datei angepasst werden. Die Steuerdatei geben Sie im Programmparameter -E (--eps_esc) an:

comet_pdf -E eps_escapes.xml

Unvollständige Pfade (wie oben) werden relativ zum Ordner von comet_pdf aufgelöst. Abkürzungen für Standardordner und Aliasnamen für Ordner sind erlaubt. Die Datei muss wie folgt aufgebaut sein:

<?xml version="1.0" encoding="utf-8"?>
<eps_escapes>

	<!-- 
		Alternativen für (E)PS, Photoshop und WebP:
		
		Geben Sie hier die Reihenfolge an, in der nach 
		Alternativen gesucht werden soll.
	-->
	<eps_escape ext="pdf" 	seq="20"/>
	<eps_escape ext="png" 	seq="30"/>
	<eps_escape ext="gif" 	seq="40"/>
	
	<!-- 
		Konvertierung beliebiger Bildformate
		
		In 'ext' gegen Sie das Format an, das konvertiert 
		werden soll. 'seq' gibt Reihenfolge und Zielformat 
		an. Die Konvertierung implementieren Sie im Skript
		imgconv/ps2pdf.cpp.
		
	-->
	<eps_escape ext="webp" seq="10:png" />
	
<eps_escapes>

<eps_escape ext="pdf" seq="20"/>

Suche in der in seq angegebenen Reihenfolge neben dem Original nach einem Bild gleichen Namens im angegebenen Format.

Beachten Sie bitte, dass nur Bildformate verwendet werden können, die von PDFlib unterstützt werden. Beachten Sie bitte außerdem, dass in diesen Fällen lediglich versucht wird, statt des Vektorbildes eine existierende Pixelvariante des Bildes zu verwenden. Eine Neuberechnung der Variante erfolgt in diesen Fällen nicht!

Eigene Implementierungen zur Berechnung von Bildalternativen können im Skript imgconv/ps2pdf.cpp hinterlegt werden. Durch den Zusatz :dest_extension im Attribut seq wird comet_pdf dieses Skript für alle Bilder mit der Endung ext aurufen.

Im Beispiel wird imgconv/ps2pdf.cpp für alle webp-Bilder aufgerufen und erstellt jeweils eine png-Variante des gegebenen Bildes

<eps_escape ext="webp" seq="10:png" />

Folgende globale Variablen sind in imgconv/ps2pdf.cpp definiert:

Hinweis: Das Skript muß nicht zwangsläufig eine Bildkonvertierung machen. Sie können hier natürlich auch Varianten mit geänderter Bildgröße, Auflösung, etc. erstellen.

Hier eine (Mac)-Implementierung zur Umrechnung von webp in png. Die Umrechnung wird durch die Zeile <eps_escape ext="webp" seq="10:png" /> in eps_escapes.xml ausgelöst.

//***************************************************************************

char	stIn		[8192];	// gInfile with quotas escaped
char	stOut		[8192];	// gOutfile with quotas escaped
char	stDoneBy	[256];	// For messages only
char	stDevNull	[256];	// Suppress shell output
	
//***************************************************************************

int main ()
{
	char			name 	[256];
	char 			cmd		[5000];
	char 			ext		[32];
	char 			extOut	[32];
	
	// 0			: Okay
	// -1 			: Suppress further calls to this script
	// Otherwise	: Error Code
	//
	*gResult		= -1;
	
	// Init vars
	//
	strcpy (stIn, gInfile);		strreplace (stIn, "\"", "\"\"");
	strcpy (stOut, gOutfile);	strreplace (stOut, "\"", "\"\"");
	strcpy (stDoneBy, "");
	
	if (system::os () == 2)		strcpy (stDevNull, "nul");
	else						strcpy (stDevNull, "/dev/null");
	file::extender (ext, gInfile);
	file::extender (extOut, gOutfile);
	
	if (strcmp (ext, "webp") == 0)
	{
		if (system::os () == 1)		
		{
			// Main work is done here
			//
			sprintf (stDoneBy, "sips of Mac OS");
			sprintf (cmd, "sips -s format %s \"%s\" --out \"%s\" > %s", extOut, gInfile, gOutfile, stDevNull);
			*gResult = system::cmd (cmd);
		}
		else
		{
			// Your part :-)
			//
			sprintf (stDoneBy, "convert. Thanks for that.");
		}
	}

	if (!*gResult)
	{
		showmessage ("%s created by %s.", file::name (name, gOutfile), stDoneBy);
	}
	else if (*gResult > 0)
	{
		showerror ("Creating '%s' by %s failed with error %d.", file::name (name, gOutfile), stDoneBy, *gResult);
	}
	
	return 0;
}

Mit der Angabe seq="-1" wird verhindert, dass ein Bildformat verwendet wird.

Um automatische Ersetzungen generell zu deaktivieren, fügen Sie die folgende Zeile in die EPS-Escapes ein. Die Angabe darf an beliebiger Stelle der Datei stehen:

<eps_escape ext="ps" seq="-1"/>

Eingebettete Bilder in InDesign®-Dokumenten werden auch in W2ML eingebettet und können von comet_pdf verwendet werden, ohne dass das Bild als Datei verfügbar ist. Es wird zwischen zwei Arten der Einbettung unterschieden:

1. Direkt eingebettete Binärdaten, z.B. über Copy/Paste von Bildern oder Bilder einer HTML-Seite, die direkt ins Dokument gezogen werden. In diesem Fall existiert kein Bildpfad zu einem Originalbild. Beim Export des InDesign®-Dokumentes in W2ML kann daher auch nur das niedrig aufgelöste Preview in die W2ML geschrieben werden und comet_pdf kann daraus auch nur (mglw.) ungenügend aufgelöste Bilder im PDF erzeugen.
2. Aus Bilddateien eingebettete Bilder: (Eingebettete Bilder aus Bilddateien erhalten Sie z.B. über die Palette Verknüpfungen mit dem Befehl Verknüpfung einbetten.) Verfügt das eingebettete Bild über einen Bildpfad und existiert diese Datei zum Zeitpunkt des Exportes in W2ML, wird die komplette Bilddatei in das W2ML eingebettet und comet_pdf kann das Bild auch in die PDF-Ausgabe in Originalauflösung einfügen.

Beachten Sie bitte, dass die Dateigröße der W2ML mit Anzahl und Größe der eingebetteteb Bilder schnell wachsen kann. Verwenden Sie eingebettete Bilder daher mit Zurückhaltung!

Beachten Sie bitte, dass bei "normal" verknüpften Bildern keine Previews der Bilder in die W2ML geschrieben werden!

Die PDFLib unterstützt Freistellpfade und Alphakanäle. Sie müssen die Pfade aber über ihren Namen ansprechen. Die InDesign®-Möglichkeit, Freistellpfade und Alphakanäle über ihren Index anzusprechen, wird nicht unterstützt.

Ausnahme: Der Alpha-Index 0 bezeichnet den ersten Alpha-Kanal eines Bildes. Der Name kann in diesem Fall ignoriert werden.

Die meisten Bildformate sind so optimiert, dass eine weitere Komprimierung mit Hilfe des Programmparamters --compression kaum etwas an der Bildgröße (und damit an der Größe des fertigen PDFs) ändert. Um eine spürbare Verkleinerung der PDFs zu erreichen, müssen die Bilder daher entsprechend ihrer Auflösung und ihrer aktuellen Skalierung neu berechnet werden.

Die jeweils aktuelle Bildauflösung eines Bildes ergibt sich dabei aus der Auflösung der Bilddatei und der aktuellen Skalierung im Dokument. Ein 72 dpi Bild wird bei einem Schwellwert von 200 dpi also ab einer Skalierung auf 36% (72 / 200 = 0,36) neu berechnet werden.

Schwellwert und gewünschte Auflösung werden in den PDF-Vorgaben festgelegt:

• /ColorImageDownsampleThreshold : Gewünschte Zielauflösung der Bilder im PDF in dpi
• /ColorImageResolution : Schwellwert der Auflösung, ab dem ein skaliertes Bild neu berechnet werden soll. Achtung: Die Angabe ist nicht der Absolutwert sondern der Faktor mit dem die Ziel-Auflösung multipliziert wird : Bei einer Zielauflösung von 144 dpi ab 200 dpi ist das z.B. 1.38889 (200 / 144 = 1,3889).

Im Gegensatz zu InDesign^® werden bei der Neuberechnung keine Unterschiede zwischen Farb-, Graustufen- und einfarbigen Bildern gemacht. comet_pdf verwendet für alle Bilder die Angaben der Farbbilder. Weitere Informationen zu den PDF-Vorgaben und ihre Anwendung finden Sie hier.

Im Screenshot sehen Sie links ein auf 10% skaliertes Bild mit einer Auflösung von 180 dpi. Rechts ist das gleiche Bild nach einer Neuberechnung auf 100 dpi. Die Dateigröße hat dabei mit 38 kB von 3,6 MB auf fast 1/100 verringert.

Für die Aktivierung der Neuberechnung muß zusätzlich zur PDF-Vorgabe der Wert der Programmoption --pdfflags den Wert 1 enthalten! Z.B. also

--pdfflags 1 oder
--pdfflags 3

Hier ein Besispiel:

./comet_pdf ... -z bbb.joboptions --pdfflags 1

Die Neuberechnung der Bilder wird mit Hilfe des Python-Moduls Pillow gemacht.

Bitte prüfen Sie vor der Verwendung des Moduls unbedingt die Lizenzbestimmungen von Pillow.

WICHTIG: Ab v5.0 verwenden Sie als Zielordner der Pillow-Installation Python 3.12!

• Mac
  sudo cp BuildBase/PIL /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages
  
  
• Windows
  sudo cp BuildBase/PIL "Ordner Ihrer comet_pdf Installation"
  
  
• Linux
  
  1. Entpacken der beiden ZIP-Pakete in BuildBase/pillow usr_lib_python38
     
  2. sudo cp BuildBase/pillow usr_lib_python38/PIL /usr/lib/python3.8
     
  3. sudo cp BuildBase/pillow usr_lib_python38/pillow.libs usr/lib/python3.8
  
  Alternativ können Sie das Modul unter Linux auch direkt installieren:
  1. sudo apt install python3-pip
  2. python3 -m pip install --upgrade Pillow
  3. sudo cp -r ~/.local/lib/python3.8/site-packages/PIL /usr/lib/python3.8/
  4. sudo cp -r ~/.local/lib/python3.8/site-packages/pillow.libs /usr/lib/python3.8/

[Seit v4.3 R36440] Alternativ zur fest eingebauten 'PILLOW'-Methode können Sie die Neuberechnung der Bilder auch selbst vornehmen. Legen Sie dazu die Skriptdatei imgconv/resize.cpp an neben Ihrem comet_pdf. Ist imgconv/resize.cpp nicht installiert, wird weiterhin die fest eingebaute PILLOW-Methode verwendet.

imgconv/resize.cpp muß, wenn vorhanden, ein cScript sein. Python wird an dieser Stelle nicht unterstützt! Folgende globale Variablen sind definiert:

Name	Type	Beschreibung
gInfile	char*	Vollständiger Pfad der Originaldatei des Bildes
gOutfile	char*	Vollständiger Pfad der bearbeiteten Zieldatei
gFormat	char*	Zielformat des neu berechneten Bildes
gImgWidth	int	Erwünschte Bildgröße in Punkten. Wird das Bild auf diese Größe skaliert, entspricht seine Auflösung den Angaben in /ColorImageDownsampleThreshold und /ColorImageResolution des PDF-Presets.
gImgHeight	int
gCurrentImgWidth	int	Aktuelle Bildgröße in Punkten
gCurrentImgHeight	int
gResult	int*	Ergebnis der Bearbeitung. Achtung, die Variable ist ein Pointer! Wertzuweisungen müssen also den Inhalt der Variable ändern, etwa so: *gResult = 0; Folgende Werte für gResult werden unterstützt: 0 : Das neue Bild gOutfile wurde erfolgreich erstellt. > 0 : Fehler beim Erstellen des neuen Bildes. < 0 : Skript nicht mehr aufrufen Nach Werten ungleich 0 wird automatisch die eingebaute PILLOW-Methode ausgeführt. Unabhängig vom Wert, den Sie in gResult setzen, sollte Ihr Skript bei erfolgreicher Ausführung (und *gResult = 12; ist eine korrekte Zuweisung - auch wenn sie einen Fehler markiert) den Wert 0, also return 0; zurückgeben.

Hier ein Beispiel. Das Beispiel verwendet ebenfalls PILLOW. Funktional haben Sie also gegenüber der eingebauten Skalierung nichts gewonnen.

Hinweis: Das Skript selbst darf zwar nicht Python sein - aber es kann natürlich einen Systemaufruf an Python ausführen. Sie müssen lediglich aufpassen, dass Sie die passende Python-Version verwenden. Grund dafür ist, dass comet_pdf intern bereits einige Envirnment-Variablen für die eigene Python-Ausführung gesetzt hat.

int main ()
{
	char			inpath	[8192];	// gInfile with quotas escaped
	char			outpath	[8192];	// gOutfile with quotas escape
	char			cmd 	[20000];

	// Escape paths
	//
	strcpy (inpath, gInfile);	strreplace (inpath, "\"", "\"\"");
	strcpy (outpath, gOutfile);	strreplace (outpath, "\"", "\"\"");
	
	// Remove any existing new file
	//
	if (file::exists (outpath)) 
	{
		file::remove (outpath);
	}
	
	// Do the resize
	//
	// As an example, we use the Python module PILLOW here.
	// The Python script resize.py corresponds functionally to the function 
	// built into comet_pdf for reducing the size of images.
	//
	// ATTENTION: Explicitly use the same Python version that comet_pdf uses!
	//
	sprintf (cmd, "python3.10 \"%s\" \"%s\" \"%s\" %s %d %d",
			file::uncurtain ("$COMET/imgconv/resize.py"),
			inpath, outpath, gFormat, 
			gImgWidth, gImgHeight);
	*gResult = system::cmd (cmd);
	
	return 0;
}

... und natürlich das zugehörige Python-Skript, das Sie im gleichen Ordner wie resize.cpp ablegen.

import os, sys
from PIL import Image

def main ():
	infile 	= sys.argv[1]
	outfile = sys.argv[2]
	fmt 	= sys.argv[3]
	width	= int(sys.argv[4])
	height	= int(sys.argv[5])
	if infile != outfile:
		try:
			print (f"Resizing '{infile}' to {width} x {height} pt")
			im = Image.open(infile)
			img_new = im.resize([width, height], Image.Resampling.BICUBIC, None)
			img_new.save(outfile, fmt)
		except IOError as errmess:
			print (f"Cannot resize image '{infile}' : {errmess}")
			return 1
		
	return 0
	
exit (main ())

Textattribute können wahlweise im Text (local overrides), in Zeichenstilen und/oder in Absatzstilen gesetzt werden. InDesign® kennt insgesamt über 300 Textattribute. Hinzu kommen etwa 250 Attribute zur Unterstützung von Tabellen.

Die folgende Tabelle entält die von comet_pdf unterstützten Text- und Tabellenattribute:

%!TT_html...<?IDTT <cNoBreak:1> ?>Text zusammenhalten<?IDTT <cNoBreak:> ?>...

Unter- und Durchstreichungen werden immer als durchgezogene Linien gezeichnet. Die von InDesign® angebotenen Linientypen wie gestrichelt usw. können leider nicht unterstützt werden. Zur Unterstützung besseren Durchstreich-Optionen werden Underlines mit einem Versatz < 2.0 als StrikeThru (also über dem Text liegend) gezeichnet!

Wird gleichzeitig durch- und unterstrichen (ein Highlight der Gestaltung), wird die Durchstreichfarbe auch für die Unterstreichung verwendet.

Besonderen Aufwand erforderten die Linien von Tabellenzellen. In InDesign® stecken hunderte Jahre Entwicklung. Das merkt man. Es ist äußerst schwierig, hier ein Erscheinungsbild wie in InDesign® zu erzeugen. Z.B. erkennt InDesign®, ob eine Linie "um die Ecke" geht und zeichnet Linien dementsprechend. Das wird von comet_pdf zur Zeit noch nicht unterstützt.

Tabellen haben eine Einstellung, ich welcher Reihenfolge Linien gezeichnet werden sollen. Der Renderer unterstützt die Möglichkeiten

• Zeilenkonturen im Vordergrund
• Spaltenkonturen im Vordergrund

Die Einstellungen Beste Verbindungen und InDesign® 2.0-Kompatibilittät werden nicht unterstützt.

Durch geschicktes Ändern einzelner Zellkonturen kann man außerdem die Zeichenreihenfolge einzelner Kreuzungen ändern. Dieses Verhalten kann nicht über Zelleigenschaften gesteuert werden und wird von InDesign® nicht in TaggedText geschrieben. (D.h. also, wenn Sie eine so geänderte Tabelle in TaggedText exportieren und wieder importieren, gehen lokale Änderungen an den Kontur-Kreuzungen verloren.) Und weil der Renderer auf TaggedText basiert, können wir lokale Änderungen an den Kontur-Kreuzungen leider auch nicht unterstützen.

[since v4.1 R24142] comet_pdf kann Anführungszeichen automatisch in typografische Anführungszeichen der aktuellen Sprache im Text ersetzen. Es werden alle von InDesign® unterstützten Sprachen unterstützt. Bitte beachten Sie folgende Einschränkungen:

1. Anführungszeichen werden ausschließlich in Texten ersetzt, die mit einer der Comet-Funktionen wir textmodel::insert, Platzhalter laden, etc. eingesetzt werden. Bestehende Texte in Dokumenten werden aus naheliegenden Gründen nicht ersetzt.
2. Eingefügter Text muss TaggedText sein, also mit einem der TaggedText-Präfixe wie %!TT beginnen.
3. Die Sprache der Einfügestelle wird für den gesamten eingefügten Text verwendet. Sprachänderungen innerhalb des aktuell eigefügten Textes werden zur Zeit ignoriert.

Die Option ist standardmäßig abgeschaltet. Mit der Programmoption

--typgraphics on

kann die Option aktiviert/deaktiert werden. Folgende Werte sind erlaubt:

on, true, yes, 1
off, false, no, 0

Mit Hilfe der Funktion prefs::set_convert_quotas kann die Option auch temporär geändert werden.

Weitere Text- und Tabellenattribute werden Schritt für Schritt folgen. Sollten Sie hier (realisierbare) Wünsche haben, wenden Sie sich bitte an unsere Entwickler.

Adobe verwendet für InDesign® einige Ascii-Zeichen anders als definiert. Wir lassen das mal unkommentiert, aber hier ist eine Tabelle dieser Zeichen:

Ausserdem nutzt Adobe teilweise den Unicode-Bereich, der für Endbenutzer reserviert ist (0xE000 - 0xEFFF). Von den Funktionalitäten, die hinter diesen Zeichen teilweise stehen, ist im PDFRenderer bisher noch nichts umgesetzt. Einige Zeichen werden ausserdem temporär vom Renderer selbst genutzt.

Wir haben fast alle Rahmeneinstellungen, die InDesign® anbietet, auch in comet_pdf implementiert. Hier die Liste der missing features:

• Schraffiert (/|\), Wellenlinie, Raute
• Bei Pfad-Objekten außerdem : Dick-Dünn und Dünn-Dick
• Pfad-Objekte unterstützen nur mittige Konturen.
• Transparente Gap-Farben werden nur in gestrichelten Linien unterstützt

Pfad-Konturen, die nicht mittig sind, werden als rot (und mittig) gezeichnet. So dürften Sie relativ schnell sehen, dass an dieser Stelle etwas nicht stimmt (und Pfadeinstellung und Rahmengröße angepasst werden müssen).

Comet_pdf unterstützt verkettete Texte.

Aber!

1. Verkettungen dürfen nicht rückwärts auf vorherige Seiten zeigen.
2. Die Rahmen der Textketten müssen auf der gleichen Ebene liegen oder zumindest so, dass Rahmen, die in der Kette weiter hinten liegen, auf weiter vorne liegenden Ebenen stehen.

Hintergrund ist in beiden Fälle, dass die Rahmen strikt in der Reihenfolge, die der Text vorgibt, gezeichnet werden müssen und dass immer nur eine Seite zur gleichen Zeit gerendert werden kann.

Platzhalter, die direkt vor einem Absatzende enden und gleich nach dem neuen Absatz wieder beginnen und sowohl die gleichen Platzhalter-IDs als auch gleiche Produkt-IDs haben, werden vom Renderer automatisch zu einem Platzhalter zusammengefasst (Es soll ja Textplatzhalter geben, die über mehrere Absätze gehen.) Daraus folgt aber eine kleine und eher theoretische Ausnahme:

Platzhalter mit gleichen Platzhalter-IDs und gleichen Produkt-IDs müssen mindestens durch ein Zeichen getrennt sein, dass nicht der Absatztrenner ist.

Platzhalter, die lediglich den Absatztrenner enthalten, können von comet_pdf nicht erkannt werden. InDesign^® trickst hier für den TaggedText auf unglaubliche Weise: Aus verschiedenen Kombinationen von zusätzlichen kontext-abhängigen Zeilentrennern und schließenden Tags hinter dem öffnenden <ParaStyle:> erkennt das Programm, ob ein Textattribut (unter Umständen auch) für den Absatztrenner gilt. Durch den für comet_pdf nötigen Umweg über das Zwischenformat W2ML kann dieses Verhalten hier nicht implementiert werden.

Im Bild sehen einen InDesign®-Screenshot einer Tabelle mit einem Bild in der Zelle (2, 2). Das Bild ist ein bißchen zu breit für diese Zelle. InDesign® zeichnet es einfach über die folgenden Spalten und Seiteninhalte und überdeckt deren Inhalte.

Dieses Verhalten wird von comet_pdf nicht unterstützt. Tabellenspalten müssen breit genug sein, damit sie einen Inline-Rahmen aufnehmen können. Eine automatische Anpassung der Spaltenbreite wird nicht gemacht. So bestimmen Sie die Mindestbreite einer Spalte:

Breite des Inlines
    - linker Zellinnenabstand
    - rechter Zellinnenabstand
    - halbe Breite der linken Zellkante
    - halbe Breite der rechten Zellkante
    - 0,5

Im Gegensatz zu Spaltenbreiten können Zeilen in ihrer Höhe an den Platzbedarf der Inlines angepasst werden. Wenn Zeilen eine feste Höhe haben oder die Inlines höher als die festgelegte Maximalhöhe der Zeile sind, wird das Inline - ebenfalls wie in InDesign®- nicht gezeichnet und verschwindet im Übersatz der Zelle.

Um in Tabellenzellen verankerte Rahmen zu zeigen, die größer als die Zelle sind (und mglw. auch neben den Zellen liegen), verwenden Sie benutzerdefinierte Anker. Im Bild ist der rote Rahmen mit einem benutzerdefinierten Anker in der gelben Zelle verankert:

In InDesign® machen Sie diese Einstellungen mit dem Menü Objekt -> Verankerte Rahmen -> Optionen. Hier die Einstellungen für das obige Beispiel. Achten Sie insbesondere auf die Bezugspunkte!

[seit v1.0 R25256] Textübersatz in Tabellenzellen kann (wie in InDesign®) mit einem roten Punkt in der Tabellenzellen anzeigt werden:

Standardmäßig bleiben die roten Punkte ausgeblendet. Verwenden Sie zum Aktivieren der Overset-Markierungen die Option -ao.

Im Gegensatz zu InDesign® kann comet_pdf den Übersatz des Textes selbstständig beseitigen. Dazu wird der Zellinhalt in 1%-Schritten solange verkleinert, bis kein Übersatz mehr entsteht. Untere Grenze der Skalierung ist 10%. Um die automatische Textskalierung bei Übersatz in Tabellenzellen zu aktivieren, setzen Sie die Eigenschaft

Tabelle -> Zellenoptionen -> Text -> Beschneidung -> Inhalt auf Zelle beschneiden

der Zelle.

Im TaggedText heißt das Attribut tCellClip.

Wir haben die Eigenschaft Inhalt auf Zelle beschneiden deshalb als Träger dieser Information verwendet, weil es dafür erstens natürlich kein natives Attribut gibt und zweitens das Attribut zumindest für uns keinen sichtbaren Effekt auf die Textdarstellung in Tabellenzellen hat.

Hier ein Screenshot der gleichen Tabelle, bei dem für jede Zelle die Eigenschaft Inhalt auf Zelle beschneiden gesetzt ist:

Voraussetzung für die Verwendung von Textvariablen ist, dass die W2MLs mit mindestens v4.0.5 R10822 der Comet-Plugins erstellt wurden.

Comet_pdf versteht alle Textvariablen mit allen Formatierungen, wie sie in InDesign® verwendet werden können. Einige spezielle Angaben können aber vom Renderer nicht ermittelt werden. Umgekehrt sind uns bei der Implementierung einige Inkonsistenzen in InDesign® aufgefallen, die wir versucht haben, zu korrigieren. Für alle Variablen gilt außerdem, dass langer Inhalt nicht, wie in InDesign®, auf die Breite das aktuellen Textrahmens zusammengeschoben (und mglw. vollkommen unleserlich) wird - die Inhalte behalten ihre normale Breite und werden bei Bedarf und Möglichkeit ganz normal getrennt.

Die folgende Tabelle gibt eine vollständige Beschreibung aller Variablen und eventueller Abweichungen zur Verwendung in InDesign®.

Metadaten von Bildern können über das cScript imgconv/read_exif.cpp auch von einem externen Tool erfragt werden. Im Skript sind die folgenden Variablen definiert:

In der installierten Version gibt das Skript -1 zurück - es wird also nur einmal ausgeführt und der Renderer ermittlelt die EXIF Daten dann intern. Vorbereitet ist das Skript aber auch für die Verwendung von exiftool. Kommentieren Sie dazu einfach die ersten Zeilen der main-Funktion aus. Stellen Sie aber davor bitte sicher, dass Sie die Lizenzbedingungen von exiftool erfüllen!

Hier sehen zwei Screenshots mit Variablen, einmal ein Darstellung von Wochen- und Monatsnamen in verschiedenen Sprachen. Einmal das volle Programm von Bild-Metadate. Auch hier sind zu Demonstrationszwecken einige Angaben mehrfach und in verschiedenen Sprachen:

Voraussetzung für die Verwendung von Grafikzellen in Tabellen ist, dass die W2MLs mit mindestens mit InDesign® CC 2015 und v4.0.5 R20104 der Comet-Plugins erstellt wurden.

Seit InDesign® CC 2015 können Tabellenzellen Bilder direkt aufnehmen. Dazu muß eine Zellen lediglich in eine Grafikzelle konvertiert werden. Dabei entsteht ein Bildrahmen, der die Zelle abzüglich dem Zellversatz vollständig ausfüllt und automatisch angepasst wird, wenn sich die Zellgröße ändert. Der Bildrahmen gehört direkt zur Tabelle, er wird nicht über ein Inline im Text der Zelle erzeugt. In der Abbildung sehen Sie einen Ausschnitt einer Tabelle mit Grafikzellen in der Spalte abc:

comet_pdf kann solche Rahmen in Zellen jetzt ebenfalls darstellen.

Leider hat Adobe die Grafikzellen etwas flüchtig implementiert: Es fehlt eine Möglichkeit, bestehende Rahmen in Zellen einzufügen. Der Rahmen kann nur über das Konvertieren der Zelle erstellt werden, alle Eigenschaften wie Farbe, Rand, etc. müssen nachträglich gesetzt werden. Schwerwiegender ist aber das merkwürdige Verhalten bei gedrehten Rahmen: Ändert sich die Zellgröße, werden die vier Eckpunkte zwar entsprechend neu positioniert, behalten aber an allen vier Seiten die gleichen Abstände zum Zellrand. Dadurch wird das Viereck aber in der Regel verzerrt:

Wir sind uns zeimlich sicher, dass das nicht dem erwarteten Verhalten entspricht. Es verhindert natürlich auch, dass eine Zeile oder Spalte mehrere gedrehte Rechtecke enthält. comet_pdf berechnet die neue Größe des Rahmens deshalb so, dass der Rahmen zwar entsprechend skaliert wird, aber seine Proportionen behält und in Richtung der größeren Seite zentriert wird:

In der aktuellen Version von comet_pdf können noch keine neuen Grafikrahmen in Zellen erzeugt werden. Das betrifft auch das Duplizieren von Zellen, Spalten oder Tabellen. Insbesondere können also auch keine Templates mit Grafikzellen verwendet werden.

Grafikrahmen in Zellen werden zwar angepasst, wenn sich die Zellengröße ändert. Änderungen des Zellversatzes werden zur Zeit noch nicht berücksichtigt.

comet_pdf unterstützt InDesign®-Objektstile. Aber (anders als Farbfelder und Zeichen- und Absatzstile) werden Objektstile beim Kopieren von Rahmen zwischen Dokumenten nicht automatisch übertragen: Existiert der Objektstil eines Rahmens nicht im Zieldokument, bekommt der Rahmen den Standard-Objektstil [None].

Folgende Eigenschaften von Objektstilen werden unterstützt:

• Füllfarbe
• Deckkraft der Füllfarbe
• Durchsichtigkeit
• Overprint
• Blendmode, Isolation und 'Knockout'
• Ecken
• Rahmenkanten
  • Stärke
  • Typ
  • Farbe
  • Farbe der Lücken
  • Abschluss
  • Gehrungsgrenze
  • Ecke
  • Deckkraft
  • Deckkraft der Lücken
  • Ausrichtung (außen, mitte, innen) mit den oben gemachten Einschränkungen
• Absatzstil (ohne Nächstes Format anwenden)
• Abstand des Textes zum Rahmen (Text Insets)
• Vertikale Textausrichtung

Voraussetzung für die Verwendung von Rahmeneinpassungsoptionen ist, dass die W2MLs mit mindestens mit v4.0.5 R20104 der Comet-Plugins erstellt wurden.

Rahmeneinpassungsoptionen sind die InDesign®-Alternative zu den Gestaltungsregeln von priint:comet. Beide Methoden gleichzeitig zu verwenden, kann zu unvorhergesehenen Ergebnissen führen. Insbesondere in Grafikzellen werden häufig Rahmeneinpassungsoptionen verwendet, um Bilder nach Rahmenänderungen wieder richtig einzupassen. comet_pdf unterstützt die Einstellungen der Rahmeneinpassungsoptionen und führt sie bei Änderungen von Rahmengrößen bei Bedarf automatisch aus.

comet_pdf interpretiert aber die seitlichen Randabstände etwas anders als InDesign®: Abstände, die das Bild nach innen verschieben (oder verkleinern) werden nicht, wie in InDesign®, relativ zur Bildskalierung angewendet. Ein linker Abstand von 10 pt bleibt also ein linker Abstand von 10 pt, unabhängig davon, ob das Bild in 100% oder in 50% gezeigt wird.

Außerdem ist das Verhalten bei unlösbaren Situationen etwas anders.

Eine unlösbare Situation ist z.B. ein 100x100 Bild in einem 100x100 Rahmen mit jeweils 10 pt Seitenrand. Wird der Rahmen jetzt nicht-proportional auf 100x50 verkleinert, muß irgendeine Bedingung fallengelassen werden: 

• ein Seitenabständ
• beide Seitenabstände
• die Bildproportionen.

Für InDesign® haben allem Anschein nach die Seitenabstände zur größeren Bildseite oberste Priorität, in der anderen Dimension kann das Bild dann über den Rahmen hinausragen. Wir konnten das Verhalten aber trotz intensiver Versuche nicht vollständig verhersehbar klären. Aber wie auch immer, für comet_pdf hat die Sichtbarkeit des Bildes Priorität.

Alle Texte der Ausgabe können automatisch übersetzt werden. Für die Übersetzung wird ein von deepl.com zur Verfügung gesteller Online-Service verwendet.

Für die automatische Übersetzung Ihrer Texte wird eine Internet-Verbindung benötigt.

DeepL versucht mit Hilfe sogenannter künstlicher Intelligenz Sätze in ihrem Kontext zu übersetzen. Hier sehen ein beeinruckendes Beispiel für die Übersetzung des Wortes Absatz in unterschiedlichem Kontext:

• Der Absatz hat einen eigene Formatierung. → The paragraph has its own formatting.
• Der Absatz ist abgebrochen.. → The heel is broken off.

Formatierter Text kann aber aus naheliegenden Gründen nur in Bruchstücken (sogenannten chunks) gleicher Formatierung zur Übersetzung geschickt werden. Die Übersetzung wird also besser, je weniger Formatänderungen ein Text enthält.

Aktuell werden von deepL die folgenden Sprachen unterstützt:

• BG - Bulgarisch
• CS - Tschechisch
• DA - Dänisch
• DE - Deutsch
• EL - Griechisch
• EN - Englisch
• ES - Spanisch
• ET - Estnnisch
• FI - Finnisch
• FR - Französisch
• HU - Ungarisch
• ID - Indonesisch
• IT - Italienisch
• JA - Japanisch
• KO - Koreanisch
• LT - Litauisch
• LV - Lettisch
• NB - Norwegisch (Bokmål)
• NL - Holländisch
• PL - Polnisch
• PT - Portugiesisch (alle portugiesischen Varianten gemischt)
• RO - Rumänisch
• RU - Russisch
• SK - Slowakisch
• SL - Slowenisch
• SV - Schwedisch
• TR - Türkisch
• UK - Ukrainisch
• ZH - Chinesisch

Die Ziel-Sprache wird als Kürzel mit der Programmoption --lang LL festgelegt. Beachten Sie biite, dass natürlich auch der Originaltext in einer der angegebenen Sprachen vorliegen muß.

Zur Aktivierung der Übersetzung muss gleichzeitig die Option --deepl definert und gültig sein!

Sie haben sicher Verständnis dafür, dass deepL für seinen Service eine (geringe) Gebühr verlangt. Um eine gültige Lizenz zu erhalten, müssen Sie sich bei deepl.com registrieren. Nach erfolgreicher Anmeldung erhalten Sie einen Lizensierungscode. Diesen Code (und nichts weiter) kopieren Sie in eine Datei. In der Programmoption --deepl path geben Sie den Pfad zu dieser Datei an. Damit steht der Übersetzung dann nichts mehr Weg.

Die Zieldatei kann wahweise PDF oder HTML sein. Geben Sie das gewünschte Zielformat im Parameter --desttype pdf | html an. Standard ist die PDF-Ausgabe.

Achtung: Die HTML-Ausgabe ist zur Zeit lediglich experimentell. Über (realistische) Anregungen und besonders über Lösungsvorschläge freuen wir uns. Aber bitte haben Sie Verständnis, dass der HTML-Export des Renderers zur Zeit nicht Teil des Supports von WERK II oder Partnern ist.

Im Unterschied zum seitenweisen Aufbau einer InDesign®- oder PDF-Datei kennt HTML Seiten überhaupt nicht. Die Größe der Ausgabefläche ist vollkommen unbekannt und im Gegenteil immer wieder unterschiedlich. Ebenso ist die Größe von (Text-)rahmen vom verwendeten Ausgabeprogramm und -rechner abhängig.

Die Anwendung von Funktionen wie "Rahmen anpassen" ist (zumindest bei Textrahmen) vollkommen nutzlos und wird deshalb gar nicht erst versucht. Aus der unbekannten Rahmengröße folgt aber auch, dass die Platzierung von Rahmen an festen Koordinaten in aller Regel nutzlos (oder sogar falsch) ist. Die Ausgabe legt daher lediglich die Abstände der Rahmen zueinander fest.

Da wir auf aufwendige Größenberechnungen weitestgehend verzichten können, ist die Generierung von HTML wesentlich schneller als PDF.

Sehen Sie hier zwei Beispiele von comet_pdf erzeugtem HTML:

Auf Grund der vollkommen unterschiedlichen Welten von Druck und Online, haben sich immer wieder neue Probleme ergeben, die in HTML/CSS/Javscript nicht oder nicht vollständig gelöst werden können. Hier nur eine kleine Aufzählung die keinesfalls Anspruch auf Vollständigkeit erhebt:

• Rahmenkanten: InDesign kennt in Kombination aller Eigenschaften mehr als 1.000 Kantentypen. Vieles davon konnten wir umsetzen. Aber innere Kanten aus mehreren Linien oder gestrichelt mit Transparenz der Kante und des Rahmens und zusätzlichem Blendmode sind jenseits einer allgemeinen Lösung.
• Freiformen: Nein, haben wir noch nicht gemacht. Und, ja, wir kennen SVG.
• Text in nicht-rechteckigen Rahmen: Das ist überhaupt nicht möglich. Und alle "Lösungsvorschläge" im Netz sind ganz eiinfach kompletter Unsinn (Wie überhaupt in der HTML/CSS-Welt nie von Lösungen gesprochen wird, sondern immer nur von Tricks - was ja dann auch eher beunruhigend ist.)
• Inline-Rahmen in Texten : Das geht in Ansätzen. Aber schön ist das nicht.
• Aufzählungspunkte: Das geht, ist aber noch nicht implementiert.

Zur Anassung der HTML-Ausgabe können eigene Style, Skripte, ... vor das Ende <head>-Teil der Datei geschrieben werden. Mit der Angabe --htmlhead path legen Sie dafür eine Datei fest. Der Inhalt dieser Datei wird 1:1 und ohne Änderungen vor das schließende </head> in die Ausgabe-HTML-Datei eingefügt. Damit haben Sie den letzten Zugriff auf die Stilinformationen und Javscript-Funktionen der Ausgabe.

Hinweis: Der sicherste Weg zu einer einfachen Lösung ist sicher, die Ergebnis-HTML in einem HTML-Editor zu öffnen und Ihre Lösungen dort zu testen.

Mit der Angabe --htmlfoot path legen Sie eine Datei fest, deren Inhalt direkt vor das schlieessende </body>- Tag der HTML-Ausgabe eingefügt wird. Wichtige Aufgabe dieser Einfügung ist die Deklaration der verwendeten Schriften, siehe folgender Absatz.

In neueren Versionen von Safari erlaubt Apple nur noch die Verwendung von Schriften, die in der Standardversion des Betriebssystems installiert wurden. Alle anderen Schriften werden ignoriert und durch eine Default-Schrift ersetzt. Eine Liste der erlaubten Schriften finden Sie hier.

Um diesem Problem zu begegnen, haben wir jede Verwendeung der CSS-Definition font-family wie folgt implementiert:

font-family:"SF Compact Display",var(--font-SF_Compact_Display-Bold);

Browser werden also zuerst versuchen, den lokalen Font zu verwenden (und dabei den benötigten Stil selbstständig ermittlen). Schlägt das fehl, wird versucht, den unter der darauf folgenden zugehörigen CSS-Variablen angegebenen Font zu verwenden. Der Name der Variablen wird dabei aus dem Präfix --font plus Fontname plus Schriftschnitt gebildet und mit dem gleichen Font vorbelegt. Der Schriftschnitt Regular wird dabei ignoriert. Leerzeichen und Anführungszeichen werden durch _ (Unterstrich) ersetzt., Fontname und Fontschnitt werden durch - (Minus) getrennt. Hier ein Beispiel:

Ein Dokument verwendet die Schriften Myriad Pro und Arial Unicode MS. Die folgenden Definitionen werden ins HTML geschrieben:

<style>
  :root
  {
    --font-Myriad-Pro : 'Myriad Pro';
    --font-Myriad-Pro-Bold-Condensed : 'Myriad Pro Bold Condensed';
    --font-Myriad-Pro-Bold : 'Myriad Pro Bold';
    --font-Arial-Unicode-MS : 'Arial Unicode MS';
  }
</style>

Um diese Definitionen zu überschreiben, kopieren Sie diesen <style>-Block und ändern die verwendeten Schriften etwa wie folgt:

<style>
  :root
  {
    --font-Myriad-Pro : 'Helvetica Neue';
    --font-Myriad-Pro-Bold-Condensed : 'Helvetica Neue Conndensed Bold';
    --font-Myriad-Pro-Bold : 'Helvetica Neue Bold';
    --font-Arial-Unicode-MS : '-apple-system';
  }
</style>

In den Html-Optionen legen Sie generelle Einstellungen zum Erzeugen des HTML fest. Hier finden Sie eine kommentierte Beispieldatei. Mit --htmloptions path legen Sie fest., ob und welche Konfigurationsdatei Sie verwenden wollen.

Mit --config_path path ändern Sie den Konfigurations-Ordner des Programmes. Alle relativen Pfade wie fontnames.xml, hyphenations, XCache usw. werden dann relativ zu diesem Ordner aufgelöst (und alle Verweise auf app_path dieser Doku zeigen dann auf diesen Ordner). Das ist sinnvoll in Fällen, in denen Sie verschiedene Konfigurationen mit den gleichen Aufrufen verwenden wollen.

Der Parameter path darf mit $DESKTOP, etc. beginnen, darf aber natürlich selbst kein relativer Pfad sein!

Für einen möglichst einfachen Workflow empfehlen wir, allfällige Nachbearbeitungen wie Datenkomprimierung oder Farbanpassungen des fertigen PDFs innerhalb von comet_pdf zu machen.

Dazu steht die DocWatch-Situation "Vor dem Schließen des Dokumentes" zur Verfügung. Dieses Skript wird bei aktivierter Dokumentbeobachtung direkt vor dem Schließen des (W2ML-)Dokumentes ausgeführt. Das Ausgabe-PDF ist zu diesem Zeitpunkt feritg und geschlossen. In dem Skript können Sie mit system::cmd externe Terminal-Programme zur Bearbeitng des PDFs aufrufen.

Das "Vor dem Schließen des Dokumentes"-Skript wird nach dem Erstellen der Meta-Daten ausgeführt. Änderungen, die das Skript am PDF vornimmt, werden alo in den Meta-Daten nicht sichtbar sein!

Ab v4.1.8 R30410 wird das "Vor dem Schließen des Dokumentes"-Skript deshalb ein weiteres Mal direkt vor dem Anlegen der Meta-Daten ausgeführt. Dieser Aufruf wird auch dann gemacht, wenn danach keine Meta-Daten angelegt werden. Um den Aufruf vom allgemeinen Vor dem Schließen-Aufruf zu unterscheiden, ist hier die globale Variable gBeforeMetaData auf den Wert 1 gesetzt. In allen anderen Fällen und in InDesign® ist diese Variable immer gleich 0.

Um bequem auf das erzeugte PDF zugreifen zu können, gibt es (ebenfalls ab v4.1.8 R30410) die globale Variable gDocumentPathPDF.

Beachten Sie bitte unbedingt, dass strukturelle Änderungen am PDF zu Fehlern bei der Generierung der Meta-Daten führen können, weil die Informationen über die Meta-Daten nicht mehr zum PDF passen.

Das folgende Beispiel konvertiert das fertige PDF in ein reines RGB-Dokument. Zur Konvertierung wird Ghostscript verwendet, für das Sie natürlich die erforderlichen Lizenzen besitzen müssen!

int main ()
{
	char		path[4096];
	String		cmd			= string::alloc ();
	String		rgbprofile	= string::alloc ();
	String		iccname		= string::alloc ();
	String 		iccpath		= string::alloc ();
	String		path2		= string::alloc ();
	String		name		= string::alloc ();
	String		tmppath		= string::alloc ();
	int			found		= 0;
	int			i;
	 
	document::path (path, gDocument);
	 
	wlog ("", "# Before close '%s'\n", path);
	 
	if (system::version () > 0)
	{
		// comet_pdf
		//
		if (gBeforeMetaData)
		{
			//Get the current color profile
			//and search for it's complete path
			//
			document::get_color_profiles (gDocument, rgbprofile);
			if (string::length (rgbprofile)) string::set (rgbprofile, "Adobe RGB (1998)");
			 
			for (i = 0; i < color::count_profiles (); i++)
			{
				color::get_nth_profile (0, 0, i, iccname, 0, 0, 0, 0, iccpath);
				if (string::compare (iccname, rgbprofile) == 0)
				{
					found = 1;
					break;
				}
			}
			 
			if (found)
			{
				//Use Ghostscript to apply the new color profile
				//The result must be written to an tmp file
				//
				file::path (path2, gDocumentPathPDF);
				string::set (tmppath, "%s/%s_tmp.pdf", path2, name);

				string::set (cmd, "gs -dSAFER -sOutputFile='%s' ", tmppath);
				string::append (cmd, "-dNOPAUSE -dBATCH -sDEVICE=pdfwrite ");
				string::append (cmd, "-dProcessColorModel=/DeviceRGB ");
				string::append (cmd, "-dColorConversionStrategy=/sRGB ");
				string::append (cmd, "-dColorConversionStrategyForImages=/sRGB ");
				string::append (cmd, "-sOutputICCProfile='%s' ", iccpath);
				string::append (cmd, "-dOverrideICC=true ");
				string::append (cmd, "'%s' ", gDocumentPathPDF);
				string::append (cmd, "> /dev/null"); //Mac and Linux Only
				 
				//Execute the command
				//
				system::cmd (cmd);
				 
				//Remove the original PDF
				//and rename the tmp
				//
				file::name (name, gDocumentPathPDF);
				file::remove (gDocumentPathPDF);
				file::rename (tmppath, name);
			}
		}
	}
	 
	return 0;
}

Comet_pdf kann in Publishing Server integriert werden. Hier finden Sie dazu eine Beschreibung. Der Publishing Server steuert comet_pdf dabei über die Comet API Scripting DOM.

[Ab v5.0 R35720] Comet_pdf unterstützt die Erstellung barrierefreier PDFs für Adobe Acrobat^® und andere PDF-Viewer.

Im Screenshot sehen Sie die sogenannten Tags für die Ein/Ausgabehilfe eines barrierefreien PDFs in Acrobat®. Mit dem rot markierten Button kann die Struktur ein und ausgeblendet werden.

In InDesign^® ist die Option zum Erstellen barrierefreier PDFs etwas versteckt über die Checkbox PDF mit Tags erstellen der PDF-Vorgaben • Allgemein aktivierbar. Mit dem Aktivieren dieser Checkbox wird in den PDF-Vorgaben das Tag /GenerateStructure auf den Wert true gesetzt. Mit der gleichen Defintion in den PDF-Vorgaben von comet_pdf aktivieren Sie auch in comet_pdf das Anlegen der Tags für die Barrierefreiheit:

/GenerateStructure true

Für das Anlegen der Tags für die Barrierefreiheit ist mindestens comet_pdf v5.0 mit PDFlib 10 erforderlich!

Die Tags der Barrierefreiheit können in zwei Reihenfolgen angelegt werden:

• Natürliche Reihenfolge
• Artikelreihenfolge

• document::get_pdf_accessibility_order
• document::set_pdf_accessibility_order

Zur Übernahme der Tag-Reihenfolge in den W2ML-Export von InDesign müssen mindestens priint:comet Plugins v5.0 R35720 verwendet werden!

Die natürliche Reihenfolge geht seitenweise von links oben nach rechts unten und wird automatisch aus den XY-Koordinaten der Rahmen berechnet. Es sind keine weiteren Einstellungen nötig.

Die Artikel und ihre Reihenfolge werden in der Artikel-Palette konfiguriert. Für cScript stehen die folgenden Funktionen zur Verfügung:

• document::get_articels
• document::articles::count, ...
• document::article::create, ...

Mit Hilfe des InDesign^®-Dialoges Objekt -> Objektexportoptionen... kann eingestellt werden, welche Informationen eines Rahmens in den Tags für den barrierefreien Zugang enthalten sein sollen. Für cScript stehen die dafür folgenden Funktionen zur Verfügung:

• frame::set_pdf_accessibility
• frame::get_pdf_accessibility
• frame::set_alt
• frame::get_alt

Artikel können vom Export ausgeschlossen sein (siehe document::article::set/get_use_for_export). InDesign^® exportiert in diesem Fall trotzdem alle Inhalte (Rahmen) des Artikels. Lediglich der Artikel-Tag wird nicht in die Tag-Struktur eingefügt. In comet_pdf können Sie mit dem (nicht für InDesign definierten) Tag /OmitItemsOfUnusedArticles der PDF-Vorgaben das Verhalten steuern:

/OmitItemsOfUnusedArticles true | false

Das Tag /OmitItemsOfUnusedArticles wird von InDesign^® ignoriert. Die Inhalte nicht exportierter Artikel werden von InDesign^® immer ins Zieldokument exportiert.

Dokumentinhalte (Rahmen) müssen nicht zwangsweise einem Artikel zugewiesen sein. InDesign^® exportiert diese artikellosen Inhalte trotzdem. Die Rahmen bekommen lediglich keine Artikel-Tags in der Tag-Struktur. In comet_pdf können Sie mit dem (nicht für InDesign definierten) Tag /OmitArticlelessItems steuern, ob diese Rahmen exportiert werden sollen oder nicht:

/OmitArticlelessItems true | false

Das Tag /OmitArticlelessItems wird von InDesign^® ignoriert. Die Inhalte von Rahmen, die keinem Artikel zugewiesen sind, werden von InDesign^® immer ins Zieldokument exportiert.

Einige (seltene) Situationen können vom Renderer nicht 1:1 zu InDesign® nachgebaut werden.

Bei Texten mit Inlines werden zuerst die Inlines gezeichnet, dann der Text. Inlines mit negativem Zeilen-Offset werden dadurch mglw. von folgendem Text überdeckt:

Hier ein Screenshot. "quam labo. Nam," gehört zum Text, nicht zum Inline. Es überdeckt den grünen Inline.

Anders verhält sich dagegen eine Text-Unterstreichung. Die liegt dahinter:

Genau genommen nicht okay. Comet_pdf zeichnet daher die Unterstreichung ebenfalls über den Inline:

Noch verwirrender sind Inlines Über der Zeile mit negativem "Abstand danach".

Text, der vor dem Anker liegt, wird vom Inline überdeckt. Text hinter dem Anker überdeckt dagegen den Inline:

comet_pdf zeichnet Inline Über der Zeile vollständig hinter den umgebenenden Text:

Sie haben einen Text mit einem Inline, der breiter als der Textrahmen ist. InDesign® zeichnet in diesem Fall über den rechten Rand des Textrahmens hinaus. Hier eine Abbildung:

Streng genommen ist das natürlich nicht in Ordnung. Von comet_pdf werden solche Inlines daher nicht gezeichnet.

Diese Fehler sind nur schwer zu finden. Das Programm schreibt daher eine Fehlermeldung in die Konsole:

Error while drawing inline -48 in text frame -45. Check whether the text frame is big enough!
    You may use option -a u to find the text frame in the document.

Im Screenshot sehen Sie Aufzählungspunkte in InDesign® (links) und comet_pfd (rechts):

Dass die erste Zeile der Aufzählungspunkte in InDesign® jeweils weniger eingerückt ist, liegt hier daran, dass der verwendete Absatzstil bei 8,5 einen Tab definiert, aber den linken Einzug mit 18 definiert. Durch den Tabulator springt die Einrückung also vor den eigentlichen Wert. Das kann von comet_pdf nicht umgesetzt werden.

Merkwürdige Effekte können Umrahmungen gekrümmter Formen erzeugen. Hier ein Beispiel bei dem offenbar einiges schief gegangen ist:

comet_pdf stellt diese Form so dar (kann aber dafür längst nicht so viele Dinge wie InDesign®, siehe hier):

[ab v4.2 R31360] Im Bild sehen Sie einen Screenshot aus InDesign® mit einer Linie mit Pfeilen an Anfang und Ende. Dabei fallen zwei Dinge auf:

1. Die Boundingbox der Linie enthält auch die Pfeilspitzen. Daraus folgt:
   1. Die dargestellte Gerade ist im Vergleich zur definerten Gerade im allgemeinen (leicht) verdreht.
   2. Der Anstieg der dargetsellten Gerade verändert sich mit der verwendeten Linienstärke.
2. Zumindest bei genügender Linienstärke ist die Darstellung der Spitzen nicht mehr so ganz richtig.

Wir vermuten, dass der Zielpunkt eines Pfeiles in der Regel wichtiger ist als seine "Schrägheit". In comet_pdf verdrehen wir die Linien daher genauso wie InDesing® das macht. Bei den Spitzen selbst haben wir uns aber für eine korrekte Darstellung entschieden. Hier ein Screenshot von comet_pdf.

In einigen PDF-Viewern können in kleinen Skalierungen merkwürdige Darstellungen inbesondere bei den Linien um Tabellenzellen entstehen. Hier ein Screenshot eines Tabellenteiles aus Adobe® Acrobat® X (10.1.9, Mac):     

    
    Screenshot einer comet_pdf-Datei

Wie Sie sehen, werden die horizontalen Linien am rechten Rand der roten Tabelle offenbar zu weit gezeichnet. In größeren Skalierungen verschwindet dieser Fehler. Es handelt sich hier um ein reines Darstellungsproblem! Zum Vergleich hier ein weiterer Screenshot aus dem gleichen Programm mit der gleichen Skalierung. Die PDF-Datei wurde diesmal mit Hilfe des PDF-Exportes von InDesign® CS6 erzeugt:

    
    Screenshot eines InDesign®-PDF-Exportes

Comet_pdf benutzt die gleichen Datenverbindungen wie die Comet-Plugins. Zur Definition der Datenverbindung verwenden Sie exakt die gleiche Datei connections.xml, die Sie auch für Adobe InDesign® Server verwenden. Die Datenverbindung wird mit nach dem Start von comet_pdf automatisch aus den Angaben in dieser Datei hergestellt. Sie geben beim Start von comet_pdf mit Hilfe der Option -l (--login) lediglich den Verbindungsnamen aus connections.xml an.

Die Datei connections.xml muss sich, wenn nichts anderes angegeben ist, neben dem Programm comet_pdf befinden. Mit der Option -c (--connection) können Sie aber auch auf eine beliebige andere Datei im angegebenen XML-Format verweisen.

Hier ein Beispiel für einen Eintrag aus connections.xml

<connection>
 	<id>1</id>
 	<name>demo</name>
 	<type>odbc_utf8</type>
 	<server>demo</server>
 	<user>demo</user>
 	<password></password>
 	<PASSWORD>GwK3Ww4Oq+p1LKI=</PASSWORD>
 	<db>comet_config</db>
 	<lang></lang>
 	<client></client>
 	<passcredentials></passcredentials>
</connection>

Die Angaben für einen Eintrag aus connections.xml entsprechen den Angaben der Datei xloginhistory.xml Ihres Comet-Plugin-Ordners. Enthält diese Datei keine Angaben zur gewünschten Verbindung, können Sie die Verbindung mit dem - Button des Logins-Dialoges sichern. Lediglich das Passwort müssen Sie noch eintragen.

Auf Grund eines Fehlers bei der Einführung der connections.xml sind in der XML die Angaben für lang und client leider vertauscht. Wenn Sie die Datei manuell bearbeiten, achten Sie also bitte darauf, dass im Element <lang> der Mandant/Client eingetragen wird und im Element <client> die verwendete Sprache.

Passwörter können im Klartext (Element password) oder verschlüsselt (Element PASSWORD) angegeben werden. Wenn Sie die verschlüsselte Version verwenden, lassen Sie die Klartext-Version einfach leer (Das Element <password> darf aber nicht entfernt werden. Wie Sie die Verschlüsslung eines Passwort ermitteln können, erfahren Sie hier.

Verwenden Sie einen Eintrag aus connections.xml und Einzelangaben zur Datenverbindung überdecken diese Angaben die Angaben der connections.xml.

Passwörter können verschlüsselt angegeben werden. Um die Verschlüsselung eines Passwort zu ermitteln, rufen Sie das Programm comet_pdf einmal mit der Option

comet_pdf --crypto myPassword

auf. Das verschlüsselte Passwort wird in die Programmausgabe (und, wenn aktiviert, ins Logfile) geschrieben:

Password : 'myPassword'
Crypto   : 'GwK3Ww4Oq+p1LKI='

Geben Sie hier einen Ordner an, in den comet_pdf temporäre Dateien schreiben darf. Jeder Programmstart erzeugt dabei einen eigenen Unterordner im angegebenen Ordner. Als Ordnername wird dabei jeweils die PID des Prozesses verwendet. Bei Programmende wird dieser Ordner wieder gelöscht.

(ab 4.1.7 R27027) Ein dem Pfad vorangestelltes Ausrufezeichen ('!') erlaubt die Angabe eines "festen" Ordners - sowohl absolut als auch relativ. In diesem Falle wird kein Unterordner mit der jeweiligen Prozess-ID erzeugt, das setzt allerdings voraus, dass in der Ansteuerung sichergestellt wird, dass nicht mehrere Renderer Prozesse gleichzeitig auf denselben Ordner zugreifen.

Wurde keine Angabe gemacht, wird im Ordner von comet_pdf automatisch der Unterordner XCache angelegt.

Der Ordner XCache und seine Unterordner dürfen nur gelöscht werden, wenn der zugehörige comet_pdf Prozess beendet ist.

(ab 4.1.7 R27027) Zwischenspeichern der von einem PublishingServer heruntergeladenen Konfigurationsdateien. Dies erfordert PublishingServer >= Version 4.1.8

Die Dateien werden in einem Unterordner des XCache-Ordners abgelegt. Sofern der beim nächsten Verwendung dieser Verbindung keine zwischenzeitlichen Änderungen des Servers vorliegen, werden diese aus dem lokalen Verziechnis gelesen, statt erneut vom Server anzufordern.

Hierfür muss

• beim nächsten Programmstart wieder derselbe XCache Ordner verwendet werden
• der Ordner nach Programmende erhalten bleiben

Beides erreichen Sie durch Angabe des --cache Wert mit vorangestelltem Ausrufezeichen ('!'), also z.B. --cache !tmp/pdf_instance1. Details siehe unter Cache

Welcher XML-Parser soll verwendet werden, wenn XML gelesen werden soll? (Hier finden Sie Informationen über die verwendeten XML-Parser.)

Folgende Möglichkeiten sind verfügbar :

• classic :
  • Windows : msxml
  • Mac : CoreFoundation CFXMLParser
  
  
• optimized :
  • Unter Windows ist die Einstellung gleichbedeutend mit classic.
  • Unter Mac wird ein Fehler im CoreFoundation-Parser korrigiert, der verursacht, dass &lt;...&gt; im laufenden Text als eigene Entities interpretiert werden. Dadurch gehen alle Leerzeichen vor und hinter diesem Textteil verloren. Mit optimized werden Whitespaces um Unicode-Zeichen der Form <0xXXXX> geschützt. ACHTUNG: Es werden ausschließlich Entities der Art <0xXXXX> berücksichtigt. Im TaggedText "aaa<cSize:72.000000> <cSize:>bbb" geht das Leerzeichen zwischen aaa und bbb weiterhin verloren.
    
  
  
• fast : In den Renderer integrierter schneller und systemunabhängiger XML-Parser. Der Parser ist etwa 50% schneller als der CoreFoundation-Parser und msxml.

Default ist der XMLParser fast. Unter Linux ist ausschließlich der XMLParser fast verfügbar. Andere Parser-Einstellungen werden unter Linux ignoriert.

Geben Sie hier einen vollständigen Pfad auf die Datei an, in der aufgebaut werden soll. Die Datei muss im Format W2ML vorliegen und sollte insbesondere die Definitionen der verwendeten Farben, Zeichen- und Absatzstile und Ebenen enthalten. Wird keine Datei angegeben, wird in einer neuen, leeren Datei aufgebaut.

Viele Platzhalter-Skripte verwenden zum Erstellen sprachabhängiger Ausgaben den Namen der aktuellen Zielebene. Wenn Sie ohne Eingabedatei starten, wird es diese Ebene voraussichtlich nicht geben (sondern nur die Standardebene 'Layer 1'). In diesem Fall können Sie gewünschte Sprachkennnung auch mit Hilfe der Option -y (--layer) festlegen.

Um ein InDesign®-Dokument als w2ml zu speichern, verwenden Sie den InDesign®-Menübefehl Datei -> Exportieren.... Im erscheinenden Export-Dialog wählen Sie dann das Format Comet Austauschformat (w2ml)

Bildverweise in W2ML-Dateien werden immer mit einem vollständigen Pfad beschrieben. Aus verschiedenen Gründen muß die Bilddatei aber nicht an der angegebenen Stelle liegen. InDesign® warnt Sie vor nicht aufgelösten Bildpfaden und verwendet dann (wenn möglich) ein eingebettetes Preview. Dieses Verhalten wird von comet_pdf nicht unterstützt,! Comet_pdf versucht aber, das Bild an anderer Stelle zu finden. Dabei wird zuerst folgendes versucht:

Hat die W2ML-Datei einen definierten Pfad der InDesign®-Originaldatei (psc:elementlist:documentPath) und beginnt der Bildpfad mit genau diesem Pfad, dann wird dieser Pfadteil ersetzt durch den Ordner, in dem sich die W2ML befindet. In diesem Ordner wird dann nach dem Bild gesucht^{*siehe am Ende das Absatzes}. Dieses Vorgehen entspricht dem "Verpacken" von InDesign®-Dateien.

Beispiel

Der Ordner 111 enthält die Datei tst.indd und den Unterordner Bilder mit dem Bild 111.png:
    
In tst.indd wird dieses Bild verwendet. Wird aus tst.indd jetzt eine W2ML erzeugt und im selben Ordner abgelegt, dann steht in dieser Datei:

    - Dokumentpfad "Pfad_zu_111/111"
    - Bildpfad "Pfad_zu_111/111/Bilder/111.png".

Jetzt wird der Ordner 111 verschoben oder umbenannt. Kein Problem für InDesign®. Aber das Bild "Pfad_zu_111/111/Bilder/111.png" gibt es ja gar nicht mehr. Jedenfalls nicht am angegebenen Pfad.

Deshalb wird der Pfadteil vor 111.png ersetzt durch den aktuellen Pfad von tst.w2ml. Und dieses Bild gibt es.

Wird das Bild auf diese Weise nicht gefunden, können weitere Pfade durchsucht werden^*. Diese Pfade geben Sie mit der Option -f an. Sie haben dabei drei Möglichkeiten:

1. Einfacher Pfad. Der Pfad darf mit den oben beschriebenen Abkürzungen $DESKTOP, ... beginnen und darf nicht auf / oder .xml enden. Dann wird genau in diesem Ordner gesucht.
2. * am Ende des Pfades. Dann werden dieser Ordner und alle seine Unterordner durchsucht.
3. Geben Sie einen Pfad auf eine XML-Datei mit den gewünschten Ordnern an. In diesem Fall muß die Angabe mit .xml enden. Die Datei muß folgendes Format haben:
   
   

   <?xml version="1.0" encoding="utf-8"?>
   <folders>
   		<folder>$DESKTOP/111</folder>
   		<folder>$DESKTOP/aaa*</folder>
   </folders>

   Auch hier gilt : Kein / am Ende. Mit * am Ende wird rekursiv gesucht. Beim ersten gefundenen Bild wird die Suche abgebrochen.
   
   Zusätzlich zu den Standard-Abküzungen können Sie auch auf alle Alias-Namen zugreifen, die im aktuellen Datenpool definiert sind. Hier finden Sie Informationen zur Definition und Verwendung von Alias-Namen für Pfade.

Alle Angaben aus -f Optionen werden addiert und die Ordner werden genau in der Reihenfolge durchsucht, in der sie definiert wurden.

Achtung : Rekursive Pfade (* am Ende) sollten aus mehreren Gründen sparsam eingesetzt werden und so lang wie möglich sein:

• Bei großen Unterstrukturen kann die Suche einige Zeit in Anspruch nehmen. Und bei der Suche Ausweichformaten von Postscript-Bildern multipliziert sich dieser Aufwand!
• Je mehr Ordner Sie durchsuchen lassen, desto größer ist die Wahrscheinlichkeit, dass Bildnamen nicht eindeutig sind und Sie ein falsches finden.

^* Für EPS-Bilder gilt dabei: Es wird nicht nach der EPS-Datei selbst gesucht sondern der Reihenfolge nach nach allen definierten Ausweichformaten. Zeigt der Bildpfad bspw. auf die Datei aaa.eps, wird in allen Ordnern, in denen nach Bildern gesucht werden kann, nicht nach aaa.eps gesucht, sondern der Reihe nach nach allen definierten Ausweichformaten, also etwa nach aaa.pdf, aaa.png, aaa.tif usw.. Das erste gefundene Bild wird verwendet.

Fehlende und (serverseitig) geänderte Bilder von URL-Links können beim Öffnen von Dokumenten automatisch neu geladen werden. Wie in InDesign® werden die geladenen Bilder im Ordner dateiname_links neben dem Dokument abgelegt.. Aktivieren Sie die Bildaktualisierung mit der Option

--urllink_update verhalten

Als Verhalten kann einer der folgenden Werte angegeben werden:

• off : URL-Links bleiben unverändert
• missing : Fehlende Bilder werden geladen
• all : Fehlende und (serverseitig) geänderte Bilder werden geladen

Bitte beachten Sie, dass (wie in InDesign® auch) URL-Links von Templates nicht automatisch aktualisiert werden.

Den Pfad und Namen der gewünschten Ausgabedatei geben Sie mit der Option -o (--output) an. Die Endung pdf wird nicht automatisch angefügt.

Existiert im Zielordner eine Datei gleichen Namens wird sie überschrieben!

Fehlt die Option wird eine Ausgabedatei wie folgt erzeugt:

• Mit der Option -i wurde eine Eingabedatei angegeben. Dann wird die Ausgabe im gleichen Ordner und mit dem gleichen Namen aber mit der Endung pdf abgelegt.
• Es wurde keine Eingabedatei angeben. Dann wird als Pfad und Namensbasis die Produktliste (Option -p) verwendet.

Mitunter kann es hilfreich sein, die UIDs, Ebenen und Textketten des erzeugten PDFs zu sehen. Mit der Option -a (--adorns) können Sie verschiedene Dokumenteigenschaften sichtbar machen. Geben Sie dazu als Wert für die Option einen String bestehend aus beliebigen Buchstaben der ersten Spalte der folgenden Tabelle an. Ein gültiger String wäre also tofu.

Mit dem Wert i können unsichtbare Zeichen im Text dargestellt werden. Die folgenden Zeichen werden zur Darstellung verwendet:

Softreturns werden in der Ausgabe nicht enthalten sein, sie müssen aus technischen Gründen für die PDF-Ausgabe in Hardreturns umgewandelt werden. Die nötigen Absatzeinstellungen werden vor der Ersetzung natürlich übernommen.

Hier ein Beispiel mit -ai:

Hier ein Beispiel mit -a ufoe:

Bearbeiten der Eingabedatei. Sie können die Eingabedatei auf drei Arten direkt bearbeiten:

• -e place : Platzieren eines Produktes. In diesem Fall müssen in den Optionen -q und -t zusätzlich Produkt und Template definiert werden.
• -e ID : ID einer Action des aktuellen Datenpools. In diesem Fall muß in der Option -l eine Datenverbindung definiert sein.
• -e path : Ausführen der Scriptdatei path. Die Datei muss dafür natürlich existieren und ein gültiges unverschlüsseltes Skript enthalten.

Die ausgeführte Aktion kann auf die folgenden globalen Variablen zugreifen:

int gParams1Int = 1;
int gParams2Int = 23;
int gParams3Int = 0;
int gParams4Int = 0;

float gParams1Float = 1.0;
float gParams2Float = 23.4;
float gParams3Float = 0.0
float gParams4Float = 0.0

char gParams1String [] = "1";
char gParams2String [] = "23.4";
char gParams3String [] = "hallo";
char gParams4String [] = "";

Die häufigste Aktion wird das Platzieren eines einzelnen Produktes sein. Für diese Aktion gibt es deshalb die Standardangabe -e place. Die Aktion platziert ein gegebenes Template an einer gegebenen XY-Position auf der ersten Seite des Ausgabe-Dokumentes und lädt dieses Template mit einem Produkt.

Für die Standard-Aktion place müssen die Optionen -q und -t zur Festlegung von Produkt-ID und Template definiert sein.

Hier ein Beispiel zur Verwendung der Option -e:

comet_pdf -e place -q "12 0 0 '115607'" -t "188 36.0 36.0" ...

Comet_pdf unterstützt die Comet API Scriptschnittstelle, mit der unter anderem das White board arbeitet. Anweisungen können mit der Option -j (--comet-api) gemacht werden. Als Eingabe wird der Pfad auf eine XML-Datei mit den API-Aufrufen und deren Parametern erwartet. Eine Beschreibung des ewarteten XML-Formates, Funktionsbeschreibungen und Beispiele finden Sie hier.

In den Comet-Plugins können globale Variablen über die Palette Einstellungen geändert werden. Eine andere häufig benutzte Möglichkeit sind modale Dialoge von cScript. Beides kann vom Renderer aus naheliegenden Gründen nicht umgesetzt werden. Um trotzdem äußere Umgebungen zu ändern, können im Aufruf des Renderer globalen Variablen aktuelle Werte zugewiesen werden. Diese Werte gelten jeweils nur lokal für diesen einen Renderer. Die Werte werden nicht im Datenbestand geändert! Zusätzlich können eigene, nur in diesem Renderer-Lauf definierte Variablen festgelegt werden.

Es können beliebig viele globale Variablen festgelegt werden. Jede Definition wird mit einer eigenen -g-Option gemacht. Für -g wird folgende Syntax erwartet:

Definition = [Type] Name "=" Value
Type       = "int" | "float" | ("char" "*") / str
Name       = IDENTIFIER
Value      = VALUE_OF_TYPE


Für Type kann der Wert "char *" oder str verwendet werden um sowohl in cScript als auch Python Zeichenketten als Datentyp festzulegen.
IDENTIFIER ist der Name der globalen Variable. Er muss also den Regeln für cScript/Python-Bezeichner genügen.
VALUE_OF_TYPE ist der Wert, den die Variable bekommen soll. Strings werden dabei in Anführungszeichen gesetzt.

Alle Definitionen werden direkt nach dem Login und VOR dem Loginskript (Panelstatement 92) ausgeführt. Sie können also bereits im Loginskript auf die globalen Variablen zugreifen.

Existiert eine globale Variable im Datenbestand, wird deren Wert überschrieben.

• cScript: Der Datentyp bestehender globaler Variablen wird nicht geändert. Eventuelle Typangaben werden hier also ignoriert und der angegebene Wert muß zum Datentyp passen. Bei Bedarf wird der Wert konvertiert.
• Python: Der Datentyp der Variable wird bei Bedarf geändert.

Existiert noch keine globale Variablen des gewünschten Namens, wird eine neue Variable des angegebenen Types angelegt.

• cScript: Die Typangabe ist hier zwingend.
• Python: Die Typangabe ist nicht ungedingt notwendig.

Der neuen Variablen wird dann der gewünschte Wert zugewiesen (der auch hier bei Bedarf konvertiert wird.).

Alle Variablen-Änderungen gelten temporär nur für den ausführenden Renderer. Parallel ausgeführte Renderer dürfen unterschiedliche Werte festlegen.

Der folgende Aufruf definiert/ändert vier globale Variablen:

comet_pdf .... -g gInt=1234 -g gStr="hallo hallo" -g "char * myGStr = 'asdasd'" -g "int gPub=120045" -g "str myGStr2 = 'Hello World'"

Das folgende Beispiel zeigt, wie mit einem Dialog umgegangen werden kann. Im Datenbestand muss dazu die globale Variable gPub definiert sein. Diese Variable wird mit einer -g-Option auf den gewünschten Wert gesetzt. Das Skript, das dann den aktuellen Wert für Publikationen abfragen soll, setzt einfach vorher die entsprechende Rückgabevariable (hier pub) auf den gesetzten Wert aus -g. Das folgende askstring2 wird in InDesign® vom Benutzer beantwortet. Im Renderer wird es ignoriert. Die Variable pub hat also danach den gewünschten Wert:

Aufruf mit comet_pdf .... -g gPub=120045

pub = gPub;

ok = askstring2 (
	"", "",
	0, "", "",
	0,
	0, "", "",
	&pub,
	"Publikation auswählen", 1,
	"Kontext wählen",
	"Ok", "Abbrechen", 0, 0,
	publications);

Mit welchem Produkt soll ein Template geladen werden? Die Option wird bei Verwendung der Option -e (Ausführen einer Aktion) ausgewertet. In der Aktion kann mit Hilfe der Variablen gRecordID, ... auf die Produkt-ID zugegriffen werden.

Die Produkt-ID wird im folgenden Format erwartet:

-q "12 0 0 'stringid'"

Beachten Sie bitte, dass Sie mind. die Option -e place setzen müssen, um das Produkt tatsächlich zu platzieren.

Mit welchem Template soll ein Produkt aufgebaut werden? Die Option wird bei Verwendung der Option -e (Ausführen einer Aktion) ausgewertet. In der Aktion kann mit Hilfe der Variablen gTemplateID, gPosX und gPosY auf die Angaben der Option zugegriffen werden.

Die Template-ID wird im folgenden Format erwartet. Die Angabe der Position ist optional. Fehlt sie, wird an der Position (0.0, 0.0) platziert. Die Positionsangaben müssen als float-Zahlen (also mit Dezimalpunkt) angegeben werden.

-t "188 36.0 36.0"

Beachten Sie bitte, dass Sie mind. die Option -e place setzen müssen, um das Produkt tatsächlich zu platzieren.

Der Seitenanschnitt kann mit Hilfe einer PDF-Vorgabe (joboptions-Datei) festgelegt werden. Wählen Sie für den Anschnitt den Reiter Marken und Anschnitt des InDesig®n-Dialoges für PDF-Vorgaben. In comet_pdf kann mit der Option -z auf diese Vorgabedateien verwiesen werden. Weitere Informationen zur Verwendung von PDF-Vorgaben finden Sie hier..

Druckermarken können mit Hilfe einer PDF-Vorgabe (joboptions-Datei) festgelegt werden. Wählen Sie für den Anschnitt den Reiter Marken und Anschnitt des InDesign®-Dialoges für PDF-Vorgaben. In comet_pdf kann mit der Option -z auf diese Vorgabedateien verwiesen werden. Weitere Informationen zur Verwendung von PDF-Vorgaben finden Sie hier..

[Since v4.3 R35256] Die PDF-Kompatibilität wird im Parameter /CheckCompliance des PDF-Presets eingestellt. Folgende Angaben werden unterstützt. Die Angaben sind case insensitive:

/CheckCompliance	Konform zu
[PDFX4...]	PDF/X-4
[PDFX5...]	PDF/X-5n
[PDFA1A...]	PDF/A-1a:2005
[PDFA1B...]	PDF/A-1b:2005
[PDFA2A...]	PDF/A-2a
[PDFA2B...]	PDF/A-2b
[PDFA3A...]	PDF/A-3a
[PDFA3B...]	PDF/A-23b

Hier ein Beispiel:

 /CheckCompliance [
    /PDFX4:2010
]

[Ab v4.3 R35256] Für PDFX/4 und höher wird ein CMYK ICC-Farbprofil als sogenannter Output Intent erwartet. Die Angabe des Output Intent ist zwingend und muß ein CMYK-Farbprofil sein. Bitte beachten Sie:

• Ist das angegebene Profil kein CMYK, kann kein PDF erzeugt werden!
• Fehlt die Angabe des Farbprofiles, wird die Option PDFX/N abgeschaltet und ein nicht-standardisiertes PDF erzeugt.

Die Angabe des Farbprofiles erfolgt über das Attribut /PDFXOutputIntentProfileSelector. Informationen zur Definition verwendeter Farbprofile finden Sie hier. Folgende Angaben sind möglich:

/PDFXOutputIntentProfile (My ICC \050a\051)

Fehlt die Angabe /UseName, wird das Farbprofil des Dokumentes verwendet. Fehlt auch das Farbprofil des Dokumentes, wird die Angabe aus --working_icc verwendet. Ist auch diese Angabe leer, wird ein einfaches PDF ohne PDFX/4-Kompatibilität erzeugt.

Verwendete RGB-Farben im Dokument werden mit Hilfe des RGB-Farbprofiles des Dokumentes (settings.rgb_colorprofile) automatisch in CMYK umgerechnet.

Mit der Option

--presets out_path

können alle verfügbaren Standard-PDF-Presets in eine Ausgabedatei geschrieben werden. Die Datei enthält die Namen der PDF-Presets, die im Standardordner settings/pdfprofiles neben comet_pdf enthalten sind. Die Einträge sind zeilenweise getrennt und werden ohne die Endung .joboptions und ohne [Klammern] ausgegegen. Nach der Ausgabe wird das Programm beendet.

Ist die Option gesetzt, werden die Seiten der Ausgabedatei auf ihren tatsächlichen Inhalt beschnitten. Leere Seiten werden nicht beschnitten.

Folgende Angaben sind möglich:

Durch den Beschnitt der Seiten entstehen in der Regel unterschiedlich große Seiten im PDF.

Die Option erwartet keine weiteren Angaben. Ist sie gesetzt, wird die erzeugte PDF-Datei am Ende automatisch geöffnet.

Die Option erwartet keine weiteren Angaben. Ist sie gesetzt, wird die erzeugte PDF-Datei am Ende NICHT automatisch geöffnet. Der Parameter ist sinnvoll bei der Verwendung von Shortcuts, die Autolaunch aktiviert haben: Mit -N kann das Öffnen der erzeugten PDF-Datei trotzdem unterdrückt werden.

Die Option erwartet keine weiteren Angaben. Ist sie gesetzt, werden Comet-Notizen der Eingabedatei als PDF-Notizen im PDF angelegt. Sonst werden die Comet-Notizen ignoriert.

Um Comet-Notizen zeigen zu können, müssen die w2ml-Dateien mind. mit v3.4 R9200 der Comet-Plugins erzeugt worden sein.

Im Normallfall generiert der Renderer einzelne Seiten. Mit der Option --spreadwise erreichen Sie, dass Seiten eines Spreads zu einer (entsprechend breiteren) Seite zusammengefasst werden. The result corresponds to the General:Spreads setting of the InDesign® PDF export.

Bitte beachten Sie, dass die auf diese Weise erstellten Seiten nur wie Doppelseiten aussehen. In Wirklichkeit sind diese Seiten jedoch Einzelseiten im PDF.

Um Seiten im PDF als Doppelseiten anzuordnen, verwenden Sie die Option /PageLayout der PDF-Presets.

Mit dieser Option kann zusätzlich zur PDF-Ausgabe des erzeugten Dokumentes auch eine w2ml-Version geschrieben werden. Diese Option ist immer dann sinnvoll, wenn Dokumente in mehreren Arbeitsschritten (z.B. im Whiteboard) bearbeitet werden. Die w2ml wird direkt "neben" das erzeugte PDF gelegt und bekommt die Endung w2ml.

[seit v4.1.6 R25001] Sichern der fertig verarbeiteten W2ML-Eingabedatei als Kopie am angegebenen (vollständigen) Pfad. Relative Pfade werden relativ zum Ordner des Programmes aufgelöst. $DESKTOP et. al sind erlaubt.

Achten Sie darauf, dass im Mac-Terminal das $-Zeichen mit \ maskiert werden muß!

Nach dem Erzeugen des PDFs können die priint-Metadaten des Dokumentes erzeugt werden. Die Metadaten werden "neben" das erzeugte PDF im Ordner name.pdf.metadata abgelegt. Existiert dieser Ordner, wird er vorher gelöscht. Hier der Screenshot eines vollständigen Metadata-Ordners:

Folgende Optionen sind möglich:

Die Werte können addiert werden. Mit der Angabe 5 erzeugen Sie die Datei name.pdf.metadata.zip. Das Zip enthält keine Previews der Cometgruppen. Soll das ZIP auch die Previews der Cometgruppen enthalten, verwenden Sie als Optionswert die 7.

Metadata-Previews sind Raster-Bilder. Um diese Bilder aus den PDFs zu erzeugen, ist spezielle Software nötig. Die Berechnung von Rasterbildern aus PDFs wird deshalb über das von Ihnen anpassbare cScript imgconv/pdf2image.cpp ausgeführt. Sie können:

1. Die Bearbeitung an das Programm zurückgeben. In diesm Fall berechnet comet_pdf die Previews mit eingebauten Standardmethoden. Nachteil ist, dass Sie an Stanardlösungen gebunden sind für die Sie mglw. weitere Lizenzgebühren zahlen müssen oder die nicht Ihren Erwartugen entsprechen.
2. Die Previews direkt im Skript erstellen. Voraussetzung ist natürlich, dass Sie über geeignete und lizensierte Software dafür verfügen.

Eine zweite Anwednung des Skriptes sind die automatischen Konvertierungen von Vektorbildern in Rasterbilder bzw. PDF. In diesen Fällen sind die Variablen gFormat und gResolution leer und Sie können die Eingabedateien in beliebige Formate mit beliebiger Auflösung konvertieren:

• gFormat = ""
• gResolution = 0.0

Die folgenden globalen Variablen sind im Skript definiert:

Das Skript enthält einige vorbereitete Konvertierugsfunktionen. Beachten Sie bitte, dass für die hier verwendete Software Lizenzgebühren anfallen können. Diese Lizenzgebühren sind nicht im Preis von comet_pdf enthalten, für die ordnungsgemäße Lizensierung der Software müssen Sie also selbst sorgen!

Das Programm gehört zur Standard-Installation des Mac OS und kann lizenzfrei verwendet werden. Für andere Betriebssysteme ist es leider nichgt verfügbar.

Das Programm ist nur für Windows verfügbar. Zur Generierung von Previews aus PDFs wird pdftoimage.exe verwendet. Ohne Lizenz erhalten die Bilder aber Wasserzeichen. Um die Wasserzeichen zu entfernen, ist eine Lizenz nötig (PDF To IMAGE ( Command Line )). So installieren Sie die erhaltene Lizenz:

1. Öffnen Sie die erhaltene Lizenzdatei
2. Öffnen Sie die Datei \imgconv\pdftoimage\licensekey.txt Ihrer comet_pdf Installation.
3. Kopieren Sie den Inhalt aus Datei 1 in Datei 2. Achtung : Fügen Sie keine weiteren Leerzeichen, Zeilentrenner oder Absatztrenner ein.
4. Sichern Sie Datei 2.

Ghostscript und ImageMagick sind für alle Betriebssysteme verfügbar. Es gibt unterschiedliche Lizenzmodelle, bei denen wir Ihnen leider keine Vorschläge machen können.

Mit dieser Option ist es möglich, aus den Seiten beliebiger PDFs ein neues PDF zu komponieren. Der Aufbau der Datei erfolgt immer als letzter Programmschritt. Als Zieldatei wird die aktuelle PDF-Ausgabe des Renderer verwendet. Eingabe der Option ist der Pfad auf eine "Partitur" in XML mit folgender Syntax:

<?xml version="1.0" encoding="utf-8"?>
<parts>
	<part path="..." pages="..."/>
	...
</parts>

Folgende Angaben für path und pages werden unterstützt:

Neukompositionen von PDFs sind auch ohne w2ml-Eingabe möglich. Für den folgenden Aufruf müssen sich die Datei mmm.xml und die PDFs aaa.pdf und bbb.pdf auf dem Desktop befinden. Aus diesen Angaben wird die neue Datei ccc.pdf erzeugt:

comet_pdf -m /Users/paul/Desktop/mmm.xml -o /Users/paul/Desktop/ccc.pdf

Es werden zwei Arten des Zusammenfügens unterstützt:

1. Einzelseiten : Bei Verwendung der Parameter -M bzw. --Merge oder wenn mind. eine Quelldatei nicht vollständig übernommen werden soll.
2. Vollständige Dateien : Bei Verwendung der Parameter -m bzw. --merge und wenn alle Quelldateien vollständig übernommen werden sollen.

Die Optionen -M bzw. --Merge sind ab v5.0 R36730 verfügbar.

Die Einzelseiten-Komposition wird angewendet, wenn mindestens eine Datei nicht vollständig ins Ziel übernommen werden soll. Ab v5.0 R36730 können Sie die Einzelseiten-Komposition darüber hinaus auch mit den Optionen -M bzw. --Merge erzwingen.

Einschränkungen für PDFlib 9.x.x: Bitte beachten Sie, dass comet_pdf Varianten, die auf PDFlib 9.x.x basieren, ausschließlich Seiteninhalte übernehmen. Verweise, Lesezeichen, Notizen, Formularfelder etc. werden von PDFlib 9.x.x nicht in das Zieldokument übernommen, siehe dazu auch das PDFlib 9 Tutorial, Kapitel 8.3.2 "Using PDFlib+PDI", Seite 208:

It is important to understand that PDI only imports the actual page contents, but not any interactive features (such as sound, movies, embedded files, hypertext links, form fields, JavaScript, bookmarks, thumbnails, and notes) which may be present in the imported PDF document.

Bei Verwendung einer auf PDFlib 10.x.x basierenden Variante von comet_pdf werden auch alle Verweise, Notizen, Formularfelder, Aktionen, Strukturelemente, Ebenen exportiert. Siehe dazu auch PDFlib 10 Tutorial, Kapitel 8.3.2 "Using PDFlib+PDI", Seite 198.

Werden alle Dokumente mit vollständiger Seitenzahl übernommen (pages gleich "1-*, "*" oder "all"), werden die Dokumente inklusive ihrer interaktiven Inhalte zusammengefügt. Für das Zusammenfügen der PDFs wird PDFBox verwendet, das sich in Ihrem Installationsordner befinden muß (z.B. imgconv/pdf2image/pdfbox-app-2.0.0-RC2.jar). Danach wird versucht, Verweise innerhalb der zusammengefügten Dateien in Verweise innerhalb der Zieldatei umzuwandeln.

Beachten Sie bitte folgende Einschränkungen:

1. (Nur Mac OS X) Beim PDF-Export schreibt InDesign® die Dateipfade von Verweisen auf externe Seiten und Textanker in Mac OS 9 - Syntax (Mac HD:Users:paul:Desktop:abc.pfd statt /Users/paul/Desktop/abc.pdf.) Obwohl die Konvertierung natürlich einfach ist - niemand rechnet damit, dass irgend jemand überhaupt auf die Idee kommen könnte, diese vor 20 Jahren abgelöste Syntax zu zu verwenden - und Ihr PDF-Reader wird den Link nicht auflösen können. PDFs, die von comet_pdf erzeugt wurden, korrigieren die OS9-Pfade.
2. PDFBox erledigt das Zusammenfügen von PDFs ganz hervorragend (und dieser Job ist wirklich nicht einfach!). Beim Umrechnen benannter Verweise (in InDesign® heißt das Textanker) treten aber gelegentlich Fehler auf - verwenden Sie also bitte nach Möglichkeit Seitenverweise.

[Ab v5.0 R36780] Jede Seite, die in das 'große' PDF eingefügt wird, kann mit beliebig vielen Zusatzelementen, den sogenannten Dekorationen, versehen werden. Ein häufiger Anwendungsfall ist das Hinzufügen passender Seitennummern.

Drei verschiedene Typen von Dekorationen stehen zur Verfügung:

• Formatierter Text
• priint:comet Templates
• Seiten von Dritt-PDFs zum Einfügen von Logos etc.

Die Definition der Dekorationen erfolgt in der gleichen XML-Datei, in der auch die Zielseiten festgelegt werden (also der Datei, die Sie in der Option --Merge et al. angeben). Fügen Sie dazu in diese Datei das Element <decorations> mit den Unterelementen <decoaration> ein.

Beachten Sie bitte, dass die Optionen -m und --merge möglicherweise PDFBox zum Zusammenfügen der Seiten verwenden. In diesem Fall werden (erwartugsgemäß) keine Dekorationen angelegt. Mit den Optionen -M bzw. --Merge verhindern Sie die Verwendung von PDFBox.

Hier die allgemeine XML-Definition für Dekorationen:

<decorations>
	
	<decoaration id="1" type="text | template | pdf | undef">
		<data args="">
			<!-- Depending on type, see below -->
		</data>
		<posx>outer 80</posx>
		<posy>bottom 20</posy>
		<!-- [<action />]  -->
	</decoaration>
	
	<!-- More decorations with unique ids -->
	
</decorations>

Text-Dekorationen fügen einen formatierten Text im Zieldokument ein. Folgende Angabe sind zur Defintion von Text-Dekorationen nötig:

• type="text"
• data :
  • Unformatierter Text
  • TaggedText
  • %!TT_html_

  Achten Sie bei der Textdefinition darauf, dass die Angaben XML-konform kodiert sind, also insbesondere &lt; statt < und &gt; statt >.

• data.args : Legen Sie hier die maximale Breite des Textes fest.
• action.id : Alternativ oder zusätzlich zu den Angaben in data und data.args können Text und Textbreite auch per Skript berechnet werden. Weitere Informationen zu Actions in Text-Dekorationen finden Sie hier.

Hier ein Beispiel einer Textdekoration mit dem Text Seite 14.

<decoaration id="2" type="text">
	<data args="">
		%!TT&lt;cSize:24&gt;&lt;cColor:Blue&gt;Seite $PageNumber
	</data>
	<posx>outer 20</posx>
	<posy>top 20</posy>
</decoaration>

Für das Rendern des Textes wird im Hintergrund ein Dokument mit einem Textrahmen geöffnet. Diese Dokument hat folgenden Standard-Einstellungen:

• Startseite ist die aktuelle 1-basierte Seitennummer des Ausgabe-PDFs. Auf die Startseite können Sie im TaggedText mit <0x0018> oder dem Schlüsselwort $PageNumber verweisen.
• Folgende Farben sind definiert:
  • Registration
  • Paper
  • Black
  • C=100 M=0 Y=0 K=0 und als Shortcut Cyan
  • C=0 M=100 Y=0 K=0 und als Shortcut Magenta
  • C=0 M=0 Y=100 K=0 und als Shortcut Yellow
  • C=15 M=100 Y=100 K=0 und als Shortcut Red
  • C=75 M=5 Y=100 K=0 und als Shortcut Green
  • C=100 M=90 Y=10 K=0 und als Shortcut Blue
  Die Farbwerte entsprechen den Standardeinstellungen von InDesign®.
• Absatzstil NormalParagraphStyle. Dieser Stil wird automatisch im Textrahmen eingestellt.
  • Schrift : Arial-Regular
  • Schriftgröße : 12pt
  • Farbe : Black
  • Tint : 100%

Im Attribut data.args von TextDekorationen können Sie eine Maximalbreite des Textes festlegen. Breitere Texte werden automatisch umgebrochen. Folgende Angaben sind möglich:

• "" : Textbreite auf die Breite der Zielseite abzüglich der Einrückung beschränken. Hat der Text z.B. einen Abstand von 20pt zum inneren Seitenrand, werden automatisch auch am äußeren Seitenrand 20pt Abstand gehalten.
• "Zahl oder Kommazahl" : Textbreite in Punkten. Der Dezimaltrenner darf fehlen oder ein Punkt oder ein Komma sein, z.B.
      200
      200.14
      200,14
  Bei Angaben kleiner 10.0 wird die Seitenbreite minus die Abstände zu den Rändern verwendet.

Folgende Schlüsselworte des Textes werden automatisch durch die aktuellen Werte beim Zusammensetzen des Zieldokumentes ersetzt:

Schlüsselwort	Beschreibung
⇨ Angaben zum Ziel-PDF. Das ist das 'große' PDF.
$PDFPath	Vollständiger Pfad des Ziel-PDFs
$PDFPathFolder	Ordner-Pfad des Ziel-PDFs
$PDFPathName	Name des Ziel-PDFs
$PDFPathShortName	Name des Ziel-PDFs ohne Dateiendung
$PageNumber	1-basierte aktuelle Seitennummer im Ziel-PDF
⇨ Angaben zum Teil-PDF, also dem aktuellen part.
$PDFPart	Vollständiger Pfad des Teil-PDFs
$PDFPartFolder	Ordner-Pfad des Teil-PDF
$PDFPrthName	Name des Teil-PDFs
$PDFPartShortName	Name des Teil-PDFs ohne Dateiendung
$PageNumberInPart	1-basierte Seitennummer im Teil-PDF
⇨ Dokumenteigenschaften des Teil-PDFs
$PagePartTitle	Titel des Teil-PDFs
$PagePartAuthor	Autor des Teil-PDFs
$PagePartSubject	Thema des Teil-PDFs

In der (optionalen) Aktion einer für Text-Textdekoration können Text und Maximalbreite berechnet werden. Ist keine Aktion definiert (action.id == 0) oder gibt die Aktion einen Wert ungleich 0 (etwa return 1;) zurück, werden die Werte von data und data.args als Fallback verwendet. Aktionen müssen in der aktuellen Datenverbindung definiert sein.

Die folgende Tabelle beschreibt die in Aktionen von Text-Dekorationen unterstützten Ausgabevariablen. Eine vollständige Liste aller in Dekorationen-Aktionen unterstützten Ein- und Ausgabevariablen finden Sie hier.

Variable	Typ	Beschreibung
gResultText	String	Text der Text-Dekoration, siehe hier Beachten Sie bitte, dass die Variable ein String ist, kein char*.
gResultWidth	float*	Maximalbreite des Textes. Achten Sie bei der Wertzuweisung auf den * vor gResultWidth und darauf, dass Sie wirklich einen float-Wert (also eine Zahl mit Dizimalpunkt) übergeben!

Setze Text und Maximalbreite einer Text-Dekoration

#pragma plain

#include "internal/types.h"

int main ()
{
	string::set (gResultText, "%%!TT<cSize:24><cColor:Blue>Seite $PageNumber");
	*gResultWidth = 120.0;
	
	return 0;
}

Template-Dekorationen fügen einen ein definertes Template der aktuellen Datenverbindung ins Zieldokument ein. Für die Verwendung von Template-Dekorationen muß eine gültige Verbindung zu einer priint:comet-Datenquelle bestehen! Folgende Angabe sind zur Defintion von Template-Dekorationen nötig:

• type="template"
• data : ID des gewünschten Templates. Bei Templates mit definierter linker und rechter Seite wird automatisch die passende Variante ausgewählt.
• data.args : Der Inhalt des Attributes wird ignoriert.
• action.id :
  • > 0 : Führe die angegebene Aktion aus.
  • ≤ 0 : Template unverändert einsetzen. Das ist insbesondere dann sinnvoll, wenn das Template lediglich einen gestalteten Rahmen mit einem statischen Text und evtl. der aktuellen Seitennummer (InDesign®-Menü Schrift -> Sonderzeichen -> Marken -> Aktuelle Seitennummer) enthält.

Hier ein Beispiel einer Dekoration mit dem Template 1199.

<decoaration id="3" type="template">
	<data args="">
		1199
	</data>
	<posx>outer 20</posx>
	<posy>top 20</posy>
</decoaration>

Mit dem Skript einer Template-Dekoration können Sie das Template vor dem Einfügen bearbeiten.

Wenn die einzige Änderung darin besteht, dass Sie eine Seitennummer anpassen, ist keine Aktion nötig : Das Template wird automatisch mit der aktuellen Seitennummer im Ziel-PDF geöffnet. Sie müssen im Template lediglich eine Text-Variable für die aktuelle Seitennummer definieren (InDesign®-Menü Schrift -> Sonderzeichen -gt; Marken -> Aktuelle Seitennummer). Diese Variable wird beim Öffnen des Templates dann automatisch richtig ersetzt.

In allen anderen Fällen beachten Sie bitte: Auch wenn es auf den ersten Blick logisch erscheint, da Templates mehr als einen Rahmen enthalten können, ist die Variable gFrame in diesen Skripten nicht definiert!

Um Rahmen im Template zu finden und eindeutig zu identifizieren, gehen Sie wie folgt vor:

1. Geben Sie dem Rahmen im Template eine eindeutige Kennung.
2. Im Skript holen Sie mit itemlist::pageframes alle Rahmen der ersten Seite
3. Mit itemlist::get erhalten Sie den n-ten Rahmen dieser Liste
4. Mit frame::get_smart_item_data können Sie die Rahmenkennung holen ...
5. ... und mit string::compare prüfen.

Da Templates im Skript geändert werden können, müssen die Templates bei jeder Verwendung neu geöffnet werden. Die Verwendung von Templates ist deshalb etwas zeitaufwändiger als andere Dekorationen. Wenn Sie mit einer Text-Dekoration das gleiche Ergebnis erzielen, sollten Sie diese Möglichkeit bevorzugen!

Das Template-Dokument darf vom Skript keinesfalls gesichert werden!

Eine vollständige Beschreibung aller in Dekorationsaktionen definierten Variablen und Konstanten finden Sie hier.

Das Skript zeigt die Aktion einer Template-Dekoration, die an den Rahmen mit der Kennung 'A' einen Seiteninformation anfügt.

#pragma plain
#include "internal/types.h"

int main ()
{
	ItemList 	frames	= itemlist::pageframes (1);
	ItemRef		fr		= item::alloc ();		// my frame
	String		label	= string::alloc ();		// label of fr
	String		name	= string::alloc ();		// needed for the short name of the input PDF
	String		txt		= string::alloc ();		// final text to append
	
	if (itemlist::length (frames) == 0) return 0;
	itemlist::get (frames, fr, 0);
	frame::get_smart_item_data (fr, label);
	printf ("Label = '%s'\n", label);
	
	if (string::compare (label, "A") == 0)
	{
		string::set (txt, "%%!TT %s, pg. %d by %s", 
		 	file::shortname (name, gPDFPart), 
		 	gPageNumberInPart,
		 	gPagePartAuthor);
		frame::append (fr, txt);
	}
	
	return 0;
}

PDF-Dekorationen fügen eine Seite eines anderen Dritt-PDFs auf der aktuellen Seite des Ziel-Dokumentes ein. Folgende Angabe sind zur Defintion von PDF-Dekorationen nötig:

• type="pdf"
• data : Vollständiger Pfad der Dritt-PDF. Der Pfad darf mit einem definierten $-Alias beginnen.
• data.args : 1-basierte Seitennummer im Dritt-PDF. Geben Sie hier entweder die Seitennummer (1, 2, 3. ...) oder einen einfachen Ausdruck zum Berechnen der Seitennummer an.
• action.id :
  • > 0 : Die angegebene Aktion berechnet Pfad und/oder Seitennummer des Dritt-PDFs.
  • ≤ 0 : Angaben aus data und/oder data.args verwenden.

Auf der aktuellen Seite des Ziel-PDFs wird oben an der Außenkante die vierte Seite des PDFs $DESKTOP/profilbild.pdf eingefügt.

<decoaration id="4" type="pdf">
	<data args="4">
		$DESKTOP/profilbild.pdf
	</data>
	<posx>outer 20</posx>
	<posy>top 20</posy>
</decoaration>

Alternativ zu einer festen Seitennummer in data.args können Sie hier auch einen einfachen arithmetischen Ausdruck zur Berechnung angeben. Der Ausdruck muß in gültiger cScript-Syntax definiert sein. Folgende Variablen sind in diesen Ausdrücken definiert:

Verwende auf rechten Seiten des Ziel-PDF die erste Seite des Dritt-PDFs und auf linken Seiten die zweite.

((pageNumber - 1) % 2) + 1

Mit dem Skript einer PDF-Dekoration können Sie den Pfad und die Seite des Dritt-PDFs bestimmen, die ins Ziel-Dokument eingefügt werden soll. Zusätzlich können Sie die Größe angeben, mit der die Seite platziert werden soll.

Die folgende Tabelle beschreibt die in Aktionen von PDF-Dekorationen unterstützten Ausgabevariablen. Eine vollständige Liste aller in Dekorationen-Aktionen unterstützten Ein- und Ausgabevariablen finden Sie hier.

Variable	Typ	Beschreibung
gResultPDFPath	String	Vollständiger Pfad der Dritt-PDF. Der Pfad darf mit einem definierten $-Alias beginnen.
gResultPageNumber	int	1-basierte Seitennummer im Dritt-PDF.
gResultWidth	float*	Skaliere die Seite das Dritt-PDFs auf die angegebene Größe. Folgende Angaben sind möglich: 0.0 (Default) : Verwende die Originalgröße > 4.0 : Gewünschte Breite. Die Höhe wird automatisch entsprechend skaliert. < 4.0 : Gewünschte Höhe. Die Breite wird automatisch entsprechend skaliert.

Das Skript definiert Pfad und Seite des Dritt-PDFs einer PDF-Dekoration. Die eingefügt Seite dabei proportional auf die Breite 100pt verkleinert.

#pragma plain
#include "internal/types.h"

int main ()
{
	string::set (gResultPDFPath, "$DESKTOP/profilbild.pdf");
	*gResultPageNumber = ((gPageNumber - 1) % 2) + 1;
	*gResultWidth = 100.0; // Don't forget, it's a float*
	
	return 0;
}

Die Positionierung der Dekorationen erfolgt über die Angaben decoration.posx und decoration.posy. Bei der Angabe fester Werte (z.B. 100 oder 100.0) wird die linke/obere Ecke der Dekoration an dieser Stelle im Ziel-PDF eingesetzt.

Alternativ können Sie Positionen auch dynamisch definieren. Die folgenden Angaben sind für decoration.posx möglich:

Für decoration.posy sind die folgenden Angaben möglich:

Alle dynamischen Platzierungen können mit einem Offset versehen werden. Die Angabe erfolgt blank-getrennt in Punkten hinter dem Positionsschlüssel, z.B. outer 20 oder outer 20.2. Die Angabe legt dabei jeweils den Abstand der entsprechenden Kante der Dekoration zum zugehörigen Seitenrand fest.

Platziere die Dekoration 20pt vom unteren Rand und 20pt von den äußeren Seitenrändern entfernt.

<posx>outer 20</posx>
<posy>bottom 20</posy>

Dekorationen können (müssen aber nicht) das Element decoration.action definieren. Hier die allgemeine Syntax des Elementes decoration.action:

<<action id="1112">
	<params>
		<param name="p1" value="my first variable" />
		<param name="stParam2" value="Paul Klee" />
		<!-- ... -->
	</params>
</action>

Neben den in den Parametern der Aktion definierten globalen Variablen sind in allen Dekorations-Skripten die folgenden Variablen definiert. Die Werte dieser Variablen dürfen nicht verändert werden!

Alle Aktionen haben die gleichen Ausgabeparameter. Aber die unterschiedlichen Dekorationstypen werten die Ausgaben unterschiedlich aus. Mehr dazu siehe hier:

• Text-Dekorationen
• Template-Dekorationen
• PDF-Dekorationen

Setzen der priint-Dokument-ID. Die Dokument-ID wird als String angegeben und direkt nach dem Öffnen des Dokumentes im Root-XML-Element des Dokumentes im Attribut "documentId" abgelegt. Mit den Scriptfunktionen xml::get_document_attribute und xml::set_document_attribute kann auf den Wert zugegriffen werden. Der Wert wird außerdem in diversen Funktionen des Produktaufbaus in einer pubserver-Verbindung benötigt.

Ab v4.0.5 R13799 der Comet-Plugins werden die im InDesign®-Dokument verwendeten Farbprofile auch in die w2ml's des Renderers eingetragen und können von comet_pdf verarbeitet werden.

Farbprofile werden üblicherweise in sogenannten icc (oder icm) Profilen festgelegt. InDesign® verwendet zur Benennung der Profile meist die im Profil festgelegten Namen. Aber diese Namen können unter MacOS sprachabhängig sein (und werden dann auch so in InDesign® angezeigt). Bei einigen Profilen werden von InDesign® jedoch auch eigene Namen verwendet. Zudem sind einige der Profile direkt in InDesign® eingebettet und haben keine eigene ICC-Datei.

Um eine eindeutige Zuordnung zwischen Profilname und -datei zu gewährleisten, ist daher ein Zuordungsdatei nötig. Diese Datei liegt im Programmordner von comet_pdf und hat den Namen colorprofiles.xml. Fehlt die Datei, werden Profil-Zuordnungen ignoriert. Mit der Option --icc pfad kann die Datei auch an belieber anderer Stelle abgelegt werden. Erwartet wird in diesem Fall der vollständige Pfad auf eine gültige XML-Datei mit den Profil-Zuordnungen. Die Pfade dürfen mit $-Abkürzungen wie $DESKTOP beginnen.

ICC-Profile der Version 4 können verwendet werden, um Farben im richtigen Profil darzustellen. Zum Umrechnen von Farben in andere Farbräume, z.B. in den Funktionen table::get_fillcolor_cmyk und bei PDF-Exporten mit Farbkonvertierungen können Sie nicht verwendet werden.

Colorprofiles.xml muß einen NULL-Eintrag haben und den Typ des Profiles (rgb oder cmyk) angeben. Profile der

Hier ein Beispiel einer gültigen colorprofiles.xml

<?xml version="1.0" encoding="utf-8"?>	
<colorprofiles>	
	<colorprofile name="" type="" version="-1" path=""></colorprofile>	
	<colorprofile name="MyICC" type="rgb" version="3" path="ppp/MyICC.icc"></colorprofile>	
</colorprofiles>

Es ist ziemlich zeitaufwendig, zu jedem verfügbaren Profil die richtigen Angaben und die richtige Datei zu finden. Ist das Profil zudem direkt in InDesign® eingebettet, finden Sie gar keine Profil-Datei. Ab v4.0.5 R13799 von comet_pdf enthält die Installation daher eine vordefinierte colorprofiles.xml und den Ordner colorprofiles, in dem die zugehörigen Profile enthalten sind. Mit dem Skripbefehl document::export_color_profiles können Sie die im Dokument verwendeten Profile exportieren.

document::export_color_profiles (0, "$DESKTOP/aaabbb", "$DESKTOP/aaabbb.xml");

Farbprofile werden nicht automatisch angewendet. Um Farbprofile des Dokumentes anzuwenden, starten Sie comet_pdf mit der Option --apply_icc. Die Option benötigt keine weitere Angaben. In den folgen drei Screenshots sehen Sie die Wirkung der Option. Gezeigt werden jeweils Ausschnitte von zwei orange Rahmen. Im einen Rahmen ist die Farbe als RGB definiert, im anderen als CMYK. In InDesign® sind beide Farben gleich - die Konvertierung der Farbe wurde ja hier auch mit dem aktuellen Farbprofil gemacht.

  In InDesign®

  comet_pdf ohne Farbprofile

  comet_pdf mit Farbprofilen

Voraussetzung für das Anwenden der Farbprofile ist:

1. Eine richtige Installation der colorprofiles.xml
2. Eingabe-W2ML mind. R13799
3. Option --apply_icc

Mit der Option

--compression [0-9]

können Sie die Komprimierung des Ausgabedokumentes beeinflussen. Mögliche Werte sind 0 (keine Kompression) bis 9 (maximale Kompression). Default ist 9. Da die Dateigröße der PDFs aber im wesentlichen von den enthaltenen Bildern abhängt und die meisten Bildformate bereits hochkomprimiert sind, hat der Kompressionsfaktor in der Regel leider keinen spürbaren Effekt. Erfolg versprechender ist hier eine Neuberechnung der Bilder.

Für die schnelle Anzeige in Web-Browsern empfiehlt sich neben möglichst kleinen PDFs auch die Option --linearize on.

Die Angabe --interactive N steuert, ob das PDF interaktive Elemente wie Buttons, Texteingaben etc enthalten kann und in welcher Tab-Reihenfolge diese Elemente aktiviert werden sollen. Default ist 0. Folgende Werte erlaubt:

Weitere Informationen zu den interaktiven Feldern finden Sie hier.

Die Optionen --pidstart und --piddone sind hilfreich bei asynchronen Aufrufen von comet_pdf. Das Programm legt die bei pidstart angegebene Datei direkt nach dem Start (und dem erfolgreichen Lesen der Programm-Optionen) an. Die unter piddone angegebene Datei wird direkt vor dem Programmende angelegt. Aus der Existenz der Dateien können dritte Anwendungen erkennen, ob ein geplanter Aufruf von comet_pdf gestartet bzw. beendet wurde.

In beide Dateien werden einige kurze Informationen geschrieben. Das Format beider Dateien ist gleich

App\t: Name Version Revision, based on ... and PDFlib ..., 64bit
Path\t: Pfad des ausführenden Programmes (oder --config_path)
User\t: Loginname des Benutzers
PID\t: Prozess-ID
Time\t: Start- bzw. Endezeit des Programmes im Format yyyymmhhhhmmss
Pages\t: Anzahl der PDF-Ausgabeseiten, -1 bei pidstart
Exit\t: Returnwert des Programmes, -1 bei pidstart

#Application arguments :
...

Hier ein Beispiel einer pidstart-Datei:

App   : comet_pdf v4.1.6 R26966, based on Comet 4.1.7 and PDFlib 9.0.4, 64bit
Path  : /Users/paul/Development/pdftest/comet_pdf
User  : paul
PID   : 8604
Time  : 20200513120858
Pages : -1
Exit  : -1

# Application arguments :
comet_pdf \
  -s posters_place \
    -l posters \
    -i $DESKTOP/fifo/render/template_de.w2ml \
    -e 1001 \
    -q 2 0 0 '' \
    -P fontnames.xml \
  -L \
  -v /Users/paul/Desktop/aaa.log \
  --pidstart /Users/paul/Desktop/s1.txt

1. Befehl richtig parametrisieren
2. shortcuts.xml aus dem Ordner von comet_pdf öffnen
3. Duplizieren Sie das <shortcut>-Element mit dem Namen priint:template. Achten Sie darauf, das gesamte Element von der Zeile <shortcut> bis zur nächsten Zeile </shortcut> zu kopieren.
4. Geben Sie dem neuen Element einen eindeutigen Namen und eine verständliche Beschreibung. Um sich später Mühe bei der Engabe des Namens im Terminal zu ersparen, sollten die Namen keine Leer- oder Sonderzeichen enthalten und mit einem Buchstaben beginnen, also etwa <name>test_1</name>. Die Beschreibung wird in der Terminal-Hilfe (-h) zusammen mit dem Namen angezeigt. Beginnt die Beschreibung description mit dem Schlüsselwort HIDDEN, wird der Eintrag dort nicht gezeigt.
5. Dem neuen Element wird jetzt für jede verwendete Programm-Option ein neues Unterelement hinzugefügt. Als Elementname wird dabei der Name der Programm-Option in genau dieser Schreibweise aber ohne ohne - bzw. -- verwendet. Als Inhalt wird der zugehörige Wert eingetragen.

Ein so konfigurierter Shortcut kann mit

    ./comet_pdf -s NAME_OF_SHORTCUT

aufgefrufen werden. Weitere Programmoptionen nach dem Shortcut sind natürlich erlaubt. Wurde eine nachfolgende Programmoption bereits durch den Shortcut gesetzt, wird die neue Einstellung verwendet.

Hier ein Beipiel für einen Shorcut namens poster1, der den Aufruf

    ./comet_pdf -l posters -i \$DESKTOP/fifo/render/template_de.w2ml -e 1001 -q "2 0 0 ''" --compression 1

vereinfacht durch

    ./comet_pdf -s poster1

<shortcut>
	<name>poster1</name>
	<description>Place one poster of priint 5.5 using action 1001</description>
	<l>posters</l>
	<i>$DESKTOP/fifo/render/template_de.w2ml</i>
	<e>1001</e>
	<q>2 0 0 ''</q>
	<compression>1</compression>
</shortcut>

Die Datei shortcuts.xml muß nicht existieren, aber wenn, dann wird sie im Ordner von comet_pdf gesucht.

Die Shorcut-Namen hello und alle Namen, die mit priint: beginnen sind reserviert!

Zu Testzwecken und im PubServer-Umfeld wollen Sie mglw. einige Einstellungen für alle comet_pdf Aufrufe ändern. Z.B kann es nützlich sein, die Logfiles an eine andere Stelle (oder überhaupt) zu schreiben oder die Bild-Kompression zu ändern. Dazu können die Standard-Shortcuts priint:args:pre und priint:args:post verwendet werden: Der :pre-Eintrag wird vor allen anderen Programmoptionen gelesen, der :post Eintrag wird ganz am Ende ausgewertet und überschreibt damit alle anderen entsprechenden Festlegungen. Mit beiden Definitionen sollten Sie vorsichtig umgehen - Sie ändern damit das Verhalten aller Aufrufe des zugehörigen comet_pdf.

Mit der folgenden Definition wird Ihr comet_pdf immer die (fast) schwächste Bildkompression verwenden. Das macht die Aufrufe bei bild-lastigen Dokumenten um den Faktor 2-3 schneller (aber die PDFs nur unwesentlich größer):

 <shortcut>
	<name>priint:args:post</name>
	<description>
			This entry is called to fix the options of ALL your calls to comet_pdf.
			The definitions also override the options that are set in the current calls to comet_pdf.
			Think twice before inserting something here!
	</description>
	<compression>1</compression>
</shortcut>

Auswahl der Shortcuts XML-Datei. Die Option erwartet die Angabe eines vollständigen Pfades inklusive des Dateinamens einer gültigen shortcuts.xml. Die Verwendung der integrierten $-Aliasnamen am Anfang des Pfades ist erlaubt

Optional kann nach dem Pfad ein mit ':' getrennter gültiger Shortcut-Name aus der definierten Datei folgen. Fehlt diese Angabe, kann der Shortcut auch mit -s myShortcut ausgewählt werden. Achten Sie in diesem Fall darauf, dass der Parameter -s nach der Defintion von -shortcuts steht.

Beide Aufrufe sind gleichwertig: Statt der Standard-Shortcuts wird die Datei scc.xml Ihres Desktops nach dem Shortcut color_frames234 durchsucht.

comet_pdf --shortcuts \$DESKTOP/scc.xml:color_frames234
comet_pdf --shortcuts \$DESKTOP/scc.xml -s color_frames234

[ab v1.0 R16600, EXPERIMENTELL] Wie die priint:comet Plugins kann auch comet_pdf im Playback-Modus betrieben werden. Verwenden Sie dazu die Programm-Option --playback mit folgenden Werten:

• off Standardwert. Der Playback-Modus ist deaktiviert.
• record Aufnehmen der Daten
• on Anwenden aufgezeichneter Daten

Den Datenordner geben Sie mit der Option --playback_path an.

Ist im Aufzeichnungsmodus (record) kein Zielordner angegeben, werden die Daten in den XCache geschrieben:

    $CACHE/U12345/XDATA/verbindungs_name

12345 ist dabei die Prozess-ID des eben ausgeführten Renderers - der jüngste Ordner im XCache. Damit die aufgezeichneten Daten bei Programmende nicht gelöscht werden, muß der Renderer in diesem Fall mit der Option -VX gestartet werden.

In der Programmausgabe sehen Sie unter dem Punkt Fit Frames die Zeit, die das Programm zum Berechnen von Text-Oversets und zum Anpassen von Rahmen an ihren Inhalt benötigt hat. Insbesondere Textverkettungen über viele Seiten und Tabellen können sehr zeitaufwendig sein. Mit dem sogenannten Layzfit versuchen wir, diese Aufrufe zu minimieren. Dafür registriert das Programm Änderungen an Text bzw. Bild der Rahmen und ihrer Geometrie und führt die aufwendige Größenberechnung nur dann aus, wenn seit dem letzten Fitframe auch wirklich etwas geändert wurde. Das kann zu einer Zeitersparnis von bis zu 20% führen.

LazyFit ist standardmäßig abgeschaltet. Mit --lazyfit 1 schalten Sie das Feature ein. Mit --lazyfit 0 können Sie die Option (z.B. aus einem vorangegengenen Shortcut) wieder abschalten.

Das Feature ist noch im exprimentellen Status. Möglicherweise haben wir Situationen übersehen, in denen Sie Änderungen an Rahmen machen können, die sich auf die Rahmengröße auswirken. Bitte verwenden Sie LazyFit im Produktivbetrieb nur nach eingehender Prüfung ihres Projektes.

Soll vor der Verwendung von Web-Bildern geprüft werden, ob die lokale Datei noch aktuell ist?

• 0 : Nein, es wird lediglich geprüft, ob die lokale Download-Datei existiert
• 1 (Default) : Ja, vor der Verwendung wird geprüft, ob die Datei noch aktuelle ist

Durch das Entfernen unbenutzer Stildefinitionen aus den Dokumenten kann die Geschwindigkeit von comet_pdf deutlich optimiert werden. Mit der Angabe --unused_styles gibt das Programm am Ende eine Liste aller unbenutzen Stile aus. Nach sorgfältiger Prüfung sollten Sie unebutzte Stile dann aus den Dokumenten entfernen:

• 0 (Default) : Keine Liste unbenutzter Stile schreiben
• 1 : Ausgabe einer Liste der unbenutzten Stile

In der Standard-Anwendung von comet_pdf werden die Ebenen des InDesign-Dokumentes lediglich zur Festlegung der Z-Order verwendet : Objekte weiter unten liegender Ebenen werden also vor den Objekten darüberliegender Ebenen ersellt. Zusätzlich wird die Ebenenfarbe zum Zeichnen der Adornments verwendet.

[Seit v4.2 R33238] Mit eingeschalteter Option --pdflayers 1 | on | yes werden die im InDesign-Dokument definieren Ebenen in der gleichen Reihenfolge und mit den gleichen Einsellungen auch im PDF-Dokument erzeugt. Beachten Sie aber bitte, dass "Gesperrt" in Acrobat nur heißt, dass die Sichtbarkei einer Ebene nicht geändert werden kann und dass die Ebene nicht gelöscht werden darf. Die Objekte gesperrter Ebenen dürfen aber im Gegensatz zu InDesign geändert werden.

Mit dieser Option wird der Python debugger server auf dem angegebenen Port gestartet.

Starten Sie das Programm mit der Option -v (--log) und der Angabe eines vollständigen Pfades zu einer Logdatei, um Logdaten zu schreiben. Existieren Pfad oder Datei nicht, werden sie automatisch angelegt.

Die Logdatei sollte (muss aber nicht) die Endung .log haben. Dateien mit dieser Endung werden unter Mac OS X bei Doppelklick automatisch vom Dientsprogramm Konsole geöffnet. Dieses Programm scrollt den Inhalt immer so, dass Sie das Dateiende sehen. Sie können hier also sehr gut den Progress der Arbeit sehen.

Die Logdatei ist im wesentlichen identisch zu den Logdaten der Comet-Plugins.

Im Produktivbetrieb sollten Sie das Schreiben der Logdatei abschalten. Es ist verlangsamt das Programm um etwa 10-20%.

Starten Sie das Programm mit der Option --logx und der Angabe eines vollständigen Pfades zu einer Logdatei, um Programmaufrufe in einer eigenen Datei mitzuschreiben.

Diese Option ist nützlich, um die Kommunikation einer Server-Komponente (z.B. PublishingServer) mit dem PDF Renderer zu überwachen. Neben Datum / Zeit und der vollständigen Kommandozeile werden auch die zur Verarbeitung benötigten Zeiten ausgegegen.

Die Option setzt den Pfad zur Logfile-Konfigurationsdatei, mit deren Hilfe gesteuert wird was und wie ins Logfile geschrieben wird.

Als Angabe wird der vollständiger Pfad der Logfile-Konfigurationsdatei erwartet. Heißt diese Datei log.xml, darf der Name weggelassen werden. Der Pfad darf mit einem der fest definierten $-Aliasse beginnen. Existiert die angegebene Datei nicht, wird die Programm-Option ignoriert und die Standarddatei log.xml Ihrer werkii-Präferenzen bzw. neben comet_pdf verwendet.

Die Angaben $DESKTOP und $DESKTOP/log.xml sind also gleichwertig und verweisen beide auf die Datei /Users/your_name/Desktop/log.xml.

[ab v1.0 R17778] Ist diese Option angegeben, wird automatisch der gesamte Datenverkehr zum und vom SOAP-Service mit geschrieben. Der Parameter hat nur bei aktiver SOAP-Verbindung eine Bedeutung. Die Logfiles werden immer auf den Desktop geschrieben. Bei Neuverbindung werden bestehende Logs zuvor gelöscht. Folgende Dateien werden geschrieben:

• _soapSENT.log - Die Datei enthält alles, was von der aktuellen SOAP-Verbindung an den Server gesendet wurde.
• _soapRECV.log - Die Datei enthält alles, was von der aktuellen SOAP-Verbindung an den Server erhalten wurde. Achtung : Diese Datei kann sehr groß werden!
• _soapTEST.log - Die Datei enthält detailierte Informationen über die Arbeit der SOAP-Schnittstelle. Erklärungen zum Inhalt dieser Datei finden Sie im User Guide von gSOAP.

Ausgabe interner Daten in die Programmausgabe. Die Ausgaben dienen zur Fehlersuche und können in den einzelnen Releases des Programmes variieren.

Die Ausgaben zeigen den Inhalt der Texte zu verschiedenen Zeiten der internen Bearbeitung. Abweichungen in der Zuordnung der Stile (Tags) zum Text sind also normal. Beachten Sie bitte auch die von comet_pdf unterstützten Textattribute.

Achtung: Die Anweisungen können sehr viele Ausgaben erzeugen. Es ist sinnvoll, die Programmausgabe mit > in eine Datei umzulenken.

Folgende Angaben werden unterstützt:

Ausgabe einer speziellen Datei mit Logangaben des PDF-Exportes. Die Dateien können nur vom PDFlib-Support ausgewertet werden.

Ausgaben von Dialogen (alert, showmessage, showerror) werden in die Standardausgabe und in die Logdatei geschrieben. Im Log werden die Meldungen mit dem Hinweis Info, Warn bzw. Error versehen. In der Standardausgabe werden die Texte farbig markiert (Infos grün, Warnungen blau, Fehler rot).

Das Programm comet_pdf beendet seine Arbeit mit einem Rückgabewert. Das Ergebnis erscheint als letzte Zeile in der Programmausgabe:

Successfully finished.

Cannot open file '/Users/paul/Desktop/Unbenannt-2.w2ml'.

Programm canceled with <kCannotOpenDocument>.
EXIT CODE 4

Die folgende Tabelle beschreibt alle Rückgabewerte von comet_pdf: