[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #67 from James Cloos cl...@jhcloos.com --- The hard part is when they only partially overlap. The code needs to trace the outlines of the overlapping portions and generate new opaque objects to paint over those areas. I might be reading this wrong, but it sounds like you're describing a behavior similar to bug 61306 and bug 42442. The anomalies reported in those BZs appear to be due to using too-little precision in the coordinates in the exported pdf. Eg, the businesscards.pdf attached to bug 42442 uses only decipoints in vector art streams. That evidently is imprecise enough for the edges to misalign at even 600 dpi. Rounding instead to centipoints might be enough to avoid those even when directly exposing offset plates at 150 dots/mm. Or it might require millpoints. Higher precision would mean larger, slower files. Finding the optimal tradeoff for a large, varied user base is at best difficult. I expect that is why some products offer multiple quality targets, such as Draft, Web, Office, Litho, et cetera. It would be interesting, though, to see whether centipoints are enough. The vector-transparency-flattening algorithm I described in the previous comment relates to those two bugs only in that one risks similaranomalies unless one uses sufficient precision, with the same size and speed tradeoffs I mention above. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #61 from jwoithe jwoi...@just42.net --- In reply to comment 60: CUPS is not a renderrer. Yes, true. I was using the term loosely. Processor might have been a better term. The point being that the issue affected more than just viewers which is why I was using a more generic term. One of the comments, noted that lo sent a pdf to cups, and that he was printing to a postscript printer. That implies that cups converted from pdf to ps. For that conversion, depending on the distribution, it will use one of ghostscript, poppler or xpdf. That was probably in response to my comment (comment 34). I haven't looked that the data flow that closely. The observation was simply that doing File|Print to these two colour printers (which were postscript printers) resulted in a greyscale rectangle. It was only later that I came to be aware that LO was sending PDF to the printer system now, which provided a connection between PDF viewers and printer output. For reference, on Slackware 13.x CUPS's pdftops is a binary which calls /usr/bin/pdftops, which is provided by poppler 0.16.4 on this distribution. Because postscript does not support transparency, each of those will render any pages which include transparency to a pixmap encased in postscript. Ok, I didn't know that. However, the fact remains that regardless of what does this conversion, it used to work. Something changed in LO 3.5 (or perhaps earlier) which broke it. Current versions of ghostscript and poppler get it right. (Note that poppler is based on xpdf; its pdftops on xpdf’s pdftops, and its splash display engine – used, eg, by occular – on xpdf.) The bug probably was specific to xpdf. Note that moving to LO 4.1 without changing anything else on the system made CUPS work correctly while xpdf was still broken - see comment 53. Also, I'm not entirely clear on the relationship but my understanding is that poppler is effectively a fork of xpdf's processing engine and that the code bases are diverging. I think that most people consider xpdf and poppler to be distinct projects now with separate codebases. It is entirely possible that the issue is common to both due to the common ancestry, but addressing it in one will not address it in the other. Affected systems may be able to avoid that bug by configuring cups’ pdftops filter to call ghostscript rather than pdftops(1) ... Since it's a compile-time option this is a good suggestion for people to try if they have the resources and ability to recompile CUPS. Most users would not fall into this category. Someone on an affected system should test whether their local ghostscript can render the pdf to an image file (png256 gives a good test). On Slackware 13.37, gs -q -sDEVICE=png256 -SOutputFile=- -dNOPAUSE -dBATCH foo.pdf where foo.pdf was attachment 75026 seemed to work (which makes gv's failure as per comment 34 on the same system all the more interesting). Beyond that, mupdf is a better viewer than xpdf; it is at least as small, fast and efficient. Agreed - mupdf looks promising. Unfortunately to date I have not been able to find an easy to use GUI wrapper for it under Linux (the Android viewer is more complete in this regard). Their default Linux viewer is functional and is something I could use, but it falls short of what I can reasonably expect general users to use. There also is gv, which uses gs to do the rendering. As detailed in comment 34, gv 3.7.1 on Slackware 13.37 with gs 9.02 crashes when fed the test PDF. It may work on other systems, but it wasn't a feasible workaround for me. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #62 from James Cloos cl...@jhcloos.com --- Something changed in LO 3.5 (or perhaps earlier) which broke it. If that is when LO started sending pdf instead of postscript, that probably is the change which triggered this bug. If it sends postscript, it has to flatten the transparency itself. Whether it was able still to send vector art, or just sent a pixmap, by avoiding pdftops it avoided the bug. my understanding is that poppler is effectively a fork of xpdf's processing engine and that the code bases arediverging Yes. And the engine xpdf uses for display is different that the one it uses to generate postscript. Poppler’s splash backend is based on the former, and its pdftops (as you’d expect) on the latter. Since it's a compile-time option this is a good suggestion for people to try if they have the resources and ability to recompile CUPS. Most users would not fall into this category. If the filter calls /usr/bin/pdftops (as it normally does), one could replace /usr/bin/pdftops with a script which instead calls ghostscript. Something based on pdf2ps, but accepting pdftops’s args. Note that moving to LO 4.1 without changing anything else on the system made CUPS work correctly while xpdf was still broken If the printer was a ps printer, that implies that older pdftops and xpdf had/have different bugs with transparency. On Slackware 13.37, gs -q -sDEVICE=png256 -SOutputFile=- -dNOPAUSE -dBATCH foo.pdf where foo.pdf was attachment 75026 seemed to work (which makes gv's failure as per comment 34 on the same system all the more interesting). Gv probably used gs’s x11alpha device; there have been improvements to that device since 9.02 (at least a couple were mine). As detailed in comment 34, gv 3.7.1 on Slackware 13.37 with gs 9.02 crashes when fed the test PDF. I hadn’t gotten that far reading the comments Long bz! Looking at pdf generated by 4.2.1.1, I don’t see anything in it which should be controversial. The best LO could do is offer an option on export and printing to flatten transparency. That involves breaking apart overlapping non- opaque objects into separate objects for each final colour, and specifying those colors in the exported file. That will have the side effect of converting any affected text into outlines. But purely opaque objects would export unchanged. That, whether pdf or ps, should pass w/o harm through the affected consumers. It needs to be an option because, for some exporting the transparency to the pdf is important. Such as when the pdf is to be included in some other document. There are open feature requests for poppler and ghostscript to do that type of flattening when converting to postscript, but it should be an easier enhancement for lo, given that lo works with higher-level objects. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 Michael Meeks michael.me...@collabora.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #63 from Michael Meeks michael.me...@collabora.com --- Hi James; great to have a CUPS / ghostscript / PDF hacker commenting at last :-) Thanks for the great input Looking at pdf generated by 4.2.1.1, I don’t see anything in it which should be controversial. Glad you don't see anything objectionable in our PDF stream =) As such I will close this as NOTOURBUG - agreed - not the perfect resolution, but this points to it. The best LO could do is offer an option on export and printing to ... This would be a great feature request to file; I'm not sure that people will love to file it, but perhaps there is indeed code to identify which pieces of the page to bitmap-ify, though there really is a reason why we prefer a meta-file format that handles transparency well ;-) Either, way, please do file a new print dialog option / enhancement feature bug for that and link it to this with SeeAlso etc. It'd be nice to attach the single, most minimal test document from here to it as well - this bug got rather horribly un-readably unwieldy by now =) Thanks for everyone's input. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #64 from jwoithe jwoi...@just42.net --- Thanks James for the additional information (comment 62). It appears that using ghostscript to do the conversion may be a feasible workaround for installations such as those mentioned by crxssi in comment 57. And the engine xpdf uses for display is different that the one it uses to generate postscript. Having different engines involved at various stages throughout the system undoubtedly added to the confusion surrounding this issue. Hopefully a transparency flattening option as outlined in comment 62 can be made workable in time for those users who are unable to upgrade their base system frequently. Of course whether this happens before such systems are updated remains to be seen. Thanks to all who helped to clarify the source of this issue even though it is not possible to completely resolve it for all users at this time. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #65 from James Cloos cl...@jhcloos.com --- The best LO could do is offer an option on export and printing to ... This would be a great feature request to file; I'm not sure that people will love to file it, but perhaps there is indeed code to identify which pieces of the page to bitmap-ify, though there really is a reason why we prefer a meta-file format that handles transparency well ;-) PDF is indeed better, and we are getting closer to a world where it can be directly rasterized on the printers. IPP-Everywhere is a significant step in that direction. My PS printer, for example, while nearly depreciated still has -- at the rate I print colour -- years of CMY toner in its current cartiges. And, at that rate, decades of imaging unit life. ☺ The flattening does not need to rasterize. It just needs to flatten fill and stroke colors to the visible results of the tranparency. When transparent objects completely overlap that is easy; the objects are painted as opaque with the result colours. Even text can be left as text in this case. The hard part is when they only partially overlap. The code needs to trace the outlines of the overlapping portions and generate new opaque objects to paint over those areas. When the partially overlapping areas have polygonal outlines, that is again easy. And one probably only needs centipoint to millipoint precision to do it well enough to avode anomolies. The hard part is dealing with the cubic outlines. One needs to create a spline extending from an arbitrary point along the orginal spline to another arbitrary point, tracing along the original. Doable, with arbitrary tolerance. And if the partially overlapping objects include a block of text, that whole block needs to be converted to outlines before doing the above. That could take significant processing, especially for a portable. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #66 from tmacalp tmac...@gmail.com --- (In reply to comment #65) The hard part is when they only partially overlap. The code needs to trace the outlines of the overlapping portions and generate new opaque objects to paint over those areas. I might be reading this wrong, but it sounds like you're describing a behavior similar to bug 61306 and bug 42442. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #56 from Michael Meeks michael.me...@collabora.com --- jwoith - thanks so much for your analysis and hard work on this ticket; sorry it didn't lead to a workaround in LibreOffice, but glad that the situation is improving for most users. Would Resolved-NotOurBug work for this ? [ of course, quite possibly it is at least partially our bug of so not entirely satisfying ], if so, any chance of closing it ? At least the details are archived here for future reference. Thanks ! -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #57 from crx...@hotmail.com --- (In reply to comment #55) On the one hand the amount of software adversely affected by the issue is shrinking. While that is true, some of us are stuck with what is [right now] current... and RHEL 6 is still what is current in business and it is likely to never be fixed for this issue (because it isn't going to use a very recent CUPS). Some people can't just upgrade the OS on whim because they want to. And for them (like me), this issue has been a pain for years and might remain a pain for more years to come. LO created the problem, it would be nice if it were fixed instead of just waiting yet more years for everyone to just be on newer PDF renderers. Let us not forget, the problem is not just with displaying PDF's generated by LO, it can also affect just regular printing in LO on affected systems ( https://bugs.freedesktop.org/show_bug.cgi?id=71104 ) (In reply to comment #56 by Michael Meeks] Would Resolved-NotOurBug work for this ? It would work to ignore a bug that isn't even majorly the fault of some other project... -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #58 from Michael Meeks michael.me...@collabora.com --- crxssi: While that is true, some of us are stuck with what is [right now] current... and RHEL 6 is still what is current in business and it is likely to never be fixed for this issue (because it isn't going to use a very recent CUPS). RedHat do a great job of supporting their product and have an active and engaged development team. I guess if you file with your RHEL contact this will get fixed / worked around wherever the bug truly is =) either in libreoffice or most likely cups. Any other objections ? -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #59 from jwoithe jwoi...@just42.net --- In reply to Comment 56: Would Resolved-NotOurBug work for this ? [ of course, quite possibly it is at least partially our bug of so not entirely satisfying ], if so, any chance of closing it ? At least the details are archived here for future reference. NotOurBug is probably not telling the whole story, although I'm not sure what else to suggest since the resolution descriptions available are by design fairly generic. It is clear that a change in LO's PDF generation code broke important applications like CUPS through LO versions 3.5, 3.6 and 4.0 (and possibly earlier). LO 4.1 changed something which made at least some versions of CUPS render what was expected (see comment 53), but older versions of xpdf (3.02 and earlier) - and perhaps other renderers too - still could not get the render right. Whether the 4.1 change was just a happy accident also remains to be seen. A noted in comment 51, CUPS 1.5.4 could not render output from LO 4.0 correctly while (as per comment 53) the same CUPS version on the same machine could deal with the output from LO 4.1. At the same time however, xpdf 3.02 could not render either output correctly. Whatever change was made between LO 4.0 and LO 4.1, it would appear to have been subtle enough to make CUPS happy while still creating issues for things like xpdf 3.02. Furthermore, while we don't know exactly what change made CUPS happy it is unclear whether the altered behaviour is due to a targetted code change or is merely a side effect of some other modification and therefore might break again later. Personally I am a little uncomfortable with marking this as NotOurBug for these and similar reasons to those outlined in comment 57. While crxssi could potentially pursue this though their RHEL support contract as suggested in comment 58, I am sure there are many other users subject to locked down systems from sources other than RHEL who would not have this option. What makes the situation somewhat tricky is that all affected PDF renderers used to work; it was a change in LO which broke them. At the same time, if LO's revised PDF output is technically correct then perhaps the behaviour does point to bugs (or missing feature implementations) in the affected renderers. Checking the changelog for xpdf 3.03 for example (http://www.foolabs.com/xpdf/CHANGES) it is clear that a number of changes were made to transparency handling between 3.02 and 3.03 which explain why 3.03 may now have a better chance of getting it right. Having said all that, I have probably personally taken this as far as I have time and knowledge to do. I am not familiar with the LO codebase, nor have I in-depth knowledge of the PDF format and its various implementations. For all machines which I manage (personally and at work) upgrading software is an option and for us this seems sufficient to address the problem at least for now. As a result of all these things, spending more time on this is not currently feasible for me. If there is no one else to pick up the investigation of the outstanding issues, then perhaps concluding it as NotOurBug makes sense if we were willing to blame the problem solely on deficiencies in other software. However, looking back at the history this is not overly satisfying as mentioned by Michael in comment 56. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 James Cloos cl...@jhcloos.com changed: What|Removed |Added CC||cl...@jhcloos.com --- Comment #60 from James Cloos cl...@jhcloos.com --- I’m coming at this late, but some comments: CUPS is not a renderrer. I can, for some jobs, use a renderer. One of the comments, noted that lo sent a pdf to cups, and that he was printing to a postscript printer. That implies that cups converted from pdf to ps. For that conversion, depending on the distribution, it will use one of ghostscript, poppler or xpdf. Because postscript does not support transparency, each of those will render any pages which include transparency to a pixmap encased in postscript. Current versions of ghostscript and poppler get it right. (Note that poppler is based on xpdf; its pdftops on xpdf’s pdftops, and its splash display engine – used, eg, by occular – on xpdf.) The bug probably was specific to xpdf. Affected systems may be able to avoid that bug by configuring cups’ pdftops filter to call ghostscript rather than pdftops(1). (It’s a compile-time options, IIRC.) Printing to non-postscript printers probably calls cups’ gstoraster filter to have ghostscript render the pdf directly to a raster file, which is then converted to the printer’s raster format (pcl, esc/p, et cetera). Someone on an affected system should test whether their local ghostscript can render the pdf to an image file (png256 gives a good test). If that works well, then configuring cups to use gs rather than xpdf/poppler for conversions to postscript should fix printing there. Beyond that, mupdf is a better viewer than xpdf; it is at least as small, fast and efficient. And it gets this right. There also is gv, which uses gs to do the rendering. Gv should be available on any distribution in use, as like ghostscript it is older than linux. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #55 from jwoithe jwoi...@just42.net --- I can confirm that the Minimal ODT test case to illustrate this bug (LO 4.0.0 PDF export) (PDF file attachment 75026) renders correctly under Slackware 13.37 when running xpdf 3.03. If xpdf 3.02 is used the rectangle renders as greyscale, as before. Given this observation and those in comment 51 and comment 53, it seems to me that a couple of things have happened which make this ticket less severe now. Firstly, some change to the LO PDF output occurred in LO 4.1.x which appears to have made CUPS capable of rendering the transparent objects. Secondly, unlike xpdf 3.02, xpdf 3.03 can now correctly render colour transparency in files produced by LO. In light of these observations I am not sure that it is worth pursuing the underlying cause of the difficulties identified in this ticket. On the one hand the amount of software adversely affected by the issue is shrinking. However, there is always an outside chance that the problems seen by xpdf = 3.02 and other software referenced in this ticket are indicative of an issue in LO's PDF output which happens by chance to still render correctly in some viewers but should still be identified and addressed lest they create further problems in the future. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 tmacalp tmac...@gmail.com changed: What|Removed |Added CC||tmac...@gmail.com --- Comment #54 from tmacalp tmac...@gmail.com --- *** Bug 71104 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #53 from jwoithe jwoi...@just42.net --- Further to comment 51, it seems that Libreoffice 4.1.3 can successfully print the Minimal ODT test case to illustrate this bug (attachment 75023) on CUPS 1.5.4 under Slackware 14.0. As per comment 51, this same CUPS version failed when used with Libreoffice 4.0.2. It would appear that Libreoffice 4.1.x changed something which happens to make this version of CUPS happier. However, the issue is not resolved yet because I note that the PDF exported by Libreoffice 4.1.3 still fails to render correctly under xpdf 3.02. Whether the correct output from CUPS is due to a targeted change in Libreoffice or is a coincidental effect of other work I cannot say. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 Michael Stahl mst...@redhat.com changed: What|Removed |Added Attachment #79133|text/plain |application/pdf mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 Michael Stahl mst...@redhat.com changed: What|Removed |Added Attachment #75023|application/octet-stream|application/vnd.oasis.opend mime type||ocument.text -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 Michael Stahl mst...@redhat.com changed: What|Removed |Added Attachment #79134|text/plain |application/pdf mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 Michael Stahl mst...@redhat.com changed: What|Removed |Added Attachment #63837|application/octet-stream|application/vnd.oasis.opend mime type||ocument.text -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #51 from jwoithe jwoi...@just42.net --- FYI, cups version 1.5.4 (as supplied in Slackware 14.0) is still affected. That is, when printing to a colour printer from Libreoffice on a system running cups 1.5.4, the transparent rectangle in attachment 75023 is still grey. Tested with Libreoffice 4.0.2. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #52 from jwoithe jwoi...@just42.net --- Regarding the suggestion of a duplicate search in comment 50, I've done a few quick searches of the bug tracker. Searching for transparency gives around 64 matches, most of which seem to be related to gradients in some way. The closest I've seen to the symptoms discussed here are bug 33591, bug 36766 (a meta bug summarising a number of transparency-related issues mostly related to presentation mode), bug 54924 and bug 55698. However, after reading the detail from these I'm not convinced that any could be classified as duplicates of this one. To my inexperienced eyes, while they may be conceptually similar (in that transparency is in some way related) the symptoms really are not a good match for the ones being dealt with here. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #44 from jwoithe jwoi...@just42.net --- (In reply to comment #41) This is a minimal ODT file which illustrates this bug. ... I have compiled pdf2svg from http://www.cityinthesky.co.uk/opensource/pdf2svg and used it on the two minimal test case PDFs (attachment 75024 and attachment 75026). I shall attach these following this message. A diff -u between these two SVGs gave the following. diff -u transparency_test-oo-3.2.1.svg transparency_test-lo-4.0.0.svg --- transparency_test-oo-3.2.1.svg 2013-05-11 10:20:38.404892277 +0930 +++ transparency_test-lo-4.0.0.svg 2013-05-11 10:20:47.860891890 +0930 @@ -1,17 +1,31 @@ ?xml version=1.0 encoding=UTF-8? svg xmlns=http://www.w3.org/2000/svg; xmlns:xlink=http://www.w3.org/1999/xlink; width=612pt height=792pt viewBox=0 0 612 792 version=1.1 defs +filter id=alpha filterUnits=objectBoundingBox x=0% y=0% width=100% height=100% + feColorMatrix type=matrix in=SourceGraphic values=0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 1 0/ +/filter +mask id=mask0 + g filter=url(#alpha) +rect x=0 y=0 width=612 height=792 style=fill:rgb(0%,0%,0%);fill-opacity:0.5;stroke:none;/ + /g +/mask +clipPath id=clip2 + path d=M 0.601562 22.800781 L 57.5 22.800781 L 57.5 0.300781 L 0.601562 0.300781 Z M 0.601562 22.800781 / +/clipPath clipPath id=clip1 - path d=M 277.601562 84.800781 L 334.5 84.800781 L 334.5 62.300781 L 277.601562 62.300781 Z M 277.601562 84.800781 / + rect width=58 height=23/ /clipPath +g id=surface6 clip-path=url(#clip1) +g clip-path=url(#clip2) clip-rule=nonzero +path style= stroke:none;fill-rule:evenodd;fill:rgb(72.155762%,27.842712%,0%);fill-opacity:1; d=M 0.601562 0.398438 L 57.398438 0.398438 L 57.398438 22.699219 L 0.601562 22.699219 Z M 0.601562 0.398438 / +/g +/g /defs g id=surface1 -g clip-path=url(#clip1) clip-rule=nonzero -path style= stroke:none;fill-rule:evenodd;fill:rgb(72.155762%,27.842712%,0%);fill-opacity:0.5; d=M 277.601562 62.398438 L 334.398438 62.398438 L 334.398438 84.699219 L 277.601562 84.699219 Z M 277.601562 62.398438 / -/g -path style= stroke:none;fill-rule:evenodd;fill:rgb(0%,0%,0%);fill-opacity:1; d=M 277.601562 84.800781 L 277.699219 84.800781 L 277.699219 62.398438 L 277.601562 62.398438 Z M 277.601562 84.800781 / -path style= stroke:none;fill-rule:evenodd;fill:rgb(0%,0%,0%);fill-opacity:1; d=M 334.398438 84.800781 L 334.5 84.800781 L 334.5 62.398438 L 334.398438 62.398438 Z M 334.398438 84.800781 / -path style= stroke:none;fill-rule:evenodd;fill:rgb(0%,0%,0%);fill-opacity:1; d=M 277.601562 62.5 L 334.5 62.5 L 334.5 62.398438 L 277.601562 62.398438 Z M 277.601562 62.5 / -path style= stroke:none;fill-rule:evenodd;fill:rgb(0%,0%,0%);fill-opacity:1; d=M 277.601562 84.800781 L 334.5 84.800781 L 334.5 84.699219 L 277.601562 84.699219 Z M 277.601562 84.800781 / +use xlink:href=#surface6 transform=matrix(1,0,0,1,277,62) mask=url(#mask0)/ +path style=fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:1; d=M 277.699219 729.5 L 277.699219 707.300781 transform=matrix(1,0,0,-1,0,792)/ +path style=fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:1; d=M 334.398438 729.5 L 334.398438 707.300781 transform=matrix(1,0,0,-1,0,792)/ +path style=fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:1; d=M 277.699219 729.5 L 334.398438 729.5 transform=matrix(1,0,0,-1,0,792)/ +path style=fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:1; d=M 277.699219 707.300781 L 334.398438 707.300781 transform=matrix(1,0,0,-1,0,792)/ /g /svg Obviously this document is much simpler than the one used for the comparison in comment 32 since it contains only the single semi-transparent frame. Does this make it any easier to work out what's going on? I am completely unfamiliar with both PDF and SVG formats. To my inexperienced eyes, it seems the older file relies on the use of a path with an explicit fill opacity setting of 0.5, while the newer one defines an alpha mask / filter pair to produce the same effect. If this is indeed the fundamental issue, the question becomes whether the use of the alpha mask is essential given that it is evidently not handled correctly by some important rasterisers like CUPS (see comment 34 for a a survey of different programs and their behaviour). -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #45 from jwoithe jwoi...@just42.net --- Created attachment 79131 -- https://bugs.freedesktop.org/attachment.cgi?id=79131action=edit SVG produced from OO 3.2.1 PDF export (attachment 75024) SVG produced from attachement 75024 using svg2pdf from http://www.cityinthesky.co.uk/opensource/pdf2svg, discussed in comment 44. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #46 from jwoithe jwoi...@just42.net --- Created attachment 79132 -- https://bugs.freedesktop.org/attachment.cgi?id=79132action=edit IW Unnamed (Modified) Row 5Col 15:41 Ctrl-K H for help SVG produced from OO 3.2.1 PDF export (attachment 75026) SVG produced from attachement 75026 using svg2pdf from http://www.cityinthesky.co.uk/opensource/pdf2svg, discussed in comment 44. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 jwoithe jwoi...@just42.net changed: What|Removed |Added Attachment #79132|IW Unnamed (Modified) |SVG produced from OO 4.0.0 description| Row 5Col 1|PDF export (attachment |5:41 Ctrl-K H for help SVG |75026) |produced from OO 3.2.1 PDF | |export (attachment 75026) | -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #47 from jwoithe jwoi...@just42.net --- (In reply to comment #44) I have found a PDF parser called pdf-parser.py at http://blog.didierstevens.com/programs/pdf-tools/. This produces a human readable description of objects found in a PDF file. I shall attach the resulting dumps from attachment 75024 and attachment 75026 in case it is useful for someone. To me it seems to confirm the conclusion reached in comment 44 but I'm ready to stand corrected by someone with more PDF format experience than I. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #48 from jwoithe jwoi...@just42.net --- Created attachment 79133 -- https://bugs.freedesktop.org/attachment.cgi?id=79133action=edit PDF object dump of OO 3.2.1 PDF export (attachement 75024) Objects found in OO 3.2.1 PDF export (attachment 75024) as reported by pdf-parser.py (http://blog.didierstevens.com/programs/pdf-tools/) and discussed in comment 47. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #49 from jwoithe jwoi...@just42.net --- Created attachment 79134 -- https://bugs.freedesktop.org/attachment.cgi?id=79134action=edit PDF object dump of LO 4.0.0 PDF export (attachement 75026) Objects found in LO 4.0.0 PDF export (attachment 75026) as reported by pdf-parser.py (http://blog.didierstevens.com/programs/pdf-tools/) and discussed in comment 47. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 jwoithe jwoi...@just42.net changed: What|Removed |Added Attachment #79132|SVG produced from OO 4.0.0 |SVG produced from LO 4.0.0 description|PDF export (attachment |PDF export (attachment |75026) |75026) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 Michael Meeks michael.me...@novell.com changed: What|Removed |Added Status|NEEDINFO|NEW CC||michael.me...@novell.com, ||tbehr...@suse.com --- Comment #50 from Michael Meeks michael.me...@novell.com --- jwoithe: thanks for your excellent work here ! comment#44 looks extremely plausible - I believe we changed how this rendering works (though I'm no expert) to use the drawinglayer; but ... So - to some degree it's a not our bug - but on the other hand, producing PDF that CUPS cannot print, particularly when the advantage of PDF over PS is ultimately transparency related ;-) seems a bit sad. Perhaps Thorsten has an idea here ... might also be worth a duplicate hunt here, I believe there were several similar issues out there, and this one should be the leader :-) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #40 from jwoithe jwoi...@just42.net --- Thanks for the clarification in comment #39. I have tested Libreoffice 4.0.0 x86 Linux en-US and can confirm that PDF files created with this version still suffer from the problem. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #41 from jwoithe jwoi...@just42.net --- Created attachment 75023 -- https://bugs.freedesktop.org/attachment.cgi?id=75023action=edit Minimal ODT test case to illustrate this bug This is a minimal ODT file which illustrates this bug. It was created under OpenOffice 3.2.1 (Linux, x86, en-US) and consists of one small frame with a background colour set to 50% transparency. The frame was created using Insert|Frame, with default settings accepted. Using this file I created two PDFs which will be attached subsequently: one using OpenOffice 3.2.1 and the other using Libreoffice 4.0.0 (Linux, x86, en-US). The problematic PDF viewers display the PDF created from OpenOffice 3.2.1 correctly, while the one from Libreoffice 4.0.0 shows greyscale where there should be a semi-transparent red-ish rectangle. It would be good to run these two PDFs through the previously mentioned analysers to see how they differ. They are simpler than the files previously looked at and perhaps the important differences may be more apparent. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #42 from jwoithe jwoi...@just42.net --- Created attachment 75024 -- https://bugs.freedesktop.org/attachment.cgi?id=75024action=edit Minimal ODT test case to illustrate this bug (OO 3.2.1 PDF export) Result of exporting attachment 75023 to PDF via OpenOffice 3.2.1. When viewed in the problematic PDF viewers, this PDF renders correctly. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 --- Comment #43 from jwoithe jwoi...@just42.net --- Created attachment 75026 -- https://bugs.freedesktop.org/attachment.cgi?id=75026action=edit Minimal ODT test case to illustrate this bug (LO 4.0.0 PDF export) This is the result of exporting attachment 75023 to PDF using Libreoffice 4.0.0. This PDF file renders the 50% transparent red area as greyscale in the problematic PDF viewers. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 jwoithe jwoi...@just42.net changed: What|Removed |Added Summary|Some PDF viewers are unable |Some PDF viewers are unable |to render shaded objects|to render shaded objects |from Libreoffice Draw with |from Libreoffice with |transparency when exported |transparency when exported |as PDF |as PDF (writer and draw ||verified) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 jwoithe jwoi...@just42.net changed: What|Removed |Added Version|3.5.6.2 release |3.6.3.2 release -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 44135] Some PDF viewers are unable to render shaded objects from Libreoffice with transparency when exported as PDF (writer and draw verified)
https://bugs.freedesktop.org/show_bug.cgi?id=44135 Joel Madero jmadero@gmail.com changed: What|Removed |Added Version|3.6.3.2 release |3.5.6.2 release --- Comment #39 from Joel Madero jmadero@gmail.com --- Version is the oldest version that you can see the issue, not the latest it's been tested on -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
