Created attachment 115539 [details]
PPTX with radial gradient
The attached pptx has a radial gradient.
When exporting to PDF from impress, the gradient is converted to path and there are ellipses with white border.
Created attachment 115540 [details]
PDF exported from PowerPoint with the expected radial gradient
Created attachment 115675 [details]
PDF exported from LibO
issue confirmed under Win8x64 using LiO 220.127.116.11 and 18.104.22.168 alpha
see PDF output in the attachement and compare with MS PDF output
*** Bug 97770 has been marked as a duplicate of this bug. ***
Created attachment 122687 [details]
test Draw document Fontwork -- export to various formats, but quality issues with PDF and EPS
This export to PDF and EPS -- conversion of gradients to paths is visually coarse.
As in duplicate bug 97770 fontwork with radial or square gradient exported to PDF is of low quality. And the banding leads to moire effects with some of the gradients and shapes.
Attaching a sample Draw document with resulting exports, paths in PDF & EPS, and clean gradients for EMF/WMF/SVG, and for rasters PNG/BMP/JPEG
@Caolán, Armin, *
I know this is down in the guts of the export filters somewhere but is there a better way to render the gradients so they'd be smoother and less prone to moiré?
Other vector formats EMF/WMF and SVG seem to be unaffected--just PDF and EPS so isn't that ghostscript/cairo in some fashion...
Created attachment 122696 [details]
test Draw document Shape radial gradiant -- export to various formats
So, although not as glaring. SVG are also affected to some extent by the gradient area fills and do exhibit moiré as well.
Attached a sample Draw document with a scroll shape and gradient fill, and export to SVG that exhibits moire.
Created attachment 122698 [details]
attachement 122696 exported to SVG, viewing in a web browser will expose moiré
Checked example from comment 8, it contains a polygon usin ga fill pattern. The fill pattern is defined using geometry (not pixels), thus re-inserting to the office and breaking up will reveal the clipped fill pattern in geometry quality. What the browsers seem to do with fill patterns is to prepare them as bitmap tile, then render a tiled fill of it, probably for speed reasons. That single tile bitmap shows AA-ed edges of the contained ellipses. To make that more obvious you may change the gradient steps to 12 or so, export to svg again and check in the browsers.
Also a good test is to use inkscape, it also shows no moire. I do not say that often, but in this case the SVG export is not the reason, but more the browser's renderers.
To really make sure I checked inside the SVG file. It contains SVG fill patters which use path objects with simple fill color and no stroke, thus the moire really comes from some AAing of the browsers, there is *no* stroke defined for the pattern fill.
Still leads to that the SVG export creates no SVG gradients - as do ther exports. That is since SVG gradients do not 'reach' the exporter. We would need:
(1) SVG gradients in primitives (already tasks for that I think)
(2) SVG (and other) exports based on primitives, *not* on metafiles like now
(3) the exporter use the higher geometry definitions
Unfortunately a lot of work, bu tat least with the primitives the migration path is available and the current 'fallback' works as well as possible.
Still reproducible with LO 22.214.171.124.alpha1 on Ubuntu 16.04.
Still reproducible with LO 126.96.36.199.alpha0+ on Ubuntu 16.04.
** 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!
Reproducible with LibreOffice 188.8.131.52 30(Build:4) on Ubuntu 19.04.