"Andersen, Jan" <jander...@informatica.com> writes: > Sorry for posting this here, where it is almost certainly not > appropriate, but I don't quite know where to ask, and I suspect some > of you guys probably do. So, this is my question: > > I work a lot with Chinese, and need to be able to display the full > range of CJK characters in Unicode; unfortunately that exceeds the > capacity of all current font specifications (that I know), and I would > like to see if I can do something about it. After all, when you > display a character, what you need is to take your character > representation (eg UTF-8) and look up a glyph - if things are > reasonably sensible, it ought to be fairly doable to replace that part > from somewhere and replace it with, say, a database interface. But > where do I even begin to understand font-handling in X?
The really short answer: X doesn't do fonts. Current thinking is that glyphs should be rendered by the client application into images, which are then passed on to X and rendered using plain image composition rather than a text-specific api. X does have a font api. It even has an api for using multiple fonts at once to render text that require several fonts, see XCreateFontSet(). But the font api has some weaknesses that easily becomes significant for modern applications. It is not entirely obvious what you want to accomplish. Are you writing an application that displays text? Then any sane modern toolkit should handle the problem for you. Of course, proper text rendering is a bit more complex than taking each unicode code point and render that as a glyph. Some writing systems and some typographic conventions renders some unicode code points differently depending on the surrounding glyphs. In european typography, the classic example would be the 'fi' ligature. Also, a single character may be represented as more than one unicode code point, in particular when using combining characters. I guess this is largely a non-issue with Chinese. And while unicode does provide combining characters for Japanese, you can probably eliminate them without loss of information by a preprocessing step (i.e. I believe there exists unicode code points for the composed form of every interesting glyph for Japanese). Not to mention that a unicode code point does not encode a glyph, not even when the code point is a fully composed character. A unicode code point encodes a character. And the same character may have different glyph representations depending on language. (It is a bit unclear to me how important this is in practice, though.) eirik _______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com