In der neusten Version des Publishers ist es nun möglich, Ersatzschriftarten anzugeben, wenn Zeichen aus einer Schriftart nicht gefunden werden. Z.B. hat die mit dem speedata Publisher mitgelieferte TeX Gyre Heros keine Zeichen für Griechisch, Arabisch oder ähnliches im Zeichensatz. Oder viele CJK (Chinesisch, Japanisch, Koreanisch) Schriftarten haben nur rudimentäre Unterstützung für lateinische Sprachen.

Die Syntax erklärt vielleicht etwas schneller, worum es geht:

<LoadFontfile name="zh" filename="Microsoft JhengHei.ttf">
  <Fallback filename="texgyreheros-regular.otf" />
</LoadFontfile>

Immer wieder wünschen sich Anwender des speedata Publishers Textsatz in anderen Schriftsystemen, z.B. das Arabische.

Textsatz im Arabischen

Doch was ist so besonders im arabischen Textsatz? Die Seiten Text Layout Requirements for the Arabic Script vom W3C und Arabic script summary von Richard Ishida gehen sehr ausführlich auf die Thematik ein. Ich erlaube mir ein paar Bilder daraus zu »klauen«.

Einige Punkte:

1. Die Sprache läuft von rechts nach links und fängt am rechten Seitenrand an. Abgekürzt wird dies oft mit RTL im Gegensatz zu den westlichen Sprachen mit LTR. Gibt es Blocksatz im Arabischen? Was ist mit Silbentrennung?

Hurra! Wieder ein neues Release der stabilen Version. Nach der Hauptversion 3.4 kommt die Version 3.6.

Interne Änderungen

Auch hier ließen sich alle Änderungen in den 13 Entwicklerversionen nachvollziehen. Der für mich wichtigste Unterschied ist, dass nun externe Bibliotheken eingebunden werden können. Das ermöglicht viele Dinge wie den Aufruf eines externen OpenType Font-Shapers oder die Implementierung von Regulären Ausdrücken, die es so in Lua nicht gibt. Gleichzeitig bin ich intern auf Go Module umgestiegen. Damit kann ich das Repository kleiner halten und gleichzeitig eine hohe Sicherheit bei den benutzten Bibliotheken erreichen.

Das sind alles Änderungen, die der Benutzer nicht sieht, aber mir das Leben doch etwas einfacher machen. Außerdem fällt die TCP-Verbindung weg, die zwischen dem Hauptprogramm und dem LuaTeX-Prozess nötig war.

Sichtbare Änderungen

• CID-basierte Schriftarten können nun benutzt werden. Das ist hauptsächlich für CJK (Chinesisch, Japanisch, Koreanisch) wichtig. Siehe auch den Artikel über die CID-keyed Fonts.
• Ausgleichen von Tabellen. Hierfür sollte ich mal einen eigenen Blogbeitrag schreiben… Damit kann man die letzte Seite einer Tabelle, die über mehrere Spalten geht (Frames), ausbalancieren.
• Unterstützung der Standards PDF/X-3 und PDF/X-4 und barrierefreie PDFs (PDF/UA). PDFs nach dem PDF/A-Standard ließen sich bisher auch schon schreiben.
• Neuer Ressourcen-Lader. Damit können nun Dateireferenzen, egal ob das Bilder, XML-Dateien oder Schriftarten sind, per HTTP, HTTPS oder aus dem lokalen Dateisystem geladen werden.
• Einbinden von SVG-Dateien, wenn Inkscape installiert ist. Siehe auch den Beitrag hier im Blog.
• Der Lua-Filter ersetzt nun offizilell den XProc-Filter, dieser wird nicht mehr unterstützt. Damit kann man vor dem eigentlichen Publikationsprozess noch eine Datenumwandlung oder ähnliches ausführen. Siehe die Seite im Handbuch.

Nächste Woche ist es wieder so weit (7.–9.2.): die alljährliche XML-Konferenz findet in Prag statt. Warum schreibe ich das hier?

Seit dem Publisher Version 3.5.7 kann man PDF/UA-konforme PDF-Dateien erstellen. PDF/UA ist auch bekannt unter »Barrierefreie PDFs« oder »Tagged PDF«. Im Prinzip bedeutet das, dass jedes sichtbare Element in der PDF-Datei ein Etikett (Tag) erhält, was für eine Rolle das sichtbare Element hat. Also, ob es eine Überschrift ist, ob es ein Absatz, eine Tabellenzelle etc. ist.

Hier folgt das Grundgerüst für eine PDF/UA-konforme Datei:

<Layout xmlns="urn:speedata.de:2009/publisher/en"
  xmlns:sd="urn:speedata:2009/publisher/functions/en"
  version="3.5.7">

	<PDFOptions format="PDF/UA"/>
	<Options mainlanguage="German"/>

	<Record element="data">
		<PlaceObject>
			<Textblock>
				<Paragraph role="H1">
					<Value select="title"/>
				</Paragraph>
			</Textblock>
		</PlaceObject>
		<Output>
			<Text>
				<ForAll select="para">
					<Paragraph role="P">
						<Value select="."/>
					</Paragraph>
				</ForAll>
			</Text>
		</Output>

	</Record>
</Layout>

Man muss also zum einen das Ausgabeformat (<PDFOptions>) festlegen, als auch die Rolle jeden einzelnen Elements. Da die Daten beim Publisher beliebig aufgebaut sein können, muss wirklich für jedes sichtbare Element die Rolle festgelegt werden. Das System kann leider nicht erraten, um was es sich handelt.

Das Ergebnis unterscheidet sich visuell nicht von einem »ungetaggten« PDF, aber intern ändert sich einiges. Schaut man sich das Ergebnis mit dem Adobe Acrobat an, so sieht man sofort die Hierarchie des Dokuments:

Die Dokumentstruktur bzw. -gliederung wird durch die hierarchischen Tags sichtbar.

Mal etwas außerhalb der Publisher-Welt. Bis vor kurzem hatte ich einen täglichen CTAN¹-Abzug, den ich per Git versioniert habe. Über ein Web-Frontend konnte man darauf zugreifen und sich den Zustand eines jeden Tages seit dem 17.3.2013 anzeigen lassen. Ganz praktisch, wenn man eine alte Version eines TeX-Pakets haben wollte.

Leider habe ich die Fähigkeiten von Git etwas überschätzt und muss es hauptsächlich aufgrund der Größe und der Serverauslastung abstellen.

Warum überhaupt eine tägliche Sicherung?

CTAN behauptet von sich (das steckt ja im Namen) ein Archiv zu sein. Technisch gesehen ist es aber nicht, denn jede neue Version eines Pakets überschreibt eine alte Version, und damit ist die alte Version nicht mehr verfügbar. Das kann aber zu einem Problem werden, wenn man – aus welchen Gründen auch immer – auf eine alte Version zurückgreifen muss. Dieses Problem kann man nur durch ein echtes Archiv lösen.

Immer wieder gibt es Nachfragen, ob der Publisher auch PDF/X erzeugen würde. Oder PDF/A. Oder ob die Druckerei das PDF vom Publisher überhaupt verarbeiten kann.

Dazu gab es immer meine Antwort, die ich reines Gewissens geben kann:

»Lieber Kunde, mach dir keine Sorgen. Bisher hat immer alles gut geklappt, ich hatte bisher noch keinerlei Reklamationen.«

PDF/X und PDF/A sind nur Konformitätserklärungen, keine Besonderheiten bei der PDF-Erzeugung. Auch ohne diese Erklärungen entsprechen die PDF des Publishers den Anforderungen dieser Normen, eine gewisse Disziplin des Anwenders vorausgesetzt (siehe unten).

Ich nutze die Software LuaTeX um das PDF zu erzeugen. LuaTeX erzeugt sehr sauberes PDF. Als Nachfolger von PDFTeX ist es eine der ersten Anwendungen überhaupt, die PDF schreiben konnte. Insofern gibt es hier keine Überraschungen.

Am meisten wird nachgefragt, ob die benutzten Schriftarten eingebettet werden. Ja, selbstverständlich werden sie das, sonst könnte der Empfänger gar nichts mit der Datei anfangen. (Hinweis: es wird immer nur die wirklich benutzte Teilmenge der Buchstaben eingebunden).

Ein paar Fallstricke gibt es doch: verlangt die Druckerei z.B., dass nur CMYK-Bilder enthalten sein dürfen, muss der Benutzer entsprechendes Bildmaterial auch zur Verfügung halten. Zwar kann das Dokument noch gedruckt werden, aber eine hundertprozentige Farbkorrektheit wird die Druckerei nicht garantieren. Insofern ist der Anwender des Publishers für die Ausgangsmaterialien verantwortlich, eine Korrektur während des Laufs wird nicht vorgenommen.

PDF/X, PDF/A und PDF/UA

Viele Anwender hätten doch gerne das Siegel, dass die PDF-Datei einem Standard entspricht. Hier gibt es mal wieder viele Standards zum Aussuchen. Für die Druckerei ist PDF/X wichtig. PDF/A ist für die Langzeitarchivierung interessant und PDF/UA (universal access) für die Barrierefreiheit.

Mit der Version 3.5.5 gibt es ein neues Feature: SVG-Dateien können ohne Konvertierung eingebunden werden, sofern das Programm Inkscape installiert ist.

Die alten Hasen erkennen sicherlich das Ghostscript-Beispiel. Hier als SVG-Quelle. Aus: https://upload.wikimedia.org/wikipedia/commons/f/fd/Ghostscript_Tiger.svg

Die Konvertierung nach PDF erfolgt im Hintergrund und unsichtbar für den Anwender.

<Layout
  xmlns="urn:speedata.de:2009/publisher/en"
  xmlns:sd="urn:speedata:2009/publisher/functions/en">

  <Record element="data">
    <PlaceObject>
      <Image file="Tiger.svg" width="10"/>
    </PlaceObject>
  </Record>
</Layout>

Die neue Version 3.5.4 des Publishers hat hauptsächlich den internen Datei-Loader verändert. Es gab ein paar Probleme mit der alten Schnittstelle in der alten Version:

• Unter Windows konnten keine Bilder mit Umlauten geladen werden.
• Manche Befehle (z.B. sd:aspectratio(), siehe die Stelle im Handbuch) konnten nur mit Dateien umgehen, die im Suchbaum zu finden sind.
• Es gab verschiedene Befehle für Bilder im lokalen Dateisystem und für Bilder, die über http geladen werden.

Die neue Version vereinheitlicht nun alle Dateizugriffe. Die Dateinamen können nun überall folgende Formate haben:

• Absoluter Pfad im Dateisystem: /pfad/zur/datei.png.
• Relativer Pfad im Dateisystem: ../verzeichnis/datei.png.
• Datei innerhalb des Suchbaums datei.png. Vor dem Start wird das aktuelle Verzeichnis rekursiv durchsucht (siehe das Handbuch).
• Absolute Pfade unter Windows wie c:\Users\....\datei.png.
• file-Schema: file://c/Users/Joe%20User/datei.png oder file:///home/user/datei.png.
• http-Schema: http://placekitten.com/g/400/300 oder https: https://placekitten.com/g/400/300

Also z.B. <Image file="https://placekitten.com/g/400/300" width="5cm" />.

Diese Dateinamen können bei Bildern, bei XPath- und Layoutfunktionen sowie auf der Kommandozeile benutzt werden. So ist es möglich, den Publisher mit

sp --dummy --data https://raw.githubusercontent.com/speedata/examples/master/technical/rotating/layout.xml

aufzurufen. Erst wird die Ressource auf dem lokalen Rechner zwischengespeichert und dann von dort aus geladen.

Der Download der neuen Version wie immer unter https://download.speedata.de/.

Die Version 3.5.2 (gestern frisch hochgeladen) hat neben diversen Bugfixes (hauptsächlich im Zuge des Upgrades auf LuaTeX 1.0.7) wieder Neuerungen erhalten.

break-below in Tabellen

Bisher gab es keine einfache Möglichkeit, das Verhalten break-below="no" in Tabellenzeilen mit Tabellenlinien zu verknüpfen. Seit der Version 3.5.2 wird das nun auch in Tabellenlinien beachtet, außerdem kann man nun in Tabellenlinien dieselbe Eigenschaft setzen.

<Layout
  xmlns="urn:speedata.de:2009/publisher/en"
  xmlns:sd="urn:speedata:2009/publisher/functions/en">
  <Pageformat height="5cm" width="7cm"/>
  <Trace grid="no" />

  <SetGrid height="12pt" nx="5" />

  <Pagetype name="foo" test="true()">
    <Margin left="1cm" right="1cm" top="1cm" bottom="1cm"/>
    <PositioningArea name="tbl">
      <PositioningFrame height="8" width="2" row="1" column="1"/>
      <PositioningFrame height="8" width="2" row="1" column="4"/>
    </PositioningArea>
  </Pagetype>

  <Record element="data">
    <PlaceObject area="tbl">
      <Table>
        <Loop select="10">
          <Tr break-below="no">
            <Td><Paragraph><Value>tablerow</Value></Paragraph></Td>
          </Tr>
          <Tablerule rulewidth="2pt" color="green"/>
        </Loop>
      </Table>
    </PlaceObject>
  </Record>

</Layout>

Ab sofort kann man steuern, ob Tabellenlinien unterhalb einer Zelle bleiben sollen, oder nicht. Tablerow beachtet nun das darüberliegende break-below='no'. Im rechten Fall ist die Tabellenlinie immer unterhalb der Zeile, ggf. wird ein Umbruch vorher eingefügt.