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

[Tapan S. P. <ta...@ya...>]

I tend to think that this discussion is quite germane to
<indic-computing-devel>, as it plays directly into issues neccesary for a
bootable OS (esp. if we are basing that on the X arch), but if others feel
otherwise, I dont mind doing it back-channel, or on the X lists themselves.

Let me just add that I tend to think that adding support for rendering
complex scripts through an extension or a toolkit may make it hard(er) to
port existing X apps (XEmac, Mozilla, etc.) to support Indic Languages, but
that is a trade-off we may have to live with, esp. if it involves a
grievous violation of the X Protocol.  Maybe I was just being too
revolutionary in my thinking.

However, if we modified the X system in a well-understood what, the
behavior of which was well-documented and easy to reason about, than the
approach Keyur took, that forfeits 100% compatibility for existing
applications, but does a good job for developing new applications and
porting popular existing applications for use in the Indian market, this
does not seem like an unreasonable direction.  For instance we have lived
with both System V and BSD now for over thirty years, so I dont see why
this couldnt co-exist with "Standard" X.  Maybe once again Im being too
revolutionary...

--tapan

----- Original Message -----
From: "Joseph Koshy" <jk...@Fr...>
To: "Tapan S. Parikh" <ta...@ya...>
Cc: <ind...@so...>; "Keyur Shroff"
<ke...@ko...>
Sent: Wednesday, February 13, 2002 10:14 AM
Subject: Re: [Indic-computing-devel] Re: NCST Indix Examined


>
>
> 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...>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com