Paul Menzel wrote:
As a side not Evince has problems displaying the output from CUPS-PDF.
The text is not readable. Xpdf displays everything correctly though. So
that issue is a separate bug in Evince I guess.
Just more information. This seems to be a CUPS-PDF issue.
$ pdffonts CUPS-PDF/test.pdf
name type emb sub uni
object ID
------------------------------------ ----------------- --- --- ---
---------
[none] Type 3 yes no yes
12 0
$ pdffonts /tmp/out.pdf
name type emb sub uni object ID
------------------------------------ ----------------- --- --- ---
---------
JMQJEJ+FreeMono CID TrueType yes yes no
11 0
But I think to remember, someone wrote in another bug report that
CUPS-PDF is not meant for printing text. Still it is strange that Xpdf
works fine.
Ok. I've had another look. My emtpy PDF came from the very bug here
reported (the fix is not in testing yet); I've copied my bzr build to
the system folder, and voila...:
Xpdf spits out a lot of "Error: Bad bounding box in Type 3 glyph" on the
CUPS-PDF file. This is consistent with "Type 3" in the font list.
Evince-gtk does work here, BUT it prints:
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug
which probably causes empty pages in some other versions of evince
and/or pixman/cairo.
So why are Type 3 fonts used?
I [22/May/2012:13:04:51 +0200] [Job 784] Started filter
/usr/lib/cups/filter/texttopdf (PID 20424)
I [22/May/2012:13:04:51 +0200] [Job 784] Started filter
/usr/lib/cups/filter/pdftopdf (PID 20425)
I [22/May/2012:13:04:51 +0200] [Job 784] Started filter
/usr/lib/cups/filter/pdftops (PID 20426)
I [22/May/2012:13:04:51 +0200] [Job 784] Started backend
/usr/lib/cups/backend/cups-pdf (PID 20427)
That means: Text is converted by texttopdf (fine).
This is sent through pdftopdf (still ok).
Then it is converted to PS by pdftops und converted back to PDF by
cups-pdf (unwanted); also the font is converted to Type 3 by one of
these two filters (not nice), but the routine outputs Type 3-bounding
boxes the pdf consumer regards as wrong (bad), which is either a bug in
the pdf consumer ("poppler"/...) or the producer (ghostscript for both
pdftops and cups-pdf over here; pdftops(cups) seems to also be able to
call pdftops(poppler-tools) which did not produce Type3 on a quick
test...).
If you gave me a hint where to assign such a report to, I
would be very thankful.
Hmm, I don't really know, but the cups-filters package has a bugtracker
at https://bugs.linuxfoundation.org/ (under the OpenPrinting product).
But just another debian bug would work equally well ...
Till?
Tobias
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
