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

 
 

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

Submitted by:  Dave <barx>
Submitted on:  Wed 12 May 2021 05:32:59 AM UTC  
 
Category:  Core Severity:  1 - Wish
Item Group:  New feature Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    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.6