On 11/03/2006, at 2:43 AM, Werner LEMBERG wrote:
[...] you have to use the `.trf' request -- to define a macro `x' which contains the contents of file `f', say .ev 1 .di x . trf f .di .evThis can be then expanded with \\*f. BTW, there is a mild limitation that only valid groff characters are accepted in the file passed as an argument to `.trf'.Thank you. I guess you mean \\*x or .xYes, of course.I've tried both and prepended the included file with \! and not. Neither of these combinations went into the PS file as PS instructions, just as text to be plotted or something to cause error exits. What did I do wrong?Maybe the two attached files do what you want. Say groff psline-test > psline-test.ps to process them. The example artificially demonstrates how to control the definition of a PS macro (taken from an external file) within groff. If this doesn't answer you question please provide a small example which I can work on. Werner
<psline.ps>
.ev 1
.di x
. trf psline.ps
.di
.ev
.
.
.de END
..
.
.
.de line
. de line-aux END
ps: def \\*x
. END
.
. nop \Y[line-aux]
. nop \X'ps: exec psline'
..
.
.
xxx
.line 70
yyy
Werner, thank you for the helping hand. I've found many things that I would not have guessed.
However, there are some problems.`.line 70' draws a line of 70 length only if there is no other .`line` request with another length. The `ps: def ..' command appends the ps routine (with $1 replaced by a number) to the prologue. When the routine is to be executed later on, only the last definition of $1 prevails (in all cases).
If you add to the prologue you do it because you want to use the same routine over an over, so
one can not `compile-in runtime-parameters'.I think that your example could be modified to do the right thing, but I would be loath
to explain such a complicated thing to any user, let alone to a novice.I hope that I've learned enough about groff's PS to enable me to convert my old SGI-Adobe troff files. However, I find that groff's PS (however capable it may be) was not designed with a user in mind:
1) We have seven \X structures and ... \Y structures.SGI-Adobe-troff had only one, and that could well do everything, including appending to the
prologue, with no problem re parameter handling.
That's a lot of distraction of attention and a lot of explaining
to do, and a lot of caveats.
2) PS inserts are not very well insulated from the rest of groff's output.
3) One needs to think more about intermediate output, about passes (?), and about when exactly
the $1 conversion takes place (see attachment)
4) One needs to keep in mind that though PS has nothing to do with
spaces/new-lines in troff's text,
the \X and \Y escapes may generate those, so a `.sp -1' may be
necessary, and that
that there could be some problem at page-ends with this approach.
5) Parameter passing to PS can be done but, as this discussion shows,
it is not trivial, though it should be.
From previous experience I find this system of escapes far too complicated, that distracts the user with the `how to' and `how not to' at the expense of the `what' that should be his only concern.
Well, I don't expect anyone to re-write groff/grops any time soon, and you may even vehemently disagree with my points. This is my two cents worth, and I hope that at some stage groff's PS will be greatly simplified. E.g. it would be a great help to engineers who must use lots of sketches/drawings beyond pic's capabilities, more so than equations and tables that are nicely catered for.
Miklos
try_ps.grf
Description: Binary data
_______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
