
| Problem | Possible Cause and Solution | 
 | 
| 
 | 
 | 
 | 
| The  | The  | 
 | 
| work correctly for some | the PostScript data that is being sent to the printing | 
 | 
| of my documents. | system. However, such  | 
 | 
| 
 | adequately achieved if the PostScript data conforms to the | 
 | 
| 
 | Adobe Document Structing Conventions. Problems may | 
 | 
| 
 | arise when using  | 
 | 
| 
 | processing if the document being printed isn’t compliant. | 
 | 
| 
 | 
 | 
 | 
| I am using BSD lpr | Legacy BSD lpr systems have a hard limitation on the | 
 | 
| (Slackware, Debian, older | length of the option string that can be passed to the | 
 | 
| distributions) and some | printing system. As such, if you selected a number of | 
 | 
| options chosen in LLPR | different options, the length of the options may be | 
 | 
| don’t seem to take effect. | exceeded and some of your choices won’t be passed to the | 
 | 
| 
 | programs responsible for implementing them. Try to select | 
 | 
| 
 | less options that deviate from the defaults, to save on | 
 | 
| 
 | memory usage. | 
 | 
| 
 | 
 | 
 | 
| I am trying to print a | Most Unix applications that offer a Landscape orientation | 
 | 
| document in Landscape | option in their printing options will generate correct | 
 | 
| mode, but it prints | PostScript code that should be printed as is. In that case, | 
 | 
| rotated and cropped. | you need to make sure that you leave the LLPR option to | 
 | 
| 
 | its default Portrait setting, to avoid unwanted rotations of | 
 | 
| 
 | the page that would result in a cropped output. | 
 | 
| 
 | 
 | 
 | 
| Some pages come out all | If the data being sent is in Encapsulated PostScript (EPS) | 5 | 
| white (nothing is | format, some earlier versions of CUPS (1.1.10 and before) | |
| printed), and I am using | have a bug preventing them from being processed | |
| CUPS. | 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 a SMB | To be able to configure and use  | 
 | 
| (Windows) printer. | as printers shared on a Windows machine), 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 to | Most Unix applications will expect a command like the | 
 | 
| be frozen while LLPR is | regular “lpr” command to be  | 
 | 
| running. | 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. | 
 | 
| 
 | 
 | 
 |