On Sun, 2 Apr 2017 11:57:49 +0200
Michael Everson <everson_at_evertype.com> wrote:
> On 2 Apr 2017, at 10:53, Richard Wordingham
> <richard.wordingham_at_ntlworld.com> 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.
Received on Sun Apr 02 2017 - 11:28:17 CDT
This archive was generated by hypermail 2.2.0 : Sun Apr 02 2017 - 11:28:18 CDT