groff
[Top][All Lists]
Advanced

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

RE: [Groff] using gpic


From: Ted Harding
Subject: RE: [Groff] using gpic
Date: Sun, 24 Aug 2003 01:25:56 +0100 (BST)

[This is about the fifth time I've tried to send this to the list!
 I've interpolated a couple of short test messages and these have
 got through, but for some reason this messages did not. Now trying
 it the hard way ... ]

n 23-Aug-03 Heinz-J|rgen Oertel wrote:
> Hello,
> is there a way to use groff number registers in pic?
> e.g. to use registers like LL in ms to draw a box or line?
> 
> Thank you for any comment or link
>  Heinz

An interesting question.

The short answer is "No". The long answer is "Yes".

For the short answer:
---------------------
First of all, in normal usage, 'pic' is run before 'troff' and
therefore the troff registers don't even exist at that point, let
alone have a value.
  Secondly, you might think it would be possible to refer to them
symbolically in some way, so that, say,  a line length in 'pic'
is encapsulated in the code emitted by 'pic' as a troff register name
which will undergo delayed evaluation when 'troff' does see the 'pic'
code later.
  I think this is not possible, for reasons of 'pic' syntax. Ultimately
any quantity referred to, symbolically or not, in 'pic' must be an
expression (which can include, of course, an explicit numerical constant).
The expression syntax in 'pic' is not compatible with symbolic references
to 'troff' registers.
In particular, for example, the code

.PS
line from (0,0) to ( \n[LL] , 0 )
.PE

will generate a 'pic' error:-- because 'troff' has not yet seen the
code, it has not substituted the numerical value of LL for "\n[LL]"
and 'pic' only sees the illegal expression "\n[LL]".

For the long answer:
--------------------
If you can arrange for 'troff' to see the code before 'pic' does, then
all such references to registers will have been replaced by their
numerical values and all will be well.
  However, you don't want to do it like troff ... | pic ... | troff
because the output of the first 'troff' will not be troff code any more.
The only way I know of to do this kind of thing (and you may want to
use it even for such mundane things as drawing a box which nicely
surrounds a text block of variable width and height without having
to get out your calculator or experiment countless times until it looks
right) is to cause 'troff' to:
a) output troff-computed PIC code to a file
b) run 'pic' on that file and collect the output from 'pic' (which will
   be 'troff' code) into another file
c) read that second file back in at that point so that it is processed
   by 'troff' 

A simple example:

.de temp
.open pcode temp.pic.in
.write pcode .PS
.write pcode box width \\n[bwid]/72000 ht \\n[bht]/72000\
       "This is a line of text in a box" \
       "and this is a second line"
.write pcode .PE
.close pcode
..
.LP
Here is some text
.br
.\" Find length of longer line plus extra space at ends:
.nr bwid \w'  This is a line of text in a box  'u
.\" Make box high enough for two lines of text plus a bit:
.nr bht 2.5v
.temp
.sy /usr/bin/pic -Tps temp.pic.in > temp.pic.out
.so temp.pic.out
.br
and here is some more text

Comments:
1. You must run groff in "unsafe" mode ( -U option ) [I hate "safe mode"!]
   because ".open" and ".write" and other useful requests are removed or
   redefined when troff starts in safe mode.
2. The above is cumbersome and convoluted, though it works. You have to
   make a macro of it, because the ".write" command copies the rest of the
   line in "copy" mode, so there is no substitution of values for
   registers if you simply put these lines into your normal imput text.
   To achieve substitution you put them into a macro: when 'troff' reads 
   the macro, it makes its substitutions before looking at what the macro
   is asking for.
3. You might want to redefine .PS and .PE to achieve better control over
   positioning etc.
4. The above simple example is bad enough. I have used this technique for
   much more complicated things, though I try to avoid the experience.
5. A somewhat simpler alternative can be to prepare the auxiliary files
   beforehand, rather than creating them within the troff run; however,
   this is cumbersome in its own way, and I have a preference for doing
   things "in-line", since you may want to edit them as part of editing
   the document and that is easier when it is in-line. In any case, the
   sort of "much more complicated things" I'm referring to above include
   making use of number register values which depend on the current troff
   run, in which case they cannot be evaluated beforehand.
6. If anyone can suggest a simpler and more straightforward approach,
   you would be doing some of us a service!

Best wishes to all,
Ted.

PS OK I know you can use the "box" macros (.B1 and .B2 in ms macros)
   for the precise task in the above example; but more complicated
   diagrams -- i.e. real 'pic' stuff -- need an approach like the
   one illustrated.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 24-Aug-03                                       Time: 01:08:36
------------------------------ XFMail ------------------------------


reply via email to

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