bugGNU roff - Bugs: bug #60587, Allow font files to specify kern...

 
 

bug #60587: Allow font files to specify kern pairs for characters in different fonts

Submitter:  Dave <barx>
Submitted:  Wed 12 May 2021 05:32:59 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
   

Jump to the original submission

Sun 25 Jun 2023 10:41:26 PM UTC, comment #6: 

Some (possibly irrelevant) comments about generating this data: http://lists.gnu.org/r/groff/2023-05/msg00032.html

Dave <barx>
Group Member
Sat 30 Jul 2022 08:58:24 PM UTC, comment #5: 

As comment #4 affirms, generating data to use the mechanism requested in this ticket is out of scope for this ticket.  But there seems little point in opening a new ticket for that, when we are a long way from needing any such data: as comment #2 alludes, providing a user-level mechanism such as Heirloom's .kernpair is the best first step, and even that (bug #44244) is unlikely to happen soon.  (And there isn't even universal buy-in that this ticket's ask is a good idea.)

But lacking an appropriate venue to brainstorm ideas for generating such data, I'm using this as the least inappropriate one.

A recent email from Deri James (http://lists.gnu.org/r/groff/2022-07/msg00219.html) provides a possible starting point for this:

"Italic fonts have extra metrics which determine how much space to add for italic correction."  So some tool could read the font metrics and spit out a list of italic glyphs that are candidates for the first glyph of each such pair.

The immediate trouble with any system to autogenerate the second glyph comes up in a point Tadziu once made (http://lists.gnu.org/r/groff/2013-11/msg00031.html): "'italic correction' is the space needed between the italic character and a tall upright character."  He cites an italic f followed by a comma as a sequence that won't need extra space.  Do font metrics include height information that could be used to pare the list?

And even this is less than sufficient.  To assuage Branden's comment #3 concern about data proliferation, I submit that an automated system should not try to handle all cases, only common ones.  For example, it's not unheard of for a font change to happen in the middle of a word, and such a font change might even benefit from some correction, such as, "I said _off_load."  But here we veer into the realm of copious data for little benefit.

The cases I think should be automated are the more common ones of adjacent letters and punctuation from different fonts.  And while font metrics (probably) don't classify a font's glyphs by type like that, happily, Unicode does.  So that gives an automated way to substantially whittle down the list of candidate pairs.

Dave <barx>
Group Member
Sat 15 May 2021 03:08:52 AM UTC, comment #4: 

Hi Branden,

You're talking about the data, whereas the (intended) scope of this bug is merely the mechanism to read the data--of which none yet exists.

You're right that it's theoretically possible this data will grow out of control once a mechanism exists for reading it.  But given the maturity of software typesetting and the complete lack of this data at present, this seems a remote concern.  Typographers don't seem to be champing at the bit to generate cross-font kerning metrics.

I agree that it's reasonable to expect the user to define her own kern pairs for unlikely and one-off combinations.  But there are common cases, like the canonical example of an italic f followed by a roman right parenthesis, that invariably require adjustment.  It shouldn't be up to every user to reinvent this kerning wheel.  Relatively common glyph combinations should Just Work.

In short, my ambitions for this feature are much more modest than what you fear.

If we did have an Heirloom-style cross-font .kernpair request (bug #44244), for groff's default fonts we could handle such common combinations with a simple startup tmac file of .kernpair requests, as I alluded in comment #2.  But if efficiency is one of your concerns, this method seems far less efficient: the tmac file would presumably cover all the font families that ship with groff, but the user may be using only a small number of these.  On the efficiency front, it's better to read and store this data only when it's needed.

In any case, I absolutely agree that as a first step, it makes sense to implement a cross-font user-invokable kerning request.  Right now, the capability doesn't even exist in groff, so let's get over that hurdle.  Give the user a tool to solve the problem first; then we can revisit the idea of automating some of that work for the user.

Dave <barx>
Group Member
Sat 15 May 2021 01:26:33 AM UTC, comment #3: 

Hi Dave,

I share Werner's instinct as to the pragmatics of this.  It seems to me like a common computer science problem--a combinatorial explosion.

Just within a font, the number of potential kerning pairs can be immense in the Unicode era.

Given a font with n glyphs, the number of kerning pairs is on the order of n^2 (I at first thought n*(n-1), but a glyph can of course require--or be given--particularized kerning with itself).


num_kern_pairs = g1,g1 + g1,g2 + g1,g3 + ... + g1, gn + g2,g1 + g2,g2 + ...
num_kern_pairs = gn*gn
num_kern_pairs = n^2


Now add F fonts with identical glyph coverage.  Each glyph g in font f1 has n^2 kern pairs just internally, and now we add each of the n glyphs in each font f2, f3, f4, ...

If I'm reasoning correctly, this turns a quadratic problem into a cubic problem.  And as a rule of thumb, any time you're dealing with an increase in the complexity class of a problem in computer science you need to consider if you're going to have enough resources to manage it.

At first blush, the concept of Heirloom Doctools troff's solution seems sound.  Fonts define their own kern pairs, and users can supplement them or override them as needed.  Most practical documents will not use a large number of fonts, and fewer still will combine arbitrary glyphs from arbitrary adjacent pairings of those fonts.

Putting the responsibility on the user to define the cross-font kernings they're going to need for a particular document seems reasonable to me.

However, we can aid them in this.  We could have a feature in groff which emits a diagnostic (probably off by default) any time it writes out a pair of adjacent glyphs without having any kerning data for them.  (N.B., this does not mean for which the kerning adjustment is defined as zero or some within-font default.  Maybe we'd have an exception for cases where the font family [family+style?] does not change, on the assumption that the font designer considered this issue and left the kerning pair undefined on purpose.)  This would catalog the occurrences for which Heirloomish .kernpair requests would need to be written.  Then let the suitably informed user deal with it.

While I have y'all's attention I wanted to re-raise he matter that has been "itching me", as I put it the other day, in our man pages.  We have italic corrections and left italic corrections.  I wonder, given the attached specimen, whether we need "bold corrections".  These would work within a font family, in a cross-style way just as the italic corrections do.  I suppose I could pilot this idea with \^ escapes in the groff_man(7) font macros.  Or maybe that is all that is necessary...?


G. Branden Robinson <gbranden>
Group administrator
Wed 12 May 2021 11:28:52 AM UTC, comment #2: 

I know very little about other typesetting software in general, so I'm not the best person to answer.

Heirloom troff offers the functionality at the user level (via the .kernpair request), but its documentation specifically states it doesn't offer a way to predefine such pairs.

Still, having the macro in user space means the underlying data structures must be able to store kern pairs for glyphs from different fonts, which seems like the hard part.  Once those data structures exist, providing a way to prepopulate them based on data in your font directory (where exactly this data would live would need to be figured out) seems like the easy(er) part: conceptually it's no different from running a startup .tmac file containing a bunch of .kernpair requests.

Then actually generating the data is the other hard part. :)  If, as you suspect, no one else offers this functionality, cross-font kerning data simply doesn't exist--which would be my guess as to why Heirloom didn't bother providing a preloading mechanism.

Dave <barx>
Group Member
Wed 12 May 2021 07:00:17 AM UTC, comment #1: 

I'm curious: Do you know any other software that supports this?  The TeX family doesn't (well, maybe such a feature could be programmed as a Lua extension in luatex).

Werner LEMBERG <wl>
Group administrator
Wed 12 May 2021 05:32:59 AM UTC, original submission:  

Font files can presently specify kerning data only for pairs of characters that are both in the same font.  A mechanism should also exist that can globally specify kerning information for pairs of characters that are in different fonts.

Bug #44715 seeks to document the current limitation, which is useful in the short term, but in the longer term, it would be better for the limitation to be removed.

(I first floated this idea in a comment in bug #44244, but that feature request has a different purpose, so I submit this separate feature request specifically for this suggestion.)

Dave <barx>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51435:  gropdf_bad_kerning.png added by gbranden (34KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by wl (Posted a comment)
  • -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-05-15 gbranden Attached File- Added gropdf_bad_kerning.png, #51435

    Back to the top

    Powered by Savane 3.13-c373.
    Corresponding source code