On 22.10.2008, at 15:10, MacArthur, Ian (SELEX GALILEO, UK) wrote: > - What do people think? Should we have an extended fl_height/ > fl_measure > mechanism to determine the actual size of the text glyphs to be drawn? > If so, I'll generate some STR's.
FLTK support for fonts is poor and inconsistent. It is limited to what the Fomrs library provided back at times when fonts were bitmapped and the "height" of a font was the same as the height of the bitmap, and a line break would simply continue that many pixels lower. But the porting of FLTK to OS X Quartz was a pain because no aspect of Quartz fonte rendering is limited to integers. In fact, assuming that a character width is evenly dividable will generate extremely ugly text. FLTK currently uses a somewhat secret flag that limits Quartz to integer math, but this makes fonts blow 10 points close to unreadable. So that first thing to support Cairo and Quartz correctly must be a move to floating point coordinates and measurements. Secondly, we will have to open up access to many more aspects of the selected font, some of which you mention in your post, and more. But here also lies the usual problem of staying fast and light: after reading through the Apple font rendering manuals for weeks, and trying to fully understand Unicode, I concluded that all font rendering in the world should be limited to 8x8 pixel bitmap fonts in the range of 32 to 126 ;-). Text rendering can fill books, and those books can fill a library. > - Do folk think the win32 fl_width() mechanism should be brought more > into line with the XFT/OSX implementation? Or should we leave it > alone? > Or...? Yes, font rendering should look more or less the same on all platforms and deliver at least similar values for the same arguments. fl_width should take kerning and ligatures into account, but it must do so quickly! This is not always the case (see Quartz) which is why the width calculation uses per-charcater buffering. The fault here lies within FLTK which does not buffer any text information an measures and renderes every text segment from scratch every time a redraw is needed. It will be extremely hard to remain efficient here! Anayway, I am starting to drift into a rant because I am overworked. I like your short-term additions and would welcome them to the current 1.3! Matthias ---- http://robowerk.com/ _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
