Date: Wed Nov 06 2002 - 11:06:29 EST
On 11/06/2002 05:05:17 AM "William Overington" wrote:
>I am thinking here of ordinary TrueType fonts on a Windows 95 platform
>on a Windows 98 platform.
So, by "ordinary" you mean a TTF with a cmap table but no GSUB or other
tables that perform glyph transformations (though fonts containing such
tables are just as much TrueType fonts as fonts that are not -- and some
fonts with such tables were part of some versions of Win 98).
> I was under the impression that the reason that
>an ordinary TrueType font will not process a ZWJ sequence on those
>was that both the operating system and the ordinary TrueType font do not
>have the capabilities to process ZWJ sequences.
Given your definition of "ordinary TrueType font", glyph transformations
are not possible, by definition. But your definition isn't all that
relevant: fonts that contain tables to perform glyph transformations can
be used on *any* flavour of Win32 (or other platforms), given appropriate
It is true that neither the western versions of Win95 or Win98 had
OS-level capability of applying tables inside TrueType fonts to perform
glyph transformations. The Mideast version of at least Win98 (not sure
about Win95) did make use of some such tables (at that time, the
technology was known as TrueType Open). But any application software on
any platform could make use of such tables, provided the software is
written to do so.
You'll probably come back to say, "But I was talking about 'ordinary
TrueType fonts'." If you insist on an invalid assumption, there's no way
to argue against it. It's like saying, "software with a character-mode UI
is not capable of displaying bitmap graphics" -- true, but irrelevant.
> My understanding is that
>even an OpenType font with ZWJ sequence facilities will not work on a
>Windows 95 or Windows 98 platform.
It can, given software that knows how to process such sequences to do
>As far as I know, there is no requirement in Unicode that the rendering
>system should notify, perhaps using an Alert dialogue box or similar, the
>end user that the ZWJ request has been "made yet not fulfilled".
>Can an advanced format font supply such a message to the rendering system
>for onward notification of the end user?
Yes, actually, there is a built-in feedback mechanism: the font provides
to the rendering system outline data for the c glyph and the t glyph, and
the rendering system rasterises those outlines in consecutive order, so
the user sees a glyph sequence "ct" rather than the ct ligature. This
feedback mechanism even works on older systems.
A font implementer could make use of this built in capability to provide
even more explicit information: a font feature might be used to cause
invisible characters to be displayed in some way (similar to seeing a
raised circle for the non-breaking space when you set Word to show
If you really want a dialog box to popup providing notification to the
user, I'm wondering how many times as the file is opened and a page is
rendered you'd like this popup to appear? 17 times if there are 17
instances of < c, ZWJ, t > that are not rendered as a ct ligature? Not on
my system, thank you.
>Also, perhaps some method of asking a font to declare a
>list of the code points for which it has a specific glyph would be
Software simply needs to inspect the cmap table. No new mechanism is
needed for this. You're enumerating solutions that need to be built for
problems that don't exist.
>There seems to be a gap between the Unicode Technical Committee encoding
>characters into a file and the process of making sure that the desired
>is rendered correctly on an end user's platform with good provenance.
It is not the job of the Unicode Technical Committee to define guidelines
or review implementations for rendering of text.
>feel that that issue needs to be addressed. Hopefully the Unicode
>Committee will wish to take that task upon itself.
I assure you, they will not.
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
This archive was generated by hypermail 2.1.5 : Wed Nov 06 2002 - 11:57:23 EST