Apache OpenOffice (AOO) Bugzilla – Issue 20085
wmf image badly exported to pdf
Last modified: 2013-08-07 14:43:45 UTC
when exporting the wmf (see attachment) to pdf, you'll get a black box instead of the transparency. But the writer displays it correctly. And print preview is okay, too.
Created attachment 9667 [details] example file with wmf inside
Created attachment 9668 [details] the result by exporting to pdf
I can Reproduce the problem on OpenOffice 1.1 (default Install, US), Win XP Pro Sp1. (And MS Office XP Sp2). It is real problem when exporting the file to pdf, the transparency is gone. Look at the Chain image.
OOo 1.1.1 approved by TZ
pl->sj: This is actually not a PDF export bug, it happens also when printing. The reason for the black rectangle around the chain element is that the chain element is actually drawn as three bitmaps; first a BitmapEx, then a Bitmap, then a BitmapEx again. The middle operation is obviously the culprit: it should be an BitmapEx with black as transparent color (setting the corresponding transparence in PDFExport::ImplWriteBitmapEx solves the problem). As far as i can see the Metafile contains a META_BMPSCALE_ACTION where it should probably be a META_BMPEXSCALE_ACTION; this IMHO means that the paint routine of the application uses DrawBitmap where it should DrawBitmapEx; alternatively this may be inside the WMF import. Could you please look into this and dispatch to the appropriate developer ?
SJ->THB: It seems that we have some problems with rasterops. Can you please takeover this bug.
Yep, it's indeed a raster op problem. Actually, a pattern raster op is involved here, for which we don't have any workaround in place currently (for src/dst only ROPs, we have). Evaluating the semantics at the moment.
The problematic place is winmtf.cxx::1648, and I'm currently unsure about how to tackle this problem. Generally speaking, appearance of raster ops in GDI metafiles _cannot_ be avoided with the existing architecture, except one renders large parts of an imported WMF/EMF into a bitmap of predetermined size (_not_ an option, since WMF/EMF should remain resolution-independent). Thus, to address this problem once and for all, one would have to emulate raster ops during printing/PDF output, generating bitmaps there (at least for printing, one knows the target resolution in advance). PDF output at least has a predetermined 'target audience' (screen, print, or publishing), which also implies a resolution. But that is a major endeavour, I'm unwilling to take for 1.1.1. Maybe I can come up with a symptomatic fix for the described case, getting back to that next week latest.
Okay, I think I've got it. The pattern issue is a decoy, regardless of pattern support emulated or not, the result is the same. The crucial point here is that OutputDevice does not support an OR raster operation. This has to be emulated by an XOR followed by an explicit 'everywhere where source has one-bits, also set target one bit' step (a and not b or not a and b or a and b). This XOR now is a no-op both on printer and during pdf export, and just paints the bitmap as-is, which happens to be black outside the chain symbol. Problem is, it's unavoidable to do it like this, since in general, I don't know what's behind the bitmap. Although, in this special case, there's a sequence of two bitmaps painted, of exactly the same size at the same output position. The ROPs are SRCAND followed by SRCPAINT, which, incidentally, is exactly swapped order of a case already handled. Thus, I can interpret the first bitmap as a mask, and the second as the image, compose both into a BitmapEx, and am done with this problem.
Please verify the fix.
change the resolution to fixed.
CGU: Verified in cws draw23 on Sols, Lin, Win.
The fix is integrated in OOo1.1.1 on Sols, Lin, Win. This version will be available soon.
Reopened to integrate fix into SRC680 MWS.
Reassigned to person who fixed this bug.
As this is fixed for 1.1.1, can we change the target to 2.0 now?
THB->CGU: Also fixed in SRC680 draw23master, please verify.
Reassigned
CGU: Cloned the task for integration in OOo2.0 Id of the cloned task is issue 25374 I close the issue
verified in OOo1.1.1
I close the issue.
I reope nthe issue to test the integration in OOo2.0
target OOo 2.0
This issue is duplicated for integration in OOo 2.0 Therefore I set the target back to OOo 1.1.1 and change the resolution to Verified.
I close this issue