Issue 114010

Created attachment 71215 [details]
hybrid pdf exposing the problem in the form

Please attach the native odt file of the problem, so that we can reproduce the
problem during export. Thanks a lot!

Created attachment 71245 [details]
ott template of document exhibiting the problem

Hello, attached file as requested.
Rgds, Daniel

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
Reader.

*** Issue 117373 has been marked as a duplicate of this issue. ***

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.

http://user.services.openoffice.org/en/forum/viewtopic.php?f=5&t=38280

I'm attaching ODT and pdf files.  Open PDF in foxit and adobe and the form text alignment is different.

Created attachment 76330 [details]
PDF demonstrating the problem in Adobe Reader only (not foxit)

Created attachment 76331 [details]
ODT document creating the form which outputs the PDF that improperly displays form font alignment in adobe reader only

http://user.services.openoffice.org/en/forum/viewtopic.php?f=5&t=38280

I too have this issue.  The only way I have found to address it is to revert to OOo 3.2.1

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.

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.

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. 

--blumel

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.

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

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!

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.

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 OpenOffice.org 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.


1a) THE ALIGNMENT ISSUE
=======================
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 (https://issues.apache.org/ooo/show_bug.cgi?id=114010#c8) 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).

Conclusions
-----------
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



1b) THE FONT SIZE ISSUES
========================
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.

Comments
--------
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).



ATTACHMENT INFO
===============
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!

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!

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...

Reset assignee on issues not touched by assignee in more than 2000 days.