Variant unicode with custom fonts

#1
A problem that has bugged me for a long time; when I am using pleco with a custom font, unless the font is totally comprehensive (ie supports both s/t, 20,000+ characters, eg. foundertype/ms fonts etc), there are bound to be display problems simply due to the font designer only choosing to provide one font character for a character that has multiple unicode options within one character set. eg. 為/爲, 說/説, 麽/麼. This is so annoying as it basically renders any font under 10,000 characters unusable as a 'good looking font' in pleco. The characters which have such variants are often the most frequent, and any text in the reader or in a chinese entry just goes all bulky and strange looking by reverting to the default font. Surely there is a way to get pleco to revert to a variant? This would not only make a massive difference in terms of aesthetics, it would also mean I can reliably plug in various 篆/草/隸 for recognition practice without having to constantly switch back to an ugly but comprehensive 楷 font.

Thanks for any help that can be offered
 

mikelove

皇帝
Staff member
#2
Unfortunately, Android doesn't have a good efficient way to determine whether or not a particular character is supported in a particular font (there is a feature to check if a character is drawable, but it also checks whether it can be drawn with a system fallback font and doesn't allow you to specify you only want a non-system one), and they don't seem to let you specify fallback fonts except systemwide (there was an exciting reference to typeface builders with fallbacks in Android 8 but it turns out that's just a fallback if the entire font is missing), so as far as I know there's no good way for us to fix this in the short term; I suppose in theory we could add our own library to parse the character mapping tables of a custom font and fetch a list of supported glyphs on that, but that would be quite a lot of work for something that frankly only a small number of people would use.

Longer-term, we're probably going to do one of these two things with text handling on Android in the next 2-3 years that should improve matters:

a) Port our custom text view code over from iOS and stop relying on Android to draw text at all (instead loading fonts + drawing text ourselves with FreeType), in which case we can do whatever we like with font fallbacks very easily; or
b) Start doing all of our text rendering with embedded web views, which do let us specify fallback fonts. This is a lot slower than our own text view but also a lot easier to get working, the main concern is that it might be too slow on some devices.
 
#3
b sounds awful. keep pleco 100 pct snappy over and beyond (almost) everything else. a 0.05 sec response time is 10 times better than a 0.1 one.
 
#5
Thats really interesting to know, I guessed it must have been an os problem, as pleco is normally so sleek, but my curiosity got the better of me. I also think a) sounds like a great option for the future, looking forward to implementation if and when possible. Thanks again for the helpful response!
 
Top