bug-groff
[Top][All Lists]
Advanced

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

[bug #60587] Allow font files to specify kern pairs for characters in di


From: Dave
Subject: [bug #60587] Allow font files to specify kern pairs for characters in different fonts
Date: Sat, 30 Jul 2022 16:58:24 -0400 (EDT)

Follow-up Comment #5, bug #60587 (project groff):

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.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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