> FWIW, the following code works fine on linux (using the Musica font
> face) but not on win32.
> I don't have ready access to a mac right now...

Hmm, well, my test code (including the simple version I just posted) *is* now 
working on this Vista box, with my proposed changes applied.

Not really sure why, as it appeared to be not working a while ago - I may have 
had finger trouble linking against the right fltk lib... oops...

Anyway, I'd like to push the change I have made, BUT it is not complete in any 
way. In particular:


- It only fixes the specific case for the win32 version of:
void Fl_GDI_Graphics_Driver::draw(const char* str, int n, int x, int y);


- But does not address the equivalent problem in:
void Fl_GDI_Graphics_Driver::draw(int angle, const char* str....); that uses a 
similar but different approach.
Actually, the "easy" fix for that method might be to *not* use fl_utf8decode() 
at all but only to use fl_utf8toUtf16() and process the whole string into UTF16 
in one go.


- The various ::width() methods need to be checked. It looks very much that the 
::width(unsigned int c); method can't handle surrogate pairs and will fail, and 
hence the ::width(const char* c, int n); also fails as it simply calls the 
first method, char by char.


- The OSX version of ::width(unsigned int c); looks to be similarly broken - it 
also fails to handle the surrogate pairs correctly, so by extension...


- The *nix versions (XFT and Xlib) look like they may actually be OK, as they 
measure UCS chars rather than UTF16, AKAICT. They seem to be OK in my tests 
(such as they are) at any rate.

--
Ian

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to