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
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
