Apache OpenOffice (AOO) Bugzilla – Issue 65128
Outline of drawing objects consists of pixels of background is an image
Last modified: 2017-05-20 10:23:57 UTC
When exporting the attached odg file to pdf, the left object, with a color as background, is exported fine to pdf. The right object (the same, but with an image as background) shows pixel in the pdf.
Created attachment 36293 [details] the odg file
Created attachment 36294 [details] resulting pdf
Created attachment 36295 [details] screenshot
I checked with "2.0.2 German version WIN XP: [680m5(Build9011)]" and can confirm the effect. I see the "stairs" in the border of the object with Bitmap-Background. The stairs have the same size as those I see for both objects if I export the objects to PNG. No Idea whether this is a limitation of OOo or a general (PDF-(?)) limitation, may be that in the PDF the colour-background-border is described as a kind of vector, but the bitmap border in some other way? @timi_openoffice: Pls specify OS and platrorm with what you did your tests.
SuSE Linux 10.1 RC2 with both OOo Novell Edition and official 2.0.2 RPM. I'm using 32 bit software on 64 bit hardware. (I didn't specify it because I thougt that it's independend of the platform.)
pl->sj: Someone sets a clip region consisting of tons of little rectangles; this actually makes up the "stair effect" on the edge of the object. The stairs are not that much a problem (users don't usually go up to 6400% zoom), but those rectangles take up lots of space. If possible that clipregion should be a polygon instead.
>> The stairs are not that much a problem (users don't usually >> go up to 6400% zoom), but those rectangles take up lots of >> space. If possible that clipregion should be a polygon instead. Also, for giving the pdf to professional printers, that would be very nice ;-)
I can't change the fact that other programs are using clip regions a lot, but at least in our application we should try to use polygon clipping instead of using clip regions. sj->aw/thb: can you please take over this issue, because I think the problem is more a drawing layer problem.
AW: It's an AutoShape, so it uses XOutputDevice::SetFillAttr and then XOutputDevice::DrawXPolyPolygon. This uses XOutputDevice::DrawFillPolyPolygon where for XFILL_BITMAP different cases are implemented. Going to debugger...
AW: It's apinted as a SdrRectObj, so the chain is: > svx680mi.dll!XOutputDevice::ImpDrawFillPolyPolygon(const PolyPolygon & rPolyPoly={...}, unsigned char bRect=0, unsigned char bPrinter=0) Line 129 C++ svx680mi.dll!XOutputDevice::DrawFillPolyPolygon(const PolyPolygon & rPolyPoly={...}, unsigned char bRect=0) Line 123 C++ svx680mi.dll!XOutputDevice::DrawXPolygon(const XPolygon & rXPoly={...}) Line 312 + 0x1f bytes C++ svx680mi.dll!SdrRectObj::ImpDoPaintRectObj(XOutputDevice & rXOut={...}, const SdrPaintInfoRec & rInfoRec={...}, unsigned char bPaintFill=' ', unsigned char bPaintLine=' ') Line 389 C++ svx680mi.dll!SdrRectObj::DoPaintObject(XOutputDevice & rXOut={...}, const SdrPaintInfoRec & rInfoRec={...}) Line 443 C++ In _ximp.cxx ln 206: if( !pOut->GetPDFWriter() && XIMP_bDrawRasterOps ) is false. Seems like someone already added som PDF export code here which may be enchanced. Looking with CVS shows: Added from SJ for #103429# AW->SJ: Please have a look. Seems like #103429# caused this.
sj->aw: I do not think that the changes I made are wrong, removing them and you create nice raster ops for the pdf filter, which is also not good, because pdf is not raster ops capable. It would be nice if you can communitate things that needs to be enchanged more precisely.
AW->SJ: I digged into the bug, identified (and documented) what happens and found that at the place where method of drawing is decided already PDF specific code was added by You. I guessed that You may know better then what happens/is needed there. This may be wrong, but i still think my guess here is straightforward and reproducable.
sj->pl: The main problem is that the PDFWriter is storing clip regions by using the vcl/region class. Always when clip polygons are intersected against simple rectangles, tons of clip rectangles are created and each polygon information is lost. To fix this, the PDFWriter should try not to lose polygon clip information...
As discussed I'll have to change storing the clipregion not in a region but a basegfx::B2DPolyPolygon to prevent the Region from breaking to rectangles when the first merge comes.
target
sorry to delay this again, but time is scarce ...
and again :-(
fixed in CWS vcl109
Created attachment 67299 [details] newer bugdoc
the original bugdoc does not show the problem anymore due to drawinglayer changes, the attached new bugdoc however shows the problem still (and the fix in vcl109 of course :-) )
please verify in CWS vcl109
Verified with cws vcl109 = ok