Device Definition Data Base

 css.devices(C)

Name

css.devices

Platforms

Unix, Windows NT

Description    

The file css.devices is a data base describing the CSS devices (printers). This data base is used by all CSS programs and utilities. The printers are defined by giving a set of capabilities and by describing how operations are performed. Initialization and termination sequences are included in css.devices.

In contrast to termcap(5) the definitions in css.devices do not serve as a reference for the CSS programs. Rather they have to be compiled with the aid of the csa(U) administrator utility into an internal, very efficient format. Thus any changes to css.devices become active only after a successful compilation.

Capabilities

The following entry describes some of the capabilities of a Brother HL-8 running in LaserJet II mode:

Definitions may span to multiple lines by giving a backslash '\' as the last character of a line. Empty fields can be included for readability and are most often used between the last field on a line and the first field on the next. Capabilities in css.devices are of three types: Boolean capabilities, which indicate that the printer has some particular feature or that a certain mode of operation shall be applied, numeric capabilities giving the size or count of something, and string capabilities, which give a sequence that can be used to perform particular printer operations or define a file name to be downloaded to the device.

Device definitions may contain an include statement:

1|Printer 1:include=file:

Include files may however not span device definitions, i.e. they may only contain capabilities of the devices they have been entered for. Multiple as well as nested include statements are allowed. The include file may be specified absolute (name starting with a slash ‘/’) or relative. Relative files are searched for in $base_dir/include (normally /usr/lib/css/include). Within include files the line continuation indicator ‘\’ may be omitted.

Types

Each capabilitiy has a two or more letter code. For instance, the fact that a printer shall be 'automatically selected', even if no device had been entered in the lpr(U) command line (i.e. it is a so called system printer), is indicated by the capability as. Numeric capabilities are followed by the character '=' and then their decimal value.

Any character can be given as three octal digits after a \ or as two hexadecimal digits after \x. Preceding a character by the tilde '~' will set its high order bit (0x80). Combinations such as '~^x' and '~\E' are supported. If it is necessary to place a CSS meta character '=', ':', '^', '~", '/' and '\' in a capability, it must be escaped by a \ (\=, \%, \:, \^, \~, \/ and \\) or encoded in the above octal or hexadecimal form.

Basic Capabilities

The dv capability serves to establish a connection between a CSS device and a Unix device. If the string starts with a slash '/', the value is taken as an Unix device file name and used as is. All other values are combined with the leading string '/dev/lp' (e.g. dv=02 will expand to '/dev/lp02'). If no dv entry is present, the name is constructed using '/dev/lp' and the logical device number (e.g. printer no. 5 is attached to /dev/lp5). As an exception to this rule, printer no. 1 attaches to just /dev/lp. To set the terminal I/O modes (such as baud rate, parity, number of stop bits, type of handshaking and all other line attributes) the setmode(U) utility should be used.

dv=//host-name/printer-share-name

Please note, that within css.devices all file names must be entered using the Unix directory separator '/'. The colon ':' after the drive letter, must be preceded by the backslash '\' (BS). Failing to do so would cause CSS to assume the end of the parameter entry:

C\:/dev/printer1

You may also enter a disk file as target device. This feature is often used to verify the output generated of device definition. The contents of this file is overwritten by each printout. E.g.the printer defined by the CssNT Setup program has the entry

dv=C\:/CssDev1.txt

Therefor, output will be directed to the disk file C:\CssDev1.txt.

All CSS programs do accept a symbolic name in place of the logical device number. The symbolic device name may be defined by the dn capability. The string is case insensitive and should not exceed 16 characters. Embedded spaces are not allowed.

The dt capability (device type) serves to group printers by type. CSS allows report routing of binary reports only to devices of the same type. Therefor the same type should be assigned only to devices with identical control language (e.g. HPGL5, PostScript). The string is case sensitive and should not exceed 14 characters.

Whenever CSS has to share a printer within distinct virtual environments or with another software package (such as alternate spoolers or office automation software with integrated spooler), a lock file name, indicating the current use of a device may be defined by the el-parameter. Any printer with such an entry will only be used, if the corresponding lock file will mark the device as currently no in use. The locking method may be chosen through the ext_lock parameter in css.default. If the printer is available, CSS signals its use by creating the file or putting an advisory lock onto the file according to the lock method chosen. The name of the lock file must be specified in absolute format (i.e. must start with the slash '/' character (e.g. /usr/spool/lock/lck..lp2). Names beginning with '/usr/spool/css/LCK..' may not be used.

The access path of the lock files must exist and be accessible by all users (see mkdir(1) and chmod(1)). When used in combination with the EXT_LOCK=sema parameter of css.default, it is the responsibility of the system administrator to assure that no unused lock files exist in order to provide undisturbed operation. Notably kill(1) commands with the -9 option should be avoided, since they disallow the killed process to cleanup its environment and to terminate in a decent way. To achieve a correct state after a powerfail, existing lock files may be removed by appropriate rm(1) commands in the file /etc/rc. In any case EXT_LOCK=lock (the default) should be favored, since it provides clean and safe locking without the danger of zombie file semaphores.

The el capability may also be used to 'cheat' CSS by assigning more than one logical device to a single physical device.

The as boolean capability is used to enable an automatic printer selection for reports that have been created without specifying a target device by the d- or r-option of the lpr(U) command. Whenever such a report is spooled, CSS will scan the as devices and - provided that the requested form is mounted - choose it for output. The as parameter should not be used for printer that have to be selected explicitly (typical for daisy wheel and off-site printers). All devices having as set are referred to as main- or system-printers.

The fact, that a particular model is not able to print in elongated mode (CSS control sequences e9 and e10), is stated by the es capability (elongate by spaces). To avoid misalignment CSS will elongate by spaces, i.e. emulate the elongate attribute by inserting a space after each character on such printers.

The et capability (expand tabs) causes tab characters to be expanded to the standard positions (9, 17, ...). This is especially useful for ports that do not support stty(1) settings.

Since device descriptions of laser printers often include form definitions such as orientation, number of lines per page and margins are often defined by the use of (form-) conditional bor entries, different logical forms (see css.forms) may be printed on the same physical paper type without the need of a form change (automatic form change). Such form groups may be defined by the use of the map capability. For instance, the entry map=a,b,e,f combines the forms A, B, E and F into one group and will allow printouts onto one form of the group, if any other form of the same group is mounted as the current form of the target device. To calculate the page- and line-length however, the definitions of the requested form will be used. Multiple map entries may be defined per device.

The xmap capability (exclusive map) allows to combine all forms except the ones defined in the xmap definition. Map entries are still allowed, but are restricted to subgroups of the xmap forms.

Printing of one or more banner pages is controlled by the bp capability. However, banner pages are generated only, if the form used includes the corresponding entry with the same name.
 

The syntax of the box and eox capabilities is:

name [<form>][/flag...][%var.eq.val...][{copy}][[page]][(line)][-option...]=value

Multiple entries (up to a system imposed limit) of the above capabilities are allowed. Output occurs strictly in the order of the definitions. By stating conditions, the selection of the statement may be restricted.

The conditions available are:

The following table defines the permissible conditions:

Options:

1|Test (Page Printer):pg:\
:eol=<eol>:eop=<eop>:eor=<eor>

The input file

Line1 linefeed
Line2 linefeed formfeed

produces the output

Line1 <eol> linefeed
Line2 <eol> <eop> linefeed formfeed <eor>

eol and eop l-option:

This option suppresses output of linefeeds (hex 0x0A) for all lines that evaluate one or more eol definitions to be active. If an active eop definition has the l-option set, the linefeed character of the last line will be suppressed (which is redundant to eol ($) -l). Of course, linefeeds may still be generated explicitly within the eox control sequence.

eop f-option:

This option suppresses output of form feeds (hex 0x0C) even if the device has been defined as page printer (pg boolean). The f-option is useful for printers that require special control sequences to end a page (e.g. single sheet feeders). It may also be helpful to develop PostScript definitions.

Suppression of form feeds is active for all pages that evaluate one or more eop definitions with the f-option set, to be active.

Example:

Common options:

Options without argument may be grouped following a single  ‘–’ character. Arguments may immediately follow the option character or may be delimited by a space.

All box- and eox-capabilities of a device are processed in the order of their definition. If conditions are present, an evaluation cycle takes place prior output. The use of dynamic condition flags allows to define if, elseif, else conditions, which ease the definition of processing variants with a default:

For a description of the operational flow of a printout see also fdu(U).

The following ordering variables are supported by CSS:

The syntax for ordering variables is:

  %[flags][(field)][[offset]][max][.min]['format']name
 

For instance, the definition bor=/usr/lib/css/mac/%+1L/%P is converted to /usr/lib/css/mac/G/prog_xy (Assumption: LANG=german). The fdu(U) utility has been designed to generate LaserJet macros. It can however also be used to easily create any type of binary bor- and eor-files by using its data command. Example:

 
1. A laser printer with two paper trays is reserved to produce correspondence. The first page of each letter shall be taken from tray one, all other thereafter from tray two:

 
2. A second double tray printer is loaded with A4 sheets in tray one and A5 sheets in tray two. Printing on both formats in portrait and landscape mode shall be managed without the need of form changes:

 
3. When printing onto the standard form A, setting the condition flag n on the command line (lpr -C n file...) shall add the current page number as header (text Page x of y). To still yield correct page breaks, an additional two lines must be taken into account in the bor setup:

Assumption: Form A ps=64

 
4. While printing checks, line 46 shall be printed in OCR font. The companies bank-account number has to be added as a constant (<program data+account-no>):

Mode 1 / the program produces lines of variable size (as in C):

 
Mode 2 / the program produces lines of fixed size (as in Cobol), so that left positioning with backspaces is required:

 
The if1, if2, tf1 and tf2 capabilities allow the definition of Unix file names (absolute path names). If the files specified exist and are readable (see chmod(1)), their content will be downloaded after bor processing (if1 and if2 file) and before eor processing (if1 and if2 file) respectively. The init- and termination file names may be constructed dynamically at runtime by the use of ordering variables. Since the same features are provided by bor and eor, these parameters may be dropped in a future CSS release. They remain supported for backward compatibility reasons only.

The op capability (output pipe) lets you define a process that is used for output in place of writing to the dv device file. The access path of the program or shell script must be entered as absolute pathname, i.e. must start with the slash '/' character and the named file must have execute permission. Prior to call of the op process an ordering variable evaluation cycle takes place. The CSS despooler subsequently feeds the report into the standard input of the named program. This feature gives the system integrator complete control to accomplish tasks such as opening connections to network nodes, dial a remote system, routing output to other processes, creating accounting information, sending mail to users or post-processing data.

Example:

/etc/css.devices:

 
/usr/css/lp_filter:

If the op process returns an exit status other than zero, the report will be set to the 'hold' status and retained in the report queue. The op parameter is not available in CssNT.

The wfc capability (write fail command) can be used to define a command that is executed when writing to the device fails for more than wft (write fail timeout) seconds. The access path of the program or shell script must be entered as absolute pathname, i.e. must start with the slash '/' character and the named file must have execute permission.

Example:

/etc/css.devices:

 
/usr/css/printerFail:

The vd boolean capability is used to identify device definitions dedicated for the report preview of css(U) and WinCss(U). Devices having vd set, are invisible to all CSS utilities, they can however be assigned to the VIEW_DEVICE and WINCSS_VIEW_DEVICE parameters in css.default. A common use of view devices is to nullify hard coded control sequences with tr definitions for undisturbed display. As an example, suppose we have an application written which generates print output for a specific printer model and we do not have the time to rewrite the programs to suite the hypothetical CSS printer. The obvious solution to achieve device independence, is to use tr definitions to replace the e1..e127 capabilities:

To set italic printing on, our device dependent program writes 'ESC I 1' (0x1b4931). The above definition causes CSS to translate this control sequence to 'ESC ( s 1 S' (the HP code to turn italic printing on) during output. The program has migrated to be device independent without changing one line of code. But one problem remains to be solved: the report preview feature of css(U) and WinCss(U) use a very simple device model for display preparation. In fact it has no capabilities defined at all, causing each 2 byte escape sequences of the CSS hypothetical printer to be silently ignored. This device definition is not well suited to process output of our example application and the report preview will contain odd characters resulting from escape codes. What we need is a device that nullifies all control sequences:

Using the above device, 'ESC I 1' and 'ESC I 0' will be replaced by nothing (the null string) when sent to the display. To connect a view device to the css(U) program, the VIEW_DEVICE parameter in css.default must be set to the proper device number, e.g. VIEW_DEVICE=901.

The WinCss report view module recognizes some basic formatting codes:

Consequently, the WinCss view device could be defined as:

To connect this view device to the WinCss(U) program, the WINCSS_VIEW_DEVICE parameter in css.default should be set to the corresponding device number, e.g. WINCSS_VIEW_DEVICE=902. The WINCSS_VIEW_DEVICE parameter defaults to VIEW_DEVICE, in which case no formatting codes should be used.

Formfeed / Linefeed

The ps capability defines the number of lines at 6 LPI the printer will advance between two consecutive form feeds. Printers that remain at their home position when receiving the second formfeed should not define ps (or ps=1) since not doing so, prevents the page parity feature from operating correctly. A ps value of 0 or 1 will cause CSS to never send a explicit formfeed, but to emulate form feeds by an appropriate number of linefeeds. The size information thereto is taken from the forms data base. Any other ps value causes raw form feeds to be sent whenever the form size (see css.forms / ps parameter) is identical.

The cr boolean causes a linefeed to carriage return / linefeed conversion to be performed, when set.

By the use of the pg boolean, a device can be defined to operate in page-printer mode, i.e. to cause the last page of any report to be terminated by a formfeed character. This capability should normally be specified for laser printers.

Character Translation

The tr capability is used to define string or character translations. The input string has to be defined between the first and the second equal '=' character. The output string is defined following the second equal sign. Embedded equal characters in both strings have to be escaped as usual ('\='). No restrictions exist to the size of the of neither of the strings. The output section may define download files and/or include ordering variables like in box and eox. Form, flag, page and line conditions as well as common options can also be specified (syntax see box). Of overlapping input strings, the shorter value is favored:

tr=1=A:tr=12=AB:

The second tr string is never translated!

Dynamic condition flags may be used for context sensitive control. If for example a flag shall be set, whenever pattern is found in a document, use:

:tr -s f=pattern=pattern:# retain pattern:\
:eop /f -c f=value...:# next eop, then clear flag:

Escape Translation

To enable the use of the features of today's printer models and still retain device independence, CSS provides a hypothetical printer model. This imaginary printer is sensitive to the control sequences Esc,1 to Esc,127 (hex 0x1B 0x01 up to 0x1B 0x7F). At printout time, these control sequences will be translated to the values defined by the e1 up to e127 capabilities of the target device. If no related entry can be found, the Esc control is silently ignored and no output is performed. For instance, if a device entry defines :e5=^N: and a program writes Esc,5 CSS will send a Cntl-N to the printer. Escape translation can be turned off by the bm capability or temporarily by the B-option of lpr(U). The assignment of the Esc controls to 'real' printer features is up to the user. However, to enable CSS to provide the automatic character pitch selection (see a-option of lpr(U)), the meaning of e1 up to e4 is predefined:

e1	change print density to 10 cpi (chars per inch)
e2	change print density to 12 cpi
e3	change print density to 16.5 cpi
e4	change print density to more than 16.5 cpi

If a printer in use is not capable to change its character pitch, e1 to e4 should not be defined. If only some of the above cpi changes are not supported, these entries should be defined equal to the next higher (denser) value. If no denser cpi is possible, the sequence for the densest value must be set. The automatic cpi selection (see a-option of lpr(U)) causes CSS to use the lowest possible pitch (i.e. the largest possible font) for the widest line of a report to fit on the current form (see css.forms / ll capability).

The syntax of the enn capabilities is:

name [-option...]=value

Options without argument may be grouped following a single ‘–’ character. Arguments may immediately follow the option character or may be delimited by a space.

Summary

The hypothetical printer model used by CSS may have features defined, that are not available on each physical device. Undefined Esc controls in the range between Esc,1 and Esc,127 (e1..e127) are thus discarded during output. This may not be the desired mode of operation e.g. for printers used by word processors. To achieve transparent data delivery without escape translation, automatic pitch selection, cr and pg processing, the target devices should be defined as 'binary mode' (bm) printer. To set a regular CSS device into binary mode for the duration of one single report, the B-option of lpr(U) may be used. In binary mode the lpr(U) a-option is ingnored and the automatic termination of the last page (pg-parameter) is not performed.

Remote Printing

The definition of the rpm capability causes CSS to ignore the dv and op parameters and connect to remote devices through TCP/IP sockets. The available settings for rpm are:

Value	Protocol	Description
lpd	BSD lpd	This is the most widely used protocol for remote printing. Almost every print box on the market supports lpd.
rlpd	relaxed lpd	Relaxed lpd is a Unitec variant of BSD lpd. Especially with large reports, it may be considerably faster than its standard counterpart. It is however not supported by each print box. Wherever possible, you should try this protocol prior the use of plain lpd.
rtel	reverse telnet	Rtel is available on some print boxes, but may exist in several variants. The CSS implementation has been fully tested with the Lantronix MPS server.
pros	Axis Pros	Pros can be used with the hardware of Axis Communications.
raw	raw TCP/IP	Some print server boxes allow to directly address their printer interface by specifying a special port number. The raw protocol may be used to connect to such ports.

The rph capability specifies the host address of a remote print server and is a required entry for all protocols. The value can be set in the standard four number notation (e.g. "128.41.1.11") or as symbolic alias name as defined in the TCP/IP hosts file. On Unix systems, this file is located in the /etc directory. On Windows systems the location varies depending on OS type and version. Each line in the hosts file contains the numeric IP address and one or more symbolic alias names.

The rpp capability specifies the TCP/IP port number to be used for the connection to the host identified by the rph entry. The value can be set as number (e.g. "515") or as symbolic alias name as defined in the TCP/IP services file. On Unix systems, this file is located in the /etc directory. On Windows systems the location varies depending on OS type and version. Each line in the services file holds the service name, a port number and a port type (the type should mostly be tcp). Port numbers are usually predefined by the print server manufacturer or by the protocol, it thus makes little sense to use symbolic names. Except for the raw protocol, commonly used defaults are defined.

The rpq capability identifies the queue name of the remote print server. This entry is named differently by almost each manufacturer and also referred to by 'remote port', 'remote service name' or 'remote printer name'. If your hardware has multiple queue names to choose from, you should select a queue that does not perform any implied actions on the data sent to it. If e.g. you get additional empty pages at the end of each report, you may have chosen a queue that appends a form feed to the print jobs it receives. The rpq entry is required by all protocols, except raw.

The rpr capability identifies the remote port number. It is transmitted to the server in the rtel protocol, but not required. It may also be used with pros as an alternative to the rpq parameter to specify the printer number handled by the Axis box (e.g. rpr=2 is the same as rpq=pr2).

The rpw capability identifies the password required to connect to the remote print server. It is used with the pros and rtel protocols. The default for pros is 'netprinter' and for rtel the empty string.

The remote print definitions for a Lantronix MPS server (e.g. named MPS_0d242f) would look like:

:rpm=rlpd:rph=128.41.1.11:rpq=MPS_0d242f_TEXT:...

For an Axis box the definition could be:

:rpm=pros:rph=128.41.1.12:rpq=pr1:...

or equivalent:

:rpm=pros:rph=128.41.1.12:rpr=1:...

Notes

Although the use of the Esc control sequences e5..e127 may be assigned freely, for compatibility reasons (e.g. with ulp(U)), we suggest the following standard:

e5	correspondence quality on
e6	correspondence quality off
e7	near letter quality on
e8	near letter quality off
e9	elongated printing on
e10	elongated printing off
e11	italic printing on
e12	italic printing off
e13	underline mode on
e14	underline mode off
e15	advance to superscript
e16	reset superscript
e17	advance to subscript
e18	reset subscript
e19	load alternate character set
e20	restore primary character set
e21..e127	unused, at disposition

If a printer model does not support a capability, the corresponding parameters should not be specified. The despooler program lpd will thereafter ignore the escape codes while printing on that device.

Files

See also

csa(U), css(P), css.forms, lpr(U), setmode(U)

Back to top