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