PDF Vergleich

PDF-Vergleich

Liebe (Fach)Kundige,

habe ein Problem mit dem Vergleich von zwei PDF-Files.

Konkret:
Es werden aus einer (umfangreichen) Applikation bestimmte
Daten als PDF ausgegeben (ueber einen kommerziellen PDF-Creator).

Die so erstellten PDF-Files werden dann entweder ausgedruckt oder
als E-Mailanhang versendet UND auf jeden Fall in ein externes
Archivsystem abgelegt.

Das Problem ist nun, dass bestimmte Sachen mehr als einmal ausgegeben
werden, da an den Basisdaten etwas geaendert wurde. Manche der 
Aenderungen wirken sich auf den Inhalt der erstellten PDF ueberhaupt 
nicht aus aber loesen die Erstellung eines Files aus.

Zum Teil ist so eine Zweit-, Dritt- usw. Erstellung auch gewollt und
muss so bleiben, aber die dadurch entstandene Zweit-, Dritt- usw. 
Abspeicherung des Dokuments in dem externen Archivsystem (da es 
inhaltlich 100% das gleiche wie die Erstausgabe) unnoetig.

Wir wollten es dadurch umgehen, das man von jedem PDF ein MD5 (oder eine 
andere Hash) erstellt und die Dokumente mit gleichem Namen und Hashwert 
nicht ein zweites Mal archiviert.

Leider funktioniert dies nicht, da alle PDF's eine Art TimeStamp oder 
GUID haben, so dass auch inhaltlich gleiche PDF's verschiedene Hashwerte 
liefern.

Frage, kennt jemand die Stelle im PDF-File, so dass man diesen Bereich
in der Hashwertberechnung nicht beruecksichtigt?

Danke.

Gruesse
Julius


-- 
(my real mail address ends with a .net tld)

Re: PDF-Vergleich

Julius Kavay schrieb:

> Frage, kennt jemand die Stelle im PDF-File, so dass man diesen Bereich
> in der Hashwertberechnung nicht beruecksichtigt?

Nun, das Erstellungsdatum steht neben anderen Metadaten im »document
information dictionary« und ggf. im »Metadata«-Stream. Siehe
<http://www.adobe.com/devnet/pdf/pdfs/PDFReference16.pdf>

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Re: PDF-Vergleich

Julius Kavay schrieb in <news:756ovjF16l6r4U1@mid.individual.net>
> Frage, kennt jemand die Stelle im PDF-File, so dass man diesen Bereich 
> in der Hashwertberechnung nicht beruecksichtigt?

Vergiß den Ansatz bzw. guck Dir an, wie PDF intern aufgebaut ist. Wenn's 
wirklich "nur" um inhaltliche Übereinstimmung geht und die PDF, die 
typischerweise "inhaltlich identisch" sind, aus gleicher Quelle stammen 
(sprich: selbes Erzeugerprogramm und selbe PDF-Engine), dann _könnte_ es 
funktionieren, den Text aus dem PDF zu extrahieren [1] und die so 
entstandenen Texte bzw. Textdateien per Hash zu vergleichen.

Wir haben hier grad für ein Projekt eine visuelle Überprüfung (auf Basis 
von gerenderten PDF) programmiert. Aber das dürfte totaler Overkill 
sein...

Gruss,

Thomas

[1] Mittels pdftotext <http://www.foolabs.com/xpdf/download.html> oder 
    am Mac bspw. per 
    
    mdimport -d2 /pfad/zum/pdf 2>&1 | grep kMDItemTextContent
    
    (geht fast Faktor zwei schneller)

Re: PDF-Vergleich

Thomas Kaiser wrote:

Danke Dir fuer das beiseiteschieben meiner Scheuklappen...

>> Frage, kennt jemand die Stelle im PDF-File, so dass man diesen Bereich 
>> in der Hashwertberechnung nicht beruecksichtigt?
> 
> Vergiß den Ansatz bzw. guck Dir an, wie PDF intern aufgebaut ist. Wenn's
PDF-Aufbau ist gut, die Spezifikation hat ueber 1200 Seiten!

> wirklich "nur" um inhaltliche Übereinstimmung geht und die PDF, die
ja, genau um das geht es mir

> typischerweise "inhaltlich identisch" sind, aus gleicher Quelle stammen 
> (sprich: selbes Erzeugerprogramm und selbe PDF-Engine), dann _könnte_ es 
ja, es ist immer die gleiche Quelle (Datenbank und Erstell-SW)

> funktionieren, den Text aus dem PDF zu extrahieren [1] und die so 
> entstandenen Texte bzw. Textdateien per Hash zu vergleichen.

Die Frage ist nunmehr, wie mache ich es am einfachsten?

Die PDF's liegen zunaechst im Speicher als Datenstream (a) und werden
dann in das Filesystem (b) gespeichert.
Gelingt es mir die Textdaten noch aus (a) zu extrahieren, waere es 
sicher ein Geschwindigkeitsvorteil zu (b), da File open und lesen entfallen.

Ich werde mal unseren PDF-Engine (PDFlib) befragen, welche 
Moeglichkeiten es fuer eine Textextrahierung da gibt.

Danke und einen schoenen Tag.

Gruesse
Julius

-- 
(my real mail address ends with a .net tld)

Re: PDF-Vergleich

Julius Kavay schrieb in <news:757uvqF16okn8U1@mid.individual.net>
> Thomas Kaiser wrote:
>
>> Vergiß den Ansatz bzw. guck Dir an, wie PDF intern aufgebaut ist. Wenn's
> PDF-Aufbau ist gut, die Spezifikation hat ueber 1200 Seiten!

Kapitel 12.2 in der Bibel [1] reicht -- Stichwort "xref".

> Ich werde mal unseren PDF-Engine (PDFlib) befragen, welche 
> Moeglichkeiten es fuer eine Textextrahierung da gibt.

Also wenn schon der komplette Erstellungsprozeß unter Kontrolle ist, 
würde ich mir den Schmarrn mit nachträglichem Abgleich der Inhalte 
komplett sparen und aus der Datenbank ein Flag mit rausschubsen, ob sich 
was geändert hat oder nicht. Aber oft sind die Wege ja verschlungener 
als einem lieb ist.

Gruss,

Thomas

[1] Aus der Feder des "Vaters" der PDFLib:
    <http://www.pdflib.com/developer/technical-documentation/books/postscript-pdf-bibel/>

Re: PDF-Vergleich

Thomas Kaiser wrote:

> Kapitel 12.2 in der Bibel [1] reicht -- Stichwort "xref".

Jetzt ist es mir klar, warum ein Direktvergleich nie und niemals 
funktionieren kann.

Aber die Bibel ist gut - da wird in wenigen Saetzen ein solider 
Ueberblick geliefert, die Details kann ich mir dann aus der 
Spezifikationen holen. Danke fuer den Link.

> Also wenn schon der komplette Erstellungsprozeß unter Kontrolle ist, 
> würde ich mir den Schmarrn mit nachträglichem Abgleich der Inhalte 
> komplett sparen und aus der Datenbank ein Flag mit rausschubsen, ob sich 
> was geändert hat oder nicht. Aber oft sind die Wege ja verschlungener 
> als einem lieb ist.
Das mit rausschubsen von Aenderungsflags wird nicht gehen, da es
stellenweise durchaus gewollt bzw. erforderlich ist, dass ohne 
(sichtbare) Aenderung trotzdem ein Dokument herauskommt.
Mal abgesehen davon, dass es oft gar nicht so einfach festzustellen ist, 
ob eine Aenderung auch auf eine Ausgabe Auswirkung hat oder nicht.

Danke fuer die Infos und einen schoenen Abend.

Gruesse
Julius

-- 
(my real mail address ends with a .net tld)

Re: PDF-Vergleich

Julius Kavay schrieb in <news:759edkF176chvU1@mid.individual.net>
> die Bibel ist gut - da wird in wenigen Saetzen ein solider Ueberblick 
> geliefert, die Details kann ich mir dann aus der Spezifikationen 
> holen. Danke fuer den Link.

Gerne. Das Ding ist IMO Pflichtlektüre bzw. gehört in jedem Fall in 
(digitale) Bibliothek, wenn man bisserl tiefer bzgl. PDF einsteigen will 
(obwohl natürlich einiges veraltet ist)


> Das mit rausschubsen von Aenderungsflags wird nicht gehen, da es
> stellenweise durchaus gewollt bzw. erforderlich ist, dass ohne 
> (sichtbare) Aenderung trotzdem ein Dokument herauskommt.

Da könnte man einfach das PDF durch Setzen von entsprechenden Metadaten 
(in XMP [1] verpackt) markieren. Mittels bspw. "pdfinfo -meta" (auch aus 
dem XPDF-Paket) könntest Du blitzschnell das entsprechende Flag aus dem 
PDF auslesen und dann entscheiden, ob erneute Archivierung nötig ist 
oder nicht.

> Mal abgesehen davon, dass es oft gar nicht so einfach festzustellen 
> ist, ob eine Aenderung auch auf eine Ausgabe Auswirkung hat oder 
> nicht.

Hmm... in der Situation (wenn eben PDF immer mit gleicher Engine erzeugt 
wird), dann sollte ein Hash über den extrahierten Text helfen. Rendern 
und Vergleich von Byte- bzw Bitmaps (in Deiner Situation zwar eher 
supersimpel) dürfte IMO nicht nötig sein.

Gruss,

Thomas

[1] <http://www.pdflib.com/developer/xmp-metadata/>

Re: PDF-Vergleich

Julius Kavay schrieb:
> Liebe (Fach)Kundige,
> 
> habe ein Problem mit dem Vergleich von zwei PDF-Files.
> 
> Konkret:
> Es werden aus einer (umfangreichen) Applikation bestimmte
> Daten als PDF ausgegeben (ueber einen kommerziellen PDF-Creator).
> 
> Die so erstellten PDF-Files werden dann entweder ausgedruckt oder
> als E-Mailanhang versendet UND auf jeden Fall in ein externes
> Archivsystem abgelegt.
> 
> Das Problem ist nun, dass bestimmte Sachen mehr als einmal ausgegeben
> werden, da an den Basisdaten etwas geaendert wurde. Manche der
> Aenderungen wirken sich auf den Inhalt der erstellten PDF ueberhaupt
> nicht aus aber loesen die Erstellung eines Files aus.

Du könntest die beiden zu vergleichenden pdf-Dateien in bibmap-Grafiken
(z.B. .png) wandeln und diese geeignet vergleichen. Probier, ob da MD5
funktioniert. Wenn nicht kann man auch per ImageMagick sowas wie eine
Differenz aus den Inhalten bilden und das Ergebnis auswerten. Nur so als
Denkansatz.

...Rolf

Re: PDF-Vergleich

On 21 Apr., 22:34, Julius Kavay
<ka...@gmx.net.valid.address.changed.to.invalid> wrote:
> Liebe (Fach)Kundige,
>
> habe ein Problem mit dem Vergleich von zwei PDF-Files.
>
> Konkret:
> Es werden aus einer (umfangreichen) Applikation bestimmte
> Daten als PDF ausgegeben (ueber einen kommerziellen PDF-Creator).
>
> Die so erstellten PDF-Files werden dann entweder ausgedruckt oder
> als E-Mailanhang versendet UND auf jeden Fall in ein externes
> Archivsystem abgelegt.
>
> Das Problem ist nun, dass bestimmte Sachen mehr als einmal ausgegeben
> werden, da an den Basisdaten etwas geaendert wurde. Manche der
> Aenderungen wirken sich auf den Inhalt der erstellten PDF ueberhaupt
> nicht aus aber loesen die Erstellung eines Files aus.
>
> Zum Teil ist so eine Zweit-, Dritt- usw. Erstellung auch gewollt und
> muss so bleiben, aber die dadurch entstandene Zweit-, Dritt- usw.
> Abspeicherung des Dokuments in dem externen Archivsystem (da es
> inhaltlich 100% das gleiche wie die Erstausgabe) unnoetig.
>
> Wir wollten es dadurch umgehen, das man von jedem PDF ein MD5 (oder eine
> andere Hash) erstellt und die Dokumente mit gleichem Namen und Hashwert
> nicht ein zweites Mal archiviert.
>
> Leider funktioniert dies nicht, da alle PDF's eine Art TimeStamp oder
> GUID haben, so dass auch inhaltlich gleiche PDF's verschiedene Hashwerte
> liefern.
>
> Frage, kennt jemand die Stelle im PDF-File, so dass man diesen Bereich
> in der Hashwertberechnung nicht beruecksichtigt?
>
> Danke.
>
> Gruesse
> Julius
>
> --
> (my real mail address ends with a .net tld)

Hallo!

Nach unserem heutigen Telefonat habe ich doch mal eben hier
reingeschaut ... ;-)
Vieles wurde hier jetzt schon gesagt...
Auch f=FCr mich gibt es zwei Vergleichsm=F6glichkeiten:
1. Textextraktion mit zus=E4tzlichen Layoutinformationen und daraus
einen u.U. auch mit einem individuellen Algorithmus einen guid-
vergleichbaren Wert ermitteln.
2. Die PDF-Ausgabe in eine Image-Datei (z.B. jpeg) rendern und dessen
Wert ermitteln.
Was in jedem Fall ausscheidet, ist der komplette PDF-Vergleich, da
z.B. in jedem PDF ein Erstellungs- und ein Modifikationsdatum erzeugt
werden. Diese sind nat=FCrlich (auch wenn der Text identisch ist) immer
wieder anders und somit w=E4ren auch ermittelte Hash-Werte immer wieder
anders.
Um sicher zu gehen k=F6nnte man auch M=F6glichkeit 1 und 2 verbinden (ist
nat=FCrlich auch eine Performancefrage).

Viele Gr=FC=DFe,
Ingo Schm=F6kel

www.PDF-Analyzer.com

Re: PDF-Vergleich

On 23 Apr., 22:58, ingo.schmoe...@gmx.de wrote:
> On 21 Apr., 22:34, Julius Kavay
> <ka...@gmx.net.valid.address.changed.to.invalid> wrote:
>
> > Das Problem ist nun, dass bestimmte Sachen mehr als einmal ausgegeben
> > werden, da an den Basisdaten etwas geaendert wurde. Manche der
> > Aenderungen wirken sich auf den Inhalt der erstellten PDF ueberhaupt
> > nicht aus aber loesen die Erstellung eines Files aus.
>
> > Frage, kennt jemand die Stelle im PDF-File, so dass man diesen Bereich
> > in der Hashwertberechnung nicht beruecksichtigt?
>
> Nach unserem heutigen Telefonat habe ich doch mal eben hier
> reingeschaut ... ;-)
> Vieles wurde hier jetzt schon gesagt...
> Auch f=FCr mich gibt es zwei Vergleichsm=F6glichkeiten:
> 1. Textextraktion mit zus=E4tzlichen Layoutinformationen und daraus
> einen u.U. auch mit einem individuellen Algorithmus einen guid-
> vergleichbaren Wert ermitteln.
> 2. Die PDF-Ausgabe in eine Image-Datei (z.B. jpeg) rendern und dessen
> Wert ermitteln.
> Was in jedem Fall ausscheidet, ist der komplette PDF-Vergleich, da
> z.B. in jedem PDF ein Erstellungs- und ein Modifikationsdatum erzeugt
> werden. Diese sind nat=FCrlich (auch wenn der Text identisch ist) immer
> wieder anders und somit w=E4ren auch ermittelte Hash-Werte immer wieder
> anders.
> Um sicher zu gehen k=F6nnte man auch M=F6glichkeit 1 und 2 verbinden (ist
> nat=FCrlich auch eine Performancefrage).

Warum nicht die dritte Methode:
- pdf(s) einlesen (read, parse to data structure)
- alles wegwerfen, was nicht zur Darstellung geh=F6rt
- rest vergleichen
Ich habe dereinst mal an einem pdf-to-svg-undandersrum converter
gebastelt und der Vergleich .xml (.svg) zuneinander war harmlos. Mann
konnte sogar so Dinge wie -hier zus=E4tzliche Linie- erkennen.
Vielleicht heutzutage mit Inkscape?

Bis bald,
    Guenther

Re: PDF-Vergleich

gkayzar@gmail.com schrieb in <news:b1b74330-4616-4035-b435-02b599730917@r36g2000vbr.googlegroups.com>
> Ich habe dereinst mal an einem pdf-to-svg-undandersrum converter
> gebastelt und der Vergleich .xml (.svg) zuneinander war harmlos.

Wenn das PDF ausreichend primitiv ist (also nur einen Bruchteil der 
Möglichkeiten des graphischen Modells von PDF nutzt), dann mag so eine 
Konvertierung von PDF nach SVG verlustfrei möglich sein (die andere 
Richtung ist natürlich kein Problem, da das graphische Modell von SVG 
ultraprimitiv ist und demnach problemlos 1:1 in PDF abgebildet werden 
kann).

Wohlgemerkt spreche ich vom graphischen Modell und nicht den Daten- 
strukturen. Bei Letzteren bildet SVG wohl höchstens ein Promillchen des 
mit PDF bzw. ISO 32000 Möglichen ab.

Gruss,

Thomas

Re: PDF-Vergleich

On 13 Mai, 11:30, Thomas Kaiser <Thomas.Kai...@phg-online.de> wrote:
> gkay...@gmail.com schrieb in <news:b1b74330-4616-4035-b435-02b599730917@r=
36g2000vbr.googlegroups.com>
>
> > Ich habe dereinst mal an einem pdf-to-svg-undandersrum converter
> > gebastelt und der Vergleich .xml (.svg) zuneinander war harmlos.
>
> Wenn das PDF ausreichend primitiv ist (also nur einen Bruchteil der
> M=F6glichkeiten des graphischen Modells von PDF nutzt), dann mag so eine
> Konvertierung von PDF nach SVG verlustfrei m=F6glich sein (die andere
> Richtung ist nat=FCrlich kein Problem, da das graphische Modell von SVG
> ultraprimitiv ist und demnach problemlos 1:1 in PDF abgebildet werden
> kann).

Kurzum stimme ich zu, das das grafische Model von PDF vollkommen
ueberfrachtet ist, und mann nur ein paar Elemente zum Setzen von
Text,
Vektorgrafik und Images wirklich br=E4uchte. Ich moechte dann aber auch
die entsprechenden Elemente in PDF sehen : animate + filter...

> Wohlgemerkt spreche ich vom graphischen Modell und nicht den Daten-
> strukturen. Bei Letzteren bildet SVG wohl h=F6chstens ein Promillchen des
> mit PDF bzw. ISO 32000 M=F6glichen ab.

Ich kann bei SVG in die metadata f=FCr JEDES grafische Element
leztendlich
komplette .xml packen. Wie man mit soeinem maechtigem Werkzeug
nur einen kleinen Teil von PDF erzielt, w=E4re mir ein R=E4tsel.

Bis bald, Guenther.

Re: PDF-Vergleich

gkayzar@gmail.com schrieb am 13.05.2009 in <news:21e9dbc4-3fb4-4554-91bf-84a5d1199560@h23g2000vbc.googlegroups.com>
> Kurzum stimme ich zu, das das grafische Model von PDF vollkommen 
> ueberfrachtet ist

Hmm... ich hab mich zwischendurch mal mit dem aktuellen (bzw. schon 
länger gültigen) Status von SVG befaßt und musste feststellen, daß ich 
extrem un- bzw. falschinformiert war. Danke also fürs Zurückbiegen 
meiner Scheuklappen hinsichtlich SVG :-)

So unterschiedlich sind die grafischen Modelle von SVG und PDF ja gar 
nicht. Wenn man die jeweilige Ausrichtung -- hier Web, dort Print bzw. 
"alles Mögliche" -- im Hinterkopf behält, sogar ziemlich identisch.

>> Wohlgemerkt spreche ich vom graphischen Modell und nicht den Daten- 
>> strukturen. Bei Letzteren bildet SVG wohl höchstens ein Promillchen 
>> des mit PDF bzw. ISO 32000 Möglichen ab.
>
> Ich kann bei SVG in die metadata für JEDES grafische Element 
> leztendlich komplette .xml packen.

Was nix dran ändert, daß am Ende ein SVG-Renderer damit umgehen können 
muß?

> Wie man mit soeinem maechtigem Werkzeug nur einen kleinen Teil von PDF 
> erzielt, wäre mir ein Rätsel.

"Datenstrukturen". PDF hat halt schon mal quasi alles von PostScript 
geerbt. Man kann im Prinzip schon allein aus historischen Gründen ein 
Bildobjekt in 'zig verschiedenen Farbräumen, Formaten, Kodierungen 
(Kompression), etc. in ein PDF stopfen, auch wenn's inzwischen wenig 
sinnvoll ist, nur ein kleines Subset davon zu verwenden.

Aber das hat ja nix mit dem grafischen Modell zu tun (Bild bleibt Bild, 
egal wie kodiert/komprimiert). Und da ähneln sich SVG und PDF dann doch 
wiederum sehr stark. Hab mich jetzt mal bisserl mit dem Fokus auf 
dynamische Seitengenerierung eingelesen und werf' hier IMO taugliche 
Startpunkte mal ab, falls es noch wen interessieren sollte:

* http://www.svgopen.org/2002/papers/danilo_fujisawa__svg_as_page_description_language/
* http://www.alexmac.cc/publications.html

Gruss,

Thomas

Re: PDF-Vergleich

On 20 Mai, 09:46, Thomas Kaiser <Thomas.Kai...@phg-online.de> wrote:
> gkay...@gmail.com schrieb am 13.05.2009 in <news:21e9dbc4-3fb4-4554-91bf-=
84a5d1199560@h23g2000vbc.googlegroups.com>
>
> > Kurzum stimme ich zu, das das grafische Model von PDF vollkommen
> > ueberfrachtet ist

[....]
>  Hab mich jetzt mal bisserl mit dem Fokus auf
> dynamische Seitengenerierung eingelesen und werf' hier IMO taugliche
> Startpunkte mal ab, falls es noch wen interessieren sollte:
>
> *http://www.svgopen.org/2002/papers/danilo_fujisawa__svg_as_page_descr...
> *http://www.alexmac.cc/publications.html
>
> Gruss,
>
> Thomas


Danke f=FCr die Links.

K=F6nnte jemand in 3, 4 S=E4tzen auch das Verh=E4ltnis von SVG zu XPS (dem
von Microsoft gepuschten PDF-"Konkurrenz"format) zusammenfassen, rein
auf deren technische Meriten reduziert (d.h. ohne "Politik", wenn's
geht)?

Ciao,
pipitas

Re: PDF-Vergleich

On 21 Apr., 22:34, Julius Kavay
<ka...@gmx.net.valid.address.changed.to.invalid> wrote:

> Das Problem ist nun, dass bestimmte Sachen mehr als einmal ausgegeben
> werden, da an den Basisdaten etwas geaendert wurde. Manche der
> Aenderungen wirken sich auf den Inhalt der erstellten PDF ueberhaupt
> nicht aus aber loesen die Erstellung eines Files aus.
>
> Zum Teil ist so eine Zweit-, Dritt- usw. Erstellung auch gewollt und
> muss so bleiben, aber die dadurch entstandene Zweit-, Dritt- usw.
> Abspeicherung des Dokuments in dem externen Archivsystem (da es
> inhaltlich 100% das gleiche wie die Erstausgabe) unnoetig.
>
> Wir wollten es dadurch umgehen, das man von jedem PDF ein MD5 (oder eine
> andere Hash) erstellt und die Dokumente mit gleichem Namen und Hashwert
> nicht ein zweites Mal archiviert.
>
> Leider funktioniert dies nicht, da alle PDF's eine Art TimeStamp oder
> GUID haben, so dass auch inhaltlich gleiche PDF's verschiedene Hashwerte
> liefern.

Ich hatte heute ein =E4hnliches Problem. Und zwar m=F6chte ich
verschiedene PDF-Seiten miteinander vergleichen, die u.U. subtile
Abweichungen voneinander aufweisen, sichtbar im Ausdruck auf Papier
oder auch bei Betrachtung auf dem Bildschirm, jedoch ohne dass es dem
menschlichen Auge auf Anhieb auff=E4llt.

Was ich zuerst versuchte:

  1. Mit Hilfe von Ghostscript die PDF-Seiten
     rendern, und zwar zu TIFF G4.
  2. Die MD5-Summe f=FCr die TIFF-Seiten bilden
     und vergleichen.

Hier hat mich allerdings dasselbe Feature in den A.... gebissen: die
TIFF-Dateien tragen intern einige Meta-Daten, u.a. einen Zeitstempel.
Sichtbar zu machen ist dies mit dem "tiffinfo" Kommandozeilen-
Hilfsprogramm, das als Teil der libtiff verf=FCgbar ist.

Und dieses Faktum bewirkt nat=FCrlich eine andere MD5-Summe, selbst wenn
die TIFFs auf Papier oder Bildschirm deckungs- und pixelgleich
rendern.

Etwas weitere Recherche bez=FCglich der libtiff-Hilfsprogramme brachten
mich dann auf die weiteren Utilities "tiffdump" und "tiffset".

Mit tiffdump kann man die Metadaten-Felder samt ihrer Nummerierung
auslesen, tiffset kann (beliebige?) Metadaten-Felder in einer TIFF
umschreiben.

Ich habe festgestellt, dass ich lediglich das "DateTime"-Feld
normalisieren muss, und dann sind in meinem Fall die TIFFs per md5sum
vergleichbar. (Falls die TIFFs z.B. von verschiedenen Applikationen
oder Software-Versionen, z.B. Ghostscript v. 8.54 und Ghostscript 8.64
erstellt wurden, m=FCsste man noch weitere Felder normalisieren.)

Was ich jetzt mache:

  1. Mit Hilfe von Ghostscript die PDF-Seiten
     rendern, und zwar zu TIFF G4.
  2. Mit Hilfe von "tiffset" das DateTime-Tag
     der TIFF-Seiten auf "2000:00:00 00:00:00" setzen.
  3. Die MD5-Summe f=FCr die TIFF-Seiten bilden
     und vergleichen.

Konkret siehen die zugeh=F6rigen Kommandos so aus (Beispiel auf Linux):

   for i in 1 2 3 4; do
       gs \
          -dNOPAUSE \
          -dBATCH \
          -sDEVICE=3Dtiffg4 \
          -dFirstPage=3D13 \
          -dLastPage=3D13 \
          -sOutputFile=3Dpage13_no${i}.tif \
          example.pdf;
        sleep 1;
       done

   tiffinfo page*.tif | grep DateTime
     DateTime: 2009:05:11 19:04:21
     DateTime: 2009:05:11 19:04:22
     DateTime: 2009:05:11 19:04:23
     DateTime: 2009:05:11 19:04:24

   for i in 1 2 3 4; do
       tiffset -s 306 "2000:00:00 00:00:00" page13_no${i}.tif
   done

   tiffinfo page*.tif | grep DateTime
     DateTime: 2000:00:00 00:00:00
     DateTime: 2000:00:00 00:00:00
     DateTime: 2000:00:00 00:00:00
     DateTime: 2000:00:00 00:00:00

   md5sum page*.tif
     5c670543016e529f7cb795d52ef11f40  page13_no1.tif
     5c670543016e529f7cb795d52ef11f40  page13_no2.tif
     5c670543016e529f7cb795d52ef11f40  page13_no3.tif
     5c670543016e529f7cb795d52ef11f40  page13_no4.tif

Ohne das dazwischengeschaltete tiffset-Kommando w=E4ren da 4
verschiedene MD5-Summen.

Um Performanz zu gewinnen, kann man beim Ghostscript-Aufruf noch einen
Parameter hinsichtlich der Aufl=F6sung mitgeben, um kleinere TIFFs zu
erzeugen (standardm=E4ssig kommen 204x196 ppi raus). Das reicht auf
jeden Fall, um einzelne fehlenden oder ausgetauschte Buchstaben
aufzusp=FCren mit einer Wahrscheinlichkeit von 99,999% (die
letztendliche Genauigkeit liegt an der "G=FCte" des MD5-Hashing-
Algorithmus).

Da noch nicht ganz klar ist, wie genau der Vergleich sein muss, um
unerw=FCnschte Abweichungen auch bei Grafik-Darstellungen 100%-ig
aufzusp=FCren, k=F6nnte man am selben Parameter die Aufl=F6sung auch auf 60=
0
oder 1200 dpi raufsetzen... Das weitere m=FCssen jetzt die Praxistests
ergeben.

Die libtiff-Tools sind auch f=FCr Windows verf=FCgbar, z.B. hier:

   http://gnuwin32.sourceforge.net/downlinks/tiff.php

Gruss, pipitas

Re: PDF-Vergleich

pipitas schrieb in <news:93e05e41-edd5-403b-b644-601a918e8a63@t11g2000vbc.googlegroups.com>
>   2. Die MD5-Summe für die TIFF-Seiten bilden
>      und vergleichen.
>
> Hier hat mich allerdings dasselbe Feature in den A.... gebissen: die
> TIFF-Dateien tragen intern einige Meta-Daten, u.a. einen Zeitstempel.

Hint: Es gibt Grafikdateiformate, die ohne dateiinterne Metadaten 
auskommen, bspw. "PNM": 

    <http://netpbm.sourceforge.net/doc/index.html#formats>

Damit kann man sich die ganzen Metadaten-Kaspereien per se sparen.

> Sichtbar zu machen ist dies mit dem "tiffinfo" Kommandozeilen-
> Hilfsprogramm, das als Teil der libtiff verfügbar ist.

Nur am Rande (bzw. abseits TIFF). Wenn's um Metadaten in Bildformaten 
_und auch in PDF_ geht, kommt man schon seit Jahren um exiftool kaum 
herum:

    <http://www.sno.phy.queensu.ca/~phil/exiftool/>

> Ich habe festgestellt, dass ich lediglich das "DateTime"-Feld 
> normalisieren muss, und dann sind in meinem Fall die TIFFs per md5sum 
> vergleichbar. (Falls die TIFFs z.B. von verschiedenen Applikationen 
> oder Software-Versionen, z.B. Ghostscript v. 8.54 und Ghostscript 8.64 
> erstellt wurden, müsste man noch weitere Felder normalisieren.)

Evtl. kippt Dir die ganze md5-Idee dann aus den Latschen, denn auch 
verlustfreie Kompressionsalgorithmen (also solche, die 100% identische 
Pixel nach Kodierung/Dekodierung hervorbringen) können zu völlig 
unterschiedlichen Datenströmen führen, je nachdem welche Optimierungs- 
parameter eingeschaltet werden. Aber keine Ahnung, ob das auf CCITT 
Group 4 auch zutrifft :-)

> Was ich jetzt mache:
> [...]
> Das reicht auf jeden Fall, um einzelne fehlenden oder ausgetauschte 
> Buchstaben aufzuspüren mit einer Wahrscheinlichkeit von 99,999%

Bin gespannt, wie hoch die Wahrscheinlichkeit für "False Positives" beim 
MD5-Ansatz ausfallen wird *g*

> Da noch nicht ganz klar ist, wie genau der Vergleich sein muss, um 
> unerwünschte Abweichungen auch bei Grafik-Darstellungen 100%-ig 
> aufzuspüren, könnte man am selben Parameter die Auflösung auch auf 600 
> oder 1200 dpi raufsetzen... Das weitere müssen jetzt die Praxistests 
> ergeben.

Da wünsche ich jetzt schon viel Spaß. Du machst aktuell noch nichts 
weiter, als Bytestreams (inkl. gefakter Metadaten) hinsichtlich 
"komplett identisch?" zu vergleichen. Die Annahme dahinter, daß damit 
auch eine visuelle bzw. inhaltliche Übereinstimmung im selben Maß 
einhergeht, könnte evtl. falsch sein (alleine schon wegen Rendering- 
Ungenauigkeiten).

Da Du TIFF G4 nutzen willst, scheint es sich um reine Text-PDF ohne 
Abbildungen und Farbe zu handeln (was die Sache "eigentlich" deutlich 
erleichtert). Wir hier (sind seit einem halben Jahr in ein Projekt 
verwickelt, bei dem es darum geht, quasi virtuelle Screenshots von 
Quark- und InDesign-Seiten mit einem gerenderten PDF zu vergleichen auf 
_inhaltliche_ Abweichungen) haben nicht das Glück. Wir mussten uns vom 
Anfang an mit Bilder, Texten und vektorisierten Elementen herumschlagen, 
dito verschiedenen Farbräumen, Rendering-Anomalien, "seltsamem" 
Verhalten seitens der Programme, wenn sie mal Seitenelemente nicht um 
Zugriff haben, etc.

Jedenfalls ist _unser_ Vorhaben keins, bei dem es nur um 100% 
Übereinstimmung eines Byte-Streams geht, sondern Farbräume ineinander 
konvertiert werden, Farbabstände _sinnvoll_ gewichtet werden müssen, 
Pixel hinsichtlich Clusterbildung untersucht und gewichtet werden, mit 
unterschiedlichen Bildauflösungen umgegangen werden können muß... und 
schlußendlich die visuellen Differenzen deutlich hervorgehoben gehören. 

Letzten Endes sind wir dabei gelandet, ein eigenes CLI-Tool dafür zu 
programmieren [1].

Hab mal ein kleines Beispiel online gewuppt:

    <http://kaiser-edv.de/tmp/xykG2h/>

In <http://kaiser-edv.de/tmp/xykG2h/visueller_vergleich/Differenz.pdf> 
sieht man die gewichtete Darstellung der Differenzen, in rohdiff.tif nur 
die reinen Farbabstände je Pixel, mit zusätzlicher Bereinigung/Wertung 
auch cleaned.tif und counted.tif. Ausgangsmaterial ist "Rezept.pdf" vs. 
"Rezept.png", der Rest temporärer Kram.

Gruss,

Thomas

[1] Aktueller Hilfetext unseres Tools:

Usage: cmpPNGtoPDF [options] png-preview print-pdf path-prefix

    cmpPNGtoPDF compares a PNG image file with a rendered PDF file 
    (cropped to the dimensions of the media box or the trim box if 
    available) using Mac OS X' CoreGraphics engine. A couple of 
    temporary files are created at a customizable location using 
    $path-prefix -- see 'Examples' below. You have to ensure that the 
    directory $path-prefix points to exists and cmpPNGtoPDF has write 
    access to its contents. Otherwise execution will fail.

    - An exit code of 0 means the files are visually identical
    - An exit code of 1 signals an unknown error
    - An exit code of 2 indicates visual differences

    cmpPNGtoPDF prints its settings on stdout and probably followed by 
    some statistics regarding the image matching and quantification 
    process. This output should be silently ignored since it is intented 
    solely for debugging/optimization purposes.
    
Options:

    --pngProfile=path
      Path to the icc-profile with which the PNG was generated.

    --cmykProfile=path
      Path to a CMYK icc-profile which should be used to convert the 
      PDFs CMYK colors to RGB.

    --scaleTo=(scaleToDPI | miniumDPI,scaleFactor)
      If one number is given, this is the dpi value into which the PNG 
      and PDF will be scaled down to.
      If two numbers separated by a comma are given, the PNG will be 
      scaled down by the scaleFactor if the resulting resolution is not 
      lower than minimumDPI.
      (All numbers are given as float values with a decimal point, e.g. 
      "1.2")

    --scalePDFAfterRendering[=[0 | 1 | true | false]]
      The PDF will be rendered at the PNG's resolution first, then 
      scaled to the resolution given by scaleTo.

    --scalePNGAfterRendering[=[0 | 1 | true | false]]
      The PNG will be read in its native resoltion, then scaled to the 
      resolution given by scaleTo.

    --intermediateCMYKforPNG[=[0 | 1 | true | false]]
      The PNG will first be rendered into a DeviceCMYK color space and 
      then processed like the PDF.

    --clusterRadiusMM=radius
      The biggest distance in mm between two pixel groups that makes 
      them part of the same cluster.
      (All numbers are given as float values with a decimal point, e.g. 
      "1.2")

    --antiAntiAlias[=[0 | 1 | true | false]]
      When the difference between PNG and PDF is calculated this switch 
      allows for "smearing" color values around the pixel currently 
      examined. If this is set, false alarms caused by antialiasing get 
      less, the thresholds can be tightend, but processing becomes 
      slower.

    --thresholds=lowThreshold,highThreshold
      This sets the thresholds that are used to find candidate pixels 
      for visible differences. The lower the thresholds are, the more 
      candidate pixels are found. Differences in .._rohdiff.tif that are 
      below the lowThreshold are ignored. A pixel for which the 
      difference is above or equal highThreshold become candidates when 
      at least two consecutive neighbouring pixels have differences 
      above lowThreshold.

      A pixel whose difference is above or equal lowThreshold is picked 
      as a candidate if at least five consecutive neighbouring pixels 
      have differences above lowThreshold, or at least two consecutive 
      neighbouring pixels have differences above highThreshold.

Examples: 

  * cmpPNGtoPDF preview.png printjob.pdf result_

    Compares preview.png with printjob.pdf in the current working 
    directory and creates the following temporary files in the same 
    directory:

    result_cleaned.tif
    result_counted.tif
    result_pdfAsYCbCr.tif
    result_pngAsYCbCr.tif
    result_renderedPDF.tif
    result_rohdiff.tif

  * cmpPNGtoPDF in/test.png in/test.pdf out/

    Compares test.png with test.pdf in the "in" subdirectory (relative 
    to cwd) and produces the following temporary files in the "out" 
    subdir:

    out/cleaned.tif
    out/counted.tif
    out/pdfAsYCbCr.tif
    out/pngAsYCbCr.tif
    out/renderedPDF.tif
    out/rohdiff.tif

  * cmpPNGtoPDF /tmp/test.png /foo/bar/test.pdf /foo/result123-

    Compares /tmp/test.png with /foo/bar/test.pdf and produces the 
    following temporary files:

    /foo/result123-cleaned.tif
    /foo/result123-counted.tif
    /foo/result123-pdfAsYCbCr.tif
    /foo/result123-pngAsYCbCr.tif
    /foo/result123-renderedPDF.tif
    /foo/result123-rohdiff.tif