L2/03-234 Source: Ken Whistler Date: August 5, 2003 Rick, Lisa, Cathy, I think this note from Paul is a significant element of the thread re the Hebrew characters, and should be entered as an L2 document and included in the agenda with the other Hebrew documents for discussion at the next UTC. If, as seems likely, the UTC will accept some variant of the CGJ proposal as the way to resolve the Hebrew combining class issue, then this catalog of desiderata from the UTC and the editorial committee for how to document the result would be a useful starting point for considering how to follow up. I'm cc'ing Paul, since I don't know if he already asked for this or has any objection to his note being put into the record on this basis. --Ken ------------- Begin Forwarded Message ------------- Subject: RE: More on Meteg and CGJ Date: Wed, 30 Jul 2003 05:23:16 -0700 Thread-Topic: More on Meteg and CGJ To: "John Hudson" , "Kenneth Whistler" Cc: , , , "Ralph Hancock" As Ken has pointed out, the CGJ is classified as a NSM (non-spacing mark) and therefore should not be treated as a control character. I will therefore, leave the glyph in stream. Some issues that are critically important if this character is to be used as a "solution" for the Biblical Hebrew problem. 1. The Unicode Editorial body needs to draft some documentation on the use and behavior of the CGJ. - How font designers should handle that character. For example, if show symbols is on, does the CGJ character have a visual representation, or is it always hidden? - How NFC ordering is impacted when the character is used with these cases of Biblical Hebrew. - Suggested uses of the CGJ and indications where it should not be used. 2. As a NSM, does the CGJ become part of the sorting and text matching algorithms or not? This is an impact on users. 3. People making keyboard standards need to add this control character to the keyboard so users can input the character. Of course, this will confuse users who never see the CGJ or don't know about its existance because there is never a visual clue it is present. Personally, I still view using the CGJ as a "patch" because it is not fixing the root problem. It is only putting a bandaid on top of the wound. It would be much better to assign correct weights to the Hebrew combining marks. Regards, Paul -----Original Message----- From: John Hudson [mailto:tiro@tiro.com] Sent: Tuesday, July 29, 2003 4:18 PM To: Kenneth Whistler Cc: Joan_Wardell@sil.org; unicode@unicode.org; kenw@sybase.com; Ralph Hancock; Paul Nelson (TYPOGRAPHY) Subject: Re: More on Meteg and CGJ At 03:16 PM 7/29/2003, Kenneth Whistler wrote: >How about: > > shin < regular meteg < CGJ < hataf < dagesh < shindot > >The CGJ prevents the reordering of the meteg around the hataf and >dagesh, and the sequence gives the font a separate >sequence to ligate, distinguishing it from >above. The meteg need to be to the left of, i.e. after, the hataf vowel: shin < hataf < CGJ meteg.2 #in context: CGJ | #Remove CGJ lookup CGJ -> I *think* I can make pretty much any sequence involving CGJ work by removing the CGJ glyph as an appropriately early stage in glyph processing: it does its job in character ordering and then gets ditched in display, having triggered any glyph substitutions necessary for further processing. However, as noted before, this is entirely dependent on CGJ being treated as a painted combining mark and *not* as an unpainted control character. I'm still *very* nervous about this proposed solution if there is a chance that applications will not paint this character. John Hudson Tiro Typeworks www.tiro.com Vancouver, BC tiro@tiro.com ------------- End Forwarded Message -------------