Forms printing issue
954 views
Skip to first unread message
Alexander Kind
Jun 2, 2015, 11:14:38 AM6/2/15
to wkhtmltop...@googlegroups.com
Hi,
Firstly I would like to thank you for you wonderful product!
I've faced with issue concerning "--enable-forms" option.
I've a simple HTML document with one input field:
Then I'm converting this document using WKHTMLTOPDF with option "--enable-forms" (encoding utf-8).
As result I get a PDF document where this field is highlighted and I can enter some text there (e.g. in the Chrome browser).
The Firefox browser says that it can't edit this document and opens its in Adobe Acrobat Reader DC.
There I can fill out the field too.
The problem is that when I print the document with filled fields - they are empty in the "Print Preview" and on paper.
I've tried multiple ways to obtain the result (import another XFDF, change encoding, process file with PDFTK) but I can't.
Please advise.
Firstly I would like to thank you for you wonderful product!
I've faced with issue concerning "--enable-forms" option.
I've a simple HTML document with one input field:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
</head>
<body>
Test form fields
<input type="text" name="testField" id="testField">
</body>
</html>Then I'm converting this document using WKHTMLTOPDF with option "--enable-forms" (encoding utf-8).
As result I get a PDF document where this field is highlighted and I can enter some text there (e.g. in the Chrome browser).
The Firefox browser says that it can't edit this document and opens its in Adobe Acrobat Reader DC.
There I can fill out the field too.
The problem is that when I print the document with filled fields - they are empty in the "Print Preview" and on paper.
I've tried multiple ways to obtain the result (import another XFDF, change encoding, process file with PDFTK) but I can't.
Please advise.
Alexander Kind
Jun 4, 2015, 9:27:58 AM6/4/15
to wkhtmltop...@googlegroups.com
Hi,
I've investigated the issue and found the following.
To ensure correct work of forms (during printing), each object with Type/Annot and Subtype/Widget (i.e. that is our input field) should have additional flag: /F 4
You can get more information about this flag and possible values there - PDF Spec 1.3, page 83. The value should be "4".
The new structure of field object is the following:
As workaround you may replace all "/Ff 0" substrings in the final PDF document to "/F 4" (with two spaces between to prevent shifting of another objects in xref).
I hope that it will be fixed in new version.
Good luck!
I've investigated the issue and found the following.
To ensure correct work of forms (during printing), each object with Type/Annot and Subtype/Widget (i.e. that is our input field) should have additional flag: /F 4
You can get more information about this flag and possible values there - PDF Spec 1.3, page 83. The value should be "4".
The new structure of field object is the following:
6 0 obj<<
/Type /Annot
/Parrent 7 0 R/Rect[34.3200000 798.679999 130.319999 812.929999 ]
/BS<</S/I>>
/FT/Tx
/Subtype/Widget
/P 5 0 R/T(test)
/DA(/Helv 12 Tf 0 g)
/F 4
>>
endobj
As workaround you may replace all "/Ff 0" substrings in the final PDF document to "/F 4" (with two spaces between to prevent shifting of another objects in xref).
I hope that it will be fixed in new version.
Good luck!
Alexander Kind
Jun 4, 2015, 10:17:47 AM6/4/15
to wkhtmltop...@googlegroups.com
Hi,
Here is an example how to use workaround in PHP:
NB! Encoding of php file should be UTF-8 or the same as in original document.
Good luck!
Here is an example how to use workaround in PHP:
// workaround to change Annot object flags from "/Ff 0" to "/F 4"
$pdf = file_get_contents('Document.pdf');
// allow fields printing
$pdf = str_replace('/Ff 0'."\n", '/F 4'."\n", $pdf);
// remove fields borders
$pdf = str_replace('/BS<</S/I>>'."\n", ' '."\n", $pdf);
// change fields font
$pdf = str_replace('/DA(/Helv 12 Tf 0 g)'."\n", '/DA(/Helv 10 Tf 0 g)'."\n", $pdf);
file_put_contents('Document.pdf', $pdf);
NB! Encoding of php file should be UTF-8 or the same as in original document.
Good luck!
Ashish Kulkarni
Jun 5, 2015, 1:36:45 AM6/5/15
to wkhtmltop...@googlegroups.com
The fix is actually reported and should be merged for the next release (0.12.3):
https://github.com/wkhtmltopdf/qt/issues/14
Can you try applying the patch to Qt and seeing if it generates PDFs
for you correctly?
https://github.com/wkhtmltopdf/qt/issues/14
Can you try applying the patch to Qt and seeing if it generates PDFs
for you correctly?
Alexander Kind
Jun 5, 2015, 2:28:59 AM6/5/15
to wkhtmltop...@googlegroups.com
Hi,
I can't since I don't have the environment to build the program.
And I faced with one more issue: if field's value are entered in html e.g.
then the field is showing empty in Acrobat Reader DC (but looks OK in Chrome). When I click the field I see the value and can edit it. After editing it becomes visible in the document and during printing.
To solve this problem I've tried to process final file using PDFTK tool with the following options:
"PDFTK input.pdf output output.pdf need_appearances"
where 'need_appearances' means: "Sets a flag that cues Reader/Acrobat to generate new field appearances based on the form field values. Use this when filling a form with non-ASCII text to ensure the best presentation in Adobe Reader or Acrobat".
After processing the document looks OK in "Acrobat Reader DC".
Accordingly the provided patch is not full and solves only one issue.
To fix this issue you should change the following:
1. Find parent object of the field (also the /parrent option should be fixed to /parent as described in your patch):
I can't since I don't have the environment to build the program.
And I faced with one more issue: if field's value are entered in html e.g.
<input type="text" name="f1" value="some value">
then the field is showing empty in Acrobat Reader DC (but looks OK in Chrome). When I click the field I see the value and can edit it. After editing it becomes visible in the document and during printing.
To solve this problem I've tried to process final file using PDFTK tool with the following options:
"PDFTK input.pdf output output.pdf need_appearances"
where 'need_appearances' means: "Sets a flag that cues Reader/Acrobat to generate new field appearances based on the form field values. Use this when filling a form with non-ASCII text to ensure the best presentation in Adobe Reader or Acrobat".
After processing the document looks OK in "Acrobat Reader DC".
Accordingly the provided patch is not full and solves only one issue.
To fix this issue you should change the following:
1. Find parent object of the field (also the /parrent option should be fixed to /parent as described in your patch):
6 0 obj
<<
/Type /Annot
/Parrent 7 0 R
/Rect[34.3200000 798.679999 130.319999 812.929999 ]
/BS<</S/I>>
/FT/Tx
/Subtype/Widget
/P 5 0 R
/T(f1)
/DA(/Helv 12 Tf 0 g)
/F 4
>>
endobj
2. Add option /NeedAppearances (I think it would be great to move this opportunity into program options)
7 0 obj
<<
/Fields[6 0 R ]
/DR<</Font<</Helv 8 0 R>>>>
/DA(/Helv 0 Tf 0 g)
/NeedAppearances true
>>
endobj
Good luck!
Paul Carlton
Mar 10, 2016, 8:03:18 PM3/10/16
to wkhtmltopdf General
You sir, are cool. Thanks.
Reply all
Reply to author
Forward
0 new messages