Re: Some discoveries about multilingual .swf's with ming0.3a

Hi David,

I somehow came to fonts first and to ming and flash later.
Well, unicode seems to be a great way to put many languages into one document,
and obviously a flash player could be a great device to support multilingual input.

On the other side, I think it will be a long time before unicode is really used throughout,
for a variety of reasons:
for a start, while unicode16 files can be recognized easily but are impalatable to the
majority of applications, utf8 files look just like codepage text. In order to find out whether
a, say, italian text is saved as codepage or unicode, it is necessary to read into the file
and watch out for characters that should not be there in the chosen encoding. It is much
the same as reading codepage text for a different version of iso-latin-xx and then finding out
the proper codetable.
Also, nobody had the idea to create new file extensions (how about .txt and .utxt) to distinguish
files and provide coexistence during a migration period.
I believe that any organisation currently using codepage, that has a large body of archived text
will be quite reluctant to switch to unicode

While unicode helps to exchange information, it does not address the issues of typography:
With some fonts, you get a couple of extra characters - typographic variations such as
swash capitals, ligatures, ...
Typography also can be quite picky about kerning.
You may not be aware of these things because the "industry leader" more or less ignores
them - the adobe indesign program is said to be the one that most completely supports
these features. In order to do that, a lot of info has been added to fonts that is simply not
present in flash's internal font format
As there was no support from said "industry leader", the same problems exist with codepage
fonts - if a particular font requires extra characters for typographic reasons, the font
designer would place them somewhere in the code table, into character positions that
are not supported by that particular font.
Of course someone using such a font had to know the code table, and auto-converting
documents using these fonts to unicode will produce rubbish.

Type designers, and the print industry, were addressing these issues in a few different
ways
- windows compatible: put the character anywhere, and use the postscript name of the
chosen character position in the postscript version of the font (a german fractured font
may have a tz ligature, and its postscript name could be ddagger)
The designers of unicode did not deal with typography, so type designers still do not know
where to put extra characters
- preserving typography: put the character anywhere, choose a postscript name representing
the character, and live with the fact that non typography-aware software may be confused
- opentype (unlike so many other open... names this does not refer to open source)
which allows to describe extra characters exactly within the font file, but requires specialized
applications to take advantage of it.
BTW: the pdf format also is aware of these issues: if a proper typography application uses
a properly encoded font with said tz ligature, the resulting pdf document will include a
table telling document indexing software to treat this character as a t and z

Back to ming and fonts: a tool that reads in an iso-latin-1 font (either swf or fdb file)
and creates a unicode fdb from it would be quite possible. In order to cope with the stuff
I talked before, it should ideally have a reencode feature driven by a table
(like: put code 0xc3 as unicode 0x1d4)
Using table would allow to make the same adjustments to a couple of fonts - of course
different weights of a particular typeface would have the same extra characters

BTW: I was faced with typographic issues long before unicode, and I was always using
unix-type OS (where there was no built-in font support other than the fixed size x-windows
fonts). I came up with a solution that uses 7bit compatible encoding for european
alphabets (this means french, czech, polish, and turkish) and a rendering engine for
postscript fonts that tries to build up characters from components. So if I wanted to use
a czech s with that crown accent, it would display in the editor as encoded (because
screen font does not have the character), and the printed document or pdf would use
a proper czech s from the font if available, or an s with the accent if that is available,
or just a plain s

In fact, I do not run windows .... I sometimes work at a place that has a lone windows machine
to read the odd message arriving as a doc or even xls file - and people tend to ask me
whether I can help them to clean up virii or fix some other oddities. Sometimes they ask
only for things as simple as exporting an explorer file list as a text file - and I either
teach dos box or come up with a perl script. The only time I wrote a c program for microsoft
environment was back in the dark ages of dos - I got a 286 machine with a pld device
software, and added an editor similar to the unix editor I was using at that time, as well
as a file transfer program. So I could edit my pld spec sheets both locally or on the
unix machine that this box was connected to. At that time I really learned my lesson: if
development efforts fail on the microsoft system, only option is to reboot (and perhaps
lose a bit of work) while on unix it is just ctrl-c and then go back to editor

Wolfgang