> Slightly OT (but maybe not). I read an interesting article > yesterday in the current c't Magazin (German computer tech > mag - has been around for 25 or so years) that there is no > real way to determine if a font is truly monospaced. The font > file formats don't always give this information, and if they > do, it's not necessarily true. Adding t that the automated > glyph insertion as described in this thread, there is no sure > way of knowing if a font is monospaced on any platform. Even > if the characters "l" and "M" have the same width, it does > not mean that some Chinese glyph somewhere up in the ranks > isn't twice as wide... .
Yup. It is tricky. A while back, I wrote my own font chooser widget for Linux, and discovered "the hard way" that a lot of fonts do not correctly report whether they are mono-spaced or not. In the end, I simply ignored the reported value and used each font to measure a few preset strings in the languages I was interested in. This gave a fairly reliable answer, for the very small set of languages I needed to support, but is clearly useless in the general case. And as I said elsewhere in this thread, a lot of CJK glyphs are effectively fixed-pitch because they tend (gross oversimplification, of course) to be rendered in a grid pattern - but as Matt points out, that does not mean they are spaced the same as LGC glyphs in a "similar" mono-spaced font. And in any case, CJK or LGC fonts tend (more oversimplification!) to be the easy cases to deal with, in so far as they tend to have one "character" in the string mapping to one glyph on the display. For some languages, the canonical representation of a word (by which I mean the series of "characters" that are stored in the computer's memory) does not have a one-to-one mapping to the displayed glyphs... There are all manner of arcane rules about glyph ordering, elisions, implicit vowels, diphthongs, the appropriate glyph shape for that character depends on the context in which it appears, etc... It is a nightmare. We can't even begin to address that... So... We can probably get reasonable looking support for LGC and CJK (especially if they are L-to-R ordered.) R-to-L ordered *text* we can probably display with fltk-1.3, though whether it really works well enough to actually render R-to-L languages I can not say for sure. For example, can we really handle semitic languages (Hebrew, Arabic, etc.) with what we have at present? I do not know, but I don't think so. As for languages from the Indian subcontinent, I think we'd have to seek experienced help: we know there are a lot of good programmers in India, some of whom must know how to do this... As it stands, we have not a hope of making that work though, I suspect. -- Ian 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
