Re: News of AFII: international standard registry of glyp...

Date: Tue Dec 22 1998 - 09:52:43 EST

       pc>You suggested that the industry may not be ready for 32-bit
       codes. I had not thought about that. Glyph IDs in TrueType
       fonts are 16-bit, I believe, so that is an issue for TrueType.
       Also, you're very right that numbers are much less useful for
       working with glyphs than mneumonic strings.

       w>I don't think so. There shouldn't be a relation between
       glyph IDs and input code points at all in TTFs! Cmaps have
       been invented to establish the needed relationship.

       What I meant was that for a typographer or script engineer, as
       they are doing their development work, mneumonic string
       identifiers will make their work easier. I certainly agree that
       what goes on in code is another matter entirely, that numbers
       are equally adequate, and that glyph IDs and codepoints are and
       should be distinct.

       w>I don't see the problem. You can always populate the PUA
       with your own scripts; you don't need to care of any of these
       assignments! If you properly separate input encoding from
       glyph addressing, no problems will occur. E.g., you can assign
       to code U+F012 your `foo' glyph, and at the same time you
       access glyph `uniF012' mapped to another code point.

       The overlapping of the Private Use Area and the Corporate Use
       Subarea is only a concern if you want to do a 1-to-1
       Unicode->Glyph mapping (e.g. for unknown glyphs or glyphs which
       can't be handled by your rendering system) -- of course, it's a
       shame that even recent software written by Apple, Adobe, or
       Microsoft still rely on the 1-to-1 Unicode->Glyph model...

       My impression of what Adobe was proposing was more than just
       glyph IDs; they were talking about character assignments. They
       were also talking about subdividing CUS (which is formally
       defined only as a subset of PUA) in a cooperative fashion among
       major developers. Just as there shouldn't be any need for me to
       worry about assigning my characters to the same codepoints that
       Adobe assigns their private characters, so there shouldn't be
       any need for Adobe to worry about whether they assign their
       private characters to the same codepoints as does Apple. Yet
       Adobe appears to be worrying about this. Adobe is suggesting
       that they and others work together to avoid the space that each
       other uses. This appears to be asking for an de facto industry
       standard of something that by definition should not become an
       industry standard.

       My biggest concern has to do with how software is implemented.
       Because MS makes use of U+F020 - U+F0FF for symbols, it may not
       be safe to assume that you will always be able to safely assign
       your own characters in this range and expect them to work as
       expected in, e.g., Word or, for that matter, on any Windows
       app. MS's software may assume certain semantics for that range.
       It is entirely up to MS what they choose to do in their
       software, and anybody who wants to live with their software has
       to deal with the decisions they made, or else buy from someone
       else. Now, hopefully, MS developers won't make it hard for
       others to use that range; indeed, I'm pretty confident that MS
       won't do that. At present, I believe that MS software will
       assume certain semantics for characters in this range only if
       the selected font is flagged as "symbol". They can always
       choose to do otherwise, though, and might be more inclined to
       do so if they were cooperating with others regarding
       allocations in the CUS.

       MS software assumes particular semantics for characters in the
       range U+F020 - U+F0FF only if the selected font is a symbol
       font. That's not a problem. What if Adobe brings to market a
       "Unicode-conformant" version of Pagemaker, and that version of
       Pagemaker assumes that U+F64D is a TABULAR OLDSTYLE COLON SIGN,
       regardless of what font is applied. I may intend for that to be
       a TAI LUE LETTER HIGH KA, and not appreciate the fact that
       Pagemaker will gladly wrap lines in the middle of words
       following that letter. Granted, the question of how to make 3rd
       party apps aware of the semantics of PUA characters is an open
       question, but the answer is definitely not for developers to
       make assumptions about those semantics.

       Now, I haven't read all of the information on Adobe's site, so
       I need to be careful that I'm not accusing them of something
       when I don't know fully what they're doing. I don't know that
       Pagemaker or other Adobe apps will behave as I've suggested in
       the previous paragraph. My point is simply that I'm concerned
       about some statements I've seen on Adobe's site with regard to
       character assignments in PUA. I hope I've explained enough here
       to show why that is a concern for me.

This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:43 EDT