2013-09-17T04:03:58
bianca0.35 mit Strawberry 5.10.1 auf Win 7 32 Bit.
OK
2013-09-17T04:03:58
biancaDas heißt, das Modul ergänzt im PDF einen JS Code der das Feld befüllt? Ist das die Technik bei der ganzen Sache?
Ja.
In Deinem Ursprungs-PDF ist die Struktur des Formulars wohl ok, das
AcroForm-Element ist da und das Feldelement auch:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
4 0 obj
<</Type/Annot/Subtype/Widget/F 4
/Rect[87.3 735.9 214.9 754.6]
/FT/Tx
/P 1 0 R
/T(Test)
/V <FEFF>
/DV <FEFF>
/MaxLen 100
/DR<</Font 5 0 R>>
/DA(0 0 0 rg /F2 12 Tf)
/AP<<
/N 15 0 R
>>
>>
endobj
16 0 obj
<</Type/Catalog/Pages 6 0 R
/OpenAction[1 0 R /XYZ null null 0]
/Lang(de-DE)
/AcroForm<</Fields[
4 0 R
]/DR 14 0 R/NeedAppearances true>>
>>
endobj
Das Textfeld hat als Default-Value (/DV) aktuell nur die BOM (0xFEFF).
In Deinem neuen PDF
fehlt das AcroForm-Element, das Textfeld ist unverändert. Es ist ein JS-Element zugefügt, das das Füllen des Textfeldes übernimmt:
22 0 obj<</S/JavaScript/JS ( function Ladda\(\) {if \(this.getField\('Test'\)\) this.getField\('Test'\).value = unescape\('foo'\); 1;}
function Init\(\) { if \(typeof this.info.ModDate == "object"\) { return true; }Ladda\(\);
} Init\(\); )>>endobj
Soweit ich das sehe, ist die Struktur des neuen PDF fehlerhaft (kein AcroForm-Dictionary). Dass das Feld trotzdem angezeigt wird, ist evtl. der Geduld des Readers zu verdanken. Vielleicht scheitert das JS aber auch an irgendwas anderem.
Die PDF-Internals sind nicht wirklich einfach zu durchschauen, aber wenn Du tiefer einsteigen willst:
Adobe PDF-Dokumentation (8.5M PDF).
Statt sich stundenlang mit dem Ergebnis rumzuschlagen: Kann man evtl. im OpenOffice-Formulareditor bereits einen Default-Wert hinterlegen?
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"