https://bugs.freedesktop.org/show_bug.cgi?id=44135
--- Comment #59 from jwoithe <[email protected]> --- 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
