Issue 101701 - No Label-Type Flds Exported to PDF Doc Export PDF Submit Fmt. FDF
Summary: No Label-Type Flds Exported to PDF Doc Export PDF Submit Fmt. FDF
Alias: None
Product: Writer
Classification: Application
Component: save-export (show other issues)
Version: OOo 3.1
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: marc.neumann
QA Contact: issues@sw
Keywords: regression
Depends on:
Blocks: 101565
  Show dependency tree
Reported: 2009-05-08 23:10 UTC by nemonoone
Modified: 2013-08-07 14:43 UTC (History)
5 users (show)

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

XML Form Document (54.15 KB, application/vnd.oasis.opendocument.text)
2009-05-09 16:19 UTC, nemonoone
no flags Details
pdf created from bug doc w/ OO.o3.0.1 (123.09 KB, application/pdf)
2009-07-06 14:24 UTC, drewjensen.inbox
no flags Details
pdf created from bug doc w/ DEV310m_14 (121.30 KB, application/pdf)
2009-07-06 14:25 UTC, drewjensen.inbox
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description nemonoone 2009-05-08 23:10:29 UTC
 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.
Comment 1 nemonoone 2009-05-09 04:35:25 UTC
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.
Comment 2 eric.savary 2009-05-09 10:22:00 UTC
Please attach sample documents
Reassigned to MSC
Comment 3 nemonoone 2009-05-09 16:19:36 UTC
Created attachment 62121 [details]
XML Form Document
Comment 4 nemonoone 2009-05-09 16:31:02 UTC
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
Comment 5 r4zoli 2009-06-09 09:40:41 UTC
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.
Comment 6 drichard 2009-06-22 13:53:51 UTC
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.
Comment 7 drewjensen.inbox 2009-07-06 14:23:17 UTC
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, 
Comment 8 drewjensen.inbox 2009-07-06 14:24:36 UTC
Created attachment 63398 [details]
pdf created from bug doc w/ OO.o3.0.1
Comment 9 drewjensen.inbox 2009-07-06 14:25:52 UTC
Created attachment 63399 [details]
pdf created from bug doc w/ DEV310m_14
Comment 10 drewjensen.inbox 2009-07-06 14:31:04 UTC
updated summary - this is not limited to XForms only.
Comment 11 marc.neumann 2009-07-08 09:09:59 UTC
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)
Comment 12 Frank Schönheit 2009-07-08 10:09:03 UTC
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 
Comment 13 Frank Schönheit 2009-07-08 10:13:25 UTC
.... 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
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
Comment 14 Frank Schönheit 2009-07-08 11:07:45 UTC
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.
Comment 15 Frank Schönheit 2009-07-16 08:01:07 UTC
fs->msc: please verify in CWS dba311b
Comment 16 marc.neumann 2009-07-16 13:05:01 UTC
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:
Comment 17 drewjensen.inbox 2009-07-29 21:22:38 UTC
Checked w/ OOO310m_17, Ubuntu 9.04