From: Sinnathurai Srivas (sisrivas@blueyonder.co.uk)
Date: Fri Feb 08 2008 - 04:52:29 CST
1/
My question was what is the criteria used to class a language as
That requires complex rendering
That requires no complex rendering.
For example Tamil could easily be implemented without the need for any
complex rendering
However, Tamil is currently implemented using complex rendering.
This was one of the main discussions and I have not seen a viable answer
that catergorically states for such and such TECHNICAL reasons Tamil was
made one that requires Complex rendering.
2/
My question was, mostly all proper publishing softwares do not yet support
complex rendering. How many years since Unicode come into being?
When is this going to be resolved, or do we plan on choosing an alternative
encoding as Unicode is not working.
3/
As for bitmap, I meant the "Rigidly-fixed-width-character" requirements.
At present, the complex rendering (which is not working yet in these
systems) will produce extremly large width glyphs which will not be
accomodated by "rigidly-fixedwidth- requirements. What is the plan to
resolve this?
4/
Storage size was one issue, I also do not think, given the available
technologies to deal with large size, this can not be the only reason why
an encoding should change, but can be changed if there are other compelling
reasons for change.
Sinnathurai
----- Original Message -----
From: "John H. Jenkins" <jenkins@apple.com>
To: "Unicode Discussion" <unicode@unicode.org>
Sent: 07 February 2008 19:14
Subject: Re: minimizing size (was Re: allocation of Georgian letters)
On Feb 7, 2008, at 11:06 AM, Sinnathurai Srivas wrote:
> There is also this question, when is it feasible to introduce complex
> rendering and when it is feasible not to introduce complex rendering. Do
> we have a cut-over point, such as character counts or any such criteria?
>
Ultimately, almost all scripts in Unicode require complex rendering
for typographically correct layout. Even a brain-dead (display-wise)
language like English needs ligatures. Unicode was designed with
complex layout in mind.
Of course, some scripts can't be displayed at *all* in a reasonable
fashion without complex layout. Typically these are scripts where the
glyph shapes used for characters regularly change in a contextual
fashion or where ligation is required in almost every word, let alone
scripts where the linear display order of glyphs doesn't match the
pronunciation order of the sounds in the words.
Character count is irrelevant, since the Han script has by far the
largest repertoire but is one of the simplest scripts in terms of
layout (although, to be honest, reproducing some older Chinese texts
will require the use of ligatures). It's simply a matter of how the
*visual* form of the text fails to represent the *letters* of the text
in a non-varying way.
The waters have been muddied by improvised solutions imposed by older
character sets. Users of MacRoman, for example, got used to typing an
explicit ï¬ and fl if they wanted them rather than letting the
rendering engine decide, and Arabic got a large number of
compatibility forms added to allow for minimally acceptable Arabic
display on systems which can't change glyphs contextually. This kind
of approach simplifies the problem of *drawing* the text, yes, but it
makes almost every other process (searching, sorting, and so on) much,
much more complex.
> When is this complex rendering non-working situation going to change.
> Particularly in Publishing. I think primarily, the scripts need support
> for publishing rather than applications or web applications though these
> are important too. When is the problem inherent to publishing using
> Unicode-complex rendering going to be resolved. Is it time to think of
> redesigning the encoding itself or do we wait for a few more years?
>
It depends on the software you're using and the platform you're on.
Word on Windows can handle most of Unicode without problems. Pages on
Mac OS X can do everything in Unicode. InDesign currently is aimed at
the rendering requirements for Western and East Asian languages, but
I'm sure that Adobe has plans to expand this.
> Finally, when will we be even consider the phenominan of bitmap
> characters in Unicode? (Hand held or giant machinery!)
>
I'm not sure what this question means, since "bitmap" refers to a
style of glyph (which Unicode doesn't deal with), and not a
character. Do you mean bitmap fonts that can be used to draw
Unicode? That problem has been considered and dealt with, at least
for TrueType/OpenType, since they support the use of bitmap glyphs in
the font file and have supported it for years.
=====
John H. Jenkins
jenkins@apple.com
This archive was generated by hypermail 2.1.5 : Fri Feb 08 2008 - 04:56:09 CST