On 04/07/2011 04:54 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > >> I believe Fl_Quartz_Graphics_Driver::width(unsigned int wc) >> is very seldom used because in most situations, one has to measure >> a string and not a single character. In FLTK, it's used only in >> Fl_Help_View to measure the space character. >> >> If conversion from a single UTF32 character to UTF16 >> is useful for Fl_GDI_Graphics_Driver::width(const char* c, int n), >> a new function could be useful. But if it's used only in >> Fl_GDI_Graphics_Driver::width(unsigned int wc), I don't think >> it's justified. > > > That may be so for the OSX portions, but the fl_font_win32 version of > ::width(unsigned int wc) probably gets used a lot. > > In particular, ::width(const char* c, int n) works by calling > ::width(unsigned int c) repeatedly for each glyph in the string (and > ::width(unsigned int c) does not handle surrogate pairs correctly at > all.) > > Also, the win32 version of ::draw(const char* str, int n, int x, int y) > attempts to render the text by calling TextOutW() repeatedly on a per > glyph basis, then uses ::width(unsigned int c) to determine how far to > advance the render position for the next glyph. > This too is therefore broken for surrogate pairs. > > Probably ::draw(const char* str, int n, int x, int y) ought to call > TextOutW() for the entire string (indeed, this is what ::draw(int angle, > const char* str,...) does, so why the non-angle version is different I > am not sure, presumably historical? > I note that ::rtl_draw(...) also renders the entire string in one go, so > it is probably the better way to handle things anyway!
It should not be using single-character width or printing apis on *any* platform. If you see this it should be fixed. Almost certainly all uses of these are historical. It may make sense to comment out the single-character fl_width functions and then fix fltk so it never uses them, then put them back in for programs to use them. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
