Issue 118730 - embedded svg graphic is printed wrong
Summary: embedded svg graphic is printed wrong
Alias: None
Product: Draw
Classification: Application
Component: printing (show other issues)
Version: 3.4.0 Beta (OOo)
Hardware: PC Windows XP
: P5 (lowest) Normal (vote)
Target Milestone: ---
Assignee: Armin Le Grand
QA Contact:
Depends on:
Reported: 2012-01-05 16:48 UTC by Regina Henschel
Modified: 2012-06-25 06:49 UTC (History)
2 users (show)

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

2test documents and result of pdf export (438.58 KB, application/x-zip-compressed)
2012-01-05 16:48 UTC, Regina Henschel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2012-01-05 16:48:46 UTC
Created attachment 77103 [details]
2test documents and result of pdf export

The attached zip contains a Draw and a Writer document with embedded svg graphics and the result of the export to pdf. The export to pdf has been done with "Lossless compression".
Notice, that the graphics are wrong in the pdf-file. I see the same error, when I print the Draw or Writer document to my HP Color Laserjet 2605dn.
It looks, as if the function graphs in the graphics have a white background and therefore hide the parts behind them. The documents look correct on screen.
Comment 1 Regina Henschel 2012-01-05 18:30:05 UTC
A similar error happens, when you convert the svg to curve, polygon, or metafile, or when you break the svg. Instead of getting a group of short lines for the function graphs (the colored lines), draw objects are generated which have a bitmap background and this bitmap has the painted function graph.
Comment 2 Armin Le Grand 2012-01-11 15:34:51 UTC
ALG: Reason identified, it's the (old) converion from Metafile to SdrObjects. In the first step the primitives get converted to a metafile which is not too bad, just losing some precision. Unfortunately the Svg contains clip paths, originally the curves are longer than the rasters. I can imagine that the programmer (whoever/whatever app is creating this) saved some work by not needing to exactly calculate that curves. The metafile gets the correct ClipRegions (the old Vcl ones). In a 2nd step this metafile gets converted to SdrObjects. In that (very old) step there is no good handling of ClipRegions, it tries to solve the problem by painting the clipped stuff to a bitmap. This works, but of course uses a bad resolution and no transparency. Sigh.
We currently have no more up-to-date converter to primitives despite I'm planning to write one for some time already. Of course a new one would just clip the geometry when a clip region is used and try to stay completely on the vector side of things.
I'll check if I can make the old stuff a little bit smarter concerning handling of ClipRegions, but I'm not sure this is possible.
Comment 3 Armin Le Grand 2012-01-12 16:03:22 UTC
ALG: Already wrote #112033# a while back, this would fix it.
Comment 4 Armin Le Grand 2012-01-13 16:53:12 UTC
ALG: Found another reason in Svg import: SvgClipPathNode used TransparencePrimitive2D to create the clipped primitive entry, by painting the clip definition as black, thus only that part being visible. This worked, but the definition allowed the conversion to metafile to transform it to a Bitmap where the visible part was filled white. This is not intended and I now changed this to use a MaskPrimitive2D as required, creating the needed clipPath from primitives by using drawinglayer::processor2d::ContourExtractor2D and merging (if needed) the received geometry. This makes the created metafile more convenient and the Break to SdrObjects better; just the old break mechanism (see #112033#) does not support ClipRegions.

ALG: I tend to use the above correction to fix this task and to point to #112033# for adding clipping to the objects created.
Comment 5 Armin Le Grand 2012-01-13 17:29:55 UTC
ALG: Comitted, done. Break and print use vector graphic now, no longer converting parts of the content to bitmaps. For the missing clipping of the lines see #112033#.
Comment 6 Oliver-Rainer Wittmann 2012-06-13 12:29:06 UTC
getting rid of value "enhancement" for field "severity".
For enhancement the field "issue type" shall be used.
Comment 7 liuping 2012-06-25 06:49:28 UTC
confirm fixing the bug on ver 1351249 in Win7 ,pass