> 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 SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
