Reproduced in

Version: 6.0.0.0.alpha0+
Build ID: 8abc7ba9784f7898576fbdd7a48f0ff9e4445a68
CPU threads: 4; OS: Linux 4.10; UI render: GL; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

[Bug found by office-interoperability-tools]

Regression introduced by:

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2017-08-22 08:05:15 (GMT)
committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2017-08-22 12:42:28 (GMT)
commit 302af8c2da58719844d22483b65a9fe5b3674684 (patch)
tree 9a0d81cb81e1130e9467f1e4de2077cea78c38f5
parent cc2cb0123ac599bf25c5e17b97b5d7bf93d3e487 (diff)
sw: Use primitive renderer for graphics
To allow using the prepared VectorData of imported
Metafiles (and EMF+), let Writer use a Primitive
Renderer for Graphic output. For now, use a temp
PrimitiveRenderer (until sw is fully adapted to
primitives).

Bisected with: bibisect-linux64-6.0

Adding Cc: to Armin Le Grand

Created attachment 136389 [details]
output after

Created attachment 136390 [details]
output before

Hi, looks like there is something messed up with the gradients and the clipping... I will investigate this bug!

Ok, first of all, in current master the rendering is completely fine, only the PDF export is affected. Therefore, the bug is somewhere is the decomposition/rendering in the drawinglayer processors. I will ask Armin for advise!

Not only PDF export, also preview in StartView (open doc, close again, quick selection of formally opened docs shows doc with same error) and in print preview (menu file/Print..., PagePreview). Seems to be a deeper error. After loading doc it is not clear what type of graphic this is - would be nice if Writer would say something about it in STatusBar as Draw/Imress/Calc does.

PrintPreview uses Metafile: In PrintDialog::PrintPreviewWindow::preparePreviewBitmap(). That MetaFile probably uses clip and polygon actions, but maybe also comment actions - needs to be debugged from here

Saw that the graphic is an OLE and indeed always the same internal decomposition of a GDI+ (not sure with the '+') is used - be it in repaint or PrintPreview. Just saw shortly that a InvertPrimitive2D is used in that content, so maybe that causes trouble - I am not sure how that might be recorded in a Metafile (that is recorded for PrintPreview).
Re-checked with PDF export, the same there. Problem seems to be HandleNewRasterOp in wmfemfhelper that creates a InvertPrimitive2D. That is more or less a placeholder, but the VclMetafileProcessor does not really do something with it except to process it's content.

I checked the bug in the last days a little bit. Armin seems right, there is something wrong the the precessing of the InvertPrimitive2D. The VclPixelProcessor2D catches the PRIMITIVE2D_ID_INVERTPRIMITIVE2D and applies some special treatment to the outdevice to enable Xor-drawing. 
In constrast, in VclMetafileProcessor2D, the primitive is processed without special treatment. This is used for PDF export and preview rendering. 

If I hack the code and copy the "case INVERTPRIMITIVE2D:" to the MetafileProcessor, at least the preview is fixed. which gives me the conclusion, the PDF export (...device?) cannot handle the special treatment.

Which EMF action is creating this invert primitive? Perhaps there's a better way to emulate it?

Failing that, I think the metafile processor can only do one thing - pre-scan the primitive list if there's crap like that, and then fallback to render everything into a bitmap. PDF in general can do raster ops (transparency groups, with some blend operations), but with quite some differences between versions (also, PDF/A1 IIRC forbids it).

Best chance is to avoid XOR completely, so if this is a gradient, chances are there to get it replaced with only using the EMF+. It may be one of the cases where the EMF+ parts replace the EMF, hopefully the XOR is in the EMF part. It may also be possible to 'restore' the orig gradient if that's different

Hi. To be honest, I am stuck here with this bug. Would it really be the best solution to fall back to the 'old' bitmap randerer if there is an XOR mask?

So indeed cloning the InvertPrimitive handling to the metafile processor seems the correct fix to me.

That the pdf export then is still faulty is not strictly speaking the same bug - it is a general omission on pdf export, that does not handle MetaRasterOpAction at all. You will hit similar problems with wmf/emf/svm files containing XOR or other ROPs.

A quick search did not turn out anything suitable, so I'd suggest to file a separate bug for the PDF export 'missing feature'. Implementation for that would need to go into pdfwriter_impl2.cxx's PDFWriterImpl::playMetafile() method (plus a member function writing a suitable transparency group or something to pdf).

The commit that introduced this issue was reverted in https://cgit.freedesktop.org/libreoffice/core/commit/?id=83baaec3a087f83d0ad3371d55671d9496771586