Bug 91252 - Export of area fill gradients to paths for PDF (and EPS) are too coarse
Summary: Export of area fill gradients to paths for PDF (and EPS) are too coarse
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.4.1.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf
: 97770 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2015-05-13 06:08 UTC by Ofir
Modified: 2019-08-13 22:35 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
PPTX with radial gradient (35.29 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2015-05-13 06:08 UTC, Ofir
Details
PDF exported from PowerPoint with the expected radial gradient (37.05 KB, application/pdf)
2015-05-13 06:09 UTC, Ofir
Details
PDF exported from LibO (210.73 KB, application/pdf)
2015-05-17 13:08 UTC, tommy27
Details
test Draw document Fontwork -- export to various formats, but quality issues with PDF and EPS (15.15 KB, application/vnd.oasis.opendocument.graphics)
2016-02-16 14:01 UTC, V Stuart Foote
Details
test Draw document Shape radial gradiant -- export to various formats (17.06 KB, application/vnd.oasis.opendocument.graphics)
2016-02-16 18:13 UTC, V Stuart Foote
Details
attachement 122696 exported to SVG, viewing in a web browser will expose moiré (2.20 MB, image/svg+xml)
2016-02-16 18:16 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ofir 2015-05-13 06:08:47 UTC
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.
Comment 1 Ofir 2015-05-13 06:09:39 UTC
Created attachment 115540 [details]
PDF exported from PowerPoint with the expected radial gradient
Comment 2 tommy27 2015-05-17 13:08:35 UTC
Created attachment 115675 [details]
PDF exported from LibO

issue confirmed under Win8x64 using LiO 4.4.1.2 and 5.0.0.0 alpha
see PDF output in the attachement and compare with MS PDF output
Comment 3 V Stuart Foote 2016-02-16 13:36:10 UTC
*** Bug 97770 has been marked as a duplicate of this bug. ***
Comment 4 V Stuart Foote 2016-02-16 14:01:24 UTC
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
Comment 5 V Stuart Foote 2016-02-16 14:24:38 UTC
@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...
Comment 6 V Stuart Foote 2016-02-16 18:04:58 UTC
*** Bug 97770 has been marked as a duplicate of this bug. ***
Comment 7 V Stuart Foote 2016-02-16 18:13:41 UTC
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.
Comment 8 V Stuart Foote 2016-02-16 18:16:29 UTC
Created attachment 122698 [details]
attachement 122696 exported to SVG, viewing in a web browser will expose moiré
Comment 9 Armin Le Grand 2016-02-25 12:22:57 UTC
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.
Comment 10 Ofir 2017-11-10 00:13:34 UTC
Still reproducible with LO 6.0.0.0.alpha1 on Ubuntu 16.04.
Comment 11 Ofir 2018-03-03 22:43:07 UTC
Still reproducible with LO  6.1.0.0.alpha0+ on Ubuntu 16.04.
Comment 12 QA Administrators 2019-03-04 03:53:15 UTC Comment hidden (obsolete)
Comment 13 Ofir 2019-08-13 22:35:04 UTC
Reproducible with LibreOffice 6.3.0.4 30(Build:4) on Ubuntu 19.04.