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.
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!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?
>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.
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.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?
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.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.
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).
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.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.
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.>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.
John Hudson
Tiro Typeworks www.tiro.com
Vancouver, BC [EMAIL PROTECTED]
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
