Issue 65128 - Outline of drawing objects consists of pixels of background is an image
Summary: Outline of drawing objects consists of pixels of background is an image
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.2
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: h.ilter
QA Contact: issues@gsl
Keywords: oooqa
Depends on:
Reported: 2006-05-06 10:51 UTC by timi_openoffice
Modified: 2017-05-20 10:23 UTC (History)
3 users (show)

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

the odg file (26.08 KB, application/vnd.sun.xml.draw)
2006-05-06 10:53 UTC, timi_openoffice
no flags Details
resulting pdf (29.89 KB, application/pdf)
2006-05-06 10:53 UTC, timi_openoffice
no flags Details
screenshot (84.41 KB, image/png)
2006-05-06 10:54 UTC, timi_openoffice
no flags Details
newer bugdoc (11.65 KB, application/
2010-01-19 17:38 UTC, philipp.lohmann
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description timi_openoffice 2006-05-06 10:51:38 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.
Comment 1 timi_openoffice 2006-05-06 10:53:02 UTC
Created attachment 36293 [details]
the odg file
Comment 2 timi_openoffice 2006-05-06 10:53:29 UTC
Created attachment 36294 [details]
resulting pdf
Comment 3 timi_openoffice 2006-05-06 10:54:05 UTC
Created attachment 36295 [details]
Comment 4 Rainer Bielefeld 2006-05-06 12:05:20 UTC
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?

Pls specify OS and platrorm with what you did your tests.
Comment 5 timi_openoffice 2006-05-06 12:26:02 UTC
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.)
Comment 6 philipp.lohmann 2006-05-08 09:46:54 UTC
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.
Comment 7 timi_openoffice 2006-05-08 14:52:43 UTC
>> 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 ;-)
Comment 8 sven.jacobi 2006-11-03 14:17:21 UTC
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.
Comment 9 Armin Le Grand 2006-11-03 14:51:14 UTC
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...
Comment 10 Armin Le Grand 2006-11-03 15:17:49 UTC
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.
Comment 11 sven.jacobi 2006-11-03 16:38:12 UTC
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
Comment 12 Armin Le Grand 2006-11-06 09:55:01 UTC
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.
Comment 13 sven.jacobi 2007-01-22 18:05:52 UTC
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

To fix this, the PDFWriter should try not to lose polygon clip information...

Comment 14 philipp.lohmann 2007-01-23 09:57:29 UTC
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.
Comment 15 philipp.lohmann 2008-03-11 13:35:14 UTC
Comment 16 philipp.lohmann 2009-01-06 17:06:44 UTC
sorry to delay this again, but time is scarce ...
Comment 17 philipp.lohmann 2009-09-05 15:44:55 UTC
and again :-(
Comment 18 philipp.lohmann 2010-01-19 17:31:10 UTC
fixed in CWS vcl109
Comment 19 philipp.lohmann 2010-01-19 17:38:14 UTC
Created attachment 67299 [details]
newer bugdoc
Comment 20 philipp.lohmann 2010-01-19 17:39:49 UTC
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 :-) )
Comment 21 philipp.lohmann 2010-02-19 14:14:55 UTC
please verify in CWS vcl109
Comment 22 h.ilter 2010-03-04 14:40:08 UTC
Verified with cws vcl109 = ok