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

Michael Everson everson at evertype.com
Tue Mar 3 10:12:55 GMT 2009


On 1 Mar 2009, at 17:22, John Hudson wrote:

> 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.

That would be OS-specific or application-specific, I guess?

> 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?]

Yes, by pointing Baseletter + combining Dagesh to the Alphabetic  
Presentation forms glyphs. I have now updated Everson Mono to do this  
in two ways. First, I checked to see that my mappings from Base +  
Diacritic to Alphabetic Presentation forms were correct. Then, I  
duplicated this GSUB feature so that the font contains both <ccmp> and  
<liga> (Why? Because some apps render <liga> but ignore <ccmp>.)

> 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.]

Ah, yes, this witchcraft. I don't really know how to do this. Does  
FontLab even support it? I know there's this VOLT thing out there, but  
as I work on the Mac OS I find myself curiously unmotivated to try to  
deal with it. I know... I lag behind... but I really do prefer font  
tools made for humans, rather than for programmers. ;-)

Or maybe it's just that I invest more effort in encoding more  
characters since there are so many yet to encode.

> 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.

"Layout engines" residing... where? Do they have names? I know that on  
the Mac OS some apps -- even apps shipped by Apple do better than  
others, but there's never any end-user info as to what "engine"  
different apps use.

> This is why you may well see variant behaviour, especially on the  
> Mac where OT Layout support remains very spotty.

Yeah, even Quark only supports some features reliably.

> 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.

:-)

By the way the new version, 5.1.6, will be the last version until  
FontLab is updated to remove the 6400-glyph limit. Everson Mono  
contains either 6400 or 6399 glyphs now... I deleted one in order to  
be able to save the font!

Michael Everson * http://www.evertype.com




More information about the EversonMono mailing list