> Without looking into it in more detail, I'm going to say docs problem - > it should not say "n characters" but should probably say something like > "the number of bytes needed to represent n characters in UTF8" or some > such thing... Or...? Yes, description should be replaced to "number of bytes", but I want to work with characters.
>> To solve the problem we can convert all string to UTF-16 and >> then restrict its by the specified length. > > Which perhaps will not work either, since as soon as you hit any > character that is not on the BMP you will need a UTF16 surrogate pair, > and the same sort of problem occurs. But in UTF-16 all symbols have size two bytes. There is no problem to set specified size of string as opposed to UTF8 where every symbol can have own size (from 1 up to 5?) . > Indeed - the reason for having the "length" option in these methods is > explicitly so that the string does not need to be NULL terminated... It is one more issue - the current implementation ignores NULL byte. It prints exactly N bytes from the source. Such behavior makes some problems for me too. May be we should check for zero char and stop printing the rest? > Not keen, if we are to have a clean UTF8 API (and I think we should) > then... What is the harm if we add one more function which accepts UTF16 string ? In MS Win it would be part of the gd->draw(...) which would invoked after conversion. >> Because in order to evaluate right length of >> text, user has to convert source line to the UTF-16, restrict >> size and convert into UTF-8 again to invoke fl_draw(s,x,y) >> where string will be converted one more time. Thus at the >> moment there is two unnecessary conversions. > > Hmm, we have functions that tell you the number of "characters" in a > UTF8 string, do these not help? I see no way to use it. Shortly - I have to print column of text lines restricted by specified length. I use the Courier font. The lines can contain any symbols - latin, cyrillic etc. I can't evaluate needed size of line in bytes if I use UTF8. Only via conversion into any accessible format with monosized symbols. > Converting to and from UTF16 is a pain (though necessary at times on > WIN32 since they opted for UTF16 as their internal API, in effect..) I know. > Anyway, best post an STR, and maybe a simple example we can use for > testing. It's no problem, but... my latest STR (fl_draw_image_mono(...) has no body at all!) hang there without any interest _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
