Re: [Groff] Request "cf"

[Miklos Somogyi]

Werner, I get all your e-mails in pairs (with the exact same date), a  
minute or so apart.

On 18/02/2008, at 7:33 PM, Werner LEMBERG wrote:

> > > > Yes, .cf copies the external file (A and B) verbatim, but to the
> > > > wrong place.
> > >
> > > Well, it works as documented...
> >
> > The documentation does not seem to say that (unlike .trf's) .cf's
> > output goes only to the intermediate file, not any further.  Is
> > there any point in having it there?
>
> The doc says `unprocessed' and mentions `\!' (which I've now corrected
> to `\!\\!' for .cf) -- from groff.texinfo:
>
>     If `\!' is used in the top-level diversion, its argument is
>     directly embedded into the `gtroff' intermediate output.  This
>     can be used for example to control a postprocessor which
>     processes the data before it is sent to the device driver.
>
> > > > I have no need for the intermediate file, I need the verbatim
> > > > copy in the final (ps) output.
>
> Well, PS is not the only output device driver...

Then it would be good to say in the manual: ".cf is not for ps"

> > > Why not using
> > >
> > > \X'ps: file foo'
> >
> > Yes, I do.  Just that having things in a diversion would be far more
> > convenient.
>
> Please explain.  I can't see an immediate reason for this.

An example: you want a macro to include images in eps format that you  
can manipulate exactly as you want them:

a) you calculate viewport, etc
b) set-up clipping for the image
c) prepare for the "image" operator
d) "file"-in the eps to be processed as current file
e) draw frame, add text, keep space, whatever

To "ffile"-in eps you need to terminate the auxiliary macro
To do anything in e) you need to define another auxiliary macro, where  
you have to duplicate all your viewport
calculations, ....
With a diversion based reading-in one could do with one auxiliary, no  
duplications.

> > > then?  It's not troff's job to prepare raw data for grops...
> >
> > I am probably wrong in this, but I always think in terms of groff
> > and don't think of the sub-duties and interaction of its components
> > unless I really have to.  And via .trf, troff does prepare raw data
> > for grops by cooking them.  I thought that .cf would do the same,
> > without cooking.
>
> `.cf' is already available in AT&T troff, while `.trf' is a groff
> extension.  groff must follow the original implementation.

Wishful thinking: another groff extension, e.g. .cf-new :-)

>    Werner

Miklos