On 21 Sep 2011, at 21:39, Nikita Egorov wrote: > > off topic: I'm not sure the word "glyph" is a proper one in our case. > IIRC the "glyph" can be only part of character. A few glyphs can be at > one character cell and make up grapheme, symbol. So I'm interested in > how many character cells will be displayed.
OK - but you can not know that from just looking at each character in the string, in the general case. In a language (say English) that has simple typography, then it can Just Work; 1 Unicode codepoint == one character == one glyph == one displayed symbol. But for languages with more complex layout constraints, e.g. Indic languages, or Semitic languages, then you need to see each symbol in the context of the surrounding symbols, and any ligatures, re-ordering, variant shapes... before you can even tell what needs to be drawn. And remember that the canonical order of the characters in the string may not match the order they are shown on screen, and that eliding some or all of the characters may substantially alter the appearance of the rendered text... Often, it may be better to render the text then clip it to fit, than to try and pick out just a few characters from the stream. But I guess you are not interested in that level of complexity! (I know I'm not!) Anyway, returning to my point before I wandered way off... For English there's generally a pretty close mapping between characters in the string, their canonical order in the string, and the glyphs that appear on the screen. I think that's mostly sort of true for LGC languages (though not always - Matt's Umlaut example...) and often true for CJK text (again, with many exceptions...) But yes, the final symbol that appears on screen may be composed of multiple fragments, and simply counting character entries in the source string is not going to help with that at all... Anyway - fltk has no tools to help with that, we just fire symbols onto the screen. To know what symbols to fire, you need to look at ICU or PanGo or some such mechanism to figure out how to compose a view of the string from the canonical representation in the bytes - then maybe just clip that to fit into the viewable area... _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
