[GTALUG] Printing Problem(s)

[D. Hugh Redelmeier]

| From: Peter King via talk <talk at gtalug.org>

I started writing this yesterday, before Stewart's concise and insightful 
message.

He's right about networking.  Of course it brings its own problems 
(security on the printer, firewall piercing on your computer, ...).
I'm guessing that this is on a home LAN, behind NAT, so security of the 
printer isn't a big concern.

I don't know enough about IPP, but I suspect that the actual data
could be in PCL or PostScript or something else and that the printer
has to intuit which encoding is used.  As described below, I suspect
that your printer is guessing wrong about this.  Perhaps IPP would not
solve your problem.

My trouble with printers is that I solve these problems once every few 
years and forget what I learned in between.

| About a year ago I bought a Lexmark MS415dn laser printer, a well-known and
| reasonably popular model; I checked linux compatibility before buying and
| it was rated highly.

I haven't used this one, so this is just guesswork.

Here are the specs of your printer:
<https://www.lexmark.com/en_us/printer/9200/Lexmark-MS415dn>

Your printer apparently has "hardware" PostScript, as well as PCL 5e
and 6.  I'm guessing that using a driver that generates PostScript is
better than using PCL.  That may not be the case if the computer is
better at rendering than the printer's processor.

Speaking of processors, the specs say: dual core, 0.8 MHz.  That's
astonishingly slow and surely wrong.  My first laser printer (from
1989) had an 6 MHz 68000 processor.

| Recently it now prints PDF files at best half the time.  Otherwise it seems
| to dump two or three lines of random gibberish (possibly postscript code)
| to pages and pages and pages, with no way to stop it short of unplugging
| it.

I'd *guess* that's not PostScript.  PostScript is somewhat readable
text.

Perhaps your driver is sending PCL.  PCL is a fairly low-level Printer 
Control Language first used in the 1980's by HP and copied by most other 
printer makers.
<https://en.wikipedia.org/wiki/Printer_Command_Language>

Printers often have to guess whether a stream is in PCL or PostScript.  
Sometimes they get it wrong.  I've not figured out why or how to fix it.

Or maybe the problem is in the program you use.  How does lpr(1) know
which kind of file that it is printing?

In theory, I think that PostScript files come with a prefix string
that can be recognized.  Like:
	%!PS-Adobe-3.0
(Grabbed from a file I just created for this.)

|  Sometimes it will print a file just fine, and then fail to print the
| very same file immediately afterwards.  Sometimes it just won't print a
| file no matter what or when.  Pulling the plug, clearing the paper jams,
| restarting the printer, restarting CUPS, telling CUPS it's ready to work
| again -- well, it's all a bit much, and even then it screws up the next job
| through about half the time.
| 
| I'm using Arch Linux with the current (5.6.4) kernel and CUPS 2.3.1.

What exactly is your chain of processing?
- What is creating the file, if any?
- what format is the file?
- what is taking the file and flinging it at CUPS?

- do different files have this problem?  eg
	lpr text-file
	lpr postscript-file
	lpr pdf-file
	printing from evince
	printing from FireFox

What changed in your system just before you observed the problem?
Perhaps an update?  Or a change of procedures?