[bug #58562] improve typography of letterspacing request .tkf ("track kerning" in groff parlance)

[Dave]

URL:
  <https://savannah.gnu.org/bugs/?58562>

                 Summary: improve typography of letterspacing request .tkf
("track kerning" in groff parlance)
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Sat 13 Jun 2020 10:59:51 PM CDT
                Category: Core
                Severity: 3 - Normal
              Item Group: New feature
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

This bug report documents two issues with the .tkf request.  For the first
problem, the functionality is as documented, but is not reasonable.  For the
second problem, the behavior is undocumented and counterintuitive.

Both these problems appear in a recent groff build (GNU groff version
1.22.4.144-c63b-dirty).

= Test case =
A simple test case illustrates both problems:


.tkf B 4 4 32 16
We the people of the United States,
in order to form a more perfect union,
establish justice,
insure domestic tranquility,
provide for the common defense,
promote the general welfare, and
secure the blessing of \fBliberty
to ourselves\fP and our posterity,
do ordain and establish the Constitution of the United States of America.


This test case uses somewhat greater track kerning than might be used in a
real-world application, in order to make the problems more visible.  But the
same problems occur on a smaller scale with smaller adjustments.


= The documented problem =
The documentation for the .tkf request states: "the track kerning amount is
added even to the rightmost glyph in a line; for large values it is thus
recommended to increase the line length by the same amount to compensate it."

It is hard to imagine a situation where the user would want such space after
the rightmost glyph on a line.  (Further, even if there are such situations,
it is far more common that a user will want the right margin to line up, so
the burden of adjusting the line length should fall on those rare users who
want an uneven right margin.)

In practice, the documentation's suggested adjustment of the line length is
simply not a reasonable requirement to place on the user, for two reasons:

0 Since the request to adjust the line length, .ll, does not take effect for
the current line, but only for the next line, the user cannot correctly place
the first .ll (to increase the line length) and the second .ll (to restore it)
based on a groff document's source.  The user must know where groff will break
the lines in order to place the two .ll requests, meaning that:
00 this adjustment can only be added manually after seeing how the document is
formatted; and
00 for any applications where parameters or content may be generated
dynamically, the line-length compensation cannot be made at all.
0 Calculating the correct amount by which to increase the line length is not
trivial.  Due to the sizing algorithm used by .tkf, the amount of space added
to each glyph, in the general case, will not directly appear in the source
document at all.  It must be calculated, from the four parameters (s1, s2, n1,
n2} passed to .tkf, via:


  (\n[.s] - s1) (n2 - n1)
 ------------------------- + n1
          s2 - s1


assuming that \n[.s] falls between s1 and s2, that s1 and s2 are not equal,
etc.  Given groff's calculation limitations, and the various conditions that
must be met for the calculation to even proceed, this may not even be possible
in the general case, and is by no means reasonable.

For instance, for the .tkf request in the above test case, the correct .ll
request:


.ll +((\n[.s]z-4z)*(16p-4p))/(32z-4z)+4p


fails for point sizes over 15 with a "multiplication overflow" error.

= The undocumented problem =
As can be seen in the output of the test case, .tkf's adding all the space to
the right of the glyph results in inconsistent spacing before and after the
bolded passage.

= History =
.tkf is a GNU extension to troff.  (Heirloom troff offers a similar extension
via its .track request.)  It is unclear when .tkf was added, as class
track_kerning_function has been in src/roff/troff/node.cpp (originally
troff/node.c) as far back as groff's git history goes, June 1991.

I originally raised the first problem on the email list
(http://lists.gnu.org/archive/html/groff/2014-01/msg00079.html).  In one
reply, Werner says
(http://lists.gnu.org/archive/html/groff/2014-01/msg00083.html) that because
.tkf is documented to work this way, any changes would have to use a new
request or a new parameter to the current .tkf request.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58562>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/