Apache OpenOffice (AOO) Bugzilla – Issue 101701
No Label-Type Flds Exported to PDF Doc Export PDF Submit Fmt. FDF
Last modified: 2013-08-07 14:43:57 UTC
Environment: OO 3.1.0 Build 9399 OS MS Windows Vista 32-bit SP1 PC AMD 64 X2 4200+ 2GB Main Memory Product: Writer. Document Type: XML Form Document Application: Creating forms and defining fields in OO easier than trying to create fields on OO document imported into Adobe Acrobat when there's no preference for Adobe LiveCycle Designer. The input fields are created in the export and there are no issues of trying to align an Adobe field on the OO document. Problem: Form label fields do not appear in Adobe Acrobat 9.1 or Adobe Reader 9.1. when the OO document is exported as a PDF. In the previous 3.0 production version as updated, all field types appeared when exported as PDF and used with the same Adobe product versions. In the OO document, fields are defined and stand alone or are associated with a specific field type such as Text Box with the Properties field 'Label Field'. Navigation: 1. Create document File|New|XML Form Document. 2.Label fields created by clicking icon 'ABC' on the Form Design toolbar (View|Toolbars|Form Design or Controls, etc.). 3.Export to PDF using File|Export as PDF and dialog PDF Options General|Create PDF form, Submit Format combo FDF (or any value). Document description: Two pages. ~40 labels and 40 text box fields. Ten sets of radio buttons. Four buttons. Four 5-column tables with cells containing the labels, fields, radio buttons, and text. Several frames, one logo graphic. Arial font only used, some bold enhancements, multiple font sizes.
Re. Original write-up. The mentioned previous OO release is 3.0.1 build 9379, form labels are exported to PDF. Documents created in 3.0.1 and exported to PDFs. One document opened in 3.1.0, two text box fields added, one existing button action changed to submit. Exported to PDF as described in original write-up, form labels not exported. Reinstalled 3.0.1. Modified document with failing PDF export in 3.1.0 now has form labels exported again in 3.0.1.
Please attach sample documents Reassigned to MSC
Created attachment 62121 [details] XML Form Document
Example labels. Table tblChangesPart01, column 3, row 2, Properties: Label Field, Name lblStreetAddressOld, Label Street Address. Does not export in 3.1.0 whether associated with tbAddress.Street.Old or not. lblZipOld is associated with tbAddress.Zip.Old, lblStreetAddressOld is not assciated with tbAddress.Street.Old.
OOo 3.1, the Text label not exported, not only in XForm, but from any database or standalone form. Same in DEV320m49 version of OOo.
This bug is confirmed on Linux, and also happens when you attempt to export a regular writer document with embedded widgets. I think I have noticed a possible pattern that might help get it fixed. After you export the form to PDF, all of the labels turn light gray (inactive) in OpenOffice. You have to close and re-open the document to get them back into "active" move. When they are inactive, you cannot click focus into them. This bug is blocking the ability for users to create PDF forms.
confirmed with Xp & Ubuntu(9.04) Setting to NEW Adding two attachements: 1 - the pdf file created by 3.0.1 from the bug doc [labels exported] 2 - the pdf file created by DEV310_m14 (build:9409) [labels lost] Adding keyword regression,
Created attachment 63398 [details] pdf created from bug doc w/ OO.o3.0.1
Created attachment 63399 [details] pdf created from bug doc w/ DEV310m_14
updated summary - this is not limited to XForms only.
confirm, set target and send to the right developer The export of the odt to pdf works in 3.0.1 broken in 3.1 and OOO310 m15 (will be OOO 3.1.1)
fs->pl: looks like a regression of CWS rtlcontrols to me. In this CWS, Window::PaintToDevice was modified: Previously, it painted to a MetaFile, and this MetaFile was played in the target device. Nowadays, Window::PaintToDevice effectively paints to itself, with recording a MetaFile. This MetaFile is played into a virtual device, and from there, as bitmap, copied into the target device. Somehow, this latter step does not arrive in the target device (I am not sure why). I see three
.... possibilities here: 1. change VCLXWindow::Draw to use Window::Draw instead of Window::PaintToDevice in case of PDF export. For some reasons, Draw currently is used only if PDF form creation is *disabled* in the PDF export, otherwise, if it is enabled, then PaintToDevice is used. This distinction does not seem to make sense to me, handling for the PDF form creation should be (and is) done in higher layers. I am not sure, however, how "Draw" interacts with RTL controls. 2. fix the PaintToDevice to also capture this case. Not sure what efforts wait here. 3. Hmm, did I write "three" instead of "two"? Can't think of a third right now ... fs->pl: would be interested in your opinion on this
I committed a fix for 1. to CWS dba311b. Going back in the history of the file, it seems the code to use PaintToDevice in case PDF form export is enabled dates back to end of 2006, and came in with CWS pdf04. This code branch is only used when a) PDF form export is disabled for the current PDF export operation, or b) the given control does not have an equivalent PDF form control (like it is the case for label fields). In case a), Draw is unconditionally used, so I do not see a reason why it should not be used in case b), too.
fs->msc: please verify in CWS dba311b
verified in CWS dba311b find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba311b
Checked w/ OOO310m_17, Ubuntu 9.04 Closing