Minimal-PDF-Beispiel in der PDF-Spezifikation

Nahm ich die minimal-PDF-Beispiel in der PDF-Spezifikation von PDF-Spezifikation, kopiert Sie in den Editor, benannte die Datei mit der Erweiterung .pdf.

Kann ich es öffnen mit einem anderen PDF-viewer (PDF-XChange, SumatraPDF, MuPDF). Aber wenn ich es öffnen mit Adobe Reader sagt, die Datei ist kaputt.

Ich bin nicht sicher, ob die anderen Zuschauer gegen diese "defekte" Datei als leere Datei oder nicht.

Die Datei soll die Anzeige einer leeren Seite, denn es ist ein minimal-Beispiel.

In der Tat, ändern Sie die minimal-Beispiel. Denn wenn ich es kopieren aus PDF-Spezifikation, um den Editor, und öffnen Sie die .txt-Datei durch einen Hex-Editor, sehe ich eine neue Zeile in .txt Datei-geben Sie mir 2 Platz. Zum Beispiel,

1 0 obj
<< /Type /Catalog

gibt mir (im Hex Editor)

1 0 obj  << /Type /Catalog

ist (in hex-Werten)

31 20 30 20 6F 62 6A 0D 0A 3C 3C 20 2F 54 79 70
65 20 2F 43 61 74 61 6C 6F 67

Die 2 Leerzeichen zwischen j und < sind 0D 0A.

Damit ich das nicht machen, werden neue Zeilen in NotePad, und ändern Sie die Werte in die xref Teil.

Unten ist der komplette code.

Wissen Sie, was falsch mit diesem Beispiel? Warum funktioniert Adobe Reader sagen, dass es kaputt ist?? Ist das, weil ich gab die falsche Werte in xref?

%PDF-1.4 1 0 obj << /Type /Catalog /Outlines 2 0 R /Pages 3 0 R >> endobj 2 0 obj << /Type Outlines /Count 0 >> endobj 3 0 obj << /Type /Pages /Kids [4 0 R] /Count 1 >> endobj 4 0 obj << /Type /Page /Parent 3 0 R /MediaBox [0 0 612 792] /Contents 5 0 R /Resources << /ProcSet 6 0 R >> >> endobj 5 0 obj << /Length 35 >> stream … Page-marking operators … endstream endobj 6 0 obj [/PDF] endobj xref 0 7 0000000000 65535 f 0000000009 00000 n 0000000074 00000 n 0000000119 00000 n 0000000176 00000 n 0000000295 00000 n 0000000373 00000 n trailer << /Size 7 /Root 1 0 R >> startxref 395 %%EOF

InformationsquelleAutor user565739 | 2012-09-30

  1. 16

    Erste:, wenn Sie "kopiert" das Beispiel aus der PDF-Spezifikation, der sehr wahrscheinlich ein paar Dinge passiert sind, die Ihre Kopie nicht wie erwartet:

    • ...Sie nicht 'kopieren' durch die erneute Eingabe in dem Beispiel in einen Texteditor, aber
    • ...du benutzt copy ' N ' Paste, mit einer PDF-Datei als Quell-Datei.

    Je nach Ihren text-editor, dass die Methode wahrscheinlich verursacht die Konvertierung der Zeilenumbruch-Konvention geändert werden [cr]+[lf] [cr] oder vice-versa. Dies wiederum bedeutet, dass die byte-offset-Nummern in das Objekt 'Inhaltsverzeichnis' (die 'xref'-Tabelle) sind nicht mehr gültig.

    Ein weiteres problem mit der PDF-Quelle-code, den Sie geschrieben ist, dass es nicht jetzt beliebig Zeilenumbrüche an alle. Einige Zuschauer werden in der Lage, immer noch schweigend, analysieren die Sache, aber nicht alle sind. Und es ist sicherlich gegen die spec, da entsprechend der Spezifikation in Kapitel 7.5.2 es wird deutlich formuliert, dass

    "Ist die erste Zeile der PDF-Datei wird ein header bestehend aus 5 Zeichen %PDF–", gefolgt von der Versionsnummer der form 1.N, wobei N eine Ziffer zwischen 0 und 7.

    Ihre Kopf gegen diese Regel.

    Auch, der "stream" in 5 0 obj ist keine gültige PDF-code, es ist nur ein Platzhalter-text (… Page-marking operators …). Einige Zuschauer können kippen, wenn Sie in einer solchen 'Müll'.

    Schließlich Ihre startxref Wert war nicht korrekt.

    So, hier ist eine Datei, die funktioniert. Ich reparierte es in einem text-editor, und ich legen Sie Ihre original-code als Kommentar nach der %%EOF für den Vergleich und Referenz:

    %PDF-1.4
1 0 obj
<< /Type /Catalog /Outlines 2 0 R /Pages 3 0 R >>
endobj
2 0 obj
<< /Type Outlines /Count 0 >>
endobj
3 0 obj
<< /Type /Pages /Kids [4 0 R] /Count 1 >>
endobj
4 0 obj
<< /Type /Page /Parent 3 0 R /MediaBox [0 0 612 792] /Contents 5 0 R /Resources << /ProcSet 6 0 R >> >>
endobj
5 0 obj
<< /Length 35 >>
stream
… Page-marking operators …
endstream 
endobj
6 0 obj
[/PDF]
endobj
xref
0 7
0000000000 65535 f 
0000000009 00000 n 
0000000074 00000 n 
0000000119 00000 n 
0000000176 00000 n 
0000000295 00000 n 
0000000376 00000 n 
trailer 
<< /Size 7 /Root 1 0 R >>
startxref
394
%%EOF

%% %PDF-1.4 1 0 obj << /Type /Catalog /Outlines 2 0 R /Pages 3 0 R >> endobj 2 0 obj << /Type Outlines /Count 0 >> endobj 3 0 obj << /Type /Pages /Kids [4 0 R] /Count 1 >> endobj 4 0 obj << /Type /Page /Parent 3 0 R /MediaBox [0 0 612 792] /Contents 5 0 R /Resources << /ProcSet 6 0 R >> >> endobj 5 0 obj << /Length 35 >> stream … Page-marking operators … endstream endobj 6 0 obj [/PDF] endobj xref 0 7 0000000000 65535 f 0000000009 00000 n 0000000074 00000 n 0000000119 00000 n 0000000176 00000 n 0000000295 00000 n 0000000373 00000 n trailer << /Size 7 /Root 1 0 R >> startxref 395
    Danke Kurt, aber warum der Wert von startxref ist 394 nicht 396. Ist das nicht dieser Wert sollte den byte-offset des Zeichens 'x' in xref in dieser Datei? Es ist 396 in einem Hex-Editor. Aber mit 396, die Datei ist kaputt, und 394 funktioniert. Ich weiß nicht, wieso.
    Führen Sie dd bs=1 skip=394 if=this.pdf. Das heißt, Sie haben übersprungen, die erste 394 bytes beim sichern der Datei. Nun sollte die Ausgabe starten Sie mit xref auf einer Linie durch seine eigenen.
    Wenn ich kopieren / eingefügt, ich hatte zu ändern, das einzelne Zeichen "..." gegen "Seite-marking-Operatoren" zu den drei Zeichen "..." und die startxref von 394 bis 398. Ich vermute, dass, wenn ich copy/Paste das Zeichen "..." war verwurschtelt. Mit der Ausweitung auf drei einzelne "." auf beiden Seiten des Baches, eine weitere 4 bytes, die mich dazu bewegt, 398 von 394 für den start in die xref-Tabelle.
    Bekomme ich nur eine leere Seite, wenn ich versuche, fügen Sie einige Inhalte, z.B., mit "BT-10 50 Td (Weg!)Tj ET" (mit den beiden Anweisungen und die start - /end-tags in separate Zeilen) als stream-Objekt 5 und-nach Anpassung der entsprechenden byte-offsets. Vorschau öffnet es in Ordnung, zeigt aber nur eine leere Seite. Ich bin mit Vorschau-Version 5 auf einem OX 10.6.8
    Ein paar mehr (hand-codiert) PDF-Beispiele, um mit zu spielen können hier gefunden werden: github.com/angea/PDF101/tree/master/handcoded.

    InformationsquelleAutor Kurt Pfeifle

Schreibe einen Kommentar