Date: Thu Nov 13 2003 - 15:21:10 EST
Jim Allan wrote,
> I take this to mean that any application can refuse to interpret PUA
> code points and still be conformant.
(Please note that in my original post, I was only expressing an
opinion of the way things "should be", rather than stating that
"this is way it is".)
Quoting from TUS 4.0, page 110, section 5.3 Unknown and missing
"There are two classes of code points that even a "complete"
implementation of the Unicode Standard cannot necessarily
interpret correctly: ..."
(One of the two classes is "PUA code points for which no private
agreement exists". -- Since no application is truly sentient or
omniscient, no application can determine that "no private
"An implementation should not attempt to interpret such
code points. However, in practice, applications must deal
with unassigned code points or private use characters. ..."
"... An implementation should not blindly delete such characters,
nor should it unintentionally transform them into something else."
In my book, the "unintentionally" should probably be dropped
from the above sentence.
> I do not find any rules as to what an application ought to do with code
> points that it does not interpret. Unless I'm missing something,
> substitution of a missing glyph indication would be conformant.
> I think it would be better if such an application indicated this in some
> other way than by the same missing glyph that it would use to indicate a
> character was not found in the current font, but I don't see that
> Unicode imposes any such requirement.
Unicode probably shouldn't impose any such requirement, the missing
glyph is not part of Unicode and is not mapped to any character.
The purpose and semantics of the missing glyph are: 'this is the
glyph that will be displayed by every application when the font
in use lacks a glyph assigned to the code point being called.'
Any other use of the missing glyph would be illegitimate and it
would also be highly misleading.
... the section about "Shape of .notdef glyph"
This archive was generated by hypermail 2.1.5 : Thu Nov 13 2003 - 16:14:33 EST