> >>One > >>such situation is Holam Male which never takes an additional combining > >>mark*. So why can't we represent it as <VAV, HOLAM, variation selector>? > >> > >> > > > >Because the UTC has ruled out <CM, VAR> as interpretable sequences. > > > > > > Is there a better reason than "because we say so"? You don't have to > answer that one.
Well how about this: because there are saber tooth tigers stuck for all eternity in the La Brea tar pits with less reason to have believed that they were stepping into a trap than the UTC believes may be lurking behind <CM, VAR> sequences. > I don't quite understand you here. Are you saying that <VAV, variation > selector, HOLAM> would be acceptable for representing a variation of the > entire grapheme cluster, or that it would not? Not. <VAV, VAR1> *could* be defined as a standardized variation sequence, given the current definition of what that means. The standard would have to specify, in StandardizedVariants.txt, just what <VAV, VAR1> looked like, as opposed to merely <VAV>, so that an implementation that chose to interpret <VAV, VAR1> would know what to do and where it would get a glyph description for the variant. If you then wanted to apply a HOLAM combining mark to that variant, whatever it looked like, you would be free to do so, of course. But the definition in StandardizedVariants.txt would be of the standardized variation sequence itself. It wouldn't define what happened when you applied a HOLAM to it, or for that matter, what happened when you applied an acute or a candrabindu to it. Variation selectors are *not* intended to stand in for a generalized glyph description language, nor to be used in indefinite sequences of "stuff" to represent arbitrary glyphic variation. The *only* allowed sequences defined, definable, and interpretable are <BASE, VAR>. That's it. Period. Fini. If holam male cannot reasonably be considered as application of a normal holam to a variant form of a vav (which itself has independent existence unrelated to the application of a holam to it), then, use of variation selectors to attempt to solve the representation problem is just a dry hole. Hmm? > > The alternatives which we might consider include <VAV, ZW(N)J, HOLAM>. Yes. Such approaches are unconstrained by the concerns which apply to variation selectors. --Ken
