Bug 112513 - FILESAVE: PDF: EMF+: Incorrect shape and gradient rasterized
Summary: FILESAVE: PDF: EMF+: Incorrect shape and gradient rasterized
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-EMFPlus-Rework
  Show dependency treegraph
Reported: 2017-09-20 09:10 UTC by Xisco Faulí
Modified: 2020-08-23 13:01 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

output after (282.69 KB, application/pdf)
2017-09-20 09:13 UTC, Xisco Faulí
output before (16.00 KB, application/pdf)
2017-09-20 09:14 UTC, Xisco Faulí

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2017-09-20 09:10:19 UTC
Steps to reproduce:
1. Open attachment 64266 [details] from bug 52145
2. export to PDF
3. Check output

Observed behaviour: Circle is a square and gradient is rastirized
Comment 1 Xisco Faulí 2017-09-20 09:10:43 UTC
Reproduced in

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]
Comment 2 Xisco Faulí 2017-09-20 09:12:36 UTC
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

Bisected with: bibisect-linux64-6.0

Adding Cc: to Armin Le Grand
Comment 3 Xisco Faulí 2017-09-20 09:13:12 UTC
Created attachment 136389 [details]
output after
Comment 4 Xisco Faulí 2017-09-20 09:14:21 UTC
Created attachment 136390 [details]
output before
Comment 5 Patrick Jaap 2017-09-20 17:12:30 UTC
Hi, looks like there is something messed up with the gradients and the clipping... I will investigate this bug!
Comment 6 Patrick Jaap 2017-09-26 13:04:18 UTC
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!
Comment 7 Armin Le Grand 2017-09-27 07:30:48 UTC
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.
Comment 8 Armin Le Grand 2017-09-27 07:55:21 UTC
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
Comment 9 Armin Le Grand 2017-09-27 09:25:45 UTC
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.
Comment 10 Patrick Jaap 2017-10-10 16:04:26 UTC
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.
Comment 11 Thorsten Behrens (allotropia) 2017-10-17 21:55:15 UTC
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).
Comment 12 Armin Le Grand 2017-10-18 07:33:05 UTC
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
Comment 13 Patrick Jaap 2017-10-26 09:52:30 UTC
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?
Comment 14 Thorsten Behrens (allotropia) 2017-10-26 11:57:12 UTC
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).
Comment 15 QA Administrators 2019-03-01 03:50:14 UTC Comment hidden (obsolete)
Comment 16 Xisco Faulí 2019-10-24 09:35:41 UTC
The commit that introduced this issue was reverted in https://cgit.freedesktop.org/libreoffice/core/commit/?id=83baaec3a087f83d0ad3371d55671d9496771586