Issue 121591 - transparent filling of polygon is printed to wrong place
Summary: transparent filling of polygon is printed to wrong place
Alias: None
Product: Draw
Classification: Application
Component: printing (show other issues)
Version: 4.0.0-dev
Hardware: PC Windows, all
: P3 Normal (vote)
Target Milestone: 4.0.0
Assignee: AOO issues mailing list
QA Contact: Suchithra
Keywords: regression
Depends on:
Reported: 2013-01-07 13:54 UTC by Regina Henschel
Modified: 2013-07-12 16:34 UTC (History)
3 users (show)

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

Polygon with transparent filling (14.74 KB, application/
2013-01-07 13:54 UTC, Regina Henschel
no flags Details
Scan of the print result (94.50 KB, image/png)
2013-01-07 14:01 UTC, Regina Henschel
no flags Details
Minimalized sample (10.58 KB, application/
2013-05-28 10:54 UTC, Armin Le Grand
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2013-01-07 13:54:34 UTC
Created attachment 80106 [details]
Polygon with transparent filling

Print the attached document. Notice the filling is at the wrong place and is far too large.
Comment 1 Regina Henschel 2013-01-07 14:01:46 UTC
Created attachment 80107 [details]
Scan of the print result

The file printed on a HP Color LaserJet 2605dn on WinXP.
Comment 2 Armin Le Grand 2013-01-31 10:28:55 UTC
ALG: Can you try what happens with PDF export to see if it's a pure printing problem, remember the transparnce removal stuff when printing (or for PDF/1A). There is even an option somwhere which asks if the transparence shall be removed when printing. When not using removal, is it in the right place?
Comment 3 Regina Henschel 2013-01-31 15:18:16 UTC
The 'transparency' setting is in Tools > Options > > Print. The error can be seen, if the option "Reduce transparency" is off, or when it is on with the setting "automatic". The pdf export dialog has no transparency setting.

The print is correct with the setting "Reduce transparency" on and setting "No transparency". But in that case not the resulting color is used, but objects behind are hidden by the now non-transparent polygon.

In the export to pdf the filling is on the correct place and has the right colors, which means, that objects behind are visible as if the polygon is transparent.

Astonishingly the print is correct, if the polygon overlaps with another shape, but not, if the other shape is located beside the polygon.
Comment 4 Armin Le Grand 2013-01-31 15:29:54 UTC
ALG: Thanks, Regina. I asked for PDF/1A (or similar) format since there no transparency is allowed and the same code used in printing is applied to remove the transparencies from the output, so trying PDF/1A should lead to the same result.
Looks as if exactly that method which removes the transparency still has errors (after all that time, it came from a wise graphics guy who is now at another project), need to rewrite this to primitives one day.
The overlapping is not so astonishing in this area: Transparency removal exactly takes those aspects into account (the objects 'behind' need to show through a created, non-transparent partial bitmap)...
Comment 5 Rainer Bielefeld 2013-05-21 06:16:42 UTC
Reproducible with reporter's sample document and server installation of  "AOO 4.0.0-Dev – English UI / German locale [AOO400m1(Build:9700) -  Rev. 1484333 Rev.1483903 (2013-05-20)]" on WIN7 Home Premium (64bit)", own separate user profile

Problem is visible with Print to FreePDF printer, transparent filling area is at the bottom right corner of the sheet area and exceeds sheet in printout as shown in Regina's scan. Still looks ok an Print Preview in printing dialog.

Already reproducible with AOO  3.4.0

Was ok with OOo 3.1.1, os this is a Regression to Pre-3.4.0, I haven't a clue whether the keyword has to be used here.
Comment 6 Armin Le Grand 2013-05-28 10:54:02 UTC
Created attachment 80735 [details]
Minimalized sample

ALG: Reduced the sample; only top and left lines kept, no line at transparent polygon. Removing one of the lines makes it work.
Comment 7 Armin Le Grand 2013-05-28 11:02:48 UTC
ALG: OutputDevice::RemoveTransparenciesFromMetaFile is used, but even when avoiding it, the transparent polygon has a wrong offset.
Comment 8 Armin Le Grand 2013-05-28 13:47:21 UTC
ALG: Avoiding mapping creates offset, tried to use LogicToPixel or ImplLogicToDevicePixel with old PolyPolygon class instead, but creates the same error. This proves that ImplGetDeviceTransformation works well. Still no idea where the sometimes wrong mapping comes from. Also checked that the printer is 600 dpi and the GdiPlus device is 600 dpi, too.
Without the two lines (only the poly, no outline) it is correct with transparent mapping, incorrect without. When using pDisableNative with transparent mapping it is correct.
Same with AOO3.4 and OOo3.3.
Comment 9 Armin Le Grand 2013-05-28 16:11:55 UTC
ALG: This is really weird. The transparency mapping is needed, printers cannot draw transparent objects at all. If not mapped, bad quality will be the result. Of couse it should not be painted with an offset, still.
OOo2.2 offers to map transparencies, but even when not mapping, it produces a good result. Looked for the sources, but could not find anymore.
There *is* a fallback case for printers in OutputDevice::DrawTransparent in outdev6.cxx, but it only supports 4 stages of transparency by using the polygon as mask and painting hor/ver arrays of rectangles. This could be activated quickly to fix this, but gives no good print quality (besides that for good quality the transparency mapping *has* to be done).
This is anyways a Win-only thing, only there do we currently have extended GDIPlus stuff. The only GdiPlus commands used when printing is the transparent polygon. In principle, GdiPlus should not be used for printers, the mapping is not correct.
OTOH it *works* and produces nice transparency results, even without previous transparency mapping. I found out by experimenting that it is ofsetted by a factor of 100/DPIX and 100/DPIY in X/Y when the printer HDC with 600 dpi is used, but I am not sure why (maybe default for GdiPlus HDCs for printers, I checked that there is *no* transformation set, though). I can use this, correct the mapping and get the correct result. Thus I now need to check if there are drawbacks...
Comment 10 Armin Le Grand 2013-05-28 16:19:13 UTC
ALG: Checked with different printer DPIs (600, 1440), works with various ones, so could be done.
Comment 11 Armin Le Grand 2013-05-29 08:53:25 UTC
ALG: Also checked with various UI resolutions (just to make sure). The factor is stable, thus I could use it. Adapting...
Comment 12 Armin Le Grand 2013-05-29 09:53:19 UTC
ALG: Adapted, did some real test prints, looks good. Preparing checkin...
Comment 13 Armin Le Grand 2013-05-29 09:55:35 UTC
ALG: Okay, done.
Comment 14 SVN Robot 2013-05-29 10:04:32 UTC
"alg" committed SVN revision 1487427 into trunk:
i121591 Corrected some transparent printing stuff for windows