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
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)
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
Created attachment 136389 [details]
Created attachment 136390 [details]
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).
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
The commit that introduced this issue was reverted in https://cgit.freedesktop.org/libreoffice/core/commit/?id=83baaec3a087f83d0ad3371d55671d9496771586