Apache OpenOffice (AOO) Bugzilla – Issue 101734
Lines of objects in header/footer not drawn on consecutive pages when exporting to pdf
Last modified: 2013-08-07 14:43:57 UTC
Since there is no entry for OOo 3.1 final (OOo310m11)yet, I file this under 3.1 RC2. - I start a new Writer document and insert headers and footers. - Draw an arbitrary object from the drawing toolbar anchored to the header/footer paragraph. - Make sure the document has more than one page either by automatic or manual page break. - Save document and export to pdf. Result: None of the objects anchored to the header or footer has any lines from page two on. I have observed this under Windows Vista 32bit, could not test it under XP. Someone else could not observe this behaviour under Linux.
Created attachment 62147 [details] drawn objects in header/footer of Writer document
Created attachment 62148 [details] pdf exported from the above
This problem does not occur with Version 3.01 on Vista
That would be a writer issue.
confirmed. This is broken since DEV300m30 - DEV300m29 works fine. From my point of view a candidate for OOo 3.1.1
OD->AW: Please take over as discussed.
AW: Very strange. Adding to aw073...
AW: No Problem in edit view; looking e.g. at pages 1-3 on a 2nd window while cahnging a rectangle in the Header of View1. Also works in PagePreview. Indeed, on pdf export, the hairline around the rectangle disappears. Debugging...
AW: Probably error found. In VclMetafileProcessor2D line geometry is additionally added to the MetaFile as comment action using a SvtGraphicStroke class (one of the extra data transport hacks of MetaFile). That class is centrally prepared in the VclMetafileProcessor2D::impTryToCreateSvtGraphicStroke helper method. What is missing is to apply the ObjectTransformation to the geometry. This is needed since the Header/Footer objects are VirtObj's which get encapsulated in a TransformPrimitive2D to create the page offset. Adding code to apply the current object transformation to the used geometry...
AW: Indeed, this is the reason. Thinking about LineStart/End (Arrows). Are they handled correctly when the transfromation does not only have an offset, but also a scaling/rotation? Checking...
AW: For the used transformation, the fix will be okay. The SvtGraphicStroke conent will be prepared in object coordinates. The used polygons (the line itself, a start and/or end of line) will be transformed using the ObjectToWorld transformation. This transformation does not contain scalings in the used case (and no unproportinal scaling, too). The scaling would have had to be taken into account for the LineWidth and the DashDotArray otherwise. Anyways, in cases of more complex transformations than translation and linear scale, it would be better to use the decomposition. This is not needed for the current possible cases, but just a note to remember this. Added debug test code to VOCOfDrawVirtObj::createPrimitive2DSequence to be able to experiment with more than a translation. It is no problem for visualisation, just for e.g. PDF export the old concept of putting stuff into SvtGraphicStroke is not sufficient; to describe the existing data, a transformation would have to be added to it. Checking in solution...
AW: SvtGraphicStroke is a hack anyways and will be removable over some time (PDF export should use primitives). Okay, done.
AW: Checked on installed Win32 install set, works as expected.
*** Issue 102040 has been marked as a duplicate of this issue. ***
AW: Also need to re-activate this one as 3.1.1 task, added to CWS aw074. Adding changes to the code...
AW: Also fixed in CWS aw074, changes checked (with the examples from the double task) and comitted.
*** Issue 103199 has been marked as a duplicate of this issue. ***
AW->WG: Pease verify as described. Me or OD may demostrate
AW: Ckecked with wntmsci12.pro build, works as expected.
AW->WG: Please review as described. Maybe a SW tester could take a look, to, OD will help too.
Reassigning Writer task to MRU for verification in CWS's and Master build.
Verified in CWS aw073 and aw074.
*** Issue 103579 has been marked as a duplicate of this issue. ***
me to CC
Hello chrk, *, I have tested it with OOO310m18 under Debian SID AMD64. I cannot confirm this issue, so it seems to be fixed ... ;) Could someone else with a different OS and/or architecture check it as well? And close this issue, if it is fixed there, too? TIA Thomas.
Header/Footer problem has been a thorny issue. For example issue 67292: problem with header/footer text only.
Cannot be confirmed in OOO310m18, because it is already fixed there. Checked in OOO310m17 and 300m54.