Greg Ercolano wrote: > The one UTF8 problem that's bitten me is the font sizes aren't > in pixels anymore, or so it seems. So apparently some work needs > to be done to ensure when a font size is selected, that is the > actual pixel height of the font. This seems to be the reason > Fl_Text_Display/Editor leaves a pixel line of 'drit' behind, > because the font is larger than the widget thinks it is. > > I have a patch that solves the Fl_Text_Display problems > of 'digital drit', but it's more a "clean workaround" to the > problem of pixel size; the patch changes an obscure variant > of fl_height() that only Fl_Text_Display and friends use, > so that it checks the *actual* size of the font, instead of > assuming the font size is the pixel size. This variant of fl_height > is public but has never been documented -- it was only during the > doxygen pass that the method became visible to the public.
IMHO the patch should be applied anyway. It cleans up and documents a public, but undocumented function. That's one point that should be done in any case. The point that only Fl_Text_Display uses it, comes in handy, since we don't need to worry about side effects. It _may_ be a bit of a performance issue, because Fl_Text_Display uses it to determine _all_ font sizes that can be used in one text buffer by checking all styles in the style table, but we can address that later. > The problem with the patch is that the patched variant returns > the 'correct' height by asking the OS how big the font is, whereas > the other more commonly used fl_height() method still returns the > font size as the pixel size, so the two variants will 'disagree' > on the height. > > Matt pointed out that our docs say the font size is the pixel size, > and apps should be able to assume this, and already do. So we really > have to get that fixed. Probably just a matter of tweaking the code > that SETS the font size to underestimate a little. Eg. setting the > OS font to be slightly smaller. Or maybe there's an actual bug in > how FLTK is requesting the XFT font size.. maybe it's not taking > into account descenders or something, because it seems to be off > by about that amount. One burger at a time ;-) We know that we need this, and we should put this font/XFT issue on our utf8 todo list, and check that later. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
