lp model file?
Wayne Patton
I am in need of having to modify a printer model file so it will print
the date/time stamp and user id on every page. Has anyone done this?
Is so, would you be willing to share how? Anyone knoe of resources
that explain how model scripts work and how to modify them?
Thanks,
Wayne
b...@atl.hp.com
For simple ASCII files (ONLY), this can be added to a printer script.
However, if the application print job contains special codes such as
cursor manipulation or formfeeds, counting lines will not work and
the solution will involve using macros in the printer language (PCL
or Postscript).
I am posting basic model script design and creation from 2 articles
I wrote for the Interex technical magazine several months ago.
-------------------
Model scripts, a short treatise
-------------------------------
With new printer products arriving (it seems) monthly, choosing a
model script might seem to be a daunting task, especially when
an exact match is not found. Here are some guidelines to help
pick a working model script.
The HP-UX Spooler
The SysV spooler, upon which HP-UX builds the lp subsystem, uses
a highly flexible spooler script to perform the output tasks
associated with a print job. Whether the destination is a local
printer (serial or parallel), a remote printer on another system
or a network printer like JetDirect, this script is the glue
between data and the printer.
In it's simplest form, the printer script is nothing more than
than a fancy cat(1) command, taking script arguments, and setting
up a few options like copy count, etc. It is *not* a driver in
the PC sense where a printer meta-language is used from the
application to the printer driver. The PC driver translates the
application's commands into codes known to the target printer.
In HP-UX, the majority of print options do not modify or interpret
the content of the print job.
Printer scripts start life as a template, or model, hence the name
model script. They are stored in the model directory where good
sysadmin practice dictates that the original models not be
modified (just like newconfig), but rather copied, modifed and then
renamed. After that, the new model scripts can be used for adding
new printers.
Starting with the dumb model script (that's the name, not a truly
descriptive term), it is fairly easy to see the 6 parameters
given to the script by it's parent, lpsched. They are:
$1 = request ID number
$2 = Login name of the requestor
$3 = Title (may be null)
$4 = Copy count
$5 = -o options
$6 = file(s) to print
In fact, you can test a printer script by simply running the script
just like lpsched runs the script. Here's an example:
cd /usr/lib/lp/model
laserjet 123 me "" 1 "landscape 12" /etc/motd > /dev/lpfile
In the example, /etc/motd is being printed with the -olandscape
and -o12 options (12 is 12 chars-per-inch for this script), and
the output is going directly to the device file (could also be
redirected to an ordinary file for testing). This is essentailly
how lpsched prints a job in HP-UX.
Model Script Features
In selecting a model script, there is a single decision at the
very beginning: does the printer support plain ASCII printing or
does it generate a special language like Poscript? HP's printing
language, PCL, is actually plain ASCII with a few enhancements
which are selected using escape sequences, so PCL is essentially
plain ASCII. Contrast that with Postscript where it is impossible
to print simple text without a large amount of special codes to
'wrap' around the original text.
So the dumb model script works for all HP printers, whether LaserJet,
DeskJet (except for the 820 and the 1000 which require driver
control of the nozzles), or dotmatrix/daisy wheel. Now the term
'works' probably needs clarification: The document you are reading
is plain ASCII and would therfore print just fine. If you need to
alter the printout such as printing in landscape mode, then the dumb
script would not work as it has no option to do this.
So we migrate to a higher level of model script for our printer to
allow for fancier printing. HP-UX has many different model scripts
available and from different sources. The primary source is from the
HP-UX Core filesets and the other source is from JetDirect software
which is supplied from Boise via the www.hp.com web page. And as
with most pieces of software, these scripts have undergone change
over the years.
LaserJet Scripts
Let's start with the original LaserJet-1 (the classic LaserJet)
which has a matching model script called (curiously enough)
laserjet. This script can rotate text 90 degrees for landscape
printing, change the default font pitch and size (options like
compressed, 10, 12) and can even print the pages in reverse
order (-orev or last page first). The last option is required for
the classic LaserJet as the pages are placed in the tray face up,
which means the first page printed will be on the bottom of the
stack and would normally need reshuffling the paper to put things
back in order.
The laserjet script will work for all models of LaserJet printers
but with some drawbacks. Options needed to control 600 dpi
printing or to select an alternate paper tray do not exist in the
script as the classic LaserJet-1 did not have such features. Enter
model scripts named for the printers they support...
The LJ-2 and LJ-3 have a few additional features but it is not
until the LJ-3Si that many new printer controls were made available.
The biggest change was the introducton of an intergrated Postscript
capability and the option to switch languages by sending codes to
the printer through PJL (Printer Job Language). Note that the LJ-3Si
*cannot* switch to Postcript automatically! Only later models starting
with the LJ-4 can do this. Some model scripts attempt to handle
the Postscript sensing/switching automatically, with varied success.
PostScript printers
So what is PostScript? It is a page printer definition language,
just like Fortran or Java, but with a specialized purpose--to form
an image on the page. PostScript is an ASCII document so it normally
contains no special binary codes. The printer accepts the language,
interprets the commands and frms an image within the printer. This
interpretive portion is one of the reasons that PostScript requires
up to twice as much RAM in an HP printer.
HP-UX has a PostScript model called (curiously again): postscript. For
a printer that only understands PostScript (HP does not make such a
printer as all HP printers start as PCL and optionally add the
PostScript capability), the dumb model script would work fine as long as
the banner page is turned off...essentially, turning the dumb script
into a simple cat command. A Postscript file would then print just
fine...no options available, but it would print with the dumb script.
However, there is no native HP-UX support for PostScript unlike other
flavirs of Unix. The SharedPrint package provides a limited PostScript
converter, and xpr can generate PostScript level 1 code from xwd
images (and there are other freeware tools). But that's about it.
Printing a plain ASCII file requires a wrapper to add the necessary
codes for prnting to a PostScript-only printer.
And that is exactly what the model script "postscript" does. It takes
a plain ASCII file and wraps it with page layout and font controls
to allow printing to a PostScript-only printer. Note that there are
very few controls available in that script, so control of paper
trays, duplexing, etc are not available. For non-HP printers, the
end user would have to add these features to a custom script. So
choose the postscript model script for non-HP, PostScript-only
printers and you can print simple ASCII files or Postscript files.
A word about sensing the language of a print job. You are probably
familiar with the file command, you know, the one that uses magic?
(actually, /etc/magic) The file command attempts to identify the
contents of a file by guessing...that's correct, guessing that a
file is an executable PA-RISC program, or a shell script or even
a PostScript file. But it performs this task by making a single
test which is to compare a magic value (string, binary number) in
a specific position in the file. The assumption is that this value
is so unique that no other file format would have this value. You
can see the potential for mistakes.
The PostScript tests made in various scripts (including the postscript
script) are somewhat successful, but far from foolprof. The /etc/magic
file has an ultra simple test: Look for the first line to contain
the string %!PS-Adobe- and it must be Postscript. However, the %
character is actually the beginning of a comment...which is optional.
So the following (perfectly valid Postscript file) will fail the
Postscript test but print just fine on any Postscript printer:
/Courier findfont 10 scalefont
setfont
/bkup { stringwidth pop neg 0 rmoveto } def
25 758 moveto
(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX) show
25 708 moveto
(This is a PostScript test file) show
25 658 moveto
(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX) show
/Palatino-Roman findfont
162 scalefont
setfont
108 36 moveto
52 rotate
(PostScript!) show
copypage erasepage
grestore initgraphics
So it is always advisable to explicitly set the -opostscript option
for HP printers...it will always work for Postscript files and saves
a lot of trees when the ASCII Postscript file is just printed as
code listing. And conversely, always use the -oascii option when printing
a plain ASCII file to a Postscript-only printer. The script makes a simple
file(1) test on the data and if the file(1) test indicates a Postscript
file then the ASCII file will be sent unprocessed, generally causing a
Postscript printer error.
PCL levels
The PCL language comes in several levels or revisions (PCL 1 thru 6
currently) where each revision is almost a proper superset of the
previous revision. The working word here is 'almost' as many of
you may have already experienced. While LaserJets are PCL printers,
compatibility with DeskJets, DesignJets and PaintJets is somewhat
difficult to predict. At the lowest levels of PCL, the language is
a slightly enhanced terminal language, based in large part on the
HP terminal codes which were first defined in the late 1970's with
the 2640A terminal.
One of the first areas of compatibility that will become apparent is
printing resolution. For many years, the LaserJet products were
limited to 300 dpi (dots per inch) but starting with the LaserJet
4 series, 600 dpi became a reality. While this made the images
sharper and less jaggy along diagonal lines, issues with text fonts
became apparent. The most common font used in plain text printing
is Courier as it is the default font for HP LaserJets. But at 300
dpi, some compromises had to be made as to the true appearance of
the font--fonts are much like artwork, with very strict appearance
controls as well as licensing from the designers. Since 300 dpi is
a fairly low resolution (a typical glossy magazine is 1800 to 2400
dpi), the Courier font is thicker than originally designed.
What this means is that a 600 dpi printer will come closer to the
true appearance of a font and thus, Courier looks thinner or 'gray'
on the newer printers. While this is a just a slight difference,
another appearance feature does make printouts different...the
physical height of the font as well as it's interline spacing, also
known as leading (pronounced led-ing). This is a typographer's
term, leftover from the days when printers used hot lead on Linotype
machines to form the text on a printed page.
Leading differences can cause a printed page to be too long, and
overflow on one printer, but fit just fine on another. Luckily,
the HP LaserJet family has interline spacing controls called
vertical spacing increment or vsi, and this spacing can override
the font's normal characteristics for lines per inch. In the
LaserJet model scripts, this option is -ovsi and is measured in
1/36th of an inch units. Thus, -ovsi4 will bunch plain ASCII
text together while -ovsi10 will look like double spacing.
All this is background as to why the term lines-per-inch no longer
applies as it does to impact printers such as dasiy wheel or other
impact printers. In the good old days, printers had fixed fonts,
cast in hardened steel and you had 132 character columns to work
with, and a choice of 6 lines/inch or 8 lines/inch. Thus, the
number of lines per page was easy to calculate. Today's page
printer (as opposed to the classic line printer) has almost infinite
control over the position and orientation of characters on the page.
Common options
There are many options available, but until recently, no man page
documented the printer scripts. If you read the lp man page,
the -o option is crypticly defined as model script dependent. This
meant that you had to read the script to determine the available
features. Around the time the 700 series workstations were first
introduced, the option 'options' became available and is invoked
with -ooptions. what this will do is to print an additional
header page with a concise listing of the model script's -o choices.
Starting with JetDirect model scripts about 1996, the net-XXXX scripts
now come with man pages (ie, man net_lj4x) which is much better than
the one page summary from -ooptions. Now an option is documented with
significantly more detail, and making it easier to understand the
more cryptic choices.
Stairsteps
In HP-UX (as most Unix's), all ASCII files are stored as variable
length records, terminated by the end-of-line character, which is
defined as the linefeed (LF). If you send the file direct to the
printer (no lp spooler or model script involved), the text is
printed correctly but not as expected by the user:
text
more text
still more text
Again, the page printers of today dutifully print what was sent
and the text goes off the end of the paper. Using a standard
HP model script and the default text mode for printing, every LF
character in the text file is appended with a carriage return (CR)
which moves the imaginary pen or cursor back to the left margin.
This is a simple filter and can only be used on text or Postscript
files.
However, graphics and bitmapped images require special escape
sequences in PCL to move around the page, and downloaded fonts
will contain special characters which are meaningful in the context
of a font but would be rendered useless if the LF characters had
an extra CR appended--thus, the -oraw option to turn off this
simple processing.
So why can't I print 2-up pages from my PC?
Well, there are actually several parts to the question. We're talking
about HP-UX, so the PC must be somehow sending the file over to the
HP-UX system. If the print job is saved to a file on the PC, then
ftp'd over to the HP-UX system, the file should be printed with the
-oraw option to prevent the corruption of imbedded LF characters.
PC Windows drivers will create a ready-to-print file, even if the print
job is plain ASCII. Even a plain DOS file will be correct as DOS
ASCII files contain CR+LF as the line termination character. Note
that ftp'ing a DOS file in ASCII mode will strip the CR since the
source/destination processing found in ftp will do the right thing
for the destination. Transferring an ASCII file in binary mode will
preserve the CR characters (which you will see in vi as ^M at the
end of every line).
The 2up or 4up option is actually fairly complex. First, the font
used for the text must be reduced such that two lines of text (about
160 characters) will fit across the page. Then codes that define
two or four logical pages are sent to the printer fllowed by a
simple graphics line for readability. Then the text is flowed into
the logical pages using the printer's automatic features to create
the images.
However, these options are ignored with -oraw since the PCL controls
for fonts, graphics and bitmaps were created for the target printer's
capabilities, ie, dots per inch, and a 2up version of the page would
require reducing all fonts to 1/4 sized dots (2 dimensions so 1/4
of the area is required for a 50% reduction), and bitmaps would also
require appropriate reduction. However, the most complex issue is
the placement of the graphic primitives (lines, boxes, circles).
In PCL, these are expressed as locations relative to the paper
size which means all grahics sequences would have to be read,
decoded and translated to their new locations in the two-up layout.
In other words, the 2-up and 4-up options are ignored when -oraw is
used, the assumption being that the file is complex PCL and cannot
be resized or rotated.
Other options
PCL files can still be adjusted for certain features...selecting a
new output tray or specifying double-sided (duplex) printing as
an example. But (and there's always a but) it doesn't always work
depending on the source for the print job. For PCL style printers,
HP model scripts always initialize or reset the printer with an
escape sequence: ESC E which places the printer into a known state.
Newer printers also use a PJL (Printer Job Language) command to
set the printer options into a standard configuration. So far,
so good. If you send a complex PCL file to the printer, the reset
will restore standard defaults with options such as duplex printing.
However, if the file to be printed came from another computer such
as a PC, the PC driver knows nothing about HP-UX or even remote
printing. Therefore, the print file will likely start with the ESC E
reset, just like an HP-UX printer script. Well, two resets are not
a problem, but here's what happens:
From HP-UX script -> PJL reset
ESC E (PCL) reset
codes to select duplex printing
Print job from PC -> PJL reset
ESC E (PCL reset
data to print
Yep. The PC file just turned off the duplex printing option because
of the PJL and PCL reset codes at the beginning of the file. So the
PC has undoe all the work of the printer script, not that this is
unexpected--PC drivers assume a direct connection to the printer
which would work just fine. So, be aware that options may appear
to be ignored due to the contents of the file you are printing.
To test this, use the head(1) and xd(1) commands to look for resets
imbedded in the data file.
The solution is to make sure the PC has already added the extra
codes to the data file--select duplex prnting or paper tray in the
PC and then print to a file. Sophisticated printers such as the
LaserJet 5Si can have PCL print jobs created that will indeed
scale to 2-up, 4-up (even more) pages, but the driver is some 5
floppies in size. Be sure to specifiy all the desired options in
the PC before printing to a file and sending the result to HP-UX.
Newer printers
We've covered a lot, but only briefly covered model script choices,
especially when an exact model script does not exist (ie, LaserJet
6 series and so on). As a rule, a lower PCL model script will work
on a newer printer since (as mentioned before), the script is just
a fancy filter for ASCII files. If a printing option which appears
in the new printer, say 800 dpi and the older model script does not
support the option, setting the printer to that resolution must be
done as part of the data file to be printed.
Another tip is to use JetDirect model scripts for all printers
starting with the LJ series 4. These model scripts all start with
net_ and have names like net_lj4x and net_lj5x. JetDirect diverges
from the classic lp spooler design in that two scripts are used to
print, one generic script designed to do the network communication
(the one found in the interface directory) and the other performs the
typical printer functions but is found in the model.real directory.
Since Boise writes these scripts, they are generally more up to date
and better tested with all the printer products. And they are
designed to support some of the special debug and testing features
found only in the JetDirect scripts. But most important: they come
with man pages. One other note about JetDirect: there have been
many versions of the JetAdmin software package and a few older
versions of the software have been included with HP-UX releases. Use
only the latest version and avoid using SAM to add, delete or modify
JetDirect printers.
While newer releases of SAM now call the jetadmin program for some
of the options, earlier versions of SAM called internal portions of
jetadmin scripts but did not set all the required environment
variables. SAM also forgot to include the bootp setup steps for a
new JetDirect card. To be safe, follow the instructions in the
JetDirect User Guide shipped with the card.
---------
In the last article, I discussed the concept of SysV spooling where
print processing is handled primarily by a shell script. This article
will go into the anatomy of a typical printer script and how you can
create a custom script for a printer. The term model script refers to
files kept inthe template directory where reference copies of scripts
are kept. When a printer is added to the system, a copy of the
appropriate model script is placed into the interface directory and
renamed as the print queue name.
The typical tasks of a model script are to take command line options and
together with the print data, process the data stream and output the
result as standard-out which is usually directed to the device file for
the printer. Within the script, options are decoded and environment
variables set, followed by checks for a banner and/or information page
and then reading the print data stream and sending the result to stdout.
There are 6 parameters passed to the script by the spooling system and
this means that the script can be tested offline by starting the script
in the same way. For a script called "prntest", you could test the
operation by:
prntest JOB MYUID TITLE 1 OPTIONS <data>
and the output from this script would be the result sent to a printer if
configured into the spooler. This is a great way to test offline to see
the results. Another tip is to pipe the results through vis or cat -v
as in the following:
prntest JOB MYUID TITLE 1 OPTIONS <data> | vis -x -n
and in this way, any special characters and escape sequences can be seen.
The options: JOB MYUID TITLE 1 OPTIONS are arbitrary when testing offline
and correspond to:
JOB = lp spooler job ID#
MYUID = user ID the started the job
TITLE = text given with lp -t
1 = copy count for this job (just 1 copy for testing)
OPTIONS = all the -o options
<data> = the file(s) to print
We'll look at both the laserjet script which is more sophisticated but
contains the basic elements. A more sophisticated script such as the
net_lj5x is used for network printing is built on the same outline but
is just a bit too complex to be used in these examples.
The major sections of a printer script are:
1. Variable initialization (default values)
2. Parameter decoding and variable settings
3. Output banner page (if selected)
4. Output option information page (if selected)
5. Repeat up to number of copies selected:
5.a. For each file in parameter $6 and beyond
5.a.a. Preset/initialize the printer
5.a.b. Setup stty if needed
5.a.c. Special handling for reverse order or normal
5.a.d. Cat the file or call filters for special layouts
5.b. Reset the printer to flush last page
5.c. If RS-232, use stty to flush any data in buffers
6. Finish the script
So let's start with the first section as we design a model script.
You'll need a technical reference manual for the new printer which
outlines all of the features you'd like to use. Features might be:
..Font controls including point size, spacing (vertically and
horizontally), family, compressed, expanded and so on
..Portrait vs. landscape printing modes
..Duplex (double sided) and paper tray (in/out) controls
..language switching (ie, ASCII, PCL, Postscript, HP/GL)
..reverse-order printing
and so on. Many of the printer's builtin features may apply only to
simple ASCII text whereas special print jobs with built-in printer
codes will need to be left untouched. Note that the majority of
model scripts do not process each line of the print data image but
rather use presets to format the text. An exception is the HP-supplied
postscript script which reads each line of the data file and encapsulates
it into a legal Postcript command.
With this list in hand, make up a set of -o options you'd like to
use. A good starting point is to look at the laserjet script or read
the man page for net_lj5x (if you have newer JetDirect software loaded
on your HP-UX system). The -o options are somewhat standardized so
it would be easier on users if -olandscape was used in your script
rather than -olongways or something similar.
You'll want to have a -oraw option which essentially ignores any special
setup for fonts and page layout as this option is used to simply cat(1)
the data direct to the printer without any special processing. You'll
probably want a provision for banner or burst pages to separate multiple
jobs stacked on the same printer. Don't forget an option to turn the
banner page off too.
The first steps are to setup a printer initialization string, set a
default language (if not already set) and handle tty settings if stdout
is connected to a serial device. It's a good idea to assign the first 4
values as in:
REQID=$1
USERID=$2
TITLE=$3
COPIES=$4
The next two values ($5 and $6) may have zero, one or many values so
they will be handled in a loop to extract all the items.
The next step is global settings and variable initialization. A good
debugging technique is to use the set -u option in the script to keep
uninitialized variables from causing silent errors. You may also want
to keep a debug option (like -odebug) which will trace the script's
activities during execution. For example, using set -x inside the
script will trace the script statements to stderr, and you can use
exec to redirect the trace to the lp log file as in:
exec 2>>/var/spool/lp/log
set -x
From this point in the script, the statements will echo to the lp
log file. The exec statement might also redirect stderr to stdout
with: exec 2>&1 This is not done in the example laserjet script.
Another step is to handle cancel and disable traps gracefully.
In the laserjet script:
trap "echo 'Terminated: $reqid' >> $log; \
trap 15; kill -15 0; exit 0 " 15
In this case, a signal 15 is sent by the lp spooler via the cancel or
disable command will be trapped and produce the string: Terminated
$reqid which is copied into the lp spooler log file. This is a required
feature of all model scripts to allow cancel and disable to work
correctly. You might want to add more information for the log file.
Don't output anything to stdout such as an echo since the cancel or
disable may be the result of a jammed printer or wrong language setting.
A common technique to initialize all the options is to use a default
value such as "def" which will be tested later in the script. If you
look at the "laserjet" script in /usr/lib/lp/model (/usr/spool/lp/model
for 9.x) you'll see this technique starting about line 212. Here is
a portion of the code:
# Initialize option variables to default values
length="def"
pitch="def"
spitch="def"
hsi="def"
quality="def"
squality="def"
spacing="def"
sspacing="def"
lpi="def"
vsi="def"
Now we need to process all of the -o options. They are collected by
the spooler into a single string. For example, the command:
lp -o12 -olandscape -oduplex
will pass $5 to the model script as "12 landscape duplex" which means
that they can be sequentially processed in a loop:
for OPTION in $5
do
case "$OPTION" in
-10 | 10) # font pitch set to 10.00 cpi
pitch="10";;
-12 | 12) # font pitch set to 12.00 cpi
pitch="12";;
-c | c) # font pitch set to compressed print
pitch="c";;
-e | e) # font pitch set to expanded print
pitch="e";;
and so on. Be sure to include $OPTION in double quotes to preserve
the string characteristics within the case statement. You can see
the basic technique in the laserjet script starting about line 246.
Notice that two forms should be handled when testing: -10 | 10
means that either string will set 10 characters per inch pitch.
The case statement allows multiple tests for the same option. For
instance, raw mode can be selected with -or as well as -oraw.
Now that all the options have been processed, it's time to run through
all the files which are stored in $6 and beyond. A simple way to handle
multiple files from $6 on is to shift all the previous parameters off
the command string, leaving just the filenames. This is done at line
436 and the variable $files will now have all the filenames which can be
processed in a for loop:
# Assume that the rest of the arguments are files
shift; shift; shift; shift; shift
files="$*"
Just before processing the files, it's time to produce the banner
page. A good technique is to make the banner page section into
a procedure. In that way, the need for a banner page can be put
into a simple test rather than a very long if statement. Be sure
to put the procedure prior to the test. The procedure is skipped
by the shell when it appears in the code and is invoked only
when called later in the script. Details on the banner page
procedure are at the end of this article.
In the laserjet script, it gets a bit complex when handling 2 and 4
pages per page. The first step is to default most of the options. This
is because dividing the page into two or four sections requires all
other options to be disabled. Then the script handles portrait versus
landscape and downloads an appropriate font to the printer.
Once that has been done, the script starts an outer loop to repeat per
the number of copies needed and an inner loop to go through each file
specified for printing. Prior to actually cat'ing the file to the
printer, all the settings are checked and the appropriate codes are
echo'ed to the printer. This starts at line 500 where the copy count
loop begins and a few lines later, the file processing loop begins:
# Print the spooled files
i=1
while [ $i -le $copies ]
do
for file in $files
do
An example of setting an option is the first test for orientation
where a case statement does nothing if $orientation="def", or
echo's the appropriate escape sequence to select landscape or
portrait mode. After several pages of option processing, the
actual output occurs starting at line 659 where the stty settings
are handled for raw mode. Then a test is made for reverse page
printing (handled by a program called lprpp) and multiple pages
per page printing (handled by divpage):
# If raw mode and RS232 interface used
# turn off output processing
if [ "$outputmode" = "raw" -a -t 1 ]
then
stty raw 9600 -opost -parenb cs8 ixon \
-istrip clocal tab 0 <&1 2>/dev/null
echo "\033&k0G\c" # Reset line termination mode
fi
Tests are made for cooked versus raw processing. Here is an
important note: raw processing is simply a cat command but for
cooked processing (needed for simple ASCII files), the lprpp
program is used to insert a carriage return (CR) after each line
feed (LF) character which in Unix is the end-of-line character.
If a plain ASCII file is printed with -oraw then the text will
stairstep down the page since no CR characters will be inserted.
Keep this in mind when you design a custom model script. The
HP LaserJet family of printers allows the setting of an automatic
handling of the LF-only characteristic. By setting the line
termination sequence to treat LF=CR+LF, the printer can handle this
task, although the laserjet script does not use this feature.
Finally, at the bottom of the file loop, the printer is reset
to default settings, the next file is processed and once the
list of files is exhausted, the copy count in incremented and
the file loop is repeated:
fi
echo "\033E\c" # Reset Printer
echo "\033)0B\c" # Secondary character set line draw
echo "\033&k2G\c" # Set line termination mode.
done
i=`expr $i + 1`
done
The very last step is to set stty again at the end. This is due
to a characteristic of the serial device driver which is reset
to 300 baud when the device file is closed. This means that any
queued data in the serial buffers at the end of the file will be lost
unless the stty command is used to set the same values...the
driver will flush any untransmitted data before executing the stty
command:
# RS-232 interface insure all buffers are
# flushed to printer
if [ -t 1 ]
then
stty raw 9600 -parenb cs8 ixon
-istrip clocal <&1 2>/dev/null
fi
exit 0
Banner Page handling:
---------------------
The banner page is useful in separating print jobs on shared printers.
Shared printers will often have jobs from many different users and
keeping the output easy to separate works well in this environment.
The banner page can be just a simple job title and user ID to an
elaborate job that selects colored paper from another bin for the
banner page. By making the banner page a procedure, it can be
tested and called as necessary. If your script needs to reverse
the order of the pages (as in the original HP LaserJet printer
which stacks the paper upside down), the banner page would be called
at the end of each job:
do_banner()
{
# Print the standard header
x="XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
echo "\r\c"
echo "$x\n$x\n$x\n$x\n"
In this example, a sereies of XXX lines is printed at the top of
the banner page. Then the user ID is printed using the block letter
program banner, followed by the user ID:
banner `echo $user`
echo "\n"
user=`pwget -n $user | line | cut -d: -f5`
if [ -n "$user" ]
then
echo "User: $user\n"
else
echo "\n"
fi
The user name is pulled from the passwd file using pwget. If no
user information is found in the GECOS field of /etc/passwd then
just a new line is output. Then additional information is printed
and the page is ejected with \f, the formfeed character:
echo "Request id: $reqid Printer: `basename $0`\n"
date
echo "\n"
if [ -n "$title" ]
then
banner "$title"
fi
echo "\f\c"
}
As you might gather form this article, writing a model script does
require some scripting skills as well as understanding the printer
you wish to control. The "dumb" model script is a good place
to start reading a simple printer script and build on the framework
by adding your printer's specific code.
--
--
?
/'^'\
( o o )
*====oOOO===(_)===OOOo======*=====================================*
| Bill Hassell | Hewlett-Packard Response Center |
| SysAdmin Oooo. | b...@atl.hp.com / Atlanta, GA. |
*======.oooO===( )========*=====================================*
( ) ) / "There are two types of computer users in the
\ ( (_/ world...those that have lost data, and those
\_) that are going to." (blh, circa 1972)
John Pezzano
Won't pr(1) do that for you?
Frank Slootweg
I (not the original poster) thought of that (pr(1)), but thought that
Wayne want the *current* date/time, not the *modification* date/time of
the file. However your (John) response prompted to look again at pr(1)
and if Wayne can use a pipeline, I think that indeed pr(1) can do it:
$ ll /etc/copyright
-r--r--r-- 1 root sys 1107 Apr 26 1999 /etc/copyright
$ date
Tue Sep 25 16:29:54 METDST 2001
$ cat /etc/copyright | pr -h `whoami` | head -6
Sep 25 16:29 2001 franks Page 1
(c)Copyright 1983-1996 Hewlett-Packard Co., All Rights Reserved.
$
I.e. by piping the output to "| pr -h `whoami` | lp ....", Wayne can
probably do what he wants.
Wayne, does that indeed solve your problem? If not, why not?
Wayne Patton
problem I also have is that we print postscript files and want to do
the same thing . . . I am now searching for postscript info, for a way
to maybe write a "filter" to insert the header I want on each page . .
thanks
wayne
On 25 Sep 2001 14:34:51 GMT, Frank Slootweg <fra...@neth.hp.com>
wrote:
b...@atl.hp.com
> In reviewing so far, I think pr would work fine for text files. The
> problem I also have is that we print postscript files and want to do
> the same thing . . . I am now searching for postscript info, for a way
> to maybe write a "filter" to insert the header I want on each page . .
Postscript has an extensive macro capability, much like PCL. I would
get a good book on Postscript to see what you can do. The tricky part
is inserting the codes into the data stream at the beginning. It would
be nearly impossible to do with a filter as Postcript files can contain
pictures, bitmaps, graphics, multiple fonts, etc, all making it very
difficult to guess where a page starts or ends (ie, a plain ASCII
file using something like pr). Postscript is a page layout language
rather than a stream of printable characters.
---