> > Arabic needs tagging of glyphs as being `initial', `medial',
> > `final', and `isolated', as specified in the Unicode book. Since
> > this is identical for all fonts the OpenType designers have
> > decided to make this information not being part of the font
> > itself. In the long run, this makes the fonts smaller.
>
> With my proposed context system it doesn't save but a few bytes
> total in the font file since the context rules can be shared by all
> the characters that need them.
Details, please.
> > Having a string of input character codes, you apply the first
> > lookup table, then you start again and process the next one, and
> > so on until all lookup tables have been applied.
>
> Wow, what a horribly bad design. No wonder including arabic
> initial/medial/final information would make the font so big.
Why do you think that it is bad design? How would you activate and
deactive typographical features? This goes far beyond `console
fonts', so it is of course more `complicated' than you expect.
However, it works reasonably well, and noone asks you to use more than
a single lookup.
You might compare this with AAT from Apple (the `morx' table as
documented in the URL I posted in a previous mail). This is something
similar but far more complicated to debug since it uses automatons
which can have almost infinite states.
> Why would I want to use this format after you explained above how
> stupid its substitution system is? I designed something much better
> on the very first attempt and since have refined it much more. I'll
> post the new ideas soon.
Aah, you will receive the Nobel prize for this. What you've done is
apparently better than man-years of works done by font experts.
Be serious! I want to see not only ideas but a complete
specification. THEN I believe you. And there is still the question
who is going to implement this.
> GPOS is undesirable for character cell glyphs.
Not at all. It handles accent stacking, and it can be even used for
fixed-width fonts (which simplifies the tables enormously).
> > > Mongolian can be and is written horizontally as well.
> >
> > Using Cyrillic, yes, but not the traditional script, AFAIK.
>
> No, in the traditional script.
I stand corrected, I haven't known that. Can you give a URL?
> Ask yourself this: what would a speaker of Urdu do if they needed to
> write a message and the only paper they had was barely tall enough
> for one handwritten letter. If your answer is "write it all on one
> line" or even "write it essentially on one line with each word
> slanted slightly diagonal" then there's absolutely no reason the
> same can't be done on a computer terminal.
Uh, oh, I can also write German with uppercase letters only if there
isn't enough room for descenders. Is this a solution?
> > I'm quite conservative here: It's a very bad idea to adopt a language
> > or script to the computer. It should be the opposite.
>
> You've hit the nail on the head with regard to why so much of m17n
> and i18n software is bloated to hell: this is the exact philosophy
> of bloatware!
Please stop with these useless rhetoric explosions. They don't help
to solve the very problems we have.
> [...] I do believe very strongly that all people (including English
> speakers) should tolerate having their language displayed in a form
> that respects both the intended look of the script and the nature of
> the medium on which it's displayed.
Of course! I've asked you already *which scripts* you want to
support, and you still haven't answered. Just say that the normal
Urdu style of writing isn't going to be supported; they have to use
standard Arabic writing (using their extended character set, of
course).
Werner
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
