Re: [Indic-computing-devel] Re: NCST Indix Examined

[<jk...@Fr...>]

Dear Tapan,

tp> Remember, X was designed and developed in a time when we were
tp> dealing with a (ISO) Latin-only world, with no idea of supporting
tp> complex scripts and / or fonts , where 8-bit char codes most likely
tp> meant glyph codes as well, so the distinction was moot.  At that
tp> point in time there was no idea of supporting complex scripts and
tp> issues such as ligatures, conjuncts, positioning, etc., nor even the
tp> idea of true type (not to mention open-type) fonts and cmap tables.

The X protocol caters only to the simplest model of text rendering
possible: X fonts are simple collections of glyphs (no additional
semantics) and X text rendering works by placing glyphs ``next'' to
each other.

This is not sufficient even for high-quality Latin text rendering
(eg:- no kerning, no ligatures), and is quite inadequate for other
writing systems.

X was NOT designed for high-quality text rendering.  Please note,
though, that this was a reasonable design in its time.

tp> As we move into the 21st century, it seems very much out of the X
tp> frame of view to have the client worrying about the specific font it
tp> will use and the corresponding mapping table, as well as positioning
tp> issues.  To me this seems clearly within the domain of the X Server,
tp> and its rendering engine.  If the X protocol is vague on this issue,
tp> it is my opinion that the X protocol should change, not our approach
tp> to this problem.

Well, the X protocol /can/ be extended in a controlled way without
necessarily breaking the 'base' semantics.  These are called
'extensions'.  Nearly every X server you would use today implements
one or more extensions to the core X protocol (you can run `xdpyinfo'
and see the extensions present in your X server).

tp> So this becomes a deeper issue of modifying the X Server to
tp> support Unicode and Open (or True) Type Fonts, which must be going
tp> on elsewhere as well.  Anyone know?

The Fonts and I18N sub-groups at the XFree86 project have been working
on these issues for quite a while now.

      http://www.xfree86.org/pipermail/fonts
      http://www.xfree86.org/pipermail/i18n

Keith Packard and a few other developers are developing "RENDER", a
protocol extension to X that provides somewhat more sophisticated text
rendering.

      http://www.xfree86.org/~keithp/render/

"RENDER" uses *new* protocol requests to do glyph rendering (named
`CompositeGlyphs{8/16/32}' respectively).  It doesn't modify the
semantics of `PolyText{8/16}' and `ImageText{8/16}', the existing
protocol requests that do text rendering.  Thus existing X clients
will continue to work unchanged.

"RENDER" moves font-specific and encoding-specific knowledge away from
the X server into the X client.

Shall we move further discussion on X protocol issues off this list?
I'm afraid we may be moving away from the charter of
<indic-computing-devel>.

Regards, 
Koshy 
<jk...@fr...>