[cups] CUPS sometimes printing command codes instead of document

[Tim Mooney]

In regard to: Re: [cups] CUPS sometimes printing command codes instead of...:

> Is there some way to tell CUPS to throw away everything that’s not
> recognized as PCL6 (i.e. recognized as ASCII) because, frankly, a print
> job that’s just thrown away is better than a print job that wastes a
> hundred pages of paper…

CUPS is just one part of the overall printing system.  It's the filters
(CUPS typically calls them "backend"s) that are responsible for preparing
a print job by transforming it into a suitable format for the destination
device.  It may also be a filter that's actually handling communication
with the printer, depending on how it was set up (e.g. socket).

> … regardless, I’d like to find the source of the problem. Is there some
> way to tell if it’s a problem because the print job is garbled by the
> source (i.e. already cut off when received by CUPS) or if it’s something
> caused somewhere in the CUPS pipeline after it has processed the
> request?

Maybe.  CUPS queues have a couple of "controls".  One is whether the queue
is "accepting" jobs, and the other is whether sending jobs to the final
device is "enabled".

If you change the queue so that it is accepting jobs but the printer is
not enabled and then submit one or more print jobs, they will be accepted
by CUPS but they will just sit in the queue.  You can then examine the
print jobs, to see if you can detect any pattern about why one job may
print successfully while another does not.

As far as how you set a queue to be 'disabled', that depends upon your
system.  You may want to look for the 'disable' or 'cupsdisable' command
and man page, or you can probably do it through the CUPS web interface.

Alternately, you can use the information in the CUPS error_log (assuming
you've enabled debug logging) to manually run the entire chain of filters
(backends) that CUPS is invoking, except for the step that sends it to
the printer, and then examine the resulting file.

Tim

>
> Von: Robert Heller
> Gesendet: Donnerstag, 6. Juni 2019 17:17
> An: The CUPS user discussion list.
> Cc: The CUPS user discussion list.
> Betreff: Re: [cups] CUPS sometimes printing command codes instead of document
>
> At Thu, 06 Jun 2019 16:35:48 +0200 (CEST) "The CUPS user discussion list." <cups at cups.org> wrote:
>
>>
>>
>> Hello,
>>
>> On Jun 6 13:33 Johannes Hass wrote (excerpt):
>>> Sometimes printing works fine, everything comes out as it should.
>>> But also sometimes you get pages full of command codes,
>>> always beginning with
>>>
>>> ime=10:05:20 2019/06/06?
>>> @PJL OKIAUXJOBINFO DATA=?DocumentName=PDF-Datei?
>>> ?
>>>
>>> And so on and so forth. The first line is obviously the current time
>>> and date. To me this looks like somewhere the beginning of the
>>> commands does not get recognized and thus everything following
>>> is interpreted as pure ASCII.
>>
>> I guess it is in your CUPS mime.convs file this part
>> ---------------------------------------------------------------
>> # Raw filter...
>> # Uncomment the following filter to allow printing
>> # of arbitrary files without the -oraw option.
>> application/octet-stream  application/vnd.cups-raw  0  -
>> ---------------------------------------------------------------
>>
>> The CUPS mime.convs file could be located in a directory
>> that differs from Linux distribution to Linux distribution
>> and/or from CUPS version to CUPS version, e.g. mine is
>> /usr/share/cups/mime/mime.convs
>> but it could also be in /etc/ or in similar directories.
>>
>> When the above line is active (uncommented) any unknown
>> data format is sent as is directly to the printer device
>> and it happens that your particular printer model
>> interprets/prints it as if it was regular plain text.
>>
>> This happens in particular on not so dumb office printers that
>> support several standard printer languages like PostScript and PCL
>> which do plain text printing as fallback mode (which makes sense
>> because plain text has no special header to identify the format,
>> cf. "There is no such thing as 'plain text'" in
>> https://en.opensuse.org/SDB:Plain_Text_versus_Locale
>>
>> Dumb cheap (mostly inkjet) devices do usually nothing
>> when they get data that they cannot recognize.
>
> They will print plain text using a default font (eg they will behave like an
> old-school "dot-matrix" printer), which appears to be what is happening here.
> Dumb cheap (mostly inkjet) printers either expect their own partitular
> bit-hacked format (usually involving ESC-prefixed command codes) or else they
> print print plain text. Smarter printers (generally laser printers) understand
> several printer "languages", like PostScript (Brother printers support
> BrScript, which is Brother's brand of PostScript) or PCL, and deduce which
> print engine to use, automagically.
>
>>
>>
>> Kind Regards
>> Johannes Meixner
>
>

-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164