[EversonMono] everson mono - bugs with Yiddish (Hebrew) with dagesh

Mark H. David mhd at yv.org
Mon Mar 2 19:29:59 GMT 2009

OK, I think I've got a description that precisely accounts for all the 
problems: the dagesh is combined with the base character *following* its 
base character, and the base character is rendered unadorned (without 
dagesh) and the following base character has the corresponding 
char+dagesh character from FBxx (alpahabetic presentation forms Unicode 
range) rendered in its place.

Now, can someone figure out how that can happen?  Is it a bug in the 
renderer or the font?



John Hudson wrote:
> Mark H. David wrote:
>> I have also learned that other fonts on MacOS share this trait of 
>> working in Mellel but not working in Nisus Writer Express or 
>> Firefox.  An example is the Ezra SIL font.  In the OpenType wiki, it 
>> says that Mellel fully supports OpenType on Mac OS X, and it seems 
>> unique among common applications in doing so.
> That's basically true.
> There are three ways in which a sequence of base letter plus combining 
> dagesh can be correctly displayed, depending on the combination of 
> layout engine and font used.
> 1. The layout engine performs a character-level substitution of the 
> precomposed letter+dagesh from the Alphabetic Presentation Forms block 
> in Unicode. This is most likely done in a buffered state during 
> display, not affecting the stored characters string.
> 2. The layout engine leaves the character string untouched and passes 
> the decomposed sequence to the font cmap table; the font then uses an 
> OpenType GSUB feature such as <ccmp> to ligate the letter+dagesh into 
> a precomposed glyph. [Michael, you mentioned ligation; is this the 
> approach you have taken?]
> 3. The layout engine leaves the character string untouched and passes 
> the decomposed sequence to the font cmap table; the font then uses an 
> OpenType GPOS <mark> feature to dynamically position the dagesh glyph 
> relative to the letter glyph. [Note that in the case of a monospaced 
> font, in which even combining mark glyphs should be on the common 
> advance width, an initial GPOS step must be made to collapse the marks 
> to a zero width.]
> The first method may work in any app using a layout engine that works 
> as described. Since character-level substitutions are faster to 
> process than glyph-level substitutions, some layout engines are built 
> to always perform such substitutions before proceeding to the font 
> cmap. Other layout engines may rely completely on the font tables, and 
> still others might simply not know what to do with a given character 
> string and font.
> This is why you may well see variant behaviour, especially on the Mac 
> where OT Layout support remains very spotty.
> The fact that this aspect of Everson Mono is working correctly in 
> Mellel is a good sign. It indicates that the fault is probably not in 
> the font, but in the other applications that a) are not performing 
> character level substitutions and b) don't know how to process OT 
> Layout tables.
> John Hudson
> _______________________________________________
> EversonMono mailing list
> EversonMono at evertype.com
> http://evertype.com/mailman/listinfo/eversonmono_evertype.com

More information about the EversonMono mailing list