[cups] Text being garbled - Ricoh Pro 1156/1157 - Cups 1.5 and 1.7.2

[Johannes Meixner]

Hello,

On Apr 20 09:39 Chris Coleman wrote (excerpt):
> ... we were running on Ubuntu 14.04 with Cups 1.7.2.
> I had a backup server that was running ubuntu 12.04
> and cups 1.5.3 so I switched over to that and the issue went away.
...
> Fast forward a month and boohoo! the problem appeared again
> on the 1.5.3 box.
...
> I decided to go ahead and put together a fresh ubuntu 12.04
> installation without any updates, the problem persists.
>
> Unfortunately I can't really share the documents in question

Without a public accessible file where the issue happens
others can do basically nothing so that you must debug
the root cause on your own.

Often the root cause of rare and exceptional issues in
the printing output is in the original printing input
data which is another reason why a public accessible
file of the original printing input is usually needed.

For example Ghostscript is full of stuff to deal with
zillions of cases of weird PostScript and weird PDF.

For some general information about some first steps
how to debug a printing issue you may have a look at
https://en.opensuse.org/SDB:How_to_Report_a_Printing_Issue

The general information therein should be basically
correct for all nowadays Linux distributions.

In particular therein see the following sections
"Get what the application submits to CUPS"
"Test if what the application had submitted
  to CUPS seems to be correct"
"It always helps to simulate printout on a
  virtual generic PostScript printer"
"Usually provide CUPS debug messages"

>From your CUPS debug messages I see that
those filters are run in your particular case:

I [20/Apr/2016:14:06:40 -0700] [Job 1186]
  Started filter /usr/lib/cups/filter/pdftopdf (PID 23055)
I [20/Apr/2016:14:06:40 -0700] [Job 1186]
  Started filter /usr/lib/cups/filter/foomatic-rip (PID 23056)
I [20/Apr/2016:14:06:40 -0700] [Job 1186]
  Started backend /usr/lib/cups/backend/socket (PID 23057)
...
D [20/Apr/2016:14:06:40 -0700] [Job 1186]
  Started filter pdftops (PID 23059)
D [20/Apr/2016:14:06:40 -0700] [Job 1186]
  Started filter pstops (PID 23060)
...
D [20/Apr/2016:14:06:40 -0700] [Job 1186]
  Starting renderer with command:
  ...
  gs -q -dBATCH -dPARANOIDSAFER -dNOPAUSE
     -dNOINTERPOLATE -sDEVICE=pxlmono -r600x600
     -sPAPERSIZE=letter -sOutputFile=- -

I.e. your original PDF print job data is converted
by /usr/lib/cups/filter/pdftopdf into "other PDF" that is
further converted by /usr/lib/cups/filter/foomatic-rip
and the final printer specific data is sent to the
printer device via /usr/lib/cups/backend/socket.

During the conversion into final printer specific data there
is a first call of pdftops to convert the "other PDF" into
PostScript then a call of pstops to convert that PostScript
into "other PostScript" finally a call of Ghostscript
to convert that "other PostScript" into PCLXL (via the
Ghostscript device "pxlmono") which is the final printer
specific data.

In short:
   PDF -> PDF -> PostScript -> PostScript -> PCLXL

In particular the /usr/lib/cups/filter/pdftopdf
filter indicates that you run the newer PDF workflow
that uses the filters from the cups-filters project
even on traditional CUPS < 1.6.

Note that cups-filters is not from CUPS upstream
but a separated project at OpenPrinting.org:
http://www.linuxfoundation.org/collaborate/workgroups/openprinting/cups-filters

Accordingly the issue is most likely not an issue in CUPS
but in cups-filters or in other software that is only
called by cups-filters (like poppler's pdftops or
Ghostscript or whatever else like TeX/LaTeX/dvips).

For some background information about that see
https://en.opensuse.org/Concepts_printing
therein the sections
"PostScript: The traditional printing data format"
"PDF: The recent printing data format"
"PostScript versus PDF as standard print job format"

Somewhere in the chain of various conversion steps
that convert your original PDF print job data
into the final printer specific PCLXL data
the issue happens that result garbled glyphs
in your particular printout.

It is possible to dissect the chain of various conversion
steps and do each step manually to find out what exact step
seems to be the root cause that finally result garbled glyphs
in your particular printout.

Dissecting the filtering chain could be a rather tricky
task and I do not know about a general documentation
that describes how to do that.

Fortunately you use Ubuntu ;-) so that it is not me
who may have to dissect your particular filtering chain
to analyze what the root cause could be that results
garbled printed glyphs in your particular case.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)