[Pkg-cups-devel] Bug#673289: Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055

[Tobias Hoffmann]

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