groff
[Top][All Lists]
Advanced

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

Re: [groff] ms footnote weirdness


From: Werner LEMBERG
Subject: Re: [groff] ms footnote weirdness
Date: Tue, 08 Oct 2002 17:13:39 +0200 (CEST)

> I'll use this as an excuse to dispense some incense about tbl (see
> attached example file).

Very nice :-)

> Please notice that the last line in the example file contains the
> values of the PS and VS registers.  I haven't figured out how to fix
> the evident: While the VS value is in device units, PS value is in
> points and only accepts integer values (in points), trying to
> specify any unit dimensions explicitly makes the macro package blow
> chunks.  I know that that is the expected behavior of ATT ms with
> (di)troff -- furthermore it would not accept a size different to 10,
> 11 or 12, but groff should allow fractional point size values
> (converted internally to device units); I for one like to set
> Verdana at 8.75/12.5 points for body text :).

The problem is non-trivial.  You can't specify a default unit for the
-r command line option of troff.  The proper solution would be to use
-d for defining PS (and friends) on the command line, then saying

  .nr PS (z;\*[PS])

within s.tmac.  But having -dPS for fractional sizes and -rPS for
integral sizes is clumsy and error-prone.

A nice feature would actually be the ability to have default units for
-r.  Since -r is evaluated before loading any macro package, we had to
carry the original command line arguments somewhere.  With other
words, I had to introduce strings which `shadow' the original register
assignments.  Example:

  -r PS1=12z -r PS2=12

The `shadow' strings could be named `regXXX':

  regPS1 -> 12z
  regPS2 -> 12

Now both

  .nr PS (z;\*[regPS1])

and

  .nr PS (z;\*[regPS2])

yield the same result.

A quick grep on the string names in groff's macro packages shows that
no package uses `reg' as a prefix, thus `regXXX' is a reasonable name
which shouldn't produce much collisions.

If you think this is a useful feature, I can implement it easily.


    Werner

reply via email to

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