Carl Brown wrote:
> If these folks really want Unicode everywhere I will write
> Unicode for the IBM 1401 if they are willing to foot the
> bill. Seriously I would never agree to such a ludicrous
> idea.
Thanks, Carl, but if "these folks" is me, I don't even know what an IBM 1401
is, let alone needing you to write Unicode support for it.
If I am allowed to introduce one more anachronism, there exist a concept
called "portability". So, once one of these nutshell implementations of
Unicode exists (on, say, a DOS box with a bitmapped font), it would not be
necessary to re-write it from scratch for each next "end-of-lifed
unsupported OS's" or embedded device.
I hope this may cast a slightly different light on the effort-to-usefulness
ratio of this.
> Can you imagine a Unicode 3.1 character properties table that
> uses 16bit addressing?
I am not sure what you mean but, yes, I can imagine it very well.
But it would be an unnecessary waste to load the whole databases in memory,
although it would be possible: the vers. 3.1 character properties contains
only about 13,000 lines. Multiply this by the 32-bits of a DOS "far
pointer", and you obtain an array that still fits in a 64KB segment. OK:
this array would crash as soon as 3,000 more characters are added to
Unicode...
But loading whole tables (or fonts) in memory is not really the way to go;
you wouldn't do this even in much more powerful environments. It would be
much better to keep the data on a file and access it through an efficient
file indexing method and a well-tuned cache algorithm.
> Unicode take lots of memory.
I promise that I won't use the word "myth" for at least a week.
But my impression is that it is rather systems like OpenType and ATSUI that
take lots of memory. And this is not a surprise nor a scandal: these systems
are designed for OS's that require lots of memory for *everything*.
But this should not draw us to the conclusion that Unicode itself is a
memory-eating monster. It is just a character set! The memory and storage
requirements of Unicode are not so terribly more complex than, say, older
double byte systems.
_ Marco
