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