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.
Build ID: 350m1(Build:2)
This product was supplied by The Document Foundation, Debian and Ubuntu.
(Ubuntu 12.04 Precise)
Just exported with LibreOffice 188.8.131.52 (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 184.108.40.206 (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 220.127.116.11.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
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 v18.104.22.168 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.
Created attachment 114538 [details]
Zip with examples of specific conditions that corrupt the PDF
If this can help: the fault is only in certain circumstances, for example here for a trapezoidal shape filled with a bitmap, and when other shapes are in particular conjunctions.
LibO 22.214.171.124 - Vista-32b
** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
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)
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: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Closing this one as duplicate to keep the list of tickets comprehensive.
*** This bug has been marked as a duplicate of bug 44731 ***
As I see, the bug 44731 differs from this bug. It's about PDF import to LO Draw and this one is about PDF export.