[haiku-development] Re: Help needed on font fallback system

  • From: PulkoMandy <pulkomandy@xxxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 6 Jul 2010 17:51:28 +0200

> The square is not actively inserted by any code in the app_server. Font files 
> often contain a glyph for an unmapped character. Freetype will fallback to 
> this glyph when you ask for glyph indices, for which the font file does not 
> contain any proper glyphs.

Ok, I got that part working. Trying to map a char to a glyph will return
0 if there is no suitable glyph, so I just had to return early in this
case instead of looking up the 0 glyph in the font with freetype.

> In GlyphLayoutEngine::LayoutGlyphs(), there is a 
> preflight run over the glyphs to determine the required locking. (Note that 
> the locking is quite delicate and you should understand it fully before 
> making changes, I can help you with that.) What needs to happen is that the 
> glyph returned from Freetype needs to be checked against the built-in 
> fallback glyph of the font file. I haven't looked at how to do this, but it 
> must be possible. 

For now I made a proof of concept test using a different cache for the
fallback font, and it seems to work pretty well. It doesn't seem as
efficient (nor clean), so I'll have to dig around the font caching to
handle it this way.

> Also I don't know how other platforms handle it, but it 
> sounds logical that font A could use font B as fallback, and font C could use 
> font D, and not font B - depending on their looks... Perhaps it's even 
> necessary to layer fallback fonts. Or to define multiple fallback fonts 
> depending on the character map code page. 

There are different ways to do it. Windows has a "similarity" indicator
in fonts to help grouping them. Apple seems to try every available font,
and if nothing is found, use a font called LastResort which shows the
unicode plane of the character and a symbol meant to help the user
decide which font to install.

My current eperiment consists of failing back to VL Gothic whenever a
char is missing. This allows to display japanese characters out of the
box, but doesn't help much with other problems.

> One thing that comes into my mind 
> though is that in order to avoid the fallback code paths in all but the first 
> encounter of the glyph index for the given FontCacheEntry, the glyph should 
> be inserted into that FontCacheEntry, even though it may end up twice in the 
> font cache overall. A second run will then find the glyph as if it were part 
> of the original font and cached the same way.

It's one way of doing it, and seems quite a good one. I'll try to see if
I can do it.

Thanks for the help !



Other related posts: