Andrew Gabriel wrote:
> Garrett D'Amore - sun microsystems wrote:
>> (This case deals with the removal of the underpinning printing
>> infrastructure
>> for a variety of legacy formats, other than basic postscript, ascii, and
>> ditroff. It depends on PSARC 2009/585. Some of this -- specifically
>> lpr -g
>> -- was discussed in PSARC 2009/538 as well.)
>>
>
>> Note that we are not planning to remove the options related to ditroff
>> output ("dpost", lpr -n, or "-Ttroff"). There are implications for
>> "troff" and "man" that rely on those things, and resolving those
>> dependencies
>> somehow will have the be subject of any effort to replace Solaris LP
>> with CUPS.
>
> I'm pleased about that - I have come across some customers whose use
> [di]troff (and groff hadn't come close to being compatible enough last
> time I looked), both for older docs, and for program generated
> typeset-quality printout.
>
> However, I don't think I've seen anyone who managed to get the printer
> filters working automatically. Pretty well always I'll see the
> customer doing something like
>
> tbl xyz | eqn | troff -mm -Tpost | dpost | lp
>
> i.e. the printing system only has to know about postscript.
>
> So I wouldn't care much about the loss of lpr -n, and lp -Ttroff, but
> the loss of [di]troff or dpost (and supporting files) would be much
> more significant.
>
> Not this case, I know, but a heads-up for any future EOF of Solaris LP
> system.
I agree wholeheartedly with you. I always manually stick dpost in my
pipeline too. One would think we ought to be able to do better than
that with cups, but really, hard copy troff is kind of an edge case
these days, and so a pipeline option isn't too bad. (There are crufty
unix people like me who still use it -- and PSARC members! -- but its
not really mainstream anymore except for use in on-line man pages, and
that's not normally done in hard copy.)
- Garrett
