> I'm not sure is it a bug or wrong docs, but there is a problem.
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...?
> I tried to use fl_draw() with explicit length of UTF-8 text (MS Win).
> Comments in fl_draw.H say "Draws an array of n characters
> starting at the given location." But in fact it doesn't work
> correctly, because the function fl_utf8toUtf16() which is
> used to convert encodings accepts count in BYTES! But we know
> byte!=symbol in UTF-8. Thereby the fl_draw() prints only part
> of characters from the source text. And last printed symbol
> is incorrect in many cases.
OK, maybe this is a bug, then, don't know yet...
>
> 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.
> For example (fl_font_win32.cxx):
>
> void Fl_GDI_Graphics_Driver::draw(const char* str, int n,
> int x, int y) {
> COLORREF oldColor = SetTextColor(fl_gc, fl_RGB());
> SelectObject(fl_gc, font_descriptor()->fid);
> - int wn = fl_utf8toUtf16(str, n, wstr, wstr_len);
> + int wn = fl_utf8toUtf16(str, strlen(str), wstr, wstr_len);
> if(wn >= wstr_len) {
> wstr = (unsigned short*) realloc(wstr, sizeof(unsigned
> short) * (wn + 1));
> wstr_len = wn + 1;
> wn = fl_utf8toUtf16(str, n, wstr, wstr_len);
> }
> + wn = (wn < n) ? wn : n;
> TextOutW(fl_gc, x, y, (WCHAR*)wstr, wn);
> SetTextColor(fl_gc, oldColor); // restore initial state
> }
>
> It works fine, but this solution treats the input line like
> null-terminated one. It can be wrong in some cases.
Indeed - the reason for having the "length" option in these methods is
explicitly so that the string does not need to be NULL terminated...
> What to
> do? I don't know exactly. May be we should set maximal
> conversion size (in several times more than input size).
> Or we can modify the function fl_draw() to work with UTF-16
> (add new one).
Not keen, if we are to have a clean UTF8 API (and I think we should)
then...
> 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?
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..)
Anyway, best post an STR, and maybe a simple example we can use for
testing.
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
