Wenn man von der Kommandozeile das Verhalten des Layout steuern möchte, gibt es ab sofort (Version 3.7.12) einen neuen Mechanismus.

Anwendungsfall ist z.B. ein Layout, das sowohl für die Druckausgabe (mit Beschnittzugabe und Beschnittmarken) als auch für die »online« Version (ggf. mit Bildern in geringerer Auflösung) vorbereitet wird und auf der Kommandozeile dann umgeschaltet wird.

Beispiel

Im Layout der Modus print abgefragt:

<Switch>
  <Case test="sd:mode('print')">
    <Options bleed="3mm" cutmarks="yes"/>
  </Case>
  <Otherwise>
    <Options bleed="0mm" cutmarks="no"/>
  </Otherwise>
</Switch>

Die speedata Layout-Regelwerke werden ja in XML formuliert. Um die Bearbeitung zu erleichtern, gibt es seit jeher ein RELAX NG Schema zum speedata Publisher. Damit können die spezialisierten XML-Editoren wie z.B. oXygen oder auch normale Editoren wie Atom oder jEdit prüfen, ob die Syntax des Layoutregelwerks korrekt ist und Vorschläge machen, welche Elemente oder Attribute an einer bestimmten Position vorkommen dürfen.

Ab sofort wird auch ein XML Schema (XSD) im Verzeichnis schema mitgeliefert, so dass auch Editoren Unterstützung bieten, die mit RELAX NG nichts anfangen können.

Für alle, die schon mal am speedata Publisher etwas ändern wollten, sich aber nicht die ganzen Abhängigkeiten für die Entwicklung installieren möchten, gibt es nun eine gute Nachricht. Ab sofort steht unter https://hub.docker.com/r/speedata/development ein Docker Image zur Verfügung, das alle Programme schon installiert hat. Das Repository von Github selbst ist nicht Teil des Images, aber einfach hinzuzufügen.

Manchmal möchte man schnell eine minimale Layout-Datei haben, um einfache Experimente mit dem speedata Publisher durchzuführen. In der Regel nehme ich das »Hallo Welt« Beispiel aus dem Handbuch und ändere dann das Layout, soweit ich das benötige.

Ab sofort gibt es auch ein Yeoman-Generator, der das »Hallo Welt« Beispiel erzeugt, ohne dass man selber etwas kopieren muss. Yeoman basiert auf npm und erfreut sich immer größerer Beliebtheit. Wenn npm installiert ist, sind es nur noch wenige Schritte bis zum fertigen Minimalbeispiel:

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.