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