bugGNU roff - Bugs: bug #58562, improve typography of...

 
 

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

Submitter:  Dave <barx>
Submitted:  Sun 14 Jun 2020 03:59:51 AM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 15 Jan 2022 07:36:15 AM UTC, comment #1: 

The second problem has now been filed separetely as bug #61828.

Dave <barx>
Group Member
Sun 14 Jun 2020 03:59:51 AM UTC, original submission:  

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:

  1. 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:
    1. this adjustment can only be added manually after seeing how the document is formatted; and
    2. for any applications where parameters or content may be generated dynamically, the line-length compensation cannot be made at all.
  2. 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.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-04 barx Severity3 - Normal 1 - Wish

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code