> > I suspect this doesn't work all that well, particularly on > linux/XFT, > > where I suspect that this workaround is partly inhibited by > my decision > > to render the text strings using XftDrawStringUtf8() directly. > > Ah, meanwhile I checked that I use xft on linux. I'll try > again without, > just to see what happens. If you were able to try a parallel build, one with XFT, and one without, then I'd very much welcome the feedback (although if you do find a problem I'll likely not be in a position to fix it all that soon!) > aware of that anyway, I only wanted to make some tests without string > conversion, and it worked on Windows, but failed on Linux. > That seemed > strange, but since there are different fonts, I'll have to test more. Fonts, and the set of glyphs they actually contain, is a bit of a pain. Some things appear *not* to work on Linux because the fonts tend to contain sets of glyphs targeted for specific languages, or language groups. This happens on Windows and OSX too, of course, but it is less obvious there because: - M$ provide a few "pan-Unicode" fonts that contain a much larger set of glyphs, making it less likely you'll hit a gap. - OSX ATSU incorporates a mechanism (off by default, but enabled in my fltk-utf8 port, despite being quite slow!) that tries to automatically substitute glyphs from a set of "fallback" fonts, if the current font does not provide the glyph you requested. Now, that last trick (auto font substitution) we sort of can do with XFT, or at least we could write some code that emulated that behaviour by creating a font set (at runtime) that covered the glyphs in the text to be rendered. I did a few experiments on this at the time, but left it out because I wasn't happy with what I'd done. I plan on going back to this. Eventually... > Yesterday I tested with test/utf8, and I could display utf-8 chars in > different fonts, even this RTL (?) text on the left side, #5 and #6. RTL - "right-to-left", used for languages (Hebrew, Arabic, etc) that are rendered in the "other direction". Other TLA's you'll often see looking at fonts are: LGC - "Latin Greek Cyrillic", used to denote a font that contains glyphs intended to cover the majority of languages that use L, G or C characters. CJK - "Chinese Japanese Korean", ditto, for C, J or K languages. -- Ian SELEX Sensors and Airborne Systems Limited 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 fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
MacArthur, Ian (SELEX GALILEO, UK) Tue, 30 Sep 2008 01:44:00 -0700
- Re: [fltk.development] Comments about t... Albrecht Schlosser
- Re: [fltk.development] Comments about t... MacArthur, Ian (SELEX GALILEO, UK)
- Re: [fltk.development] Comments about t... Albrecht Schlosser
- Re: [fltk.development] fltk-1.3 and ISO... MacArthur, Ian (SELEX GALILEO, UK)
- Re: [fltk.development] fltk-1.3 and ISO... Albrecht Schlosser
- Re: [fltk.development] fltk-1.3 and ISO... MacArthur, Ian (SELEX GALILEO, UK)
- Re: [fltk.development] fltk-1.3 and ISO... Albrecht Schlosser
- Re: [fltk.development] fltk-1.3 and ISO... matthiasm
- Re: [fltk.development] fltk-1.3 and ISO... imacarthur
- Re: [fltk.development] fltk-1.3 and ISO... Albrecht Schlosser
- Re: [fltk.development] fltk-1.3 and ISO... MacArthur, Ian (SELEX GALILEO, UK)
- Re: [fltk.development] fltk-1.3 and ISO... Albrecht Schlosser
- Re: [fltk.development] fltk-1.3 and ISO... Albrecht Schlosser
- Re: [fltk.development] fltk-1.3 and ISO... imacarthur
- Re: [fltk.development] fltk-1.3 and ISO... Albrecht Schlosser
- Re: [fltk.development] fltk-1.3 and ISO... MacArthur, Ian (SELEX GALILEO, UK)
- Re: [fltk.development] fltk-1.3 and ISO... imacarthur
- Re: [fltk.development] fltk-1.3 and ISO... Bill Spitzak
- Re: [fltk.development] fltk-1.3 and ISO... MacArthur, Ian (SELEX GALILEO, UK)
- Re: [fltk.development] fltk-1.3 and ISO... Albrecht Schlosser
- Re: [fltk.development] fltk-1.3 and ISO... Michael Sweet