On 7 Apr 2017, at 23:17, Christoph Päper <christoph.pae...@crissov.de> wrote:
>> The only connection this has with emoji is that it uses the variation
>> selector system.
>
> As I've shown, that's not the *only* connection.
Christoph, YOU ARE WRONG.
Emoji as a special relationship with vendors and a particular implementation
environment.
Vendors via the UTC look at symbol and pictograph and other characters and
decide if they want to give these symbols and pictographs and other characters
the special characteristic which implies generally colour rendering and implies
an obligation to supply input methods for those characters. That is expensive,
and while evidently there are users who need to send BROCCOLI to one another,
nobody but nobody needs to send an 8 x 8 chessboard matrix in a tweet. Get it?
Emoji has nothing to do with the proposal to support standardized variation
sequences for use with chess characters to provide support for their usage in
chessboard diagrams.
Please stop trying to conflate emoji and chess characters. It is NOT, I think,
a solution which the UTC would agree to. I would oppose it in SC2.
>> None of that is necessary, or relevant, to chess diagrams.
>
> Chess diagrams (unlike chess notation) are often rendered as graphics, not
> text.
Because there is no robust text representation of chess diagrams. This proposal
shows how very easy it is to support that behaviour, in parseable and
interchangeable text, so that unparseable graphics don’t have to be used.
> Board and glyphs may have fancy designs and colors, e.g. wooden fields.
Two centuries of standard chess diagramming practice is all that’s needed to
support. That’s text. That’s data. That’s what’s important. You want a pretty
chess program, you can go download one. That’s not the same as this.
>> I don't believe emoji are even necessarily fixed-width.
>
> In all existing implementations they are.
That’s not true.
> They are even always square. I'm not sure whether their em square always
> matches the sinographic ("ideographic”) square, but it seems as if it usually
> does.
Not always, and that’s enough chaos. There is no standardization currently in
chess fonts. One of them splits queens and rooks into two separate characters.
This proposal solves that.
> Without the need for ZWJ sequences, Opentype fonts can employ their
> Contextual Alternates `calt` feature to select the correct background color
> in diagram notation: In a sequence of up to eight chess pieces without an
> empty square with explicit color, an initial U+2656-FE0F White Rook,
> U+2654-FE0F White King, U+265B-FE0F Black Queen or U+265F-FE0F Black Pawn
> would default to a black background, U+2659-FE0F White Pawn, U+2655 White
> Queen, U+265A-FE0F Black King or U+265C-FE0F Black Rook to a white
> background. Other than that, each character uses the alternate glyph with
> opposing background color from its preceding (left-side) glyph. The empty
> squares work as explicit anchors.
Well that’s a lot of effort to go to. And there’s no legible fallback if the
“calt” features can’t be invoked. This is a bad solution. Thank you for
suggesting it.
> If you want, I could write and post the code in Adobe OT feature file
> notation required for `calt` to demonstrate that this would yield results as
> expected for all full-size 8*8 diagrams and even for many detail diagrams of
> a section of the board.
And when “calt” substitutions can’t be displayed? What kind of fallback do you
have?
Michael Everson
