Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | PDF export of form controls broken | ||
---|---|---|---|
Product: | Base | Reporter: | Frank Schönheit <frank.schoenheit> |
Component: | code | Assignee: | christoph.lukasiak |
Status: | CLOSED FIXED | QA Contact: | issues@dba <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues |
Version: | DEV300m30 | Keywords: | regression |
Target Milestone: | OOo 3.1 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Attachments: |
Description
Frank Schönheit
2008-08-27 11:38:33 UTC
adding "regression" keyword (the export works fine in m29), targeting Created attachment 56038 [details]
document to reproduce the bug case
Created attachment 56039 [details]
PDF document resulting from exporting the bug doc in DEV300m29
Created attachment 56040 [details]
PDF document resulting from exporting the bug doc in DEV300m30
*** Issue 93178 has been marked as a duplicate of this issue. *** *** Issue 93177 has been marked as a duplicate of this issue. *** *** Issue 93171 has been marked as a duplicate of this issue. *** 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... AW: Works well, committed. Done. AW->WG: Please review as described in the task. Maybe FS wants to check, too. 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.) fs->aw: see above for why this is not fixed. Created attachment 57958 [details]
controls as they look in CWS aw058
AW: Checked with Frank and corrected an error in drawinglayer. Checked in. Building new install sets. AW->WG: Please review as described. Verified in CWS. Reassigned. As to issue 93169 problem still exists in master version OOo-dev 3.1 .0 (OOO310m9 Build:9396) for Windows XP. See attachment. Created attachment 61449 [details]
After exporting controls.odt to PDF format
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 |