|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | embedded svg graphic is printed wrong | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Draw | Reporter: | Regina Henschel <rb.henschel> | ||||
| Component: | printing | Assignee: | Armin Le Grand <Armin.Le.Grand> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | Normal | ||||||
| Priority: | P5 (lowest) | CC: | doneyourself, issues | ||||
| Version: | 3.4.0 Beta (OOo) | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
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. 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. ALG: Already wrote #112033# a while back, this would fix it. 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. 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#. getting rid of value "enhancement" for field "severity". For enhancement the field "issue type" shall be used. confirm fixing the bug on ver 1351249 in Win7 ,pass |
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.