WRT transient font matching: whatever CoreText does, it gets the same effect, I think. All I know is that when I have an English font selected and switch to a Chinese IME and it picks a Chinese font for me, and there's somehow an association an italic looking English font will pick an italic looking Chinese font. I've actually been a little curious about how that happens.
> OS X widgets know that their version of fl_width is slow and optimize for > that by caching and minimizing re-rendering. Fl_Text_Editor simply re-renders > the whole text... . Ah, this explanation makes sense to me. So it seems like there are a couple options. One is to do the caching, add a memoizing wrapper around fl_width so the app can control the cache (and put a note on fl_width saying it may be slow), then modify the various text displays to use it. Maybe Fl_Text_Display is the only one that renders enough text to need it. Another is try to replace Fl_Text_Display on OS X with a native widget. Presumably there is an OS provided styled text entry that already does all this stuff. I guess it depends on how convenient it is to integrate with fltk idea of a style map or fltk event handling. But provided it gives a pretty low level way to integrate then this would be the best option. Otherwise if it's going to be a nightmare of hackery and inconsistency then it would be better to stick to pure fltk. Also, caching in fltk may make sense if windows and linux are expected to follow suit and get fancier with their text rendering. Certainly that seems more likely than them getting simpler and faster. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
