I am running version 7.10 with a HP laserjet 1200.

In System/Administration/Printing/Policies there is a place to mark "Enabled" for the printer. During a normal work day it will un-mark itself, so that I have to check to see if it is enabled before printing something. There does not seem to be any pattern to the behavior. In other words, it does not seem to be related to booting the machine or starting the printer.

This may be a "problem" but it seems more to be a bug. In any case I need some counsel as what to do.

Thanks,

José

Can't tell from your post what Linux distribution, but can guess that it's probably running the Common UNIX Printing System (CUPS). The "Enabled" toggle in your system administration app likely reflects whether the queue on your computer (i.e. pipeline of print jobs) for this printer is turned on or off (i.e. will try to deliver the jobs or just hold them.) In some Linux distributions (RedHat/Fedora at least) the default option setting for the cups service is to turn off a the queue for a printer if cups encounters a problem with a print job. When this happens you have to manually restart the queue (browsing to http://localhost:631/printers and restart the printer should work - this is CUPS, not distribution, specific) after fixing the problem. Just resolving the printer problem and even power cycling the printer won't get printing restarted without this step.

You can override the default option of stopping the queue (same URL) and choose either to automatically retry or abort any failed job. These might make more sense if the printers errors are transitory and don't require intervention.

Thanks Damonhart

Yes it is the CUPS system on Ubuntu 7.10. Administration/Printing has a "Policies" tab with the "Enabled" choice. I will try the "abort" selection for error policy.

It can be quite frustrating. Yesterday I verified that "Enabled" was checked and then printed a page. When I looked at printing policies it was unchecked, and the page I just printed was waiting to be printed.

Hopefully the error policy factor was the cause. Will wait and see after a few trials.

Again, thanks.

José

In the case cited, some issue resulting from the job itself caused CUPS to halt the queue. If you can never isolate a cause, then the retry or abort options might be more useful. We had a network printer which must have had a buggy interface as multiple CUPS connected workstations frequently halted queues and had to be restarted. Good luck!

Well, it looks like I have a solution. I have the printer connected USB, and I never even thought of the possibility of using a parallel connection.

So I tried that, and so far, all is working OK.

So thanks.

José