Hello again Peter,
Please see my answers below.
F. Avery Bishop
Program Manager, International Evangelism
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Monday, September 20, 1999 11:09 PM
To: Unicode List
Subject: Re: Uniscribe for Win32 Unicoders
>I hope I'm not the only one who would like to know the answers
to these questions. I think Uniscribe will do a lot for the
cause of Unicode and multilinual software on Win32 once a few
of us figure out how to use it and deploy it and start
spreading the word.
No, you're not by any means the only one who would like to know
the answers to those questions. We've got more besides!
I'd summarise our questions as:
- What is the nature of the relationship between Uniscribe and
fab> Currently Uniscribe uses the OpenType feature tables for Indic scripts
only. All other scripts are displayed using the standard TTF tables such as
CMAP, and (in the case of Arabic), with hard-coded algorithms initialized
form the data in the GSUB table.
- Does USP10.DLL provide support for all of the capabilities of
OT? For example, OT allows language-specific rules to be
included. (Actually, "language" is not the real notion the
Typography folks have in mind, but it's an acceptable
simplification for purposes of this discussion.) Does USP10
support language-specific shaping behaviour?
fab> Not today. We also don't support general OT Arabic fonts, for example,
to position glyphs vertically to give the diagonal flow of a Nastaliq font.
- Does USP10.DLL support the 'required features' concept of OT
whereby a font can specify which rules *must* be obeyed for a
fab> No, however, see below.
- Just how generic is the knowledge of script behaviour that's
in USP10.DLL? E.g. could I achieve rendering of Arabic or of
Devanagari using shaping behaviour that is different than those
behaviours MS provides for Arabic and Devanagari simply by
chaning the data in the OT font tables? I.e. just how
extensible is the Uniscribe/OT system?
fab> Short answer: No. Long answer: For Arabic, we follow a standard set of
Arabic tables (I believe they are init, medi, fina, and alon), as well as
the liga table for ligatures and the mset table for mark placement. We'll do
any shaping specified in these tables, and ignore other tables. For Indic we
support a standard set of tables given in our Indic OT specification, which
provide general control of Indic behavior, and ignore other tables. I was
going to include here a link to the URL of that spec, but just found that
it's not finalized and therefore not published. We do expect to finalize it
and put it on the web shortly, however.
fab> As a general comment, we understand that there is a need for generic
text layout based on OpenType, and are looking into whether/how to add that
support in the future. It won't be available in IE5/Windows 2000, however.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT