Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Gradients have artifacts in pdf and slideshow|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||ace_dent, Armin.Le.Grand, ccheney, h.ilter, issues, rjksmith, skywalk|
|Target Milestone:||OOo 3.x|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description andreasm82 2006-05-31 17:08:19 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
Comment 2 andreasm82 2006-05-31 17:15:42 UTC
Created attachment 36839 [details] the pdf file, the file is also very big!
Comment 3 michael.ruess 2006-06-01 08:50:18 UTC
Reassigned to HI.
Comment 4 h.ilter 2006-06-01 09:35:42 UTC
HI->PL: The view and performance is better with Adobe Acrobat 5.0 than Adobe Reader 7.0
Comment 5 philipp.lohmann 2006-06-01 10:12:43 UTC
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.
Comment 6 philipp.lohmann 2006-06-15 16:20:03 UTC
Comment 7 ace_dent 2006-06-28 13:34:20 UTC
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
Comment 8 ace_dent 2006-06-28 13:35:11 UTC
Created attachment 37392 [details] Test case with gradient background image
Comment 9 ace_dent 2006-06-28 13:36:25 UTC
Created attachment 37393 [details] Exported PDF by Impress. Bug: white lines
Comment 10 ace_dent 2006-06-28 13:37:13 UTC
Created attachment 37394 [details] PDF created with Acrobat6: Better gradient, smaller file
Comment 11 ace_dent 2007-07-06 09:45:10 UTC
The problem with gradients exported as quantized polygons, is also described in Issue 13352.
Comment 12 bjoern.milcke 2007-08-21 12:52:00 UTC
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
Comment 13 philipp.lohmann 2007-10-19 14:51:33 UTC
adjusting target due to limited resources
Comment 14 stderr 2008-12-02 13:24:26 UTC
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
Comment 15 andreschnabel 2009-01-17 10:04:18 UTC
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)
Comment 16 clippka 2009-10-14 09:09:51 UTC
*** Issue 105857 has been marked as a duplicate of this issue. ***
Comment 17 clippka 2009-10-14 09:11:55 UTC
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...
Comment 18 Armin Le Grand 2009-10-21 14:05:26 UTC
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!
Comment 19 philipp.lohmann 2010-02-10 17:19:07 UTC
*** Issue 108484 has been marked as a duplicate of this issue. ***
Comment 20 florut 2010-02-16 10:39:01 UTC
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
Comment 21 florut 2010-02-16 10:55:13 UTC
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.
Comment 22 philipp.lohmann 2010-02-16 10:56:50 UTC
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.
Comment 23 florut 2010-02-16 11:21:28 UTC
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!!)
Comment 24 ace_dent 2010-02-16 12:31:42 UTC
@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.
Comment 25 philipp.lohmann 2010-06-04 13:33:53 UTC
Comment 26 philipp.lohmann 2010-12-09 19:06:29 UTC
fixed in CWS vcl118
Comment 27 philipp.lohmann 2011-01-20 17:01:26 UTC
please verify in CWS vcl118
Comment 28 h.ilter 2011-02-01 14:45:34 UTC
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.
Comment 29 h.ilter 2011-02-01 14:46:53 UTC
Comment 30 philipp.lohmann 2011-02-08 14:24:17 UTC
Resetting target accroding to new task handling scheme announced here: http://blogs.sun.com/ratte/entry/some_changes_for_the_openoffice
Comment 31 Brian Wright 2013-06-30 07:02:34 UTC
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.
Comment 32 Armin Le Grand 2013-07-01 08:43:02 UTC
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..
Comment 33 Marcus 2017-05-20 11:27:41 UTC
Reset assigne to the default "firstname.lastname@example.org".
Comment 34 R Smith 2018-02-09 14:55:48 UTC
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.