Metadaten-Extraktion aus PDFs und we:metadata

[jpunktkpunktzwo]

Zwei verwandte Probleme. Vielleicht auch nur ein Verständnisproblem.

Erstens:
In http://documentation.webedition.org/wik ... 7/metadata wird davon geredet, dass man Metadatenfelder für "Grafiken bzw. Binärdateien (PDFs etc.)" pflegen kann.

Automatisch beim Hochladen extrahieren lassen kann man die Metadaten auch. Das aber nur bei Bildern via EXIF/IPTC.

Wäre es nicht auch sinnvoll, das auf die Metadaten aus PDFs (XMP Metadata als XML im PDF) auszuweiten?
Im "Information"-Reiter eines hochgeladenen PDFs werden diese Metadaten ja unten auch schon als "PDF Daten" ausgegeben.

ACHTUNG: Da stimmt etwas mit dem Encoding nicht. Ich habe sowohl PDFs aus InDesign als auch aus Word generiert und hochgeladen. Beide Male wurden alle Umlaute verschwurbelt in "PDF Daten" angezeigt, während sie in Foxit Reader und dem firefox-internen PDF-Viewer sauber angezeigt wurden. Test-PDF anbei:

Umlaute-Test-Upload-ins-CMS.pdf

Aus Word

(44.37 KiB) 145-mal heruntergeladen

Zweitens:
Man kann ja wirklich Metadaten-Felder zu PDFs etc. im "Hochladen"-Reiter pflegen – wenn auch nicht automatisch extrahiert.

Allerdings kann man die via <we:metadata> dann doch offenkundig nur bei Bildern auslesen.

Das entspricht zwar der Dokumentation unter http://www.webedition.org/de/dokumentat ... z/metadata aber ich finde es widersinnig. So werden aus den Metadatenfelder bei PDFs real quasi nur webEdition-interne "Notizfelder".

Getestet habe ich das mit untenstehendem Template. Solange ich via <we:img /> im EditMode ein Bild verlinke, kann ich die Metadatenfelder auslesen.
Wandele ich das <we:img /> in Zeile 2 ein <we:href /> um, um ein PDF auswählen/verlinken zu können, zeigt er mir keines der beiden <we:field /> mehr an. Alles zwischen <we:metadata>…</we:metadata> ist ausgeblendet.

Oder denke/mache ich etwas falsch?

Code: Alles auswählen

<we:ifEditMode>
	(PDF oder) Bild auswählen: <we:img name="PDFDatei" />
</we:ifEditMode>
<we:ifNotEditmode>
	<main>
		<pre>URL der verlinkten Datei: <we:href name="PDFDatei" only="href" /></pre>
		<fieldset>
			<legend>Metadaten</legend>
			<we:metadata name="PDFDatei">
				<p>Titel: <we:field name="Title" /></p>
				<p>NeuesZusatzMetaFeld: <we:field name="NeuesZusatzMetaFeld" /></p>
				
			</we:metadata>
		</fieldset>
	</main>
</we:ifNotEditmode>

[mokraemer]

Also das PDF hab ich mir mal angesehen. Das ist ziemlich fies, da müßte ich erst mal die Spec lesen was das für ein Encoding darin ist. Die "Texte" sind ja alles Bilder, da geht hier eh nicht viel. Die Metadaten sind seltsam kodiert, das müßte aber schon gehen. Generiert Word immer solche seltsamen Header, auch ohne Umlaute? Das PDF von LibreOffice sieht da um Welten besser aus.

Die Felder werden hauptsächlich für die Suche herangezogen um Titel und Beschreibung anzuzeigen und dann auch in den Suchindex aufgenommen.

Das 2. kann ich grad noch nicht beantworten.

[jpunktkpunktzwo]

Also das PDF hab ich mir mal angesehen. Das ist ziemlich fies, da müßte ich erst mal die Spec lesen was das für ein Encoding darin ist. Die "Texte" sind ja alles Bilder, da geht hier eh nicht viel. Die Metadaten sind seltsam kodiert, das müßte aber schon gehen. Generiert Word immer solche seltsamen Header, auch ohne Umlaute? Das PDF von LibreOffice sieht da um Welten besser aus.

Das PDF-Format finde ich generell fies. A real PITA. Ekelige Fallstricke, serielle Datenströme, tote Datenströme, obskure Encodings und falsche Implementationen allerorten.

Laut Standard müssen die XMP-Metadaten fürs Dokument in UTF-8 im Dokument sein.
http://wwwimages.adobe.com/content/dam/ ... nPart3.pdf
Abschnitt "2.6.1 PDF".

Beim Word-PDF sah mir das nach UTF-16 mit BOM aus, was ich in den "PDF Daten" in webEdition angezeigt bekam.

Ändere ich in SVNREV 12643 in webEdition/we/include/we_classes/helpers/we_helpers_pdf2text.class.php die Zeile #144 von

Code: Alles auswählen

return CheckAndConvertISOfrontend(preg_replace_callback('#\\\\(\d{3})#', 'we_helpers_pdf2text::setOctChar', trim($str, self::TRIM_STRING)));

in

Code: Alles auswählen

return CheckAndConvertISOfrontend(mb_convert_encoding(preg_replace_callback('#\\\\(\d{3})#', 'we_helpers_pdf2text::setOctChar', trim($str, self::TRIM_STRING)), 'UTF-8', 'UTF-16'));

stimmte die Ausgabe für das Word-PDF (zwei Screenshots anbei).

Ich habe dir auch mal noch ein InDesign-PDF angehängt. Da scheint der Quelltext zunächst aufschlussreicher, aber die Metadaten kommen darin 2× vor. Ein Mal als XMP und ein Mal in Slash-Schreibweise

Code: Alles auswählen

/Subject(Zum Laden und Ausdrucken: Über Haarausfall…)

.
Da extrahiert webEdition momentan die Slash-Schreibweise. Darin ist der String aber in latin1 vorhanden.

Lasse ich die Ausgabe in Zeile #144 folgendermaßen konvertieren, stimmt die Anzeige nämlich wieder:

Code: Alles auswählen

return CheckAndConvertISOfrontend(mb_convert_encoding(preg_replace_callback('#\\\\(\d{3})#', 'we_helpers_pdf2text::setOctChar', trim($str, self::TRIM_STRING)), 'UTF-8', 'ISO-8859-1'));

Die Felder werden hauptsächlich für die Suche herangezogen um Titel und Beschreibung anzuzeigen und dann auch in den Suchindex aufgenommen.

Wäre doch für PDFs auch sinnvoll.

Das 2. kann ich grad noch nicht beantworten.

Die Meta-Daten-Extrahier-Klasse webEdition/we/include/we_classes/weMetaData/we_metadata_PDF.class.php ist jedenfalls schon vorhanden.

Sieht mir nicht nach besonders viel Arbeit aus, das Extrahieren der Metadaten dann mal auch mal noch auf die PDFs auszuweiten sowie das für die Suche und die Tags we:metadata/we:field verwendbar zu machen.
Das ist nicht als Gedrängele gemeint. Sieht im Quelltext aber so aus als sei fast alles schon vorhanden, nur nicht verknüpft.

So könnte man eine geschlossene Verwertungskette für diese Metadaten vom Grafiker (baut die Metadaten nach Vorgabe ein) zum Web-Redakteur (der das PDF in webEdition hochlädt) zur automatischen Auslese und Verwendung in den Templates hinbekommen.

Dann können sich in Auflistungen von Downloads, in Drucksachen-Übersichten usw. automatisch die Titelangaben dadurch ändern, dass jemand ein PDF neu hochlädt und sich das alles aus den Metadaten zieht.

Auch für die XML-Sitemaps/SEO wäre das extrem schniek. U. v. v. m.

Beste Grüße

[jpunktkpunktzwo]

Die Code-Änderung hat offenkundig (Screenshots im letzten Post) das Interpretieren von ModDate und CreationDate gekillt.

Vielleicht sollte man das Extrahieren/Konvertieren von PDF-Text und Metadaten in der class we_helpers_pdf2text mal eine externe PDF library machen lassen und dadurch das Problem der PDF-Implementations-Fehler, -Encodings usw. usf. auslagern.

Die momentane Klasse ist zwar schön klein, aber wenn das PDF immer nur beim Hochladen und im Information-Reiter (und nicht immer live bei den Tags we:metadata/we:field) von einer größeren PDF library interpretiert würde, sollte auch das nicht viel Performance schlucken.

Spricht IMHO also noch mehr für die automatische Extraktion via Metadatenfelder

[mokraemer]

Die Suche ist doch drin.

Das andere müßte nur wo anders gemacht werden. Zeigt aber dann einen klaren Verstoß gegen den PDF Standard, also kein Wunder das es nicht geht.

[jpunktkpunktzwo]

Die Suche ist doch drin.

Okay … mein Fehler. Die Frontend-Suche nutze ich noch nicht weil nur Metadaten.

Das andere müßte nur wo anders gemacht werden. Zeigt aber dann einen klaren Verstoß gegen den PDF Standard, also kein Wunder das es nicht geht.

Microsoft halt: (Embrace && extend) || Pfusch.

Danke für https://qa.webedition.org/tracker/view.php?id=11153

[mokraemer]

indesign wäre doch adobe. haben die was an der Spec geändert?

[mokraemer]

Vielleicht sollte man das Extrahieren/Konvertieren von PDF-Text und Metadaten in der class we_helpers_pdf2text mal eine externe PDF library machen lassen und dadurch das Problem der PDF-Implementations-Fehler, -Encodings usw. usf. auslagern.

wenn du eine findest, laß es mich wissen. Die meisten taugen nicht viel und kaum eine kommt mit PDFs >1.4 klar. Man kann das auch kaum voraussetzen - glaube nicht das ein Provider eine fragliche binäre Extension generell installiert. Und On-The-Fly würde ich das trotzdem nie machen. Suchen muß man ja so oder so können.

[mokraemer]

ich habs jetzt nicht geprüft, aber mit Bug #11153 sollte doch eigentlich auch die Metadaten des PDF's gehen - halt bei dir noch so kaputt wie bekannt.