Apache OpenOffice (AOO) Bugzilla – Issue 10613
document printed wrong from writer, both to .ps file and printer
Last modified: 2013-08-07 14:43:23 UTC
I was working on a 17-page document and printing it to a .ps file from time to time. Suddenly some pages looked wrong. I've cut it to one page which doesn't work. If the contained image is eliminated, then it does work. I'll attach a .tgz archive which contains the document, the image and a screenshot of what 'wrong printing' means ( portions of text are messed up ). I've replicated this on two systems with Red Hat Linux 8.0. I tested printing to a real printer too, looks the same like in the screenshot.
Created attachment 4278 [details] .tgz archive with document, linked image and print screenshot
HI: The print on paper is like as the attached snapshot.
looks bad
*** Issue 4136 has been marked as a duplicate of this issue. ***
pl->thb: as discussed, the problem results from the two graphics that are printed as transparent BitmapEx which Printer::GetPreparedMetafile outputs as one large bitmap which is afterwards overlain by the real text.
Hm. The two bitmaps do have alpha channel, but it's all opaque. So, an easy workaround for the user would be to remove the alpha channel. Nevertheless, this is a bug and should not happen, will investigate ASAP.
I think the algorithm should be changed: currently it first gets all transparent objects and works on the whole bound rect, then adding all objects that intersect this bound rect. It should instead work on the single transparent objects only adding the obects in the metafile that intersects them thereby creating multiple transparency regions.
Well, the problem is that actually only a single bitmap is generated for transparent content (okay, it's banded for printing, but essentially it's only one bitmap). Thus, if for the worst case two tiny transparent icons reside top-left and bottom-right on a page, the whole page is rendered as a bitmap. Shudder. Have to determine all distinct transitive closures of intersecting objects, where at least one of them is transparent.
Fixed so far, although not yet the optimal solution. Sadly, had to increase worst-cast time complexity from O(n^2) to O(n^3). But I'm positive that it's possible to reduce that to O(n^2) when exploiting the 2D topology.
*** Issue 9180 has been marked as a duplicate of this issue. ***
Verifying in apps01...
Verified on apps01. This is a general printing bug, should maybe tested in the other applications, too.
Fixed
Verified with 644m3s1_8536 (cws:apps01).
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.
*** Issue 11444 has been marked as a duplicate of this issue. ***
*** Issue 13010 has been marked as a duplicate of this issue. ***
*** Issue 11429 has been marked as a duplicate of this issue. ***
*** Issue 14322 has been marked as a duplicate of this issue. ***