vielleicht könnte man die Vorschau für PDF-Dokumente dahingehend
erweitern, dass sie im Falle von mehrseitigen PDFs am unteren Rand auf
die Mehrseitigkeit hingewiesen wird. zB mit einer Seitenanzeige 1/x

Ich bin schon ein paar mal darauf hereingefallen, dass ich nicht auf dem
ersten Blick gesehen habe, dass es ein PDF ist und mich gewundert habe,
dass die Informationen unvollständig sind.

Entweder interessiert der Inhalt oder nicht.

Es ist ein saumäßiger Aufwand, PDFs zu analysieren und zB die
Anzahl der Seiten und eine Art Vorschauu zu generieren. Jede
Software die PDFs erzeugen kann, tut das auf seine Weise.
Die Laufzeit wäre entsprechend. Keine Ahnung, in was die
Forensoftware geschrieben ist - aber PHP käme da an seine Grunzen.

Dazu kommt noch eine Unmenge an Grafikformaten die PDF dartellen
kann. Das grenzt an Strafarbeit nur um Dir ein Paar Sekunden der
kostebaren Zeit zu sparen.

Ich glaube nicht, daß sich der Aufwand lohnt.

PS: PDF ist ein sehr gutes Format, nur halt auch mal zickig bis
bockig. Es gibt weder vernünftige Fehlermeldungen noch Prüfprogramme.
Ich vermute, alle Datenblätter online sind PDFs.

Solltest Du Dir mal die Mühe machen, das PDF-Format zu lesen und zu
verstehen ...

Ruby sollte das können (= keine Erfahrung damit).

Joachim Drechsel schrieb:
> Es ist ein saumäßiger Aufwand, PDFs zu analysieren und zB die
> Anzahl der Seiten und eine Art Vorschauu zu generieren

Also bisher konnte jede Bibliothek wenigstens die Anzahl der Seiten
bestimmen soooo wild ist das nun auch nicht, nur wird Andreas seine Zeit
vermutlich erst mal anderweitig verwenden da es noch viele andere
Baustellen gibt.

z.B. das Tool "pdfinfo" gibt kompfortabel noch sher viel mehr als die
Seitenzahl aus...

pdfinfo test.pdf 
Producer:       iText 2.0.7 (by lowagie.com)
CreationDate:   Thu Dec 22 14:11:34 2011
ModDate:        Thu Dec 22 14:11:34 2011
Tagged:         no
Pages:          1
Encrypted:      no
Page size:      595 x 842 pts (A4)
File size:      3798 bytes
Optimized:      no
PDF version:    1.4

Es bringt aber nichts.

Das PDF muss komplett gelesen werden (obj-Liste zumindest), dann
die rootpage finden und auseinandernehmen. Mit einem Interpreter
dürfte das dauern.

Joachim Drechsel schrieb:
> Entweder interessiert der Inhalt oder nicht.
>
> Es ist ein saumäßiger Aufwand, PDFs zu analysieren und zB die
> Anzahl der Seiten und eine Art Vorschauu zu generieren. Jede
> Software die PDFs erzeugen kann, tut das auf seine Weise.

Wie ein Dokument erzeugt wird ist doch völlig egal, da die Ausgabe
standardisiert ist. Oder was willst du damit sagen?

> Die Laufzeit wäre entsprechend.

Ich glaube du sollst mal ein Blick werfen in die PDF Dokumentation...

Seitenzahl einlesen ist nicht so ein Problem, Es Reicht den Index am
Schluss des Dokuments zu parsen ("xref"). Ganz am ende des PDFs steht
der Start des xrefs.

Das lässt sich mit 50 Zeilen Code bewerkstelligen, sofern nur die
Seitenzahl gewünscht ist.

> Keine Ahnung, in was die
> Forensoftware geschrieben ist - aber PHP käme da an seine Grunzen.

FPDF kann PDFs erzeugen, und FPDI ist das überhaupt kein Problem mit
PHP!

http://www.setasign.de/products/pdf-php-solutions/fpdi/

Kommt aber nicht so auf die Programmiersprache an, nur ein Beispiel
gegen deine Argumentation.

> Dazu kommt noch eine Unmenge an Grafikformaten die PDF dartellen
> kann. Das grenzt an Strafarbeit nur um Dir ein Paar Sekunden der
> kostebaren Zeit zu sparen.

Naja, hat das irgendwas mit der Seitenzahl zu tun!?

Zudem lässt sich eine PDF Vorschau einfach mit "convert" aus imagemagic
erzeugen.

> Ich glaube nicht, daß sich der Aufwand lohnt.
>
> PS: PDF ist ein sehr gutes Format, nur halt auch mal zickig bis
> bockig. Es gibt weder vernünftige Fehlermeldungen noch Prüfprogramme.
> Ich vermute, alle Datenblätter online sind PDFs.

z.B. Poppler gibt durchaus Fehlermeldungen aus beim Parsen...

>
> Solltest Du Dir mal die Mühe machen, das PDF-Format zu lesen und zu
> verstehen ...

Hast du denn die Spezifikation durchgelesen? Alle 1500 Seiten?

Ich gebe zu ich habe nie die komplette Spezifikation gelesen, aber
vielleicht 10% und ich habe selbst Code geschrieben der PDFs mergen
kann.



Ich finde die Idee, anzuzeigen das noch mehr Seiten da wären garnicht so
schlecht.

Es reicht die erste Seite als Grafik darzustellen, aber die Anzahl
Seiten sagt dann ob sich ein Download lohnt oder ob man mit der Vorschau
schon alles gesehen hat.



mfg Andreas

Ich sehe nur, daß Du Dich mit PDF noch nicht so richtig befasst hast ...

Joachim Drechsel schrieb:
> Es bringt aber nichts.
>
> Das PDF muss komplett gelesen werden (obj-Liste zumindest), dann
> die rootpage finden und auseinandernehmen. Mit einem Interpreter
> dürfte das dauern.

Auszug aus einem PDF (gekürzt):

Parsen... Naja, einfaches lesen reicht, nichts kompliziertes... Muss ich
jetzt einfach noch zeigen...

Alles markiert mit "HIER" und in Klammern die Lesereihenfolge, es wird
zuerst am Ende der Datei gelesen.

endobj
3 0 obj <--- HIER (4) Index
<< /Type /Pages /Kids [
4 0 R
22 0 R

...

119 0 R
125 0 R
] /Count 15 <--- HIER (5) Seitenzahl
>>
endobj
1 0 obj
<</Type /Catalog /Pages 3 0 R <--- HIER (3) start des Indexes
>>
endobj

...

2 0 obj

...
xref
0 172
0000000000 65535 f 
0000062574 00000 n 

...

0000172390 00000 n 
0000172804 00000 n 
trailer
<< /Size 172 /Root 1 0 R /Info 2 0 R <--- HIER (2) am ende: Root ist 1 0
>>
startxref <--- HIER (1) startadresse der XREF
177392
%%EOF

Joachim Drechsel schrieb:
> Ich sehe nur, daß Du Dich mit PDF noch nicht so richtig befasst hast ...

Danke. Gleichfalls.

Beweis siehe oben. Falls du nicht meiner Meinung bist: Bitte begründen,
und nicht einfach sagen das meine Aussage falsch ist.

Ich lasse mich gerne belehren, wenn ich falsch liegen sollte, aber dann
mit Beispiel oder Referenz.

Besten Dank!


mfg Andreas

Das /Count kann genausogut indirekt sein.

Auf jeden Fall wird das PDF "von hinten" gelesen (vermutlich haben sie
das mal gemacht damit sichergestellt ist, daß die GANZE Datei auch da
ist). Mit etwas "Glück" gibt es mehrere xref (serialized PDF) damit's
im Web etwas Schmackes gibt.

>Ich lasse mich gerne belehren, wenn ich falsch liegen sollte, aber dann
>mit Beispiel oder Referenz.

Von falsch habe ich nichts geschrieben. Es ist nur nicht ganz so
einfach.

Es gibt genauso viele Arten und Stile, ein PDF zu erzeugen wie es
Programmierer gibt. Versuche mal zum Spaß, ein PDF textmäßig
auseinanderzunehmen (zuverlässig, nicht EINMAL aus Hobby). zB aus
Rechnungen die Positionen herauszuziehen weil es die Firmensoftware
mal wieder nicht kann.

PS: Mach mal ein "Hello World" mit Corel Draw und mit Word. Gib
beides als PDF aus (wenn möglich, unkomprimiert weil einfacher zu
lesen). Dann mal ab in den Editor.

Joachim Drechsel schrieb:
> Es bringt aber nichts.
> Das PDF muss komplett gelesen werden (obj-Liste zumindest), dann
> die rootpage finden und auseinandernehmen.

Also zum generieren der Vorschau wird Andreas wohl auch wenigstens
eine Seite lesen müssen, da das ganze eh zeitverzögert im Hintergrund
läuft ist das ganze auch überhaupt nicht zeitkritisch.

Joachim Drechsel schrieb:
> Das /Count kann genausogut indirekt sein.
>
> Auf jeden Fall wird das PDF "von hinten" gelesen (vermutlich haben sie
> das mal gemacht damit sichergestellt ist, daß die GANZE Datei auch da
> ist). Mit etwas "Glück" gibt es mehrere xref (serialized PDF) damit's
> im Web etwas Schmackes gibt.
>
>>Ich lasse mich gerne belehren, wenn ich falsch liegen sollte, aber dann
>>mit Beispiel oder Referenz.
>
> Von falsch habe ich nichts geschrieben. Es ist nur nicht ganz so
> einfach.

Sorry, meine Fehlinterpretation...


> Es gibt genauso viele Arten und Stile, ein PDF zu erzeugen wie es
> Programmierer gibt. Versuche mal zum Spaß, ein PDF textmäßig
> auseinanderzunehmen (zuverlässig, nicht EINMAL aus Hobby). zB aus
> Rechnungen die Positionen herauszuziehen weil es die Firmensoftware
> mal wieder nicht kann.

Natürlich gibt es die Spezialfälle. Aber wenn die Software 95% aller
PDFs parsen kann und die Seitenzahl anzeigen kann wäre das für diesen
Fall bereits erledigt.

Das Inhaltliche Textparsen, das du hier ansprichst, werde ich gar nicht
versuchen zu implementieren, ich weiss schon was dahinter steckt.

Da kann die Software machen was sie will, also von links nach rechts
oder umgekehrt Felder schreiben etc.

Wenn du das wirklich zuverlässig und generell haben willst hast du
warscheinlich fast eine OCR Software implementiert;-)

So eine Lösung hat natürlich nichts mehr mit meinem Beispiel zu tun,
jedoch bin ich immer noch der Meinung das so ein billiger Parser, der
meisten, aber halt nicht immer funktioniert für die anzeige der PDF
Seitenzahl bereits genügen würde.

Im Gegensatz zu deiner Software, die zuverlässig funktionieren muss.



mfg Andreas

Andreas B. schrieb:
> Wenn du das wirklich zuverlässig und generell haben willst hast du
> warscheinlich fast eine OCR Software implementiert;-)

Für einige PDFs mach ich das:
PDF->TIFF->Tesseract->Text funktioniert so leidlich ... :)

schluchz

Ich habe xpdf probiert und alles mögliche andere. Irgendwann habe
ich gemerkt, mein Mopped braucht nur mehr PS :-)))

PDF kann einen in den Wahnsinn treiben. Die Analyse (also eins
zerpflücken) ist heftig, krass wird es, will man welche erstellen.
Die üblichen Libraries sind für den Einsatz als CGI-Programm viel
zu fett, also selbst bauen (zB Streamdaten aus einem Großrechner
mit hinterlegten Formularen). Die schlappen 1200 oder 1500 Seiten
hat man ja schnell durch wie nix grrr.

Es gibt NICHTS. Kein Programm, das einem Fehler anzeigt. Selbst
von Adobe kommt die Auskunft "Ja, die Fehlernummern. Das weiß hier
auch keiner. Und die wechseln bei jedem Release" aaargggghhhh

Nur PostCsript ist schlimmer. Oder XML ...

Joachim Drechsel schrieb:
> *schluchz*

tröst

> Ich habe xpdf probiert und alles mögliche andere. Irgendwann habe
> ich gemerkt, mein Mopped braucht nur mehr PS :-)))

Sollte heutzutage meist nicht mehr so das Problem sein, also ich
genehmige meiner Applikation nur für den PDF Merge Teil durchaus
100MByte RAM und natürlich auch etwas CPU...

> PDF kann einen in den Wahnsinn treiben. Die Analyse (also eins
> zerpflücken) ist heftig, krass wird es, will man welche erstellen.

Das erstellen sehe ich nicht so als Problem, mit FPDF kommst du das
schon ziemlich weit...

Natürlich, 64MByte RAM sind schnell weg. Ich erstelle PDFs im Bereich
von 300 - 500 Seiten, viele Bilder. Durchaus bis 50MByte gross.

Läuft seit ca. 5 Jahren im 24h Betrieb... (In der Firma, anderes
Projekt;-))

> Die üblichen Libraries sind für den Einsatz als CGI-Programm viel
> zu fett, also selbst bauen (zB Streamdaten aus einem Großrechner
> mit hinterlegten Formularen). Die schlappen 1200 oder 1500 Seiten
> hat man ja schnell durch wie nix grrr.
>
> Es gibt NICHTS. Kein Programm, das einem Fehler anzeigt. Selbst
> von Adobe kommt die Auskunft "Ja, die Fehlernummern. Das weiß hier
> auch keiner. Und die wechseln bei jedem Release" *aaargggghhhh*

Acrobat habe ich auswärts mal getestet, naja, er hat mir gesagt mein PDF
hätte Fehler drin... Soweit war ich aber auch schon vorher=)

Poppler hat mir dann über STDERR ausgegeben das ein Objekt XY nicht
gelesen werden kann.

Dann natürlich so lange auskommentieren bis nichts mehr falsches drin
ist, und dann Fehler suchen;-)


>
> Nur PostCsript ist schlimmer. Oder XML ...

XML!? XML im XML-Editor deiner Wahl öffnen und da den Fehler korrigieren
wo eine Rote Linie ist;-)

Validieren macht sogar der Firefox beim öffnen...


mfg Andreas

Joachim Drechsel schrieb:
> Es ist ein saumäßiger Aufwand, PDFs zu analysieren und zB die
> Anzahl der Seiten und eine Art Vorschauu zu generieren.

Es wird bereits standardmäßig eine Komplettvorschau aller PDFs
generiert, z.B.
http://www.mikrocontroller.net/attachment/preview/....
Was fehlt ist nur das passende UI.

Hai Andreas,

ich bekomme Daten als XML (in CSV wäre das ca 1 % des Volumens),
zu jeder Rechnung/Lieferschein etc ein PDF. Das läßt sich ganz
gut verarbeiten (es geht um Mengen, mehrere 100 MB pro Nacht laufen
da rein, immer das gleiche Format). Kein Problem. Die PDF lege
ich in einen Container, die Daten landen in SQLite.

Andere Kunden liefern einen wunderschönen Datenstrom in EBSCDIC
mit einer leicht vermurksten ASA-Steuerung, die Codierung ist nur
so ungefähr EBSCDIC - dafür gibt's ja deutsche Umlaute ... Weil
es nur Streams sind muß das Rechnungsformular mit eingebaut
werden. Natürlich abhängig vom Datum weil ja die GFs dauernd
wechseln.

Noch ein anderer Kunde liefert PDF ohne irgendetwas dazu. Sie
haben sogar das Firmenlogo vergessen. Also müssen die PDFs bei
der Anzeige (!) modifiziert werden. Das archivierte Original darf
ja lt. KPMG nicht verändert werden (beim Import ist die Laufzeit
nicht das Problem, beim Ausliefern via Web schon).

Soderle, jetzt bauen wir mal ein rechnungsforular so getreu nach
daß nicht einmal ein Steuerprüfer etwas zu motzen hat. Einscannen,
mit Corel vektorisieren, als PDF "ausgeben" und dann die wesentlichen
Sachen herausziehen.

"Projekte" und "Libraries" helfen einem da nicht wirklich weiter.

Mir bleibt aber nichts anderes wie PDF übrig, der Adobe Reader
ist bei gescannten Daten halt unschlagbar und kein Browser stellt
dir TIFF dar. SVG bringt es da auch nicht.

Mit PDF bin ich mittlerweile fast so fit wie mit 6502 Assembler :-)))

Joachim Drechsel schrieb:
> Hai Andreas,
>
> ich bekomme Daten als XML (in CSV wäre das ca 1 % des Volumens),

Hat dann aber nichts mit Validierung zu tun. Das dein Kunde ein
möglicherweise unpassendes Format gewählt hat ist wohl einfach Pech für
dich;-)

> zu jeder Rechnung/Lieferschein etc ein PDF. Das läßt sich ganz
> gut verarbeiten (es geht um Mengen, mehrere 100 MB pro Nacht laufen
> da rein, immer das gleiche Format). Kein Problem. Die PDF lege
> ich in einen Container, die Daten landen in SQLite.
>
> Andere Kunden liefern einen wunderschönen Datenstrom in EBSCDIC
> mit einer leicht vermurksten ASA-Steuerung, die Codierung ist nur
> so ungefähr EBSCDIC - dafür gibt's ja deutsche Umlaute ... Weil
> es nur Streams sind muß das Rechnungsformular mit eingebaut
> werden. Natürlich abhängig vom Datum weil ja die GFs dauernd
> wechseln.
>
> Noch ein anderer Kunde liefert PDF ohne irgendetwas dazu. Sie
> haben sogar das Firmenlogo vergessen. Also müssen die PDFs bei
> der Anzeige (!) modifiziert werden. Das archivierte Original darf
> ja lt. KPMG nicht verändert werden (beim Import ist die Laufzeit
> nicht das Problem, beim Ausliefern via Web schon).

Ist wohl ein Murks, naja.

Ich musste mal Visio Dokumente als PDF exportieren, und ca. 100
Einzeldokumente Dokumente als ein PDF ausliefern.

Habe das nie 100%ig zuverlässig hin gekriegt, zum Glück ist das jetzt
abgeschafft;-)

Eigentlich müsste ja der Ersteller saubere Daten liefern, dann wäre es
ja kein Problem;-) eigentlich

> Soderle, jetzt bauen wir mal ein rechnungsforular so getreu nach
> daß nicht einmal ein Steuerprüfer etwas zu motzen hat. Einscannen,
> mit Corel vektorisieren, als PDF "ausgeben" und dann die wesentlichen
> Sachen herausziehen.
>
> "Projekte" und "Libraries" helfen einem da nicht wirklich weiter.

Ja klar, ist auch ein Spezialfall.

>
> Mir bleibt aber nichts anderes wie PDF übrig, der Adobe Reader
> ist bei gescannten Daten halt unschlagbar und kein Browser stellt
> dir TIFF dar. SVG bringt es da auch nicht.
>
> Mit PDF bin ich mittlerweile fast so fit wie mit 6502 Assembler :-)))

OK, ich werde mich nicht weiter mit dir anlegen, höchstens mal Anfragen
wenn mein PDF Export nicht funktioniert=)


Die eigentliche Diskussion hat sich ja erledigt, da sowieso alle Seiten
exportiert sind hier im Forum;-)


mfg Andreas

Kunden die saubere Daten liefern ?

Eher friert die Hölle zu.

Joachim Drechsel schrieb:
> Kunden die saubere Daten liefern ?
>
> Eher friert die Hölle zu.

Ich zitiere mich:
eigentlich

Du kannst es auch positiv sehen: er sichert dir den Arbeitsplatz=)


mfg Andreas

Andreas B. schrieb:
> Du kannst es auch positiv sehen: er sichert dir den Arbeitsplatz=)

;-)

Herrschaftswissen :-))))))))))

leute, was macht ihr denn hier für eine Diskussion draus.
Da ohnehin bereits aus den Pdfs Vorschaubilder gerendert werden, wird es
doch kein Problem sein, da noch die Seitenzahlen reinzurendern.

Andreas Schwarz schrieb:
> Es wird bereits standardmäßig eine Komplettvorschau aller PDFs
> generiert, z.B.
> http://www.mikrocontroller.net/attachment/preview/....
wow, ist das nicht extrem platzfressend?
> Was fehlt ist nur das passende UI.

Vlad Tepesch schrieb:
> Andreas Schwarz schrieb:
>> Es wird bereits standardmäßig eine Komplettvorschau aller PDFs
>> generiert, z.B.
>> http://www.mikrocontroller.net/attachment/preview/....
> wow, ist das nicht extrem platzfressend?

Dieses Bild ist 22k. Nehmen wir an wir haben im Schnitt 50kBytes.

Nehmen wir weiter an wir haben 10GByte zur Verfügung, und überschlagen
das kurz, das gibt so ca. 200'000 Seiten.

Ich meine mal gelesen zu haben das es auf einem Rootserver läuft, daher
gehe ich aus 10GByte sind da eher wenig...




mfg Andreas

Na ja, was sind im Terabyte-Zeitalter schon 10 GB.

>Validieren macht sogar der Firefox beim öffnen...

Habe ich erst jetzt gesehen. Ich habe Original-XML - FF stürzt da
"das hätte nicht passieren dürfen" ab, der IE nagt 5 min auf den
Bytes herum. Die XML hat >20 MB, Nutzanteil vielleicht 20 kB.

Validierung hilft da kaum etwas, die Daten müssen ja
rein (probiere mal, die IT einer großen Firma dazu zu bewegen, etwas
fehlerfrei zu machen - viel Spaß. Bis die Meetings herum sind, der
Schuldige gefunden und das "Problem" (nee, nicht "Fehler") in Ordnung
ist laufe ich wieder in der Badehose herum).

zZ gibts einen internal error, wenn man eine .pdf-Datei anhängen will.