Samsung ML-1740 User Manual (ENGLISH) - Page 115

Problem, Possible Cause and Solution - won t print

Page 115 highlights

Problem Possible Cause and Solution The N-up setting does not work correctly for some of my documents. The N-up feature is achieved through post-processing of the PostScript data that is being sent to the printing system. However, such post-processing can only be adequately achieved if the PostScript data conforms to the Adobe Document Structing Conventions. Problems may arise when using N-up and other features relying on postprocessing if the document being printed isn't compliant. I am using BSD lpr (Slackware, Debian, older distributions) and some options chosen in LLPR don't seem to take effect. Legacy BSD lpr systems have a hard limitation on the length of the option string that can be passed to the printing system. As such, if you selected a number of different options, the length of the options may be 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 document in Landscape mode, but it prints rotated and cropped. Most Unix applications that offer a Landscape orientation option in their printing options will generate correct PostScript code that should be printed as is. In that case, 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 white (nothing is printed), and I am using CUPS. If the data being sent is in Encapsulated PostScript (EPS) format, some earlier versions of CUPS (1.1.10 and before) have a bug preventing them from being 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 a SMB (Windows) printer. To be able to configure and use SMB-shared printers (such 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 be frozen while LLPR is running. Most Unix applications will expect a command like the regular "lpr" command to be non-interactive 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. 6.22 SOLVING PROBLEMS

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150

S
OLVING
P
ROBLEMS
6.
22
The N-up setting does not
work correctly for some
of my documents.
The N-up feature is achieved through post-processing of
the PostScript data that is being sent to the printing
system. However, such post-processing can only be
adequately achieved if the PostScript data conforms to the
Adobe Document Structing Conventions. Problems may
arise when using N-up and other features relying on post-
processing if the document being printed isn’t compliant.
I am using BSD lpr
(Slackware, Debian, older
distributions) and some
options chosen in LLPR
don’t seem to take effect.
Legacy BSD lpr systems have a hard limitation on the
length of the option string that can be passed to the
printing system. As such, if you selected a number of
different options, the length of the options may be
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
document in Landscape
mode, but it prints
rotated and cropped.
Most Unix applications that offer a Landscape orientation
option in their printing options will generate correct
PostScript code that should be printed as is. In that case,
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
white (nothing is
printed), and I am using
CUPS.
If the data being sent is in Encapsulated PostScript (EPS)
format, some earlier versions of CUPS (1.1.10 and before)
have a bug preventing them from being 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 a SMB
(Windows) printer.
To be able to configure and use SMB-shared printers (such
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
be frozen while LLPR is
running.
Most Unix applications will expect a command like the
regular “lpr” command to be non-interactive 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.
Problem
Possible Cause and Solution