> > > Trying to understand whether UTF support is now complete in FLTK-1.3, > > I see with a default FLTK install (thus with xft) on a Debian Linux > > that Greek and Arabic text display correctly, but I don't get asian > > characters displayed. Yet, I believe to have the required fonts, > > because asian characters appear correctly in browser pages, window > > title bars, and Nautilus file manager. > > Is this the current stage of FLTK UTF support, or am I missing some > > packages ? > > It's most likely to do with the fonts you are using, rather than the > fonts you have installed, I think. > > I'll try and explain... > > Note that recent versions of winXX (maybe since Vista, not sure) and OSX > do a pretty good job of "filling in" missing glyphs for the current font > - e.g. if you have some version of "Courier" selected as your font, but > display some text that uses glyphs that are not in the actual font you > loaded, the font rendering engine will fall back to some default > substitutions from other fonts to fill in the gaps. > > But XFT does not do that - it looks for the glyphs in the font that you > selected, and if the glyph is not present, you get a missing glyph... > > Now, very few fonts are "pan-Unicode" as that makes for a *huge* file, > and the few that are "pan" tend to have rather rough and ready glyphs > for most codepoints... > > So in general, with fltk rendering using XFT, you get missed glyphs. > > However, it does not have to be like that - XFT allows you to sort of > "merge" several fonts together to get better coverage, and there are > patches in the STR files (from Timothy Lee) to do pretty much that; you > would pass a comma separated list of font names to Fl::set_font(...) and > XFT sort of makes a font that is a superset of those faces, thus > potentially getting better glyph coverage. But those patches are not > applied yet - though if you wanted to give them a try out, that would be > very helpful! > > Alternately, XFT can be asked whether a font contains a particular > glyph, so we could write code to search the installed fonts and find the > ones that would work for any given section of text... (I had code to do > this, but don't know where I hid it now.) > > This would be more time consuming at runtime, but might give more > consistent results (it would depend less on the programmer picking a > suitable font at compile time, not knowing what fonts the end user will > actually have available, for example...) > > Many tools (e.g. via panGo or otherwise) do essentially that at runtime, > which is possibly why your fonts work in gnome apps, but not in fltk > apps.? > > Did that make sense?
Ian: that is a perfect explanation. Many thanks. It looks like your code that finds fonts for handling missing glyphs would be very handy at this time. I much prefer this solution than the alternative one that requires the programmer to fiddle with Fl::set_font(). _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
