On 7 Apr 2017, at 23:17, Christoph Päper <christoph.paeper_at_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
Received on Fri Apr 07 2017 - 17:41:57 CDT
This archive was generated by hypermail 2.2.0 : Fri Apr 07 2017 - 17:41:57 CDT