Issue 93169

Summary: PDF export of form controls broken
Product: Base Reporter: Frank Schönheit <frank.schoenheit>
Component: codeAssignee: christoph.lukasiak
Status: CLOSED FIXED QA Contact: issues@dba <issues>
Severity: Trivial    
Priority: P3 CC: issues
Version: DEV300m30Keywords: regression
Target Milestone: OOo 3.1   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
document to reproduce the bug case
none
PDF document resulting from exporting the bug doc in DEV300m29
none
PDF document resulting from exporting the bug doc in DEV300m30
none
controls as they look in CWS aw058
none
After exporting controls.odt to PDF format none

Description Frank Schönheit 2008-08-27 11:38:33 UTC
- open the attached document
- export it to PDF
- open the resulting PDF in a PDF viewer of your choice
=> a lot of the controls which are part of the text document have not, or with
   wrong position/size, been exported
Comment 1 Frank Schönheit 2008-08-27 11:39:18 UTC
adding "regression" keyword (the export works fine in m29), targeting
Comment 2 Frank Schönheit 2008-08-27 11:39:44 UTC
Created attachment 56038 [details]
document to reproduce the bug case
Comment 3 Frank Schönheit 2008-08-27 11:40:34 UTC
Created attachment 56039 [details]
PDF document resulting from exporting the bug doc in DEV300m29
Comment 4 Frank Schönheit 2008-08-27 11:40:58 UTC
Created attachment 56040 [details]
PDF document resulting from exporting the bug doc in DEV300m30
Comment 5 Armin Le Grand 2008-10-17 13:40:14 UTC
*** Issue 93178 has been marked as a duplicate of this issue. ***
Comment 6 Armin Le Grand 2008-10-17 13:42:46 UTC
*** Issue 93177 has been marked as a duplicate of this issue. ***
Comment 7 Armin Le Grand 2008-10-17 13:48:03 UTC
*** Issue 93171 has been marked as a duplicate of this issue. ***
Comment 8 Armin Le Grand 2008-10-17 13:59:03 UTC
AW: The FormControl primitive rendering was defaulted to decomposition on aw033
(which is a good test and revealed other stuff). For this fix, i will add
special rendering for the ControlPrimitive2D in the VclMetafileProcessor2D and
the VclPixelProcessor2D.
One problem was the pos and size of the controls. There was a choice to position
and size them either (a) in the VOC at the point in time the PrimitiveSequence
is fetched (ViewObjectContactOfUnoControl::createPrimitive2DSequence) or (b)
directly in the primitive renderers when a ControlPrimitive2D is rendered. Old
version used (a), but had an own positioning for the controls in the renderers
which was pixel based and was not working for all cases.
I experimented with (b) but ran in big problems, e.g. when the controls are in
live mode, the VCL-Windows representing them reduces the repaint region and thus
the form control primitive would sometimes not be in the region at repaint
preparation and would not be repainted -> not nrewly positioned. Only one
exapmle, there were others.
So i now decided to (a) which also allows to greatly reduce complexity in the
renderers since they imply that pos and scale (and font scale) are correct and
just need to resemble the various paints in the former VOCs for FormControls.
Only one case cannot be simplified, the decompose of the FormControl, since it
aints at (0, 0) in a VDev and uses quadratic pixel reduction to not make the
bitmaps too huge. There, the font scaling still needs to be set individually
(fixed in aw057 already).
After positioning and sizing (and zooming) in (a), i corrected the handlings of
ControlPrimitive2D in the two renderers mentioned above. All Cases so far are
working just as expected. Also the decompose of ControlPrimitive2D to bitmap
primitive(s) does not happen anymore now (but was necessary to test since other
primitive technique users will not support ControlPrimitive2D directly).
Doing some more tests...
Comment 9 Armin Le Grand 2008-10-17 17:29:35 UTC
AW: Works well, committed. Done.
Comment 10 Armin Le Grand 2008-11-06 11:19:08 UTC
AW->WG: Please review as described in the task. Maybe FS wants to check, too.
Comment 11 Frank Schönheit 2008-11-13 08:38:57 UTC
re-opening.

See the (to-be-)attached controls.aw058.pdf:
- The text of the check box and the radio button is printed twice
- the font of the label control and the group box are too large
- the drop down list box and combo box have artifacts at the right hand side
- (let's not talk about the table control. This was broken before, and is
  broken now, though in another way.)
Comment 12 Frank Schönheit 2008-11-13 08:39:18 UTC
fs->aw: see above for why this is not fixed.
Comment 13 Frank Schönheit 2008-11-13 08:40:06 UTC
Created attachment 57958 [details]
controls as they look in CWS aw058
Comment 14 Armin Le Grand 2008-11-13 11:35:26 UTC
AW: Checked with Frank and corrected an error in drawinglayer. Checked in.
Building new install sets.
Comment 15 Armin Le Grand 2008-11-14 10:23:35 UTC
AW->WG: Please review as described.
Comment 16 wolframgarten 2008-11-18 15:02:34 UTC
Verified in CWS.
Comment 17 wolframgarten 2009-01-19 13:09:49 UTC
Reassigned.
Comment 18 vladimir_hitekschool 2009-04-08 08:35:13 UTC
As to issue 93169 problem still exists in master version OOo-dev 3.1 .0 
(OOO310m9 Build:9396) for Windows XP. See attachment.
Comment 19 vladimir_hitekschool 2009-04-08 08:36:33 UTC
Created attachment 61449 [details]
After exporting controls.odt to PDF format
Comment 20 thorsten.ziehm 2010-02-22 14:43:19 UTC
This issue is closed automatically. It should be fixed in a version with is
available for longer than half a year (OOo 3.1). If you think this issue isn't
fixed in the current version (OOo 3.2) please reopen it. But then please pay
attention about the field 'target milestone'.
The closure was approved by the Release Status Meeting at 22nd of February 2010
and it is based on the issue handling guideline for fixed/verified issues  : 
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues