Created attachment 67160 [details] Drawing which demonstrates the bug in PDF export. See the attached Draw file. Export it as a PDF. Open in Okular or Acroread. Notice that the gradient has become black. Now delete the transparent blue region from the drawing and export again. Notice that it now exports the gradient properly. LibreOffice 3.5.4.2 Build ID: 350m1(Build:2) This product was supplied by The Document Foundation, Debian and Ubuntu. (Ubuntu 12.04 Precise)
Just exported with LibreOffice 3.5.4.2 (350m1(Build:2)) in Ubuntu 12.04 32-bit and opened with Evince (standard Ubuntu viewer). It looks the same as in Draw, with gradient. So, NOT confirmed.
OK, it only happens if you have PDF/A mode enabled. With that option disabled, the gradient exports properly.
In PDF/A - yes, but it says that the format doesn't support transparency thus it is deleted during export. Don't use transparency or don't use PDF/A. Do you really need them both?
Hold on, it's not the lack of transparency that I'm complaining about. I understand that. Adding a transparent object screws up a non-transparent object. That shouldn't happen. The gradient is clearly supported, because it works fine if there's no transparent object in the drawing. But adding one makes the gradient go black.
Chris, I agree that this is really a bug. I just wonder why do you need PDF/A. There are bugs which prevent of using new versions of LibO (bug 48409) but this bug doesn't prevent. I don't have idea why do you care about this bug and I really want to know.
I would like to use PDF/A mode because I think this is more standard version of the PDF format (well documented and widely implemented). I think that Adobe has a tendency to treat PDF as their own proprietary standard that they can extend as they see fit, and PDFs that use these features may not work in readers other than Adobe's (e.g. Evince, Okular, xpdf). So it seems comparable to using an open (or at least documented) document format such as ODT or RTF instead of Microsoft's latest abomination, in the interests of wider compatibility. If I am mistaken and PDF/A is not so useful then I would really like to know about it.
You're right that PDF/A is more compatible because it's an ISO 19005-1:2005 standard. But you're a bit mistaken fearing of new Adobe features when exporting a document from LibO. LibO can't have the newest incompatible features from Adobe. So I confirm that there's a bug of exporting to standard format, it's not good. I don't know if I have the right to change status of the bug. Do I? Confirmed with LibreOffice 3.5.4.2 (350m1(Build:2)) in Ubuntu 12.04 32-bit. BTW, there is another bug of exporting to all PDFs. You say that your gradient looks fine if you delete transparent object but it's not. Check bug 55698.
Confirmed with Libo Version 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)
confirmed in LibO 4.0.4 and 4.1.0. See also Bug 65439 PDF/A-1a saving corrupts gradients, while if you unflag the PDF/A-1a option saving is fine. I think that this transparency issue is a limit of the PDF/A-1a, so IMHO this is not a LibO bug. moreover you receive a warning telling that tranparent component could not be exported accurately.
I agree with comment #9 that transparency (and thus gradients) is not supported by PDF/A-1. According to Wikipedia (http://en.wikipedia.org/wiki/PDF/A) PDF/A-2 is required: >Transparent objects and layers (Optional Content Groups) are forbidden >in PDF/A-1, but they are supported in PDF/A-2. >The use of transparency is forbidden in PDF/A-1. The majority of PDF >generation tools that allow for PDF/A document compliance, such as the >PDF export in OpenOffice.org or PDF export tool in Microsoft Office 2007 >suites, will also make any transparent images in a given document >non-transparent. That restriction was removed in PDF/A-2. I do not have a copy of ISO 19005-1:2005 or ISO 19005-2:2011 to completely confirm this but it would seem indicative.
thanks Owen. this is the confirmation that it's not a LibO bug but a limitation of PDF/A-a1 format
Hi all, To repeat my earlier comment: "Hold on, it's not the lack of transparency that I'm complaining about. I understand that. Adding a transparent object screws up a non-transparent object. That shouldn't happen. The gradient is clearly supported, because it works fine if there's no transparent object in the drawing. But adding one makes the gradient go black." And kitaets commented in #5: "Chris, I agree that this is really a bug."
@ Owen Genat & tommy27 At first I argued with Chris because I had misunderstood him (as both of you). Maybe this bug is not very important but it's a bug.
@Chris and Kitaets ok. I misunderstood the situatuion. I changed bug summary to make clearer what the bug is about.
Created attachment 83870 [details] ZIP containing Inkscape SVG/PDF and Draw PDF/A-1a of Inscape SVG. Thanks Chris and kitaets for the clarification about the issue. I feel it would be helpful if we could obtain a PDF/A-1 document that contains a non-transparent gradient as a confirming example. The source does not need to be an LO document. I ask this because I am not sure how a non-transparent gradient is calculated and stored. Can anyone point to a definition of how a two-colour, non-transparent, single-gradient is calculated/stored? Do either layer use transparency? I can import an SVG created in Inkscape v0.48.3.1.r9886 (refer attached), which contains a basic gradient from 100% blue to 100% magenta and it exports from Draw v4.1.0.4 under GNU/Linux to PDF/A-1 without the blacking out effect in the original example. The resulting PDF does however suffer from incorrect angle of gradient and poor gradient quality. Can others create some two-colour, non-transparent, single-gradient object tests using different applications / graphic formats?
Seems confirmed - moving to NEW as REOPENED is not right.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.