On Sun, 2 Apr 2017 11:57:49 +0200 Michael Everson <[email protected]> wrote:
> On 2 Apr 2017, at 10:53, Richard Wordingham > <[email protected]> wrote: > > while <U+2657, U+FE01> would be the white bishop on a black square. > > Perhaps someone can show me evidence from mathematical symbols or > > Japanese kanji that such semantic modifications are perfectly > > acceptable. > There isn’t a semantic modification. It’s a graphic modification, > just like Even the emoji VSes regulate display, not semantics. Thus: > > 2194 ↔ LEFT RIGHT ARROW > = z notation relation > ⁓ 2194 FE0E text style > ⁓ 2194 FE0F emoji style > > This is a matter of display, of font glyph selection. We seem to agree that it should be a graphic modification, rather than as semantic modification. The question I pose is, "Is it just a graphic modification in this case?". I'm not convinced that it is. A player starts with two non-interchangeable bishops. <U+2657, U+FE01> could only refer the white bishop that is restricted to black squares. That's a semantic difference. > > If these variation sequences are acccepted, I hope that the > > intention that they contribute to producing presentable populated > > chess boards in plain text will be captured in at least the Unicode > > Standard. > My intention would be to re-format the proposal document as a UTN for > guidance to implementors, if that’s what you mean. <snip> > > I can see issues with line-spacing, which I believe is formally out > > of control in true plain text. > > So is the font rendering. The immediate parallel that comes to mind is the ideographic square. A sequence of CJK ideographs should be a monospace sequence - and that is the major point of most of the ASCII clones with 'IDEOGRAPHIC' or 'FULLWIDTH' in their names. The uniform width is a key part of the semantic of the seqeunces being discussed. > We could add some *COMBINING WHITE GAME SQUARE FILTER and *COMBINING > BLACK GAME SQUARE FILTER, but this does not simplify matters. First, > you would have to decide what base character to use for the squares > on which no characters stand. I think that the proposed 25A1 WHITE > SQUARE and 25A8 SQUARE WITH UPPER RIGHT TO LOWER LEFT FILL make > better sense because in environments where the OpenType features > cannot be supplied the plain text is still legible, if not beautiful. U+00A0 makes a lot of sense as the base character. Also having variants of U+25A1 and U+25A8 that match the game square filter modifiers seems quite legitimate. Possible lack of OpenType support is supposed not to be an admissible justification. > Your suggestion is not going to alter the burden on the font with > regard to display. My suggestion actually increases it. I suggested it because it seems to be the proper thing to do. Variation sequences seem to be the easier solution - provided they are supported in the first place. <snip> > to > > 2654 FE00; Unqualified chesspiece; # WHITE CHESS KING > 2654 FE01; Chesspiece on white; # WHITE CHESS KING > 2654 FE02; Chesspiece on black; # WHITE CHESS KING > > (that is: > > sub uni2654 uniFE00 by uni2654 ; > sub uni2654 uniFE01 by uni2654FE02 ; > sub uni2654 uniFE02 by uni2654FE01 ;) > > But I didn’t see any need for that, since 2654 is already the > unqualified chesspiece. If there’s a formal need for triplets rather > than couplets here, I’ll conform to it, but that seems to be > incidental to the robustness of the proposal. It's an incidental detail, but if needed someone will have to attend to it. U+2654 is simply the chesspiece; a font that only had variants for white and 'black' backgrounds could nominate either as the glyph for U+2654 on its own. > > 2) <U+82A6, U+E0100> is not catered for. If one needs to be sure > > of having its distinctive form, another font must be used. > > > > If I have understood the intended use correctly, then we need > > another variation sequence to explicitly specify a glyph of U+2656 > > suitable for use in plain-looking running text, analogous to > > <U+0032, FE0E> for a text-style '2'. A renderer can then ask > > whether a font supports plain text white rooks, as opposed to > > providing one dimensioned for assembling chess boards. > > If a font doesn’t support a glyph or a sequence, then operating > systems substitute other glyphs or the .notdef glyph or whatever, no? No. First of all, the substitution mechanism is usually above the operating system layer, with varying degrees of application control. Secondly, the mechanism can only look for a substitute if it knows that the glyph is missing. If it's looking for an OpenType font for a glyph of the family <U+82A6, U+E0100>, the obvious mechanism is to consult the cmap format 14 subtable. The font gives no indication of what glyph families the font's default rendering of U+82A6 is supposed to belong to. Richard.
