From: John Hudson (tiro@tiro.com)
Date: Wed Nov 06 2002 - 08:01:41 EST
At 04:05 11/6/2002, William Overington wrote:
>I am thinking here of ordinary TrueType fonts on a Windows 95 platform and
>on a Windows 98 platform.
Sorry. I thought this was a discussion about Unicode.
>However, I thought that the ordinary
>TrueType format would not support ZWJ sequences in itself and that not only
>would a later operating system be needed but that also an OpenType font
>would be needed and that an ordinary TrueType format would not be able to do
>the job. Was I wrong in that thinking?
The Unicode cmap table as been part of the TrueType specification since the
earliest days. This means that any Unicode character, including ZWJ, can be
supported in any TrueType font. In order to perform display time glyph
level substitution for sequences involving that character, optional layout
tables are necessary (along with, of course, Unicode text processing and a
layout engine that uses the optional font tables). But my earlier point was
that doing nothing when you encounter a ZWJ character in text is a
perfectly valid implementation of the Unicode Standard. Not every font is
required to have glyph support for every possible ZWJ sequence, so the
Unicode support in an 'ordinary TrueType font' that does not include the
optional layout tables cannot be judged deficient for not supporting any
ZWJ ligation+ZWJ+. Oops, watch out for that n. ligature!
> >To say that a font only supports Unicode if it can process and
> >render as a ligature every usage of the ZWJ character is foolish: every
> >font would have to contain glyphs and substitution lookups to support every
> >potential use of ZWJ in every possible
> >c+ZWJi+i+ZWJi+r+ZWJi+c+ZWJi+u+ZWJi+m+ZWJi+s+ZWJi+t+ZWJi+a+ZWJi+n+ZWJi+c+ZWJ
>i+e.
>
>I have had a long think about this.
Oh dear.
>Suppose that a sequence of Unicode characters in a plain text file is mostly
>in English and has the sequence c ZWJ t in it at various places.
>
>Suppose that the font is an advanced format font which does not have a
>special glyph for the sequence c ZWJ t yet will simply render it as ct just
>as if the ligature had not been requested.
>
>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?
The font doesn't need to do this, because an application can produce such
an alert based on the presence of 'unresolved' ZWJ glyphs in a document. It
seems to me that the processing required to do is a lot of work to go
through to inform the user of something that he's probably either already
noticed or doesn't care about anyway. In any case, it would be easy to see
which ZWJ sequences had been rendered as ligatures and which not by
toggling a 'Display Control Characters' option.
>While on this topic, perhaps a standradized method of a font reporting that
>it has no glyph for a character which it is asked to render might be a good
>idea. I am aware that a black line box could be displayed, yet in a long
>document, one of those might easily slip past a general viewing of the text
>in a printshop.
There is a standardized method for all sfnt fonts. This is the inclusion of
the .notdef glyph, which is a requirement of the TrueType specification. As
you note, in many fonts this appears as a black line box, but it can take
any form, some of which are easier to spot in proofreading. Adobe use a box
with an X across it. I use a box with a large question mark in it.
Here's an exercise for your enthusiasm, William: devise the form of the
perfect .notdef glyph. It needs to unambiguously indicate that a glyph is
missing, i.e. it should be something that can easily be mistaken for a
dingbat, and it needs to be easy to spot in proofreading in both print and
onscreen (some applications, e.g. Adobe InDesign, make the latter a bit
easier by applying colour highlight to the .notdef glyph).
>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 text
>is rendered correctly on an end user's platform with good provenance. I
>feel that that issue needs to be addressed. Hopefully the Unicode Technical
>Committee will wish to take that task upon itself. It not, then perhaps
>some other process can be found of codifying a standard method.
This is an implementation issue and is the responsibility of individual
system and application developers. If you over-define a standard, by
creating lots of little rules for every possible eventuality in
implementation, you'll find that people will not implement your standard.
> >That's even more moronic that saying that a font has to contain a glyph for
> >every character in Unicode in order to support the standard.
>
>I did not write that.
I didn't say you did. This is often and erroneously cited as the definition
of a 'Unicode font', so was a useful comparison to the suggestion in your
message that Unicode support somehow depended on the ability to process ZWJ
ligation. Neither statement is true.
John Hudson
Tiro Typeworks www.tiro.com
Vancouver, BC tiro@tiro.com
It is necessary that by all means and cunning,
the cursed owners of books should be persuaded
to make them available to us, either by argument
or by force. - Michael Apostolis, 1467
This archive was generated by hypermail 2.1.5 : Wed Nov 06 2002 - 09:43:59 EST