Standard 14 Font-Ressourcen und jadice

Motivation und Hintergrund – Das Problem der einheitlichen Textdarstellung

Texte können über verschiedene Wege in einem elektronischen Dokument hinterlegt werden. Eine Möglichkeit besteht darin, die kompletten Inhalte als Bild, also als Raster- oder Vektorgrafik, zu hinterlegen. Eine Andere ist die Verwendung von Schrifttypen (Fonts), um Text mit einer visuellen Darstellung zu versehen. 

Werden Texte als Bilddaten hinterlegt, ist ein Vergrößern ohne Qualitätsverlust mit hohem Aufwand verbunden.

Werden Texte als Bilddaten hinterlegt, ist ein Vergrößern ohne Qualitätsverlust mit hohem Aufwand verbunden.

Das Hinterlegen des Textes als Rastergrafik ist die einfachste und sicherste Methode, um eine konsistente Darstellung zu gewährleisten. Diese birgt jedoch eine Reihe von Nachteilen in sich. Einerseits ist im Nachhinein die Weiterverwendung der Texte z.B. in Form der Textextraktion, durch Kopieren oder das Durchsuchen des Texts nicht oder nur durch den Umweg einer Schrifterkennung möglich. Andererseits ergibt sich eine Einschränkung der Skalierbarkeit bzw. ein Qualitätsverlust beim Vergrößern, der nur durch höhere Auflösung der Grafik und damit höheres Dokumentvolumen begegnet werden kann.

Werden im Gegensatz hierzu die Texte direkt als Text im Dokument hinterlegt, können diese zu einem späteren Zeitpunkt auch wieder extrahiert werden, um beispielsweise eine Volltextsuche zu ermöglichen.

Damit eine Darstellung von Texten möglich ist, wird neben dem eigentlichen Text auch immer noch eine Schrifttype benötigt. Hierbei handelt es sich meist um eine Datei, welche die Darstellung der Schrift definiert, und als Font bezeichnet wird. 

Woher kommen Fonts?

Verschiedene Dokumentenformate erlauben das Einbetten von Schrifttypen zur Darstellung von Text und im Idealfall sind die verwendeten Fonts im Dokument eingebettet. Die Darstellung ist damit portabel und in jeder Umgebung eindeutig.

Leider sind Schrifttypen jedoch nicht immer in den Dokumenten eingebettet.

Ein Bestand von Schrifttypen steht als Teil des Betriebssystems zur Verfügung. Jedoch haben verschiedene Betriebssysteme selten eine vergleichbare Auswahl von Schriftarten. Die Unterschiede spiegeln sich in der Art, im Erscheinungsbild und in der Vollständigkeit der Zeichen wieder. So kann es passieren, dass auf einem Betriebssystem ein Dokument gut dargestellt werden kann, aber das gleiche Dokument  auf einem anderen Betriebssystem gar nicht (fehlender Font),  mit schlechtem Schriftbild (keine passende Ersatzschrift im System) oder mit fehlenden Zeichen (unvollständiger Zeichensatz) dargestellt wird. Die Ursachen hinter dieser Problematik und weitere Hintergrundinformationen werden im Artikel /wiki/spaces/JKB/pages/897993, der demnächst veröffentlicht wird, beschrieben.     

Neben den konkreten Fonts gibt es in Java zudem noch die so genannten Logischen Fonts. Die offizielle Java SE Dokumentation spricht von Physical Fonts und Logical Fonts (siehe: https://docs.oracle.com/javase/tutorial/2d/text/fonts.html).
Logische Fonts sind keine konkreten Schriftarten, wie beispielsweise Arial, sondern werden durch einen logischen Namen definiert, welcher gleichzeitig die Ausprägung festlegt. Die für jadice-relevanten Ausprägungen sind hierbei Serif, SansSerif und Monospaced – in wenigen Situationen auch Dialog bzw. DialogInput.
Die konkreten Schriftarten, die sich dahinter verbergen bzw. auf die im konkreten Anwendungsfall abgebildet werden kann, obliegen der JVM. Java nutzt auf unterschiedlichen Plattformen dafür unterschiedliche Schriftarten. Im Ergebnis kann die Darstellung von Text in unterschiedlichen Umgebungen stark variieren. 

PDF und das Konzept der Standard 14 Fonts

PDF definiert einen speziellen Satz an Fonts - die so genannten Standard 14 Fonts. Wichtig ist hierbei folgende Definition aus der PDF Formatspezifikation:

These fonts, or their font metrics and suitable substitution fonts, shall be available to the conforming reader.

ISO 32000-1:2008, Kapitel 9.6.2.2 "Standard Type 1 Fonts (Standard 14 Fonts)"

Daraus ergibt sich, dass einer anzeigenden Software diese Schriften, bzw. ein Satz metrisch kompatibler Schriften, fest zur Verfügung stehen soll.

Standard 14 Font Ressourcen und jadice

Oft werden in Client-Lösungen Dokumente angezeigt, verändert oder Annotationen aufgebracht. In einem weiteren Schritt werden diese Dokumente serverseitig in einer Dunkelverarbeitung weiter verarbeitet. Auch der umgekehrte Fall, Dokumente werden serverseitig vorverarbeitet, bevor sie in Client-Lösungen zur Anzeige gelangen, ist häufig anzutreffen. In beiden Fällen ist es wahrscheinlich, dass die Betriebssysteme und Umgebungen der Clients und des Servers sich stark unterscheiden. jadice Produkte sind als Pure-Java-Lösung plattformunabhängig und werden für diese Aufgaben sowohl server- wie auch clientseitig eingesetzt. Deswegen sehen sich jadice Produkte mit dem Problem der einheitlichen Darstellung konfrontiert.

Die jadice document platform adaptiert das Konzept der Standard 14 Fonts mit dem zukünftigen Ziel einer formatübergreifenden, einheitlichen Darstellung von Texten sowohl von Dokumenten als auch von Annotationen.

Zum Auftakt dieser Entwicklung ist ab Version 5.4.1.0 ein neues Paket mit Standard 14 Fontressourcen als Teil der Standard-Distribution aufgenommen worden. Ab dieser Version wird empfohlen, das mitgelieferte Standard 14 Fontressourcen-Paket in den Klassenpfad aufzunehmen.

Die Quellen für das Standard 14 Fontressourcen-Paket stehen öffentlich unter der Apache License, Version 2.0 zur Verfügung. Zu finden sind die Quellen und die Substitutionstabelle im Github-Projekt documentplatform-standard14-fonts.

Stand der Umsetzung

  • Bereitstellung eines neuen Pakets mit jadice Standard 14 Fontressourcen
    • Hinweis: Für die Schriftart Symbol existiert derzeit keine freiet Variante. Daher sind aktuell nur 13 der 14 Fonts abgedeckt.

  • Unterstützung für PDF Dokumente

    • Abdeckung von 13 der Standard 14 Fonts (PDF-Spezifikation): Helvetica, Times New Roman, Courier; jeweils in den Ausprägungen Regular, Italic, Bold, Bold+Italic durch metrisch kompatible Fonts.

    • Nicht abgedeckt: Symbol.

  • Das entsprechende Projekt inklusive der 13 verfügbaren Fonts ist auf github unter https://github.com/levigo/documentplatform-standard14-fonts verfügbar.
  • AFP/MO:DCA: Standardmäßige Definition von Ersatzfonts basiert nun auf Standard 14 Fonts. 
  • ALF: Standardmäßige Definition von Ersatzfonts basiert nun auf Standard 14 Fonts. 
  • Text: Konfiguration über TextFont Klasse in TextReaderSettings
  • COLD: Standardmäßige Definition von Ersatzfonts basiert nun auf Standard 14 Fonts. 
  • Annotationen: Logische Fontnamen/Fontnamen der Standard14-Fonts können aufgelöst werden und werden verwendet. Siehe auch https://support.levigo.de/products/jadice/documentplatform/current/german/sect.anno.font.resolving.html
  • Anpassbare Zuordnung von Ersatzfonts basierend auf den Standard-14 in verschiedenen Ausprägungen
    • bei Dokumentformaten: Der Scope wird in einer Map zurückgeliefert: Key (String) = Scopes.FORMAT Value (Object) = entsprechende Formatklasse
    • bei Annotationen: Der Scope wird in einer Map zurückgeliefert: Key (String) = Scopes.SOURCE Value (Object) = entsprechende Annotationstyp
    • pro Dokument ist die Konfiguration beim Laden über die FontFactoryReaderSettings möglich
  • Einheitliche Darstellung logischer Schriften
    • serif, sansserif, monospaced können via LogicalFontFactory aufgelöst werden
    • Nachvollziehbarkeit, welche Schrift für welchen logischen Font angewendet werden soll: wird durch entsprechende FontFactory Implementation durchgeführt.
  • Umgebungsneutrale, einheitliche Darstellung durch Verwendung gleicher Zuordnungen von Schriften
    • Mögliche Vorgehensweise:
      1. Eigene FontManager Implementation erstellen und dort alle benötigten Fonts registrieren. Die Fonts sollten mit der Anwendung mitgeliefert werden.
      2. Eigene FontFactory Implementation mit entsprechender Mapping Logik implementieren. 
      3. FontFactory Implementation beim Laden mit FontFactoryReaderSettings konfigurieren
  • Konfiguration von Zuordnungen
    • Zuordnung: Fontname zu physikalischem Font kann über eine FontFactory Implementation erfolgen. Voraussetzung: benötigte Fonts sind beim FontManager bereits registriert


Ein Überblick über die Weiterentwicklung zukünftiger Releases der jadice document platform sind den aktuellen Release Notes und der Roadmap zu entnehmen.

Verwandte Artikel