Re: Why people still want to encode precomposed letters

From: verdy_p (
Date: Thu Nov 27 2008 - 13:37:34 CST

  • Next message: John Hudson: "Re: wrong ccc for 0602?"

    "Adam Twardoch" <> 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