DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current I seem to be very late to this particular party, which is bad because it is entirely possible that some of the issues flagged are my fault... Anyway, trawling through the STR, there are a few oddities and misconceptions, so in the hope that I can add some clarity I offer the following thoughts... The Euro symbol: The sample code uses U+0080 for this, which is wrong. Sort of. Here comes the mess... The Unicode spec defines the range 0080 to 009F as non-printing control characters, but it seems like no one ever uses them. Now... lots of web pages that claim to be UTF8 are actually in some MS code page, derived from CP125x, which *does* use the range 0080 to 009F for characters, and in CP125x 0080 *is* the Euro symbol. So there is a sort of unofficial convention to assume that anything in the 0080 to 009F range is actually CP125x and map accordingly. Even fltk has some support for this, see the file fl_utf.c and search for the define ERRORS_TO_CP1252, which does exactly that. However, I do not think we have ERRORS_TO_CP1252 enabled by default. So in fltk, 0080 is *not* a Euro sign, although it possibly could be... As Albrecht observes later in the thread, a more appropriate choice for the Euro sign is U+20AC, but just to add further confusion, the code point U+20A0 is define as "EURO-CURRENCY SIGN", which is *not* the Euro symbol itself, but a standard symbol for currency... Confused yet? Anyway... The odd wrapping kind of looks as if we are just wrapping a wee bit early on the lines with non-ASCII glyphs? It sort of mostly works, but is just a bit premature? Is that what others are seeing? For the record, I'm actually trying this on a WinXP box right now, so XFT behaviour might well be different...! The OP doesn't say what platform they are on, but does mention that the non-ASCII chars seem to be rendered in a different font from everything else. This possibly implies the OP is on Vista or OSX, either of which can do automatic substitution of fonts to handle "missing" glyphs. Other platforms (XFT, Windows prior to Vista, etc.) don't do this auto-font-substitution but if we really want to, we probably can make them do it (albeit with a bit of extra work in fltk...) Now, the OP speculates that the wrap code is counting the physical bytes rather than the glyphs, and this is quite possibly true. The file fl_utf8.cxx provides the functions fl_utf8len() and fl_utf_nb_char() that we probably ought to be using, and I have a vague recollection that the text-editor stuff possibly has it's own private, and slightly different, versions of these functions too. No, I donât know why. Lastly, Greg has some comments about how to find a font that can render his text; For what it is worth, I have (somewhere) a program that I wrote for XFT+fltk, that will tell you whether a font has the glyphs needed to render your text... If I can find it, you are welcome to a copy. In principle, it is "trivial" to extend that code to search all the installed fonts to find the one that has the fewest missing glyphs... Also, in principle, it is possible with XFT to construct a "super font" as a "union" of several actual fonts, to obtain the extra glyph coverage. Fltk does not currently support that, but there are patches posted (by Timothy Lee IIRC) that take us in that direction... Maybe we need to look at those again? Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current
_______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
