Apache OpenOffice (AOO) Bugzilla – Issue 65970
Gradients have artifacts in pdf and slideshow
Last modified: 2018-02-09 14:55:48 UTC
Please take a look at attached files. The red circle displays very slow in Adobe Reader and Foxitreader. It also uses 100% cpu and looks very bad :( Everything looks well in openoffice! So it seems to be a problem of the export-feature in openoffice. using openoffice 2.0.3 RC4 german
Created attachment 36837 [details] the document
Created attachment 36839 [details] the pdf file, the file is also very big!
Reassigned to HI.
HI->PL: The view and performance is better with Adobe Acrobat 5.0 than Adobe Reader 7.0
Actually i don't see what you mean by "looks bad". please elaborate. As to the slowness: the circular gradient used is rendered as many small rectangles (as one would do on a pixel device). This explains the slowness as well as the size of the resulting PDF. If possible we should support gradients in a more effective way.
target
Using OOo Impress 2.0.2 and 2.0.3RC6. Changed Summary and Component to better reflect problem. Attached is a more 'business' realistic test case. For posters I work in Powerpoint using a template containing a background graphic, originally generated with Visio2003, but imported as a standard MS 'Picture'. This displays fine in Impress. However, the exported PDF could be better (compare Impress to Acrobat outputs). OOo converts the gradient into sections of uniform colour, with the following problems: - Very fine white lines can be seen between the gradient steps, which is not visually acceptable. - The resulting complexity of the drawing causes increased CPU load while rendering the PDF and increased file sizes (~150% larger in this test case). The white gaps between the gradient steps is a Defect; maybe another problem with PDF export accuracy /rounding? As a future Enhancement, more efficient handling of gradients would be nice. I have adjusted the Target to 2.x to keep this bug on the 'radar'. Hope that doesn't offend. Regards, Andrew
Created attachment 37392 [details] Test case with gradient background image
Created attachment 37393 [details] Exported PDF by Impress. Bug: white lines
Created attachment 37394 [details] PDF created with Acrobat6: Better gradient, smaller file
The problem with gradients exported as quantized polygons, is also described in Issue 13352.
Created attachment 47669 [details] There are also breaks in linear gradients. This png was created with Mac's Preview from a pdf exported by OOo
adjusting target due to limited resources
If anyone has any workaround *at all* for the linear gradient issue, I'd be most grateful to hear them! My seminar slides are currently stuck in ODP and going nowhere... Sofar as I can see, the consequence of this bug is that I can't use gradients in anything that I may later want to export to PDF... is there honestly no workaround? 3rd party conversion tools? Anything? :s
possible workaround: - create a square (drawing element) of the size of your presentation slide (use impress or draw) - set gradient background for that square - export this square to .png - use this .png as background image for your presentation (you may import the .png in background settings for any drawing object - unfortunately not in the slide background settings)
*** Issue 105857 has been marked as a duplicate of this issue. ***
changing summary as this is not only a pdf problem. @cl->pl,aw: I think this is a major annoyance so I set target to 3.3. For me this looks like an aa-artifact. Can we turn of aa while rendering gradients? Should not make much quality impact for gradients anyway...
AW: Looked for some infos. The VclMetafileProcessor2D produces a MetaFile containing a direct call to mpOutputDevice->DrawGradient, embedded from a SvtGraphicFill. Should be the same as before primitives. The call to mpOutputDevice->DrawGradient creates a XGRAD_SEQ_BEGIN/XGRAD_SEQ_END encapsulated content for MetaFile (see OutputDevice::DrawGradient, if( mpMetaFile ). In PDFExport::ImplWriteActions the SvtGraphicFill for the gradient (enc by XPATHFILL_SEQ_BEGIN, XPATHFILL_SEQ_END, see META_COMMENT_ACTION section) is not used sice SvtGraphicFill::fillGradient is not supported. The contained info is not skipped, but executed. There, the XGRAD_SEQ_BEGIN/XGRAD_SEQ_END is used (see .CompareIgnoreCaseToAscii( "XGRAD_SEQ_BEGIN" )). This filters for a MetaGradientExAction and ignores the rest. The MetaGradientExAction is then used in PDFExport::ImplWriteGradient. There, first AddGradientActions is used to produce the filled polygons. Then a IntersectClipRegion is used to mask for the filled PolyPolygon. AW->PL: I do not know what IntersectClipRegion in PDFExport::ImplWriteGradient does, but maybe it creates 'many small rectangles' as described..? At least, the same happens with versions before Primitives and AA, thus it's definitely not AA relicts or decomposition problems. HTH!
*** Issue 108484 has been marked as a duplicate of this issue. ***
Using ooo 3.2 (but previous versions also) in Writer and Draw module I also observed artefacts in gradients for exported pdf (vertical white stripes for horizontal gradients). Please notice that the issue is the same when using integrated PDF export feature OR cups-pdf OR by printing in a PS file ON LINUX. The problem does not appear in WINDOWS either using integrated PDF export or pdfcreator. That is why I suspect something between OOO and GHOSTCRIPT !? Guys, do you observe the same things
BTW I forgot to tell that the windows-version that works under MS Windows was 3.2 either. I would also add that the issue is the same using this Windows-version in WINE.
This is a visualization artifact of the PDF reader; turn off antialiasing for line art and the problems diminish (e.g. in adobe reader switch off "smooth line art"). However we need a more permanent solution.
You are right. With a PDF file created under OOO/LINUX, gradients displays artefacts in Okular, Gimp/Linux. A bit less (depends on the zoom) with Foxit under Linux. The exact same PDF file shows OK under Windows/FoxitReader (VirtualBox) for zooms modes above 50%. Under 50% artefacts are coming. The same PDF doc but created from OOO/Windows displays well no matter the zoom mode. I did not find a way to disable anti-aliasing (...for "line-art"!?) in Okular neither Foxit, but anyway this issue is really annoying (I'm talking about my Resume, I cannot bet on the way it'll be displayed on my potential employer!!)
@pl, while this may be a visualization problem too, the Defect is the very inefficient creation of gradients as individual artwork. As you commented, gradients should be supported more efficiently.
fixed in CWS vcl118
please verify in CWS vcl118
Verified with cws vcl118 = Fixed but failed. The fix makes the quality worse from bugdoc: looksbad.odt to PDF Issue will be removed from cws list and reopened as new.
Reassigned back
Resetting target accroding to new task handling scheme announced here: http://blogs.sun.com/ratte/entry/some_changes_for_the_openoffice
Any ETA on getting this worked into a new release? The gradient appears fine when creating slides. Whenever I present with gradients on a Mac, the gradient is marred by odd lines and artifacts. It's not limited to just the creation of PDF files, although it does cause problems there too. The effect is very pronounced with a linear vertical gradient progressing from white to a pastel purple. I'm on version 3.4.1 and the issue is still present. Happy to provide example screenshot if needed.
ALG: Hi Brian, tkanks for remembering on this one. AOO4.0 is close, so it will not be doable there, but I have some plans which would prevent that stuff from happening in the future. Grepping for later..
Reset assigne to the default "issues@openoffice.apache.org".
This has been outstanding for a very long time, and is still a problem in v4.1.1. The background gradient is effectively useless for PDF presentations, and would be a great feature if it worked. Please fix it.