Change the recently-added 'o'-processing so it maps to 'l' instead of 'f'.

'l' ("plain text which includes control characters") is somewhat more
appropriate for 'o' ("postscript files"), and in fact some printers treat
'l' as a request to print a postscript file.

MFC after:	1 week
This commit is contained in:
Garance A Drosehn 2001-11-27 01:32:25 +00:00
parent 4aa8b109d5
commit 21ecfd4a44
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=86935
2 changed files with 15 additions and 10 deletions

View File

@ -193,13 +193,15 @@ __END_DECLS
* 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)
* take this id as a request to print a postscript file,
* and because of *that* some OS's use 'l' to indicate
* that a datafile is 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'.
* will treat it the same as 'l'.
* 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

View File

@ -676,14 +676,6 @@ 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;
@ -691,6 +683,17 @@ print(struct printer *pp, int format, char *file)
av[3] = indent;
n = 4;
break;
case 'o': /* print postscript file */
/*
* Treat this as a "plain file with control characters", and
* assume the standard LPF_INPUT filter will recognize that
* the data is postscript and know what to do with it. These
* 'o'-file requests could come from MacOS 10.1 systems.
* (later versions of MacOS 10 will explicitly use 'l')
* A postscript file can contain binary data, which is why 'l'
* is somewhat more appropriate than 'f'.
*/
/* FALLTHROUGH */
case 'l': /* like 'f' but pass control characters */
prog = pp->filters[LPF_INPUT];
av[1] = "-c";