[Top][All Lists]

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

Re: [Groff] Re: begin page blues

From: Miklos Somogyi
Subject: Re: [Groff] Re: begin page blues
Date: Sun, 12 Mar 2006 23:49:08 +1100

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

This 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 .x

Yes, 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 >

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.



.ev 1
.di x
.  trf
.de END
.de line
.  de line-aux END
     ps: def \\*x
.  END
.  nop \Y[line-aux]
.  nop \X'ps: exec psline'

.line 70


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.


Attachment: try_ps.grf
Description: Binary data

reply via email to

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