Add minimal support for "o"-type print-file actions in lpd control files.

This was described in the original RFC wrt lpr, but most lpr's do not
actually implement it.  There is some indication that MacOS 10.1 will
be using this when sending postscript files to print servers (that is
what "o"-type was supposed to signify -- postscript files).

MFC after:	1 week
This commit is contained in:
Garance A Drosehn 2001-09-20 01:04:50 +00:00
parent 06fdffd84d
commit 626fb2a6fa
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=83684
2 changed files with 29 additions and 13 deletions

View File

@ -183,20 +183,26 @@ __END_DECLS
*
* The following indicate actions to take on a given datafile. The same
* datafile may appear on more than one "print this file" command in the
* control file. Note that ALL ids with lowercase letters are commands
* to "print this file":
* control file. Note that ALL ids with lowercase letters are expected
* to be actions to "print this file":
*
* f - "file name", a plain-text file to print
* l - "file name", text file with control chars to print (some
* printers recognize this id as a request to print a
* postscript file)
* p - "file name", text file to print with pr(1)
* t - "file name", troff(1) file to print
* n - "file name", ditroff(1) file to print
* d - "file name", dvi file to print
* g - "file name", plot(1G) file to print
* c - "file name", cifplot file to print. This action appears
* when the user has requested 'lpr -c'.
* d - "file name", dvi file to print, user requested 'lpr -d'
* f - "file name", a plain-text file to print = "standard"
* g - "file name", plot(1G) file to print, ie 'lpr -g'
* l - "file name", text file with control chars which should
* be printed literally, ie 'lpr -l' (note: some printers
* take this id as a request to print a postscript file)
* n - "file name", ditroff(1) file to print, ie 'lpr -n'
* o - "file name", a postscript file to print. This id is
* described in the original RFC, but not much has been
* done with it. This 'lpr' does not generate control
* lines with 'o'-actions, but lpd's printjob processing
* will treat it the same as 'f'.
* p - "file name", text file to print with pr(1), ie 'lpr -p'
* t - "file name", troff(1) file to print, ie 'lpr -t'
* v - "file name", plain raster file to print
* c - "file name", cifplot file to print
*
* U - "file name" of datafile to unlink (ie, remove file
* from spool directory. To be done in a 'Pass 2',

View File

@ -408,6 +408,8 @@ printit(struct printer *pp, char *file)
* R -- laser dpi "resolution"
* f -- "file name" name of text file to print
* l -- "file name" text file with control chars
* o -- "file name" postscript file, according to
* the RFC. Here it is treated like an 'f'.
* p -- "file name" text file to print with pr(1)
* t -- "file name" troff(1) file to print
* n -- "file name" ditroff(1) file to print
@ -626,7 +628,7 @@ print(struct printer *pp, int format, char *file)
pp->tof = 1;
}
if (pp->filters[LPF_INPUT] == NULL
&& (format == 'f' || format == 'l')) {
&& (format == 'f' || format == 'l' || format == 'o')) {
pp->tof = 0;
while ((n = read(fi, buf, BUFSIZ)) > 0)
if (write(ofd, buf, n) != n) {
@ -674,6 +676,14 @@ print(struct printer *pp, int format, char *file)
return(ERROR);
}
fi = p[0]; /* use pipe for input */
case 'o': /* print postscript file */
/*
* For now, treat this as a plain-text file, and assume
* the standard LPF_INPUT filter will recognize that it
* is postscript and know what to do with it. These
* 'o'-file requests could come from MacOS 10.1 systems.
*/
/* FALLTHROUGH */
case 'f': /* print plain text file */
prog = pp->filters[LPF_INPUT];
av[1] = width;