[Groff] Re: Composed glyphs - quick and dirty solution

[Michail Vidiassov]

Dear Werner,

On Fri, 3 Mar 2006, Werner LEMBERG wrote:

> request to groff to activate an option so that it tries to compose
> missing glyphs automatically if both the base and accent characters
> are available.  On the other hand I'm not sure whether this is a good
> thing from the typographical point of view.

For fonts that lack composition data (core PS fonts, for example)
that seems the only way to produce at least some result.

> > For base PS fonts (Courier, Helvetica, Times) accent placement may
> > be somewhat improved, since there are hand-made tables for accent
> > placement, that may result in better positions than just centering
> > the accent.  That tables originate from second millenium attempts to
> > "add more characters" to base PS fonts (ogonkify project).
> Hmm, I'm not happy about a PS-only solution.  If any, than support for
> the CC keyword would help to handle the ogonkify solution, I think.

I was thinking in terms of small improvements of the current state.

Making groff understand character composition and improving ligatures
is not a "quick and dirty solution".

PS-only solution arises as the problem is with core PS/PDF fonts,
 that lack some popular composed characters.
The later have to be added with algorithmically derived (as in case of 
ps-achar) or hand-crafted positioning (tables from ogonkify).
Hand-crafted tables are font-specific ;)
Font-specific solution becomes PS-only solution, since it is a PS font.

Adding parsing CC to afmtodit does not make sense, since
the only useful AFM files with CC are files form ognkify, AFAIK.
(Predecessors of ogonkify or Vietnamise version of URW fonts considered
irrelevant.)
Converting the data for use in groff looks like one-time effort.
Making FontForge emit CC does not seem to be right for the following 
reason.

Concerning class-based approach to composites in ligatures.
Opentype font information is class-based, groff font is going to be
class-based, AFM is table based.
Passing information from Opentype font to groff font via AFM seems
to be a troublesome way.
May be it is easier to change FontForge to write troff font files
or at least export kerning and composite positioning information in some
easily-parseable format?

As to the huge size of tables resulting from conversion of class-based 
data, Adobe used the following solution:

   5. Adobe Type Manager and kern pair filtering

   For many programs, support for kerning in OpenType fonts is provided to a
   limited degree by the Windows and Macintosh Adobe Type Managers. This
   limitation arises because most programs that are not OpenType-aware assume
   that all the kern pairs in a font can reasonably fit is a single table, and
   that there will be no more than a few thousand kern pairs. Providing more
   kern pairs than this causes such programs to crash. With the class-based
   kerning supported by OpenType layout, even a font with only 220 glyphs will
   usually exceed the limit, if well-kerned. In order to allow use of OpenTyoe
   fonts without crashing many current programs, the Adobe Type Manager
   programs support kerning via the legacy operating system calls by first
   fully expanding the class-based kerning to a list of single glyph name
   pairs, and then filtering this list through a hard-coded list of glyph
   names. If the glyph name on either side of the kern pair is not in the
   filter list, then the kern pair is omitted. The kern filtering list for
   Windows 95 and Mac OS 9 is [81]here. The kern filtering list for Windows NT
   and 2000 is [82]here.

           Sincerely, Michail