Printer problems - what to do when it happens

[wedgetail]

I have developed some insight into how certain aspects of printing in linux works. I have faced a number of highly interesting problems that I have tried to figure out the cause of. I have made records of certain procedures which I will try to record here so you can have a go yourself when your xyz all singing whatever printer is letting you down.

Unfortunately I find that as soon as I let go of working with printer tasks I forget very quickly even where my records are (too many of them).  Since this will be built up from my records I want to be able to change the layout to suit as I find my bits, so I am going to lock the topic.  

This will not deal with how you install your printer in PCLinuxOS this is to help you get some life back into the printing process when all else seems to have failed.  Printing in linux can be very frustrating and I think partially because there are too many options but so be it.

I have been through a number of approaches and in the end I have found that to save time a combination of konsole work and little bit of CUPS Webinterface use is the only thing that has not let me down yet.  CUPS is a fantastic service and too big for the home user, with that I mean it is so complex that one gets lost very easily.  What I have done is picking my way through certain routes and found that a number commands will serve a user quite well despite not being simple.

CUPS
If you click on following and see CUPS 1.4.6 you will know you have CUPS installed, normally I will use the second line, instantly telling you how many printers you hve installed.

http://localhost:631
http://localhost:631/printers/

Initial facts to post in Forum
If you have a printer problem and seek Forum help, please be sensible and come up with facts.  For example if you have had some life in a printer setup:

1.. What Desktop are you using, KDE, LXDE ....?

2.. What Driver, post the konsole output of this

ls -l /etc/cups/ppd/

Would also help if you tell whether inkjet or a laserjet

3.. Well when Old-Polack rolls his sleeves up you will be asked for fdisk -l to attract my attention the following will stop me skipping your post if I see it.

lpstat -t

lpinfo -v

lpoptions -p <your printer queue>

The following can be a bit big, so probaly best left until asked for, but if it is only 5 or 6 lines might as well get included

lpoptions -p <your printer queue> -l

By the way your pinter queue(s) are revealed in lpstat -t

The beauty of ISO 2012.02
It does not have CUPS installed, I can hear deep silence    Well there will be situations where personal customisation has got mixed up and it is necessary to go back to a reference standard, so to speak start from the very first beginning.  I can now replicate the system you are supposed to be running.

The reason is that the need to print from an application to a file and look in much closer detail what is going on.  Since in linux printing from an application natively produces a postscript file or now it seems perhaps a pdf file.  The resulting file may need some closer scrutiny. Ought to be rare having to do this.  However this is very handy to keep in mind when the problem gets tricky, the one I have in mind right now is Zyberhawk.

With no printer installed you can still open an application, say Kwrite and print the content of for example menu.lst but your only 'printer' is print to file.  The menu.lst is a simple txt file no fancy formatting.  If the menu.lst is opened with nano or vim as well this is reasonable proof that the saved file is storing the text as ascii characters.  Further if one looks at the filesize and character count they are close.

Funny when no printer is yet installed in then I was expecting the option to save as .txt.  I expect this because I come from a DOS/Windows background.  Linux native printing format is postscript and I ought to get used to that an application then would offer save to file as postcript.  So when I open a text file in Kwrite and try to print without a printer installed, I can only Print to file with option .ps or .pdf.  Print to file at least show you what format or page layout the operation will involve.

The surprise for me is still that if there is a printer installed via CUPS and a text file is printed from Kwrite (and other applications?), the file that is sent to the printer is a .pdf format. When trouble shooting this should be remembered. 

It is possible to pint a text file in a manner that the file that is sent to the printer is just simple ascii stream. This is done by using command line instructions to print the file.  There are two instructions available in CUPS, the lpand lpr

How did I know that Kwrite prints a text file from a .pdf format? It is possible to trap the temporary file from any printer or more correct printer queue installed. How to take advantage of this temp file is described below.

================ A bit more advanced  ========================

As this whole post has been lifted from a recent topic I am leaving it here, despite it will seem out of place for the moment. I can then refer to it when needed.

a.. Turn the power off your printer

b.. Need to open a standard test file in Kwrite, as I do fair amount of konsole work when trouble shooting, copy/paste the line:

kwrite /usr/share/printer-testpages/testpage.asc &

The result will be self explanatory, about half a page of ascii text.

c.. Print this file from Kwrite just opened, using your driver of choice. Nothing will seem to happen, that is fine.

What happens is that the file has been dealt with by CUPS, a temporary file is trapped at a location to be revealed, it is trapped just before the CUPS backend handler for the job. Suffice to say this file is the final result and only needs to be transported to the physical printer.  We want to look at it and see if it looks proper  

d.. The file is found here, where there can be many files waiting to be printed from the queue, it should be the last one. The novelty has worn off looking at them all so I do a grep to cut down a bit. The last d00xxx-001 is the one

ls -l /var/spool/cups |grep d

e.. Need to know what sort of file (remember our nice ascii text file?)

head -5  /var/spool/cups/d00xxx-001

f.. Very likely you will find it is a pdf file, first line good indication. Okular is then used to look at it.

okular /var/spool/cups/d00xxx-001

Well if Okular shows the text nicely as it was in kwrite, then you know that CUPS has done pretty well to this stage.

If you now turn the printer on it should automatically print what you have just seen. (good idea not to have many waiting jobs in the queue at this stage  ) Just click here, where you can delete files if required.

http://localhost:631/jobs/

The question is how far do you get in above sequence.  When things go bust just stop and report. The sequence is designed to tell me a fair bit of what is going on in a system that appears to have a driver.

[wedgetail]

Here I am going to look at how many printers are available when you have installed all the recommendations plus the kitchen sink.

CUPS has the ability to read all databases that may be available as far as printers are concerned. I will not go into the details suffice to say that you no doubt would like to know in an easy way.  For a full installation you will have options around 13,000 which seems a bit superfluous as just one or at most a few are needed.  A few if you understand the implications and advantage of running multiple 'printers' (even if it is the same printer)

Because there are that many the number will be piped to a text file in /home/<user>/Documents for convenience.  Open a user konsole (if you use root konsole you will get permission battle)

lpinfo -m > /home/<user>/Documents/120520-Available_printer_drivers.txt

I prefer to sort this list and I have found a trick in kwrite that does this nicely, so the above file opened in kwrite via konsole as follows:

kwrite /home/<user>/Documents/120520-Available_printer_drivers.txt &

When in kwrite hit the F7 key and in the field that appears at the bottom  type sort then save the file.

Now you can search this file for your xyz all dancing printer model.  You soon get the hang of finding your particular model. What you are finding is the name of the "driver" or <model-name>.ppd or <model-name>.gz

I will just mention both extensions as CUPS can handle both, ie there is no need to expand the compressed version of the <model-name>.ppd. In general you just need one driver and the first one found may well be fine but of course there are reasons why more than one is often found.  So a bit of experimenting with different drivers may be needed. 


If your model is not there some thinking needed

(work in progress)