RE: Accessing alternate glyphs from plain text

From: William_J_G Overington (
Date: Mon Aug 16 2010 - 02:40:07 CDT

  • Next message: CE Whitehead: "RE: CSUR Tonal"

    Thank you for your reply.
    On Saturday 14 August 2010, Peter Constable <> wrote:
    > You are assuming that the application
    > will automatically select certain alternate glyphs at the
    > ends of lines.
    Well, I am suggesting that an OpenType-aware application using an OpenType font that had GSUB entries regarding e U+EE0F, h U+EE0F, t U+EE0F (or, if formally encoded by Unicode and ISO, e U+FE0F, h U+FE0F, t U+FE0F) would automatically substitute an alternate ending glyph at the end of those lines where it has been specifically requested in the plain text and not otherwise.
    > There are limits to what can be done here:
    > automatically selecting a feature in a given context is easy
    > for software to do; knowing that the result is aesthetically
    > pleasing is not. The OpenType 'falt' feature, "Final Glyph
    > on Line Alternates" (see,
    > can be used for your scenario. But it probably should be
    > left to a user to select that manually rather than having
    > software apply it automatically. Thus, you should have an
    > additional step after #3 to apply that feature.
    Well, it seems to me that that is not my scenario. It is just perhaps the nearest available scenario if my ideas are refuted and only existing OpenType features are considered.
    > Btw, not all fonts will support that feature; it is up to
    > the font designer to choose which features they want to
    > support.
    > Re the GSUB implementation in a font, you gave (for one
    > case)
    >     e unicode_ee0f -> e_alt_end
    > (I'll assume that each of the references here is to a
    > glyph, not a character.)
    Well, I suppose that they could all be glyphs, I was not thinking of it like that though. I was thinking of trying to convey the meaning that if the character sequence e U+EE0F is detected, then use the glyph that has the postscript name within the font of e_alt_end. However, I have only a little knowledge of OpenType technology, so I accept that I may not have been thinking about it in the correct way.
    > I'm not sure what you intend by the
    > second input, "unicode_eeof". If this is meant to correspond
    > to a variation selector, then this is not how to implement
    > this in an OpenType font.
    I used unicode_ee0f to mean U+EE0F. It is a Private Use Area character. I am using it to correspond to the variation selector U+FE0F because it would be incorrect for me to use U+FE0F at the present time as the sequences e U+FE0F, h U+FE0F, t U+FE0F are not encoded in regular Unicode at the present time. Thus I use Private Use Area codes throughout in the examples that I produce.
    Thank you for the notes about the way that variation sequences are supported in OpenType and for the notes about the falt feature and other aspects of OpenType technology.
    Previously I wrote as follows.
    In order to access an alternate starting glyph, for these experiments one could use U+EE0C.
    end quote
    Also, I wrote as follows.
    ... and U+EE0E for an ending glyph that is about five times the width of the basic glyph (except for an m, where it would be so that it matched the other characters): ...
    end quote
    I have written a short poem, as an example for discussion, that uses these two codes.
    Blossom on the hedgerows
    Beneath a sky that is clear
    Fresh leaves on deciduous trees
    Show that spring is here
    Please note how there are two uppercase letters B in the poem, so that the first will use an alternate starting glyph (that is, a swash capital in this particular case) if such a glyph is available: the second will use the basic glyph of the font.
    Yet suppose, please, in a hypothetical scenario, that this poem had just been written by someone after the regular Unicode character plus variation selector pairs, and some others, had all been brought into official use, though I will still use the Private Use Area codes here.
    Suppose that the person who had written the poem wanted to request that the g in the word spring be as swash as possible, within the boundary conditions of the particular situation, in whatever way the particular font wishes to do that.
    This would be done by looking at the list of available letter g plus variation selector pairs and choosing the most appropriate.
    The author would first calculate a 2 x 2 matrix of values for the letter g in the word spring in this poem.
    This would be as follows.
    (4, 1)
    (2, 5)
    This is calculated as follows.
    From the g, for ascenders and descenders, count how many positions of clearance space there are either side of the g, not counting i, j, l, I, J or space characters). Here there are 4 back to the second t of that, 1 forward to the h of here, 2 back to the p of spring and 5 forward to the end of the line.
    The list of available letter g plus variation selector pairs would have a clearance requirement matrix for each glyph.
    Continuing with the hypothetical scenario, elsewhere, a font designer has made a font using the clearance requirement information in the list of available letter g plus variation selector pairs. Specimen glyphs would be in the list, though wide variation in fonts would be expected. It would be for each font designer, for each font, to choose which glyph of the font he or she should use for each letter g plus variation selector pair that he or she chose to support in the font. The font designer would need to base his or her decisions on using the advance width of the character other than i, j, l, I, J that had the smallest advance width in the font.
    Suppose that the author decides to use g U+EE09, which has the following clearance matrix requirement.
    (0, 0)
    (2, 1)
    The poem then becomes as follows.
    Blossom on the hedgerows
    Beneath a sky that is clear
    Fresh leaves on deciduous trees
    Show that spring is here
    The letter g would probably have more character plus variation selector pairs than some other characters.
    William Overington
    16 August 2010

    This archive was generated by hypermail 2.1.5 : Mon Aug 16 2010 - 02:44:46 CDT