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 ...
Joachim Drechsel schrieb: > Keine Ahnung, in was die > Forensoftware geschrieben ist ruby on rails heißt der Kram iirc.
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...
1 | pdfinfo test.pdf |
2 | Producer: iText 2.0.7 (by lowagie.com) |
3 | CreationDate: Thu Dec 22 14:11:34 2011 |
4 | ModDate: Thu Dec 22 14:11:34 2011 |
5 | Tagged: no |
6 | Pages: 1 |
7 | Encrypted: no |
8 | Page size: 595 x 842 pts (A4) |
9 | File size: 3798 bytes |
10 | Optimized: no |
11 | 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
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.
1 | endobj |
2 | 3 0 obj <--- HIER (4) Index |
3 | << /Type /Pages /Kids [ |
4 | 4 0 R |
5 | 22 0 R |
6 | |
7 | ... |
8 | |
9 | 119 0 R |
10 | 125 0 R |
11 | ] /Count 15 <--- HIER (5) Seitenzahl |
12 | >> |
13 | endobj |
14 | 1 0 obj |
15 | <</Type /Catalog /Pages 3 0 R <--- HIER (3) start des Indexes |
16 | >> |
17 | endobj |
18 | |
19 | ... |
20 | |
21 | 2 0 obj |
22 | |
23 | ... |
24 | xref |
25 | 0 172 |
26 | 0000000000 65535 f |
27 | 0000062574 00000 n |
28 | |
29 | ... |
30 | |
31 | 0000172390 00000 n |
32 | 0000172804 00000 n |
33 | trailer |
34 | << /Size 172 /Root 1 0 R /Info 2 0 R <--- HIER (2) am ende: Root ist 1 0 |
35 | >> |
36 | startxref <--- HIER (1) startadresse der XREF |
37 | 177392 |
38 | %%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/45980/page_snapshots/011.png. 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
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).
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.