Marco Cimarosti wrote:
> > Indeed. And it wouldn't be fair to fault businesses reluctant to
> > invest millions of dollars to target an impoverished market.
>
> Well, I am not saying that it would be easy, or that it would be worth
> doing, but would it really take *millions* of dollars for implementing
> Unicode on DOS or Windows 3.1?
It could be done with, say, Ramon Czyborra's Unifont and QBasic.
>
> I think that many programmers and font designers on this list would be happy
> do it, if they just had enough free time or a little funding.
>
Funding makes the world revolve, free time makes it rotate. It
probably wouldn't be too difficult to come up with something
which would provide basic Unicode file viewing under DOS, maybe
even with input/editing, too. What's really going to slow down
the DOS application is the look ups required to emulate OpenType
features needed for complex scripts like Indic or Latin.
>
> > Pre-composed Latin characters in the PUA don't require
> > any special rendering support, they'd be rendered the same
> > as any precomposed BMP Latin character.
>
> I thought that the PUA was being considered here as a place to put the extra
> *glyphs* needed internally by a rendering engine -- not as a direct mean of
> encoding text.
If the PUA is used in order to display Latin Unicode on older
systems, like Win 9x, the source page in true Unicode would need
to be converted to a new file using the PUA encodings before it
could be displayed.
In TrueType/OpenType, glyphs don't have to be mapped (assigned to
code points). Many fonts have glyphs which the user can't access
directly, this is especially true now with OpenType.
>
> In the case of PUA being used as a repository of extra glyphs, special
> rendering support is indeed required: which is, the part of the rendering
> engine that maps sequences of base letter + diacritics to the precomposed
> PUA code points.
>
This could be handled at the input level, the display mechanism
would only be presented with the final form. In other words,
if the goal is to provide support on older OS, valid Unicode
documents from other sources would need to be converted to
the PUA. If one makes a file on their system with PUA, it would
need to be converted to valid Unicode prior to posting it to the
web or world. The keyboard layout for the PUA should be set
up to enter the PUA code points.
Users might elect to store personal data in the PUA form on their
system, they wouldn't need to convert it back and forth for their
own viewing.
At least, this was my thinking. Rather than trying to duplicate
some fairly complex programs designed to run with much memory
and speed for the old hardware, it should be more streamlined to
treat the whole thing like code page conversion. The user wouldn't
need to be aware of the encoding at all, such an application could
be made to do such things automatically. Sure, it would be slow,
but that's the speed of the old computers. Naturally, this approach
would work best with plain text. Word processor files don't lend
themselves well to external conversion.
> > The 'cmap' in TrueType fonts for Windows uses double-byte encoding.
> > (Windows NT supports the new specs which allow multi-byte.)
>
> Does this mean that TrueType fonts for Windows NT would be capable of
> breaking the 64-KB barrier and support a whole Unicode font which also
> support extended planes? Really TrueType or OpenType?
No. The new cmap supports more than double-byte in order to access
non-BMP encodings. The Glyph IDs (the number/order of the glyphs
in a font) remain locked at 65536 max. Unfortunately this isn't
expected to change, last I heard.
>
> >
> http://www.linguistics.unimelb.edu.au/research/hmong/hmongaustpahawh.html#pa
> hawh
>
> What script is this? Do you know where I could find more info about it?
There should be an English version of that page at the same site.
Michael Everson has a proposal for the script which can be accessed
from the Roadmap page at:
http://www.egt.ie/standards/iso10646/bmp-roadmap-table.html
(I think it's Michael Everson's proposal, the link to hmong.pdf isn't
working as of this posting.)
Also, Daniels and Bright "The World's Writing Systems" devotes
Section 57 to the script in an article by Martha Ratliff.
Best regards,
James Kass.
