On 23 Oct 2008, at 13:16, Albrecht Schlosser wrote: > > (1) IMHO, the "windows fl_measure bug" should be fixed, because > measuring text should be as platform neutral as possible, if feasible.
The more I look into the way win32 handles fonts, the less convinced I am that this is really a bug as such - rather, it is "differently correct" as it were. What really matters is that it returns consistent results that, which it does, for the most part. Bill has switched to just measuring the whole string in fltk-2, and I will try that with your test code too, but the down side is that we lose the glyph caching mechanism (which Matthias quite likes, I think) and I have no feel at all for how "expensive" measuring the string really is at runtime... > (2) fl_measure should keep delivering a constant height value, as > Bill suggested, and as you confirmed by using an alternate > approach. IMHO we need to be able to measure multiline text for > labels with constant line spacing, and editors should have constant > line spacing as well. Maybe lots of code depend on this feature. Yes - for now I only suggest we add a new API and leave all the existing ones alone. > FWIW, I wrote a small demonstration program to see how fl_measure > works now. I append measure.cxx, together with measure.png that > shows the output of the three test versions (from left to right) > that are mentioned in measure.txt (the text output of these three > versions): Windows, FLTK 1.1 / Linux, FLTK 1.1, non-Xft / Linux, > FLTK 1.3, Xft. Thanks. I'll add that into my test harness too. > Interesting point: the windows version seems to be off by a few > pixels for the "off" box width. The text is chosen to demonstrate > different glyph ascent and descent values. Maybe you can use the > "how" argument to substitute your new functions for testing. Yes - I see that. And (bizarrely, I think) in a test using your test string, I find that GetTextExtentPoint32W() returns a slightly wider value for the string as a whole, than that which we are computing. Which would probably have the effect of "fixing" this artefact... Might be interesting to try a string that will be kerned, maybe with a "T" next to an "o" or something similar... Cheers, -- Ian _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
