> Also, measuring the width of glyphs on OSX is very fragile; rather than = > using our "errors to 8859" workaround, it measures the UTF8 string = > directly, and faults if the UTF8 is malformed (this of course is what = > causes the tooltips fault reported elsewhere, but may also cause any use = > of fl_measure to choke in the same way.) > > I guess we need to make the behave the same as the rest of fltk - in = > particular you can create and display a string, but if you then try to = > measure it, segfault... I guess the tooltip code measures its string to = > know how big a popup window to make, and that's where it all goes = > pear-shaped. > > Thoughts? Is it likely that the WOrkaround proposed by Albrecht, viz we = > convert from UTF8 to UTF16 using our own method, and hence getting the = > benefit of the "errors to 8859 / errors to cp125x" hacks, then = > convert/measure the UTF16 string instead?
In r.8596 I have changed Fl_Quartz_Graphics_Driver::text_extents() so it uses the "errors to 8859 / errors to cp125x" trick. It should thus be resistant to faulty UTF8 now. fl_width() and fl_draw() functions already have this property on Mac OS. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
