Michael Jansson wrote:
> > Transmitting text in visual order is simply not Unicode: it
> > is a hack for
> > which you'd better chose another name.
> > > and contain extra information
> > > to let the user agent (the browser, a.k.a. 'ua') know which
> > > alternate form to use for a character.
> > It sounds totally useless: this extra information is already
> > implicitly
> > contained in the text, and it is called "context".
> Hang on here. I'm not saying that a Unicode capable ua should
> do this. Why
> would it? If an app support Unicode then it supports Unicode.
> There would be
> no need for messing up the text? We all know the reasons why
> you should not want to do that.
> What I am saying is that if you are going to resort to
> preprocessing text
> into glyph indices, then you might as well base it on Unicode
Why on earth? If a browser is incapable of handling Unicode, it would not
even be able to handle your pseudo-Unicode.
Moreover, a browser incapable of handling Unicode is also incapable of
handling HTML, so it's place is the trash can.
> and not dream up your own encoding format as you outline in
> your previous mail.
I am afraid you totally misunderstood my previous mail. I'll try to express
I never outlined any encoding format of any kind. The encoding format I have
in mind is *standard* *unabridged* Unicode. Full stop.
What I was talking about was my(?) idea for how to *render* complex scripts
using traditional fonts, such as those small unpretentious fonts embeddable
in web pages.
The mainstream way to render complex scripts is using "smart fonts", such as
OpenType, Graphite, or AAT. Smart fonts contain all the needed information
to transform strings of Unicode characters into strings of glyphs.
This is a very flexible method, which allows the maximum of freedom to type
Traditional fonts do not contain these information. What I argued is that
these fonts can anyway be used for rendering complex scripts, provided that
the transformation from strings of Unicode characters into strings of glyphs
is done *out* of the font.
For this to be possible, it is necessary to have a fixed set of glyphs and
transformations agreed upon between the people who implement the "ua" and
people who draw the font.
Of course, this is not a flexible method, and it binds the hands of type
designers. That's why I suggest it only for fallback mechanisms such as web
Someone wishing to read Hawaiian web pages without having an Hawaiian font
probably doesn't bother for typographical excellence!
> Whether you want to call it visually ordered Unicode or
> something else is really beside the point.
I am not sure whether an expression like "visually ordered Unicode" would be
legal. I say "legal" in its strict and literal meaning: I guess they could
sue you for selling a product which promises such a "feature".
> > > I don't see why you need code points in this case. A ua can
> > > easily render text with nothing but glyph index as input,
> > Of course it can. But I fail to see why you want to call it a
> > "Unicode" ua.
> I would not. Again, I'm pursuing the idea *you* presented earlier. The
> reason why you would want to resort to such an approach would
> be if an ua do *not* support Unicode (or at least not for a specific
No, again, that is YOUR idea. I already told you my idea for browsers not
supporting Unicode: the trash can.
However, the fact that an application "supports Unicode" does not mean that
it is obliged to be display any possible Unicode character, including those
for which the application has no fonts.
> If you want
> to show Tamil with IE on Win98, then can't use real Unicode,
> even though
> Win98 can show individual Unicode characters. You better
> evaluate what you
> options are on such a platform, and deal with the issue if
> you still want to show Tamil there.
You basically have three options:
1) Throw Win98 in the trash can and buy a decent OS, running on a
decent computer with decent Tamil fonts.
2) Throw IE (or some of its DLL's) in the trash can and write a
decent browser (or part of it), implementing complete Unicode functionality.
3) Throw Unicode in the trash can and encode Tamil using a hack
(ASCII based or Unicode based, it doesn't matter).
Option (1) is obviously the best one, but it might clash against economic
Option (2) is what I was talking about (although not about IE specifically).
Particularly I was wondering whether and how web fonts could play a role
Option (3) is what you seem to be talking about.
This archive was generated by hypermail 2.1.2 : Fri Jul 05 2002 - 04:16:48 EDT