From: verdy_p (email@example.com)
Date: Thu Nov 27 2008 - 13:37:34 CST
"Adam Twardoch" <firstname.lastname@example.org> wrote:
> If Philippe wants to add some clarifying adjective to his use of the
> term "kerning" (e.g. Philippean kerning), no objection to that. But I'd
> rather he did not hijack the general term for his own definition.
I won't add more clarification, because all what I had to say about what I meant was already written explicitly.
Some have argued that I was not general enough (because I used the term "pair") but they misread what I wrote, and
I was clear enough: I had explicitly already included pairs of anything (not just pairs of characters, but pairs
containing composites, including new glyph ids assigned to other pairs, so this included the triplet case as well,
if treated as pairs containing a pair in one of the elements, or even glyph classes, described in another message
for easier conception of specific mark-to-mark positioning that are different from the default position indicated
by an isolated glyph id).
If you want I can call it "advanced kerning" and this clearly indicates any difference of position between
* the default anchor position set by the properties of an isolated glyph, and
* the corrected anchor position for a specific pair (or glyphs, or composites, or glyph classes, each one given an
id, and defined separately in a font)
Then a basic renderer will just use the default anchor positions (for example to create basic font metrics for
individual characters), but will not adjust the relative positions of base characters, or of specific marks
relative to a base glyph or to a composite or to another mark. This will be exactly like rendering without enabling
kerning at all. Of course, most fonts are encoding most of these anchors in separate ad-hoc tables (notably the
advance width), general font metric properties (that just define in fact some average positions that still need to
be adjusted for a subset of the glyphs that the font supports).
A more advanced renderer will use the "advanced kerning" and it will manage not only the simple font metrics (basic
average anchor positions applicable to all glyphs in a given font style) and the simple (horizontal only) kerning
(usable only for the horizontal text layout, and not correctly setting the prefered positions of diacritics, and
not adjusting the advance width for some "zero-width" diacritics that need more space than what the base glyph
And I don't want to discriminate this "advanced kerning" by trying to split it between "mark-to-mark positioning"
or "base-to-mark positioning" or "kerning" (old, biased to horizontal Latin for English only because it can't even
handle the simple case of i with a circumflex above, a case that is still needed for very common language such as
For me, the system should work as a whole and support 2D adjustments for EVERYTHING, because your existing attempt
to discriminate between "mark-to-mark positioning" and "base-to-mark" positioning fails to handle many tricky cases
that solutions using GSUB for long and incomplete lists of specific character pairs can't handle gracefully without
the help of tricky code implemented in the renderer (so finally, you'll still need to add more specific tables in
fonts, and you continue to complicate their design).
The way I see this system, it would be powerful enough to EVEN support the Brahmic vowels written as glyphs on the
left and/or right of base characters: for this to work, the "origin" anchor, on the default baseline, must be
modifiable as well (with the effect of moving all its anchors in the reverse direction, so that all the glyphs that
the base contains will also be moved, including the basic anchors for font metrics like the bounding box, margin
box, composition square for ideographs, caret position, and all its other anchors for the other composed diacritics
that it may include).
This would also apply to the case of the French 'î' (a narrow 'i' with a wider circumflex above it), for some font
styles that need such adjustment), or the base letters with overstrockes (when these strokes should not collide
from letter to letter, despite their default advance gap is too narrow to avoid this undesired collision).
Yes you will still have font creation tools that will still speak about "kerning" tables that can't support 2D
position adjustment. These tables should still be populated, if possible (i.e. when the vertical component of the
position adjustment is null and just applies to modify the default advance anchor set by individual glyphs), but
separate tables (in fonts) will still be needed for all other types of adjustments (other anchors, vertical
adjustments for lowercase or uppercase letters, diagonal adjustments for Vietnamese tone marks above another
This archive was generated by hypermail 2.1.5 : Thu Nov 27 2008 - 13:40:50 CST