indic-computing-devel

Re: [Indic-computing-devel] UTF-8

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

sunil> -- I agree. Because UNICODE would double the traffic between the server 
sunil> and the client.

The typical web page has a few KB of text and markup along with
references to hundreds of KB of embedded images.  Using UTF-8 or other
similar encoding for the textual content is unlikely to cause the
total traffic per page to increase by much.

tp> Now i agree there is a strong argument that this should be done server 
tp> side b/c of portability, but it is not always true that Unicode 
tp> transfers should take 2x as long.

True.

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

Re: [Indic-computing-devel] NCST

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

> He has some very compelling reasons for doing things the way he did,
> which he has been fighting out with the GTK/Pango people on his own.
> I tend to agree with his view to a certain extent.

I'm sure many of us would be interested in knowing the rationale
behind the NCST design -- in particular, breaking the X11 protocol was
an extreme step which I'm curious about.

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

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

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.

--tapan


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

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

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

[Keyur S. <key...@ya...>]

--- "Tapan S. Parikh" <ta...@ya...> wrote:
> 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.

On this point I am fully agree with Koshy's idea that we
should write an extention. X has been evolved through
extentions. Writing an extention and then incorporating
them into various applications is a long process. However
in my opinion this is accceptable solution which may be
proved better in long duration. Changing or breaking X
protocol is definately not a great idea. Provision is there
for you to define new data structure and write an
extention. So why not to take advantage of it?

While starting my work on IndiX, I also decided to give
support using an X extension. But unfortunately, I had to
work under strictly imposed constraints :-( esp. that
applications should not be modified for Indian language
support. So I did the thing in whatever way the people
wanted me to do and also tried to do it in best possible
way!

(I have downloaded test suite. But I think I'll have to
read documents before running it. At the moment I am busy
with preparation of IndiaSoft exhibition to be held in
Delhi. So after 24th Feb only I'll be able to test it). 

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

And we also have two desktop environments in X (KDE &
GNOME). ;-)

Regards,
Keyur


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

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

[Keyur S. <key...@ya...>]

--- Joseph Koshy <jk...@Fr...> wrote:
> 
> 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>.

Like Tapan, I also believe that this discussion is more or
less related to [Indic-computing-devel]. But if you wish,
we can move it off the list.

Regards,
Keyur


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com