Kent asked: > How should a freestanding double diacritic be encoded (for purposes of > meta-discussions, and the like): <SPACE, dbl diacritic> or <SPACE, dbl > diacritic, SPACE>?
It *could* be represented as <SPACE, dbl_diacritic, SPACE>, of course, or for that matter <SPACE, dbl_diacritic, TAB>, or other possibilities. The combining character sequence, in either case, is the <SPACE, dbl_diacritic> sequence. But it *should* be represented by something visually more meaningful, such as <U+25CC, dbl_diacritic, U+25CC>, which is how the standard itself tends to represent it when needing to engage in a meta-discussion. The whole point of a double diacritic is its graphic application to two base characters, which point is lost in the discussion if you don't show a graphic base when displaying the character in isolation. > How should combining characters (spacing as well > as non-spacing) that are not vertically centered *roughly* be displayed, > e.g. <SPACE, right-side combining character>, should that *roughly* > be displayed with or without a typographic void to the left of it? It's up to the application. And again, I would say that if this level of detail is a concern to the person originating the text, then the better convention is to represent the combining character on a *visible* generic base. > So > if I want a space (though not an overgrown one), should one use > <SPACE, SPACE, right-side combining character>? Or even <SPACE, > ZWSP, SPACE, right-side combining character>, to prevent "space > collapse". > And similarly for left-side combining characters. Likewise for defective > combining sequences. If I want a visible pseudo-base, a dotted ring, or > an > underline, the answers are fairly clear, using a suitable character as a > base. Exactly. Which is why you should use such conventions if you care about the placement in this detail. Otherwise, you up-level and make use of whatever mechanisms a typesetting application makes available for individual adjustment of the placement of glyphs. --Ken > But not for the cases above. I don't think that should entirely up > to each font (maker), without any recommendation. (A "should" rather > than a "shall" is quite sufficient.) > > /kent k > >
