Message | Status | Do this... |
|
|
|
“Limit Check | The print job was too | You might need to reduce the |
Error” message | complex. | complexity of the page or |
appears. |
| install more memory. |
|
|
|
Common Linux Problems
Problem | Possible Cause and Solution |
|
|
I can’t change settings | You need to have administrator privileges to be able |
in the configuration | to change global settings. |
tool. |
|
|
|
I am using the KDE | You may not have the GTK libraries installed. These |
desktop but the | usually come with most Linux distributions, but you |
configuration tool and | may have to install them manually. Refer to your |
LLPR won’t start. | distribution’s installation manual for more details |
| about installing additional packages. |
|
|
I just installed this | Some versions of the KDE or GNOME desktop |
package but can’t find | environments may require that you restart your |
entries in the KDE/ | session for the changes to take effect. |
Gnome menus. |
|
|
|
I get a “Some options | Some printers have conflicting settings, meaning |
are not selected” error | that some settings for two options can’t be selected |
message while editing | at the same time. When you change a setting and |
the printer settings. | the Printer Package detects such a conflict, the |
| conflicting option is changed to a “No Choice” value. |
| You have to choose an option that does not conflict |
| before being able to submit the changes. |
|
|
I can’t make a printer | In some conditions, it may not be possible to |
the system default. | change the default queue. This happens with some |
| variants of LPRng, especially on recent RedHat |
| systems that use the “printconf” database of |
| queues. |
| When using printconf, the /etc/printcap file is |
| automatically refreshed from the database of |
| printers managed by the system (usually through |
| the “printtool” command), and the queues in /etc/ |
| printcap.local are appended to the resulting file. |
| The default queue in LPRng is defined as the first |
| queue in /etc/printcap, and therefore it is not |
| possible for the Linux Printer Package to change the |
| default when some queues have otherwise been |
| defined using printtool. |
| LPD systems identify the default queue as the one |
| named “lp”. Thus, if there is already a queue by this |
| name, and if it doesn’t have an alias, then you won’t |
| be able to change the default. To work around this, |
| you can either delete the queue or rename it by |
| manually editing the /etc/printcap file. |
|
|
Problem | Possible Cause and Solution |
|
|
The | The |
not work correctly for | processing of the PostScript data that is sent to the |
some of my | printing system. However, such |
documents. | only be adequately achieved if the PostScript data |
| conforms to the Adobe Document Structing |
| Conventions. Problems may arise when using |
| and other features that rely on |
| the document being printed isn’t compliant. |
|
|
I am using BSD lpr | Legacy BSD lpr systems have a hard limitation on |
(Slackware, Debian, | the length of the option string that can be passed to |
older distributions) | the printing system. As such, if you selected a |
and some options | number of different options, you may have |
chosen in LLPR don’t | exceeded the length of the options and some of |
seem to take effect. | your choices won’t be passed to the programs |
| responsible for implementing them.Try to select |
| fewer options that deviate from the defaults, to |
| save on memory usage. |
|
|
I am trying to print a | Most Unix applications that offer a Landscape |
document in | orientation option in their printing options will |
Landscape mode, but | generate correct PostScript code that should be |
it prints rotated and | printed as is. In that case, you need to make sure |
cropped. | that you leave the LLPR option set to its default |
| Portrait setting, to avoid unwanted rotations of the |
| page that would result in cropped output. |
|
|
Some pages come out | If the data being sent is in Encapsulated PostScript |
all white (nothing is | (EPS) format, some earlier versions of CUPS (1.1.10 |
printed), and I am | and before) have a bug preventing them from being |
using CUPS. | processed correctly. When going through LLPR to |
| print, the Printer Package will work around this |
| issue by converting the data to regular PostScript. |
| However, if your application bypasses LLPR and |
| feeds EPS data to CUPS, the document may not |
| print correctly. |
|
|
I can’t print to an SMB | To be able to configure and use |
(Windows) printer. | (such as printers shared on a Windows printer), you |
| need to have a correct installation of the SAMBA |
| package that enables that feature. The “smbclient” |
| command should be available and usable on your |
| system. |
|
|
My application seems | Most Unix applications will expect a command like |
to be frozen while | the regular “lpr” command to be |
LLPR is running. | and thus return immediately. Since LLPR is waiting |
| for user input before passing the job on to the print |
| spooler, very often the application will wait for the |
| process to return, and thus will appear to be frozen |
| (its windows won’t refresh). This is normal and the |
| application should resume functioning correctly |
| after the user exits LLPR. |
|
|
7.18