A question about fonts

[Eirik Byrkjeflot Anonsen]

"Andersen, Jan" <jandersen at 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