In den 59 von Word exportierten PDFs aus dem öffentlichen Sektor, die wir für einen früheren Artikel über denselben Scan validiert haben, schlug Klausel 7.21.4.1-1 – Schriftarten nicht eingebettet – bei 64 % fehl. Dies war der dritthäufigste Fehler in dieser Stichprobe und der einzige der Top drei, den Word tatsächlich per Kontrollkästchen beheben lässt.
Was „nicht eingebettet“ für die Person bedeutet, die zuhört, nicht für die, die druckt
Jeder Buchstabe, den ein PDF anzeigt, wird als numerischer Zeichencode gespeichert, der mit einer Schriftart verknüpft ist, nicht als buchstäblicher Unicode-Zeichenwert. Irgendetwas muss „dieser Glyphe, in dieser Schriftart, an dieser Position“ zurück in „den Buchstaben T“ übersetzen, bevor ein Screenreader, ein Suchfeld oder ein Kopier-Einfüge-Vorgang damit arbeiten kann. Ein PDF kann diese Übersetzung explizit in einer Nachschlagetabelle namens ToUnicode CMap mitführen. Wenn diese vorhanden ist, ist die Extraktion eindeutig, egal welche Schriftart auf dem Lesegerät installiert ist oder nicht. Wenn sie fehlt, greift der Reader auf die interne Kodierung der Schriftart zurück – was nur funktioniert, wenn die tatsächliche Schriftart oder etwas, das sich identisch verhält, zur Verfügung steht. Entfernen Sie die Schriftart aus der Datei, haben Sie genau das entfernt, wovon dieser Rückgriff abhängt.
Welche Schriftarten fehlen und was mit ihnen verloren geht
Die zwei Schriftarten, die für fast alles verantwortlich sind
Von den 38 Dateien in unserer Stichprobe, die 7.21.4.1-1 nicht bestehen, haben wir den Schriftnamen aus jeder fehlgeschlagenen Prüfung gelesen, die veraPDF gemeldet hat. Zwei Familien machen fast das gesamte Problem aus:
| Schriftfamilie | Dateien, in denen sie fehlt | Anteil der 38 |
|---|---|---|
| Times New Roman | 35 | 92 % |
| Arial | 29 | 76 % |
(Dateien können beide vermissen, daher summieren sich die Anteile nicht auf 100 %.) Dies sind die zwei Schriftarten, die jede Windows-Installation bereits besitzt, was genau die Falle ist: Sie werden auf dem Rechner, der sie erstellt hat, korrekt gerendert, sodass niemand merkt, dass etwas nicht stimmt, bis die Datei ein Gerät – oder eine assistive Technologie – erreicht, das etwas anderes substituiert.
Ob die Datei dem Nutzer einen Rückgriff bietet
Wir haben dann geprüft, ob diese Dateien die ToUnicode-Tabelle enthalten, die den Fehler abmildern würde. Mit pikepdf gegen alle 38 Dateien zählten wir jedes einzelne nicht eingebettete Schriftobjekt – 144 an der Zahl, was mit der Anzahl der fehlgeschlagenen Prüfungen von veraPDF für dieselbe Klausel übereinstimmt – und fragten, ob jedes davon eine ToUnicode CMap besitzt: Keines der 144 tut dies.
In der Praxis funktionierte die Extraktion hier dennoch. Wir haben dieselben 38 Dateien durch pdfplumber laufen lassen, und der ungarische Text – einschließlich der Doppelakut-Vokale ő und ű, die in einer einfachen Windows-1252-Codepage nicht existieren – wurde korrekt ausgegeben, da der eigene Decoder von pdfplumber bereits die Standard-Tabelle /WinAnsiEncoding kennt, die jede dieser 144 Schriftarten deklariert, unabhängig davon, ob eine ToUnicode-Tabelle sie unterstützt oder nicht. Also ist heute niemandem das Kopieren und Einfügen kaputtgegangen. Was fehlt, ist die Garantie: Die Datei gibt selbst kein Versprechen darüber ab, wie ihr Text gelesen werden soll, und überlässt diese Aufgabe vollständig dem Tool, das sie als Nächstes öffnet. PDF/UA erlaubt es einem Ersteller nicht, sich darauf zu verlassen, und nachdem wir 144 dieser Schriftobjekte geprüft haben, ohne ein einziges Gegenbeispiel zu finden, würden wir das auch nicht tun.
uv run --quiet python3 -c "
import pikepdf
pdf = pikepdf.open('file.pdf')
for page in pdf.pages:
for font in page.get('/Resources', {}).get('/Font', {}).values():
fd = font.get('/FontDescriptor')
if fd and not any(k in fd for k in ('/FontFile', '/FontFile2', '/FontFile3')):
print(font.get('/BaseFont'), '- ToUnicode:', '/ToUnicode' in font)
"
Wird das mit einem neueren Word besser? Wir haben es geprüft: Nein
Es wäre ein schönes Ende, wenn die Fehlerquote einfach sinken würde, je neuer Word wird. Gruppiert nach dem Feld Producer in den Metadaten jeder Datei, über die 54 unserer 59 Dateien, die tatsächlich von einer Version von Word selbst erstellt wurden:
| Word-Version (Producer-Feld) | Dateien | Schriftarten nicht eingebettet |
|---|---|---|
| Word 2007 | 3 | 3 (100 %) |
| Word 2010 | 2 | 2 (100 %) |
| Word 2013 | 2 | 2 (100 %) |
| Word 2016 | 17 | 13 (76 %) |
| Word 2019 | 14 | 9 (64 %) |
| Word LTSC | 4 | 3 (75 %) |
| Word für Microsoft 365 | 9 | 4 (44 %) |
| Word 2021 | 2 | 0 |
| Word 2024 | 1 | 0 |
Wenn man dies als Trend liest, würde man schlussfolgern, dass Microsoft den Standard stillschweigend korrigiert hat. Betrachtet man die Stichprobengrößen, fällt diese Schlussfolgerung jedoch auseinander: Die zwei neuesten Versionen decken zwei Dateien und eine Datei ab. Das ist kein Beweis für irgendetwas – es sind zu wenige Daten, um sich eine Meinung zu bilden, und so zu tun, als wäre es anders, ist genau die Art von Überinterpretation, die diese Art von Messung aufdecken, nicht erzeugen soll. Wenn Sie wissen wollen, was Ihre eigene Installation standardmäßig tut, ist der Test im nächsten Abschnitt der einzige, der Ihnen das tatsächlich sagt.
Die Lösung ist ein Kontrollkästchen, und es gehört in die Vorlage
In Word: Datei → Optionen → Speichern → Schriftarten in der Datei einbetten. Aktivieren Sie dies, und die Einstellung gilt für das Dokument, das Sie gerade geöffnet haben – was die Falle ist. Es ist nicht systemweit, daher beginnt ein neues Dokument oder ein Kollege an einem anderen Computer wieder damit, dass es nicht aktiviert ist. Der einzige Weg, wie dies über eine glückliche Datei hinaus überlebt, ist, es in die Vorlage einzubauen, die jeder tatsächlich öffnet, anstatt es als Schritt zu betrachten, an den man am Tag des Exports denkt.
Words eigene Beschreibung der Einstellung ist stillschweigend bedingt: Sie speichert die im Dokument verwendeten Schriftarten, „wenn die Schriftarten eingebettet werden dürfen“. Times New Roman und Arial – die zwei Schriftarten, die in dieser Stichprobe fast den gesamten Schaden anrichten – tragen Microsofts Standard-Einbettungslizenz, daher ist diese Bedingung hier nie ein Hindernis. Das kann für alles, was Sie separat lizenziert haben, anders sein: Manche kommerzielle und kostenlose Schriftarten werden mit einer Einbettungsbeschränkung geliefert, die in der Schriftdatei selbst verankert ist, und keine Exporteinstellung setzt eine Lizenz außer Kraft, die die Schriftart nicht gewährt.
Das Aktivieren des Kästchens offenbart ein zweites: Nur im Dokument verwendete Zeichen einbetten. Lassen Sie es aktiviert. Es reduziert nicht, was ein Validator oder ein Screenreader erhält – eine Teilmenge bettet immer noch die exakten Glyphenumrisse ein, die das Dokument tatsächlich zeichnet, was alles ist, wonach einer von beiden jemals fragen wird – es vermeidet lediglich das Mitführen der etwa tausend Glyphen einer vollständigen Schriftart, die das Dokument niemals verwendet. Wir haben dies anhand unseres eigenen Korpus geprüft: Wo dieselben 59 Dokumente eine Schriftart tatsächlich eingebettet haben, trugen 229 der 337 unterschiedlichen eingebetteten Schriftobjekte (68 %) das sechsstellige Teilmengen-Präfix, das Word auf eine gekürzte Schriftart stempelt – BCDEEE+Calibri zum Beispiel – und keines davon löste die Einbettungsprüfung aus. Teilmengenbildung ist in diesem Datensatz bereits der Normalfall, kein Kompromiss.
Der einzige Punkt, an dem Sie die Teilmengenbildung etwas kostet: Wenn ein anderes Tool später ein PDF mit Teilmengen bearbeitet und versucht, Text in dieser Schriftart hinzuzufügen, fehlen die Glyphendaten für die neuen Zeichen. Das ist eine echte Einschränkung – sie gilt nur nicht für die Veröffentlichung eines Dokuments, das Sie danach nicht an einen PDF-Editor weitergeben werden, wofür eine Vorlageneinstellung gedacht ist.
Was Einbettung nicht behebt
Die Schriftarteinbettung verdient ihren Platz als die Lösung, die jeder tatsächlich umsetzen kann, aber sie ist eine Lösung unter mehreren, und es ist wichtig, klar zu sagen, dass sie nicht die größte ist. In derselben Stichprobe schlagen der PDF/UA-Identifikator (71 % der Dateien) und der Dokumenttitel im Metadatenstrom (68 %) häufiger fehl als die Einbettung – und Word hat für beides keine Einstellung. Das Aktivieren der Schriftarteinbettung wird diese nicht berühren. Es wird auch kein Dokument wiederherstellen, das seine Struktur nach dem Export durch einen Komprimierungsvorgang vollständig verloren hat, was seine eigene Fehlerart ist, die es wert ist, separat geprüft zu werden, falls in Ihrem Arbeitsablauf nach Word noch etwas ausgeführt wird.
Wenn Sie Ihre eigenen Dokumente prüfen möchten
Words Barrierefreiheitsprüfung wird eine fehlende Schriftart niemals markieren – es ist per Design nicht eines der sieben Dinge, die sie prüft, da sie das Dokument prüft, das Sie geschrieben haben, nicht die Datei, die Word ausgibt. Der einzige Weg, dies zu wissen, ist, sich das PDF selbst anzusehen. Unser PDF-Barrierefreiheits-Checker meldet dieselbe Klausel wie veraPDF bei jeder Datei, die Sie hochladen, ohne dass etwas installiert werden muss; die PDF/UA-Fehlerreferenz erklärt, was jeder Fehler bedeutet und welche eine Vorlageneinstellung tatsächlich verhindert; und der PDF/UA-Leitfaden deckt ab, was der Standard über diese eine Klausel hinaus erfordert. Beginnen Sie mit einem Dokument, das die Leute tatsächlich herunterladen – Times New Roman und Arial richten den meisten Schaden an, und sie sind in fast allem enthalten, was Ihr Büro veröffentlicht.