Re: [Groff] How to embed PS char into groff input

[Tadziu Hoffmann]

[snip]

> The reason I wouldn't do this is that it involves editing
> the "prologue" file for any such character, whereas if
> you need to use PostScript-defined characters of this kind
> then you may want to use several different characters
> in the same or in different documents. I much prefer to
> leave the "prologue" file strictly untouched, except for
> any changes which one may wish to apply to all documents.
> 
> Therefore I personally recommend the kind of approach
> I suggested, where the character has an independent
> "stand-alone" definition which can be incorporated
> "in-line" when it is needed.
> 
> (Also, this kind of thing may not be needed for ever,
> and unless you remember to re-edit the "prologue" file
> to remove it when no longer needed, you will end up
> with something which I try to resist as much as possible,
> namely system files which resemble a drawer-full of
> underwear and unmatched socks ... ).

I fully agree with you.  That's why I also mentioned that
the whole procedure could equivalently be performed with a
"ps: def" device control in the manuscript (or in a file of
its own, sourced by the manuscript) instead of editing the
prolog file.  Actually, this seems to be exactly the reason
for implementing the "ps: def" in the first place.

> The method I illustrated (involving a complex use of \n[.ps]
> etc) was developed when I first encountered the need, and
> for this example some of the numerical features (like the
> \h and \v motions) were hand-tuned.

Same here, only that the hand-tuning went into the
PostScript code.  Anyhow, the user of the character doesn't
really care how it is implemented, as long as it does the
intended job.  It's perhaps just a matter of taste, but I
usually like to keep the code as uncluttered as possible.


> It may well be possible to work out how to incorporate
> your variant of the PS code (which does its own scaling)
> into an in-line ".char" definition, though for the
> moment it is not obvious to me how to do it (but see below).
> 
> I am wondering if a variant:
> 
>   .char \[rose] \X'ps: exec \\n[.ps] \\*[rose]'\h'1m'
> 
> could be conveniently developed, where \*[rose] is
> a string containing all the PostScript code similar
> to in your version. I haven't had time to try this yet.

Should work just as well.  Just put the definitions of the
wedge and rose procedures in the string "rose", and define

.char \[rose] \X'ps: exec \\*[rose] \\n[.ps] rose'\h'1m'

The only difference is that you keep redefining the
procedures (however, always with the same value), instead of
defining them only once in the prolog.


> > (By the way: the \*{, \*} definitions in the groff-1.17.1 version
> > of gs.tmac do not allow nesting, because the size is restored
> > with \s0 which can only go back one size change.)
> 
> Sure, but for this illustration it doesn't matter; the point
> was to demonstrate that this definition behaves like any
> other character (e.g. "A"), rescaling as one would expect.

I suspected that was your point (and I wasn't really
criticizing anybody for this).  I was just playing around
with your example and wondering why the font did not return
to the original size, so I had a look at the implementation
(I'm not an "ms" user myself).  Anyhow, it's not really a
design flaw, because it simply wasn't meant to be used nested.


Cheers,
Tadziu