On 07/17/12 07:33, darren legge wrote:
> If I re-compile fltk to not use xft then it starts much quicker (4 seconds)
> but utf8 characters do not show correctly. I thought xft was just
> anti-aliasing
> (which won't work with pcf fonts anyway). It seems xft is required for utf8
> to work though - is this true ?
No, I don't think that's true; I've rendered utf8 stuff without xft,
pretty sure.
Many times I've seen my fltk apps displaying chinese/japanese
in bitmapped fonts back in ye olde days (ie. in chunky, non-anti-aliased
fonts).
Or at least, it used to work. Probably still does; I haven't
looked back since xft started becoming default on linux platforms.
I recall having to download special font files to get utf8 working;
I'd search around for 'japanese fonts for linux', look for the fonts
they recommended downloading, then made sure they showed up in
xfontsel(1),
then I'd play around with Fl::set_font() in my app to assign that font
to the FLTK font I wanted it to be assigned to (eg. FL_HELVETICA,
FL_COURIER, etc)
Perhaps the issue you're having is simply the OS's bitmap font files;
where the font files themselves might not have glyphs for the utf8
chars you're trying to render, or perhaps the machine has them, but
they are not default, and just using Fl::set_font() to pick the right
one will solve it.
I found I had to experiment a lot with the Fl::set_font() function
to find the right fonts to map so that eg. japanese characters would
render correctly. I'd then recommend to my customers to install those
particular fonts so my app would show the japanese text correctly.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
