groff
[Top][All Lists]
Advanced

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

Re: [Groff] The \D request in nroff and troff modes


From: Werner LEMBERG
Subject: Re: [Groff] The \D request in nroff and troff modes
Date: Wed, 14 Jul 2010 14:20:59 +0200 (CEST)

> I have found what may be a bug either in tbl or in groff's \D
> request.  Or I don't understand how either works.

It's a problem which I don't know to solve while keeping tbl device
independent.

In troff PS mode, the registers \n[.H] and \n[.V] (the resolution in
horizontal and vertical units, respectively), both return 1; in
addition, there are 72000 units per inch.

In nroff mode, we have \n[.H] = 24, \n[.V] = 40, and 240 units per
inch.  In other words, the width of a character cell is exactly
24 units.

The basic question is when to switch on a character cell.  Consider
this diagram:

      0     1     2
   +-----+-----+-----+  ...
   0     24    48    72 ...

It's obvious that the values 0..23 are somehow `assigned' to character
cell 0, and for orthogonality we have to assign position 24 already to
character cell 1.

Another complication is that everything which specifies a length is
rounded internally to be multiples of either \n[.H] or \n[.V].  In
nroff mode this means that a horizontal length of 12u is still one
character cell, but 13u is rounded up to be two character cells.

Now look at these two tables:


  .ll 36n
  .TS
  expand tab(@);
  l l.
  _
  address@hidden
  _
  .TE
  .TS
  expand tab(@);
  |l l|.
  _
  address@hidden
  _
  .TE


If you compare the PS output of the first and second table (attached)
with a magnifier you can see that the horizontal lines are of equal
length, regardless whether there are vertical lines or not.

Here is the result if formatted with the utf8 device:


  ─────────────────────────────────────
  Left                           Right
  ─────────────────────────────────────
  ┌───────────────────────────────────┐
  │    Left                Right      │
  └───────────────────────────────────┘


As can bee seen, grotty is smart enough to replace the intersections
with proper cell characters, and effectively the horizontal line
lengths are the same too.  However, it is obvious now that basically
the lines should be shifted half a character cell to the left to make
it really symmetrically w.r.t. the text, but this is not possible.

Does this explain why a single horizontal line is one character cell
too long?  Since the user might use vertical lines arbitrarily I don't
know a way to reliably shorten the horizontal lines for a `better'
output.

BTW, if you always shorten horizontal lines by a small correction
value, the above tables look like this:


  ────────────────────────────────────
  Left                           Right
  ────────────────────────────────────
  ┌───────────────────────────────────│
  │    Left                Right      │
  └───────────────────────────────────│


grotty then has no longer a chance to properly replace intersections,
since the lines indeed no longer intersect.

I could imagine that a special nroff mode of tbl is a solution, but I
fear that a clean implementation is a major task with a lot of work.
Patches are highly welcomed, however.


    Werner

Attachment: table-test.ps
Description: PostScript document


reply via email to

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