man ptal-printd (Administration système) - hpoj reference: CWptal-printd

NAME

hpoj reference: CWptal-printd

SYNOPSIS

ptal-printd devname [options...]

DESCRIPTION

The CWptal-printd daemon creates a special file (specifically, a named pipe), which simulates a traditional unidirectional printer character device. Any data written to this pipe special file, presumably by the print spooler, is correctly routed through CWlibptal, CWptal-mlcd, and on to the printer. Using CWptal-printd makes it easy to set up a print queue in conjunction with the hpoj software, because given a particular print spooler, almost exactly the same procedure is used to set up printing with an hpoj-driven multi-function peripheral as would be used to set up printing with a single-function printer. The only difference is where the print job data goes; instead of printing to something like CW/dev/lpCI0CW or CW/dev/usb/lpCI0CW, the print queue is configured to print to something like CW/var/run/ptal-printd/mlc_par_CIOfficeJet_Series_700CW or CW/var/run/ptal-printd/mlc_usb_CIOfficeJet_G85CW. Important: If you're using CUPS (Common UNIX Printing System) as your print spooler, then CWptal-printd likely will not work for you, because for security reasons newer versions of CUPS refuse to print to arbitrary file locations. The hpoj software now includes a CUPS CWptal backend (CWptal-cups) which you should use instead of CWptal-printd. Click here for more information on setting up printing with the hpoj software. Syntax The CWptal-printd command-line syntax is as follows:

OPTIONS

•
CWCIdevnameCW is the PTAL device name (required)

Recommended options:

•
CW-like /dev/lpCI0CW Copies the pipe's permissions (mode, owner, and group) from the CW/dev/lpCI0CW device node. It's probably OK to specify CW/dev/lp0 regardless of how your device is connected, as long as the specified device node is actually present on your system. However, this is not necessarily the case anymore with the advent of CWdevfs on some distributions, so CWptal-init now caches these permissions in a separate file (CW/etc/ptal/ptal-printd-like) and passes it to "CWptal-printd -like".
•
CW-morepipes CInCW Creates n additional pipes (for example, 9) for this device, in case you want to set up multiple print queues.

Other possible options (not necessary in most cases):

•
CW-pipename CIfilenameCW Sets name of pipe. The default is based on the PTAL device name, with colon characters mapped to underscores.
•
CW-pipepath CIpathCW Sets path of pipe if name doesn't contain a path (i.e. no slashes). The default path is CW/var/run/ptal-printd.
•
CW-colon CIcharacterCW Sets character to replace colon when using default pipename, since colons have a special meaning in CW/etc/printcap. The default is the underscore character.
•
CW-mode 0CIoctalCW Sets pipe permissions (use leading CW0 for octal). The default is 0622 (user read/write, group/other write-only). Since it is set explicitly in the code, the CWumask setting doesn't affect it.
•
CW-owner CIuidCW Sets pipe owner (numeric user ID only). The default is the current effective UID.
•
CW-group CIgidCW Sets pipe group (numeric group ID only). The default is the current effective GID.
•
CW-nofork Runs in the foreground instead of the default as a background daemon.
•
CW-retrydelay CIsecondsCW Sets retry delay if PTAL print-channel open fails. The default is 30 seconds.
•
CW-timeout CIsecondsCW Sets idle timeout, where the PTAL print channel is closed if no data or end-of-file is received. The default is no timeout.
•
CW-uel, CW-nouel Enables/disables wrapping jobs with UEL/end-of-job escape sequences. The default is disabled.

NOTES

Previous versions of CWptal-printd used CW/dev/ptal-printd as the default CW-pipepath. That has now been changed to CW/var/run/ptal-printd, because some platforms have a read-only CW/dev file system. For the sake of backwards compatibility, CWptal-init attempts to create a symlink from CW/dev/ptal-printd to CW/var/run/ptal-printd so you don't have to recreate your print queues when upgrading from a previous hpoj version. If you're setting up multiple print queues to the same device, then you should ensure that the "CW-morepipes CInCW" option is passed to CWptal-printd. This option causes the specified number of additional pipes (for example, 9) to be created with the same base name as the main pipe but with two underscores (or the character specified by CW-colon) and a 1-based index appended, for example, CW/var/run/ptal-printd/mlc_usb_PSC_750, CW/var/run/ptal-printd/mlc_usb_PSC_750__1, CW/var/run/ptal-printd/mlc_usb_PSC_750__2, etc. Simply set each print queue to send its data to a different one of these pipes to ensure that print data from multiple queues doesn't get interleaved (with quite undesirable results). Don't confuse the CWptal-printd daemon (with a trailing "CWd") and the CWptal-print command-line utility (without a trailing "CWd"), which is an alias for CWptal-connect. CWptal-printd logs startup and error messages to syslog (CW/var/log/messages) in addition to logging to standard error. If you specify the CW-uel switch, a UEL (Universal Escape Language) sequence (CWCIEscCW%-12345X) is sent before a print job, and a PCL end-of-job sequence (CWCIEscCWE) and another UEL are sent after a print job, to help identify job boundaries for the printer. However, this may not happen in the case of back-to-back print jobs, because CWptal-printd may not get an end-of-file indication when reading from the pipe if data from the next job is already in the pipe by the time it reads the last data from the previous job. CW-nouel is now the default behavior, because normally print drivers automatically add these kinds of escape sequences if necessary, the printer already gets job boundaries based on when the print channel is closed and reopened between jobs, and it may cause problems when printing to devices that don't support PCL. If during a print job an error occurs with communicating with the device, the rest of the print job data is discarded, subject to the limitations discussed above regarding CWptal-printd's ability to detect boundaries of back-to-back jobs. Subsequent jobs are retried indefinitely if it's not possible to re-open the print channel to the device.