Re: [fltk.development] [Library] r7536 - branches/branch-1.3/src/xutf8

2010-04-20 Thread Duncan Gibson
I've incorporated most of the comments made in the previous thread Re: [Library] r7530-branches/branch-1.3/src/xutf8 I think that these, more straightforward, changes to mk_wcwidth.c should now be portable across all platforms, unless someone has an embedded system where sizeof(unsigned int) is

Re: [fltk.development] [Library] r7536 -branches/branch-1.3/src/xutf8

2010-04-20 Thread MacArthur, Ian (SELEX GALILEO, UK)
I've incorporated most of the comments made in the previous thread Re: [Library] r7530-branches/branch-1.3/src/xutf8 Lovely. Though, as ever, I have even more comments... I think that these, more straightforward, changes to mk_wcwidth.c should now be portable across all platforms, unless

Re: [fltk.development] [Library] r7536-branches/branch-1.3/src/xutf8

2010-04-20 Thread Albrecht Schlosser
On 20.04.2010, at 10:08, MacArthur, Ian (SELEX GALILEO, UK) wrote: Well... I still wonder if we need src/xutf8/fl_wcwidth.c at all? My preference would be to put that functionality into the existing file src/fl_utf.c, which is kind of where I think it belongs anyway... In particular, that

Re: [fltk.development] [Library] r7536-branches/branch-1.3/src/xutf8

2010-04-20 Thread Duncan Gibson
Well... I still wonder if we need src/xutf8/fl_wcwidth.c at all? My preference would be to put that functionality into the existing file src/fl_utf.c, which is kind of where I think it belongs anyway... I kept it separate for testing purposes. fl_wcwidth() can certainly be moved into

Re: [fltk.development] [Library] r7536-branches/branch-1.3/src/xutf8

2010-04-20 Thread MacArthur, Ian (SELEX GALILEO, UK)
Well, so far, for solving the STR-2158 problems at least, I had only identified one place where fl_wcwidth() would be needed, and seeing as you have to call fl_utf8decode() to get the ucs value to pass to fl_wcwidth(), the extra testing is already done in fl_utf8decode(). Ah. OK. I was

[fltk.development] Fl-printer tree r7542

2010-04-20 Thread MacArthur, Ian (SELEX GALILEO, UK)
Manolo, Is the fl-printer svn tree expected to build under win32 at present? With r7542, I'm getting... Compiling Fl.cxx... In file included from Fl_win32.cxx:1940, from Fl.cxx:1494: ../FL/Fl_Printer.H:75: warning: `class Fl_Printer' has virtual functions but non

Re: [fltk.development] Fl-printer tree r7542

2010-04-20 Thread manolo gouy
Manolo, Is the fl-printer svn tree expected to build under win32 at present? With r7542, I'm getting... Compiling Fl.cxx... In file included from Fl_win32.cxx:1940, from Fl.cxx:1494: .../FL/Fl_Printer.H:75: warning: `class Fl_Printer' has virtual functions but non

Re: [fltk.development] Fl-printer tree r7542

2010-04-20 Thread Albrecht Schlosser
manolo gouy wrote: Manolo, Is the fl-printer svn tree expected to build under win32 at present? With r7542, I'm getting... Sorry. I forgot one .H rename. It should compile now. $ svnversion 7546 $ make === making jpeg === === making zlib === === making png === === making src === make[1]:

Re: [fltk.development] Fl-printer tree r7542

2010-04-20 Thread manolo gouy
manolo gouy wrote: Manolo, Is the fl-printer svn tree expected to build under win32 at present? With r7542, I'm getting... Sorry. I forgot one .H rename. It should compile now. $ svnversion 7546 $ make === making jpeg === === making zlib === === making png === === making

Re: [fltk.development] [Library] r7536-branches/branch-1.3/src/xutf8

2010-04-20 Thread Duncan Gibson
Me: Well, so far, for solving the STR-2158 problems at least, I had only identified one place where fl_wcwidth() would be needed, and seeing as you have to call fl_utf8decode() to get the ucs value to pass to fl_wcwidth(), the extra testing is already done in fl_utf8decode(). Ian: Ah. OK.

Re: [fltk.development] [Library] r7536-branches/branch-1.3/src/xutf8

2010-04-20 Thread imacarthur
On 20 Apr 2010, at 23:07, Duncan Gibson wrote: Anyway, this has been committed and is now live... Lovely. I wonder if Fl_Text_Buffer should be tweaked to use the new fl_wcwidth(char*) directly rather than fl_wcwidth_(ucs) version then? It (Fl_Text_Buffer character_width) seems to be