Die Älteren werden sich erinnern, dass ich mich dereinst regelmäßig über die mangelhafte Qualität diverser PDF/A-Exporte mokierte. Fast sieben Jahre später muss man feststellen, dass sich dahingehend einiges zum Besseren gewandelt hat. Ein mir aktuell vorliegendes Beispiel: In der Version 9 lieferte der Abbyy Finereader kein korrektes PDF/A. Der Export der Version 12 (jeweils “Professional”) ist (soweit meine Validierungstools ordentlich arbeiten) tadellos. Abgesehen davon ist die OCR-Erkennungsquote deutlich verbessert.
Schlagwort: pdf/a
Abbyy Finereader: Guter Support und bald auch korrektes PDF/A
Zeit für eine kleine Korrektur. Am 18. November bemängelte ich den Support bei Abbyy und auch den fehlerhaften PDF/A-Export. Ich schrieb:
Nach anfänglich gutem Kontakt blieben dann nach und nach die Antworten aus.
Der anfänglich gute Kontakt ist wieder aufgenommen. Wie ich nun erfuhr: Das von mir zur Evaluation der Standardkompatibilität verwendete Preflight-Modul arbeitet in den verschiedenen Adobe-Versionen unterschiedlich. Erst ab Adobe Acrobat 9.0 Pro arbeitet Preflight korrekt, wie auch Leonard Rosenthol (“Technical Standards Evangelist for Adobe Systems that focuses on PDF Standards”), bestätigt:
NOTE: this may/will mean that what you saw in Acrobat/Reader 8 and earlier does not match what you are seeing in Acrobat/Reader 9 when viewing standards-complaint files. But guess what – that’s because Acrobat 9 is now correct!
Wenn das Validierungstool nicht korrekt arbeitet, kann man nicht standardkonform entwickeln. Abbyy hat allerdings zugesichert, dass der Finereader in Kürze an die (korrekte) Validierung nach Adobe Acrobat 9 Pro angepasst wird. Der Abbyy Recognition Server arbeitet bereits standardkonform.
Abbyy Finereader Professional: fehlerhaftes PDF/A und schlechter Support
Abbyy Finereader: Guter Support und bald auch korrektes PDF/A
Abbyy wirbt mit PDF/A-Export für den Abbyy Finereader Professional, schon ab Version 8.1. Der PDF/A-Export ist jedoch fehlerhaft.
„Abbyy Finereader Professional: fehlerhaftes PDF/A und schlechter Support“ weiterlesen
OpenOffice.org 3.0 ante portas
Golem kündigt OpenOffice.org 3.0 an.
Eine weitere wesentliche Neuerung ist der PDF-Import, mit dem sich existierende PDF-Dateien verändern lassen, auch wenn die originale Quelldatei nicht mehr vorhanden ist. Neu ist auch das Startcenter, das sich nach dem Starten der Anwendung zeigt: Es erlaubt, direkt Dokumente zu öffnen oder neue anzulegen. Bislang startete die Textverarbeitung Writer als Standardapplikation.
Klingt erst einmal richtig gut. Der PDF/A-Support bei OpenOffice.org ist ja ohnehin vorbildlich. Vielleicht tut sich auf diesem Weg nun auch eine Möglichkeit auf, vorhandene PDF-Dateien nachträglich mit eingebetteten Schriften zu versehen?
Der 1. Release-Candidate steht schon zum Download bereit.
Word misstraut dem früheren Selbst
Was man beim Wandeln alter Dateien sehr heterogener Herkunft in PDF/A alles erlebt und erfährt, wäre (wenn es nicht ein so unglaublich trockenes Thema wäre) einen Abenteuerroman wert. Ein besonders schönes Fundstück: Microsoft blockiert das Öffnen von mit früheren Versionen von Word hergestellten Dateien durch Word 2007. Unglaublich, aber wahr. Um das zu beheben, muss nun in der Registry gefummelt werden.
Abwärtskompatibel geht anders. Wahnsinn, warum schickst Du mich in die Hölle…
PDF/A vs. Open Access?
Subjektive Meinung: PDF/A ist der vermutlich am schlechtesten implementierte Standard seit Erfindung von Dokumentstandards überhaupt. Es ist veröffentlichungswilligen und dem Open Access zugeneigten Autoren kaum zumutbar, schon vorhandene Dokumente in standardkonformes PDF/A zu konvertieren. Kaum eine Lösung hält, was sie verspricht, bei fast jeder Konvertierung schlägt irgend etwas fehl. Auf meinen Hilferuf zur PDF/A-Konvertierung haben sich etliche Leute bei mir per Mail gemeldet. Alle mit dem gleichen oder zumindest ähnlichen Problemen.
Wie ist Abhilfe zu schaffen? Eine mögliche Lösung scheint mir, auf die konsequente Einhaltung des PDF/A-Standards bei Dokumentenservern zu verzichten. Wer etwas veröffentlichen will, sollte nicht mit allzu vielen technischen Hürden belastet werden. So wie es momentan aussieht, steht die an sich gute Idee, einen offenen und einheitlichen Standard für Dokumentenserver zu verwenden, einer breiten Akzeptanz der Selbstarchivierung entgegen.
Es ist einfach lächerlich, dass jeder Autor vor der Archivierung seiner Dokumente drei Semester PDF/A studieren muss. Um eine breite Akzeptanz von OA zu erzielen, müssen wir es den Autoren so einfach wie möglich machen. Youtube und Slideshare müssen zumindest hierbei Vorbilder sein. Klar ist, dass eine solche Einfachheit vermutlich nicht erreicht werden kann. Zu unterschiedlich sind die Ziele der Dienste. Aber als Richtlinie kann und soll der Veröffentlichungsvorgang bei solchen Angeboten dienen.
Bleibt das Problem der Langzeitarchivierung. Eine mögliche Umsetzung wäre, diese zentral z.B. durch die DNB zu organisieren. Sie sollte auf jeden Fall nicht zum Problem der Autoren werden.
Ich bitte um Meldung in den Kommentaren: An welcher Bibliothek funktioniert der Umgang mit PDF/A auch nur halbwegs problemlos?
Hilferuf zur PDF/A-Konvertierung
Wie man als regelmäßiger Infobibleser sicherlich mitbekommen musste, beschäftigt mich das Thema PDF/A in letzter Zeit in hohem Maße. Immer wieder stoße ich auf Probleme, die zwar nicht ohne Weiteres, aber irgendwie dann doch zu beheben sind. Zwei Fehlermeldungen konnte ich bislang jedoch nicht beseitigen.
Weiten-Informationen für Zeichen sind inkonsistent
ist die bei Weitem häufigste Fehlermeldung bei der Konvertierung von ‘normalem’ PDF in PDF/A. Werte Infobib-Leser, gibt es eine Möglichkeit, dies gezielt zu beheben? An Werkzeugen steht u.a. Adobe Acrobat Professional 9.0 inkl. Preflight zur Verfügung.- Gibt es eine Möglichkeit, Schriften nachträglich einzubetten? Das Dokument wird ja schließlich auf dem Monitor angezeigt, also müsste es doch möglich sein, exakt diese Schriftart auch einzubetten?
Für Hinweise auf Lösungsmöglichkeiten wäre ich äußerst dankbar!
PDF/A mit Open Office 2.4
Beeindruckend locker flockig funktioniert die PDF/A-Erzeugung mit OpenOffice 2.4. Preflight meldet bei der Validierung: Keine Probleme gefunden
. Das sollte bei der Erzeugung von PDF-Dateien eigentlich selbstverständlich sein, ist es aber nicht. Wer noch nach Argumenten sucht, warum man OpenOffice als wissenschaftlich Schreibender einsetzen sollte, müsste spätestens jetzt überzeugt sein. Hochschuldokumentenserver nehmen oft (und berechtigterweise) nur Dateien im PDF/A-Format an.
Online zu PDF/A konvertieren und überprüfen
Neevia bietet einen kostenfreien, web-basierten Dokumentenkonvertierer an. Unterstützt werden zahlreiche Formate der Kategorien Generic Formats (z.B. Adobe PDF oder Adobe PostScript), Word Processing Formats (ASCII Text, ANSI Text, Microsoft RTF, Microsoft Word for PC v2 bis u.a. Microsoft Word for Windows 2000, Microsoft Works, Microsoft Windows Write, WordPerfect), Spreadsheet Formats (Corel QuattroPro, Lotus 1-2-3, Microsoft Excel, Microsoft Works Spreadsheet), Presentation Formats (Lotus Freelance, Microsoft PowerPoint) und Graphic Formats (BMP, GIF, JP2, JPEG, JPG, PGM, PICT, PNG, TIFF und wirklich viele mehr) als Ursprungsdatei. Umgewandelt werden kann in verschiedene graphische Formate und – hier wird es interessant für Gelegenheits-Selbstarchivierer – in PDF/A.
Neevia Document Converter eXpress makes it possible for anyone to instantly convert files to PDF or Image without the need of installing special software.
Das ist richtig, allerdings gibt es eine Begrenzung auf 1 MB pro Datei. Für Aufsätze mit nur wenigen Darstellungen ist das ausreichend, für die Dissertation muss man dann schon zu einer Programminstallation greifen.
Man sollte stets prüfen, ob das erhaltene Dokument auch wirklich dem PDF/A-Standard entspricht. Intarsys bietet einen entsprechenden Online-Check an. Ein von mir testweise mit dem Neevia Document Converter erzeugtes PDF/A bestand den Test ohne Beanstandungen, eine andere Datei (PDF 1.7), die ich zu Vergleichszwecken validieren ließ, erhielt folgende Fehlermeldung:
Document information dictionary ohne korrespondierende XMP-Struktur
Stream Objekt mit ungültigem Endstream
Unkalibrierter Farbraum ohne passenden OutputIntent
Font Times-Bold muss eingebunden sein
Font Helvetica muss eingebunden sein
Font Times-Roman muss eingebunden sein
Font Helvetica-Bold muss eingebunden sein
Font Helvetica-BoldOblique muss eingebunden sein
Font Helvetica-Oblique muss eingebunden sein
Keine gültige PDF/A Versionsinformation vorhanden