Re: [Groff] Request "cf"

[Miklos Somogyi]

On 23/02/2008, at 4:28 AM, Werner LEMBERG wrote:

> > Werner, I get all your e-mails in pairs (with the exact same date),
> > a minute or so apart.
>
> Yes, one from the groff list, and one directly from me.  My mailing
> program automatically removes such duplicates...
>
> > > Well, PS is not the only output device driver...
> > Then it would be good to say in the manual: ".cf is not for ps"
>
> Mhmm.  Why?  I think you got the wrong picture about .cf; actually,
> it's a quite useless request for most situations.

Yessir. Imagine if the Unix command "cp" would copy everything verbatim
as its name implies, but into an inaccessible place.
Would not life be quite difficult then?

If heritage requests are untouchables (I don't mind), why not provide  
a version
of "trf" that just does not cook? The graphics equivalent of "cp"?

> > 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 "file"-in the 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.
>
> I don't understand step d: How can an EPS file be processed as the
> current groff file?

It is not processed in the groff file. It is processed in grops'  
output, that is PS.
"Current file" is PostScript for the hex/ascii85/etc data stream that  
follows the "image" operator
or the process that contains it. As the "image" op is executed it  
devours the "current file" in which it resides
until it reaches the end of the image data.
This is by far the most common image processing in PS because the  
alternative (having image data
in a string) is very limited in size.

You taught me a year or so ago how one can smuggle one's own PS into  
grops' output.
One of them is the "\X'ps: file ...", the other is "trf".
Each of them are useful, each of them have limitations. "trf" can not  
read-in ascii85 encoded stuff because it is full
of backslashes.

The "\X'ps: file ..." thing can read anything but it can not be used   
in an embedded macro that is a
"ps: exec" stuff itself. That's why you have to close this embedded  
macro for a)-c) with a "\Y", then you read-in your file with "\X",  
then you need to open another embedded "ps: exec" macro to finish the  
job.

And here you need to redo a lot of calculations.
Having a "trf" with no cooking would make this thing a lot simpler.
I do not want to go into more detail here, they are in the archive: ps- 
in-groff.tar.gz

> The only communication between groff and an EPS
> image is the `psbb' request (for step a and b) so that you can set up

I don't use psbb, the bounding box is not intrinsic to the image.
All one needs is the width and height in pixels, and then the image  
can be mapped to any viewport in a variety of ways.
Width and Height can be deduced from the header of the eps file by the  
"image" routine, or these can be parameters
to the macro that does something with the image.

Miklos

> the right call to \X'ps: file ...'.
>
>
>    Werner