https://issues.apache.org/ooo/show_bug.cgi?id=121591
Armin Le Grand <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |ACCEPTED --- Comment #9 from Armin Le Grand <[email protected]> --- 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... -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
