Issue 114010 - Text entry Fields too small in forms exported to PDF
Summary: Text entry Fields too small in forms exported to PDF
Alias: None
Product: Writer
Classification: Application
Component: save-export (show other issues)
Version: OOO330m3
Hardware: PC All
: P3 Trivial with 46 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 117373 (view as issue list)
Depends on:
Reported: 2010-08-20 09:08 UTC by dsto
Modified: 2013-08-07 14:44 UTC (History)
15 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

hybrid pdf exposing the problem in the form (88.78 KB, application/pdf)
2010-08-20 09:13 UTC, dsto
no flags Details
ott template of document exhibiting the problem (18.14 KB, application/vnd.oasis.opendocument.text)
2010-08-22 07:56 UTC, dsto
no flags Details
PDF demonstrating the problem in Adobe Reader only (not foxit) (15.42 KB, application/pdf)
2011-04-09 23:40 UTC, uwslothman
no flags Details
ODT document creating the form which outputs the PDF that improperly displays form font alignment in adobe reader only (10.14 KB, application/vnd.oasis.opendocument.text)
2011-04-09 23:43 UTC, uwslothman
no flags Details
Set of problematic and gradually fixed ODT and PDF made with OOo 3.2, OOo 3.4 and manual edits (96.00 KB, application/download)
2012-06-15 18:47 UTC, Fulvio
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description dsto 2010-08-20 09:08:39 UTC
We have a form in a table with about 20 entry fields, all of identical height
(created with copy-paste). The form displays well when used as ODT/DOC. 
The form exported as PDF exposes odd behaviour: Beginning at line 2, the text in
the entry fields is crushed vertically (it appears the height of the entry
fields is not sufficient anymore) and is getting unreadable versus the bottom of
the form. PDF Readers tried: Acroread (Linux), Evince (Linux), Document Reader
Comment 1 dsto 2010-08-20 09:13:56 UTC
Created attachment 71215 [details]
hybrid pdf exposing the problem in the form
Comment 2 michael.ruess 2010-08-20 11:38:47 UTC
Please attach the native odt file of the problem, so that we can reproduce the
problem during export. Thanks a lot!
Comment 3 dsto 2010-08-22 07:56:49 UTC
Created attachment 71245 [details]
ott template of document exhibiting the problem
Comment 4 dsto 2010-08-22 07:58:15 UTC
Hello, attached file as requested.
Rgds, Daniel
Comment 5 michael.ruess 2010-08-23 13:01:46 UTC
MRU->PL: can confirm this on Windows either. Export the attached Writer document
to PDF and see that the text form fields are now too small when opened in Adobe
Comment 6 eric.savary 2011-03-15 04:58:32 UTC
*** Issue 117373 has been marked as a duplicate of this issue. ***
Comment 7 uwslothman 2011-04-09 23:39:38 UTC
Here is a forum discussion of the bug.

It seems to be an interaction between open office and adobe reader.  I do not get the error when using foxit.  I am had the same problem running on oo 3.0 and updated to 3.3.  Adobe reader similiarly updated from 9 to 10.

I'm attaching ODT and pdf files.  Open PDF in foxit and adobe and the form text alignment is different.
Comment 8 uwslothman 2011-04-09 23:40:34 UTC
Created attachment 76330 [details]
PDF demonstrating the problem in Adobe Reader only (not foxit)
Comment 9 uwslothman 2011-04-09 23:43:16 UTC
Created attachment 76331 [details]
ODT document creating the form which outputs the PDF that improperly displays form font alignment in adobe reader only
Comment 10 timcastle 2011-06-28 14:27:12 UTC
I too have this issue.  The only way I have found to address it is to revert to OOo 3.2.1
Comment 11 paolocollector 2012-01-03 13:13:38 UTC
I have it too.
I cant believe that this has not been fixed yet. My company cant move to 3.3 because of this and it looks like it wont be fixed in 3.4 too.
As many stated export to pdf works fine in 3.2. If this is too hard to fix, can you just move back that funtionality to the old version please?
That one was working.
Comment 12 Carl Michael Giblhauser 2012-01-11 08:59:26 UTC
Since almost any form likely contains text entry fields (that are probably required like name, address or email address), this bug renders the whole PDF form export useless.

The workaround that i use now is rather clumsy. I installed an outdated version of Ubuntu (9.10) in a small virtual machine. That came with a version of OOo (3.1) that still produces working text entry fields in PDF forms. Our forms have to be updated every now and then. Should i for some reason be out of office there's now no one else who could get that job done.
Comment 13 revslowmo 2012-01-12 22:25:03 UTC
The priority of this bug needs to be increased as it renders a entire function in the program useless for making PDF's that have forms. 

Comment 14 hanya 2012-01-14 16:46:21 UTC
Workaround: to use Helvetica as font for text field without "Embed standard fonts" of PDF Options dialog. This means Adobe 14 standard font to use in the field.
Comment 15 paolocollector 2012-01-16 08:51:32 UTC
Thanks for the workaround, but it makes my forms looking absolutelly ridicolous
I think that there is a real need for a fix.
With all the "print to pdf" tools around, export to form is the only reason why users would use this functionality
Comment 16 thebestrtaken 2012-02-03 21:19:03 UTC
I tried this with and with out a frame.  I also changed the frame size.  IF the frame is twice the size of the font height, it works ok.  It looks REALLY REALLY bad, but it works.  If you turn off any type of frame (Not Flat or 3D look), your space can be smaller, but there is some sort of offset applied (like a lineFeed or something, or font command) that makes it start on a new line.
Hope this helps.  I am trying to get everyone to switch to OpenOffice for everything.  This makes the software look cheap. Not intended to be offensive, but to make people aware.  I think the OpenOffice product is AWESOME and I appreciate all the work that has been put into it!  Thanks All!
Comment 17 ldekay 2012-03-03 19:13:09 UTC
There is no problem using NitroPDF to open the file, but with Adobe Reader none of the alignment settings make any difference.  The text in the form field is always aligned as if there's a leading line break, the bottom of the text is cut off by the lower border of the field unless the field is at least .4" high.  

With LibreOffice changing format to multi-line works a bit better, but this workaround doesn't help with OOO3.3.
Comment 18 Fulvio 2012-06-15 18:47:38 UTC
Created attachment 78344 [details]
Set of problematic and gradually fixed ODT and PDF made with OOo 3.2, OOo 3.4 and manual edits

I've tried to make sense of this bug today, while working with and comparing results of tests made in parallel with Apache OpenOffice 3.4 and 3.2 (both on Windows)..and I've observed the following facts:

1) There are at least two distinct problems: one related to font sizes and the other to text alignment

2) The problem depends little on the OOo version exporting the file to PDF. It seems to be strictly dependant upon the content of the ODT file itself (more on this later)

3) If you have a "proper" ODT file, the exported PDF file looks like almost (while still not 100%) the same in all recent OOo versions (>= 3.2)

4) Both problem seems to be due to a change in how missing style values (defaults) inside the ODT are dealt with in different OOo versions.

When you added Text Edit Fields with OpenOffice 3.2, it didn't write two attributes inside the style:style/style:graphic-properties tag (reference inside the draw:control property "draw:style-name"), that OpenOffice 3.4 instead writes by default inside the ODT.
The properties are: draw:wrap-influence-on-position="once-concurrent" style:flow-with-text="false"

If you manually edit the content.xml of the ODT posted by uwslothman ( to add those properties, and export the file to PDF with OOo 3.4 you get (almost) the same result as the original file exported with OOo 3.2.

What does this mean to me? 
It means that OOo 3.2 automatically applied the wrap-influence-on-position="once-concurrent" and flow-with-text="false" properties if they were missing inside the ODT (and they were missing by default for fields added in OOo 3.2), while OOo 3.4 doesn't automatically apply those properties (neither during the export nor saving the ODT) if they are missing inside the ODT (and they wouldn't be missing if the field were added in OOo 3.4).

Once a field is added in OOo 3.2 will not be exported fine in later versions until it is:
- deleted and added again in that later version
- someone finds what UI actions are needed to make OOo 3.4 add those properties inside the ODT
- the content.xml is edited by hand to add those properties

1a.I) If you have an ODT created with OpenOffice 3.2 (where you didn't customize the font) and you export it with OpenOffice 3.4, the text inside the Text Edit Fields will display differently compared to the PDF exported by OpenOffice 3.2.
1a.II) And, if you create a new ODT with OpenOffice 3.4 the text inside the Text Edit Fields is almost unreadable (truncated at the top).

When you added Text Edit Fields with OpenOffice 3.2, it didn't write three attributes to the style:style/style:text-properties tag (reference inside the draw:control property "draw:text-style-name"), that OpenOffice 3.4 instead writes by default inside the ODT.
The attributes are: font-size, font-weight and font-name.

Origin and workaround for the size issue
1a.I) This is again due to OpenOffice versions handling differently the missing tag attributes inside the ODT. While OOo 3.2 used something like Arial 9pt by default if the font attributes were missing, OOo 3.4 uses the Default Font that is SegoeUI 9pt (at least on my system!). Manually specifying the font solves the problem.
1aII) The default OOo 3.4 font is Arial 14pt which is way too big to fit inside a Text Edit Field spanning only one line (svg:height="0.5cm"). Manually specifying a smaller font (even Arial, but with a font size of 8pt or 9pt) solves the problem.

I think that newer OOo versions should use a smaller font by default, or determine a proper font to fit the Text Box when it gets resized (proportionally to its height).

I've made a zip with a few ODT an PDF I used to make the tests.

1a) The Alignment Issue folder inside the zip contains uwslothman's original ODT and problematic PDF, and an EDITED one were I manually added the missing properties inside the content.xml, and PDF export from the edited PDF with both 3.2 and 3.4 versions.
1b) The Font Size Issue folder contains a series of incrementally modified documents:
  1 => Created with OOo 3.4, with a single field
  2 => Added a field with OOo 3.2 and exported to PDF with both versions: both PDF look wrong.
  3 => Changed the first field font with OOo 3.4 and exported the file.
  4 => Changed the font to both fields with OOo 3.4 to be specified (not undefined), and exported with both versions: the PDF looks the same!
Comment 19 Fulvio 2012-06-15 19:44:17 UTC
Obviously there may be other problems, and maybe also problems not related to the default styles handling...those two problem I explained above are the ones I encountered and (I think) almost understood.

I hope that my analysis will be of some help to those trying to fix the code!
Comment 20 paolocollector 2012-08-31 14:11:52 UTC
Thanks Fulvio for the investigation.
Is there any chance that this bug will ever be fixed?
Is that because it would take away business from Adobe if this starts working again?
I am not sure what to think anymore...
Comment 21 Rob Weir 2013-07-30 02:23:44 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.