groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Request "cf"


From: Miklos Somogyi
Subject: Re: [Groff] Request "cf"
Date: Mon, 18 Feb 2008 20:10:47 +1100


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]