> 1. Incorrect counting of bytes instead of characters for UTF-8 glyphs. > That's a one line fix.
And about the only one I understand... > 2. Incorrect assumption that all [non-control] characters occupy just > one column. sparkaround's CJK characters occupy 2 characters. Note that fontconfig (and I think XFT and freetype) actually identify three base font width types: FC_MONO - all glyphs in the font are the same width FC_DUAL - where the font has glyphs in precisely two widths, one twice as wide as the other FC_PROPORTIONAL - glyphs are whatever width they like Now, I think the FC_DUAL case is common in CJK fonts that also (usually) have fairly complete Latin (or even LGC) pages. This is probably the case the sparkaround has? And if so, can we leverage that to our advantage and simplify the code by assuming the widths have this 1:2 relationship...? Though, if this is FC/XFT specific, how does that help us with OSX and win32? > This is fixable by incorporating Markus Kuhn's wcwidth.c code > and changing some Fl_Text_* routines to use a char* or ucs > parameter > instead of just one char at a time. I was working out the best > approach and consolidating this in light of... > > 3. wrap_mode(1, 0) should result in wrapping text at the widget width > based on the pixel width of characters, but in fact this only works > for ascii, and not higher UTF-8 characters. I was investigating... Urgh... 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
