Freitag, 20. Juni 2014

*grrrr* – Oder wie man mit LaTeX vielleicht ein PDF/A erzeugt

Vorwort


Dieser Beitrag ist entstanden, als ich versucht habe herauszufinden, wie ein Doktorand seine mit LaTeX erstellte Masterarbeit möglichst von Hause aus als PDF/A abliefern könnte.

Damit das nicht zum Rant ausartet, habe ich die einzelnen Punkte sachlich zusammengefasst. Wer mag kann sich ff. Szene dazu vorstellen (links).

Nach aktuellem Stand läßt sich mit LaTeX wenn überhaupt, nur valides PDF/A-1b erstellen.

Nein? Doch! Orrr.

Meine Recherchen zu PDF/A-2b haben keine Resultate erbracht. Eigene Anpassungen an den LaTeX-Paketen hyperref und ggf. hyperxmp bzw. pdfx wären dazu notwendig. Wer hier Infos hat, immer her damit. Auch sonst sind Eure Kommentare gerne gesehen.

 

Schriftarten


PDF/A erwartet, daß alle Schriftarten eingebettet sind. Dies gilt auch für die Schriftarten, die zB. in Diagrammen oder Bildern vorkommen, die unter LaTeX mit \includegraphics{} eingebettet werden.

Mit dem Befehl pdffonts (Teil von Ghostscript) kann man sich ausgeben lassen, welche Schriftarten im PDF verwendet werden und ob diese eingebettet sind (Spalte emb).  LaTeX selbst ist in den meisten Distributionen so konfiguriert, daß das Tool pdflatex Schriftarten in das Dokument einbettet.
Dies sollte man aber trotzdem für alle einzubettenden PDFs (Diagramme etc.) prüfen, da LaTeX diese quasi nur ins zu erzeugende PDF übernimmt.


$> pdffonts test.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
MSQLLN+URWPalladioL-Bold             Type 1            Custom           yes yes yes    480  0
ZWIRUB+URWPalladioL-Roma             Type 1            Custom           yes yes yes    481  0
[none]                               Type 3            Custom           yes no  no     493  0
BAAAAA+CMUSansSerif                  TrueType          WinAnsi          yes yes yes   1669  0
TDAPEI+Arial-BoldMT                  TrueType          MacRoman         yes yes no    1738  0
TNUBAM+Menlo-Regular                 TrueType          MacRoman         yes yes no    1739  0
CTFEKI+ArialMT                       CID TrueType      Identity-H       yes yes no    1740  0
Arial                                TrueType          WinAnsi          no  no  no    3019  0
ABCDEE+Calibri                       TrueType          WinAnsi          yes yes no    3020  0

Unter Linux kann man mit ff. Befehl die Fonts auch nachträglich in PDFs einbetten:
gs \
 -sFONTPATH=/path/to/fonts:/another/dir/with/more/fonts \
 -o output-pdf-with-embedded-fonts.pdf \
 -sDEVICE=pdfwrite \
 -dPDFSETTINGS=/prepress \
 input-pdf-where-some-fonts-are-not-embedded.pdf
Falls zB. MS Arial fehlt, das Debian-Paket ttf-mscorefont-installer installieren, die Fonts sind dann unter /usr/share/fonts/truetype/msttcorefonts/ zu finden.
Für Postscript bzw. EPS gilt dies analog.

Kurzum, für alle in ein LaTeX Dokument einzubettenden Grafiken im PDF-Format sollten wir sicherstellen, daß die Fonts eingebettet sind.

Transparenz in Grafiken


Da PDF/A-1b auf PDF Version 1.4 aufbaut, sind Transparenzen im PDF nicht gestattet. Wenn man Grafiken einbettet, sollte man sicherstellen, daß diese keinen Alpha-Channel benutzen. Für PNG etc. kann man GIMP oä. nutzen.

Wenn PDFs (zB. Diagramme etc.) als Grafiken genutzt werden kann man über ff. Kommando prüfen, ob diese Transparenzen enthalten:

$> pdfimages -list test.pdf
page   num  type   width height color comp bpc  enc interp  object ID
---------------------------------------------------------------------
  14     0 image    1762   232  rgb     3   8  image  no       670  0
  14     1 smask    1762   232  gray    1   8  image  no       670  0
  16     2 image      64    94  rgb     3   8  image  no       735  0
  16     3 smask      64    94  gray    1   8  image  no       735  0
  16     4 image      64    94  rgb     3   8  image  no       736  0
  16     5 smask      64    94  gray    1   8  image  no       736  0
  16     6 image     708   134  rgb     3   8  image  no       737  0
  16     7 image     529   135  rgb     3   8  image  no       738  0
  16     8 image     133    18  rgb     3   8  image  no       739  0

Dabei erkennt man am Type "image" gefolgt vom Typ "smask" die relevante transparente Stelle. Aus obiger Ausgabe also diese Zeile:
 
  14     0 image    1762   232  rgb     3   8  image  no       670  0
  14     1 smask    1762   232  gray    1   8  image  no       670  0
Mit ghostscript kann man diese PDFs auch umwandeln, das Ergebnis muß aber kontrolliert werden, weil sich uU. das Aussehen ändern kann:
$> gs \
  -o pdf_without_transparency.pdf \
  -dHaveTransparency=false \
  -sDEVICE=pdfwrite \
  input_with_transparency.pdf

Farbräume


Auch hier sind Vorbereitungen nötig. Da LaTeX einfach nur stumpf die Grafiken in das LaTeX-Dokument einbindet, müssen wir dafür sorgen, daß möglichst alle Grafiken nur einen Farbraum nutzen. Hier kann ebenfalls pdfimages wie oben genutzt werden. Dort ist die Spalte color relevant.

Mit folgenden ghostscript-Aufrufen kann man nachträglich die Farbräume anpassen. Dabei gehen Informationen verloren, so daß man das Ergebnis auf jedenfall durch Sichtkontrolle prüfen sollte.

Für Konvertierung nach sRGB:

$> gs \
    -o output_rgb.pdf \
    -sDEVICE=pdfwrite \
    -dBATCH -dNOPAUSE -dCompatibilityLevel=1.4 \
    -dColorConversionStrategy=/sRGB \
    -dProcessColorModel=/DeviceRGB \
    -dUseCIEColor=true \
    input_cmyk.pdf
Für Konvertierung nach CMYK:
$> gs \
   -o output-cmyk.pdf \
   -sDEVICE=pdfwrite \
   -sProcessColorModel=DeviceCMYK \
   -sColorConversionStrategy=CMYK \
   -sColorConversionStrategyForImages=CMYK \
    input_rgb.pdf
Für PDF/A-1b wäre sRGB zu empfehlen.

Dazu brauchen wir eine Farbprofildatei.  Wir können das Farbprofil von Color.org (sRGB) herunterladen und nach sRGBIEC1966-2.1.icm umbenennen.


Damit wären die wichtigsten Vorbereitungen abgeschlossen. Für  eingebettete PDFs wäre es sinnvoll, wenn diese keine Kompression nutzen würden.

 

Das eigentliche LaTeX-Dokument


Zuerst sollte man sicherstellen, daß man eine aktuelle TexLive-Distribution nutzt. Für die Erstellung der PDFs hat man die Wahl zw. Nutzung des Pakets pdfx oder einer Kombination von hyperref und hyperxmp.
Ich habe mich hier für letztere Variante entschieden.
Zuerst müssen wir das Farbprofil in das LaTeX-Dokument einbinden. Dazu reicht folgender Code im Header:
\immediate\pdfobj stream attr{/N 3}  file{sRGBIEC1966-2.1.icm}
\pdfcatalog{%
/OutputIntents [ <<
/Type /OutputIntent
/S/GTS_PDFA1
/DestOutputProfile \the\pdflastobj\space 0 R
/OutputConditionIdentifier (sRGB IEC61966-2.1)
/Info(sRGB IEC61966-2.1)
>> ]
Das Paket hyperref wird mit der Option pdfa geladen, damit in PDF/A nichterlaubte Optionen nicht aus Versehen gesetzt werden. Das hyperxmp Paket sorgt dafür, dass die für PDF/A zwingend notwendigen Metadaten im XMP Format eingebunden werden:


\usepackage[pdfa]{hyperref}
\usepackage{hyperxmp}
% Beispiel aus hyperxmp-Beschreibung, der Befehl \hypersetup fügt zusätzlich bibliographische Metadaten in das PDF ein:
\author{Albert Einstein}
\hypersetup{%
 pdftitle={%
  On a heuristic viewpoint concerning the production and transformation of light
 },
 pdfauthor={Albert Einstein},
 pdfauthortitle={Technical Assistant, Level III},
 pdfcopyright={Copyright (C) 1905, Albert Einstein},
 pdfsubject={photoelectric effect},
 pdfkeywords={energy quanta, Hertz effect, quantum physics},
 pdfcaptionwriter={Scott Pakin},
 pdfcontactaddress={Kramgasse 49},
 pdfcontactcity={Bern},
 pdfcontactpostcode={3011},
 pdfcontactcountry={Switzerland},
 pdfcontactphone={031 312 00 91},
 pdfcontactemail={aeinstein@ipi.ch},
 pdfcontacturl={%
 },
 pdflang={en},
}
Da PDF/A auf einer eindeutigen Zuordnung Glyphen zu Zeichensatz besteht, müssen dazu noch diese Paket eingebunden werden:
  • glyphtounicode.tex maps glyph names to corresponding Unicode.
  • glyphtounicode-cmr.tex does the same for cmr  fonts

\input glyphtounicode.tex
\input glyphtounicode-cmr.tex 
\pdfgentounicode=1
Nachtrag 2014-06-25: Auf der TeX-Mailingliste kam noch ff. Hinweis:

\usepackage[noTeX]{mmap}

> Even in XeTeX this requires careful use of fonts and mappings.

 mmap.sty  is designed for use with pdfTeX, not XeTeX.

> For example, the Times New Roman font has the "fi" ligature in a
> private area and does not have ligature substitution pointing to it,
> which means if you use it you are in trouble and if you don't you
> won't get your ligature.

mmap.sty  defines CMap resources for the (old) standard TeX fonts.
          More recent fonts do not need what it provides.

If you want to use Times New Roman, then sorry,  mmap  does nothing for you. But you don't want to use TNR for mathematics, do you?
It isn't designed for that.


Da bestimmte Kompression nicht erlaubt ist, ist ff. hilfreich:
\pdfobjcompresslevel=0
\pdfinclusioncopyfonts=1

Nun sollte pdflatex ein PDF/A1-b Dokument erzeugen.

Nachtrag 2014-06-25:  Ebenfalls auf der TeX-Mailingliste war unter Subject "very subtle endobj bug in latest pdftex" folgendes Problem mit pdftex in TeX Live 2014 geschildert:

> It seems that pdftex in TeX Live 2014 is copying
>
>>> \rendobj
>
>
> as
>
>>> endobj
>
>
> ignoring \r.

the problem is in pdftoepdf.cc, line 602:

        pdf_puts(">>");

This problem was in the previous versions of pdftex, too. It's not a serious problem, but yes it would prevent pdf/a validation.

However the fix is not simply to change it to

        pdf_puts(">>\n");

since it would add some unwanted blank lines. I will take a close look during the week.


Zur Validierung kann man das Online-Werkzeug von 3Heights nutzen: http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx


Freitag, 6. Juni 2014

Am Ende der Nahrungskette?

Gestern war ich auf dem Bibliothekartag und im Anschluß der Vorträge zum Thema Langzeitarchivierung entspann sich eine kleine hitzige Diskussion, darüber ob man im Workflow die abliefernden Stellen dazu bekommen könne, Dokumente für das Langzeitarchiv zukünftig in besserer Qualität bereitzustellen.

Das Kernproblem ist, daß man im Langzeitarchiv aus folgenden Gründen nur archivfähige Dokumente halten möchte. Archivfähig (sh. Nestor Handbuch)  sind diese Dokumenttypen dann, wenn sie:

  • offen spezifiziert sind, damit man im Notfall einen Programmierer heransetzen kann, falls keine anderen Werkzeuge mehr existieren
  • große Verbreitung erfahren, weil dann die Chance hoch ist, daß genügend Erfahrungen mit dem Dokumenttyp vorhanden sind (und der Aufwandf sich ggf. lohnt)
  • eine geringe Komplexität besitzen, da so Interpretationsmissverständnisse und damit Fehler minimiert werden
  • ohne Rechtemanagment versehen sind, damit man die Dokumente ohne Probleme (Schlüssel weg, Anbieter existiert nicht mehr) lesen und verarbeiten kann
  • selbstdokumentierend sind, sprich: wichtige Aussagen über das Dokument selbst, wie Autor, Erzeugungsdatum, Stichworte im Format hinterlegt sind. Hintergrund ist hierbei, daß man im Fall der Fälle, wenn nur noch dieses Dokument existiert, man den Katalog an Metadaten neu aufbauen könnte.
  • robust gegen kleine Fehler sind. Fehler bleiben nicht aus. Seien es durch Hardware bedingte Bitfehler oder Fehler in der Software. Robust sein bedeutet auch, daß kleine Fehler im Datenstrom keine großen Schäden im Dokument nach sich ziehen. Deswegen fallen komprimierte (Teil-)Dokumente nicht unter diese Forderung.
  • keine oder nur geringe Abhängigkeiten von spezieller Hardware, Software oder anderen Resourcen haben. 
Da die Welt nicht ideal ist, werden Bibliotheken immer auch Dokumente angeboten bekommen, die nicht obige Kriterien erfüllen.

Üblicher (vereinfachter) Workflow
für Bibliotheksaufnahme

Unsere Kollegin hatte in ihrem Vortrag folgenden Workflow vorgestellt, der versucht einen Kompromiß zwischen "idealer Welt" und "Wir machen es den Abliefernden so einfach wie möglich" zu erreichen, in dem Dokumente nach obigen Kriterien geprüft und bei Verletzung eine Automatische Korrektur (ggf. Konvertierung) in ein besser für die Langzeitarchivierung geeignetes Dokument zu erreichen. Da die Konvertierungstools dabei das Aussehen des Dokumentes verändern können, wird das Ergebnis dem Abliefernden zur Überprüfung mitgeteilt.
Erweiterter Workflow um Abliefernden
die Konformität zum Langzeitarchiv so
einfach wie möglich nahezubringen
Die Diskussion entspann sich daran, daß es "schlicht unmöglich sei, die Abliefernden damit zu belasten", weil man doch "froh drüber sein muss, wenn überhaupt abgeliefert werde". In dem Zusammenhang fiel auch der Satz: "Als Langzeitarchiv stehen wir am Ende der Verwertungskette" und der Abliefernde "hat ja gar keine Veranlassung an die Langzeitarchivierung" zu denken.

Ich halte diese Aussagen im Übrigen für eine faule Ausrede. Ja, es stimmt, zur Zeit ist kaum ein Bewusstsein für Langzeitarchivierung vorhanden. Aber da heißt es nicht, Kopf in den Stand zu stecken, sondern dieses Bewusstsein zu wecken.

Wir haben auch gar keine andere Wahl. Die Zahl der vielfältigen elektronischen Formate wächst  nahezu exponentiell. Die Zahl der elektronischen Publikationen (wie anfangs die der Bücher) ebenfalls.

Europäische Produktion von gedruckten Büchern ca. 1450–1800.png
Europäische Produktion von gedruckten
Büchern ca. 1450–1800
“ von Tentotwo,
CC BY-SA 3.0 über Wikimedia Commons.
Absatz EBooks in Deutschland, Quelle: Statista


Wenn wir nur auf Bitstream-Preservation (Reines Backup) setzen werden wir einen Großteil unseres kulturellen Erbes verlieren.

Als Gedächtnisorganistionen werden wir immer nur ein Bruchteil der Ressourcen zur Verfügung haben, es ist utopisch zu glauben, daß man, Zitat: "Badbank für Archive" einrichten könne. Also machen kann man das schon, doch es ist dann eine bloße Datenmüllhalde, die dem eigentlichen Zweck der Langzeitarchivierung, die Verfügbarhaltung und Sicherung der Nutzbarkeit von Dokumenten entgegenläuft.

Kurzum, wir leben nicht in einer idealen Welt, aber ein Grund zu kapitulieren ist das nicht. Wir müssen spätestens jetzt anfangen darauf hinzuwirken, daß von unserer Kultur mehr als nur die Reste bleiben.