Proposal to add standardized variation sequences for chess notation

[Philippe Verdy]

2017-04-04 1:30 GMT+02:00 Michael Everson <everson at evertype.com>:

> On 3 Apr 2017, at 23:07, Asmus Freytag (c) <asmusf at ix.netcom.com> wrote:
> >
> > On 4/3/2017 2:15 PM, Michael Everson wrote:
> >> On 3 Apr 2017, at 17:16, Asmus Freytag <asmusf at ix.netcom.com> wrote:
> >>
> >>>>> The same indirection is at play here.
> >>>>>
> >>>> This is pure rhetoric, Asmus. It addresses the problem in no way.
> >>>>
> >>> Actually it does. I'm amazed that you don't see the connection.
> >>>
> >> I’ve never understood you when you back up into that particular kind of
> abstract rhetoric.
> >
> > Sometimes thinking through something in abstract terms actually
> clarifies the situation.
>
> Of course I know that’s your view. It’s just never been an effective
> communication strategy between you and me generally.
>
> >>> The “meaning” of a chess-problem matrix is the whole 8 × 8 board, not
> the empty dark square at b4 or the white pawn on
> >
> > In other words, you assert that partial boards never need to be
> displayed. (Let's take that as read, then).
>
> No, I am sure that a variety of board shapes can be set in plain text with
> these conventions, though the principle concern is classical chess notation.
>
> >> The “problem” the higher-level protocol is supposed to solve is the one
> where a chess piece of one colour sits in an em-squared zone whether light
> or dark. In lead type this was a glyph issue. Lead type had just exactly
> what my proposal has: A piece with in-line text metrics, spaced
> harmoniously with digits and letters, and square sorts with and without
> hatching.
> >
> > Leaving aside the abstract question whether modeling lead type is ipso
> facto the best solution in all cases…
>
> I think it was a good expedient solution in lead type and that this
> proposal offers a robust parseable digital version of that solution, and I
> assert people will make use of that data structure.
>
> >> OK, then you support the part of the proposal that applies VS1 and VS2
> to the chess pieces.
> >
> > My statement just was that a proposal where piece + VS should be
> M-square, piece w/o VS should be generic, might make some sense (and same
> for a suitable "empty" cell).
> >
> > The next question would be whether the alternation in background is best
> expressed in variation sequences or by some other means.
>
> I think the value in the data structures I have described is best retained
> as text. Anything else just seems it would be simply needlessly complex,
>
> > If you never need to show just a single field, then I concede that the
> main drawback of variation selectors for the background style is absent;
> however, reading ahead in your message, the partial grid appears to be
> common, therefore the reason to choose an alternate solution to the
> background style is a strong one.
>
> Well, it’s text, Asmus, so you can delete all but one line of a board if
> you want:
>
> ▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏
>
> There. So… what are you talking about? It’s a text matrix. It’s like a
> kind of poem.
>
> ▗▁▁▁▁▁▁▁▁▖
> ▕□︀▨︁□︀▨︁□︀▨︁♞︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁♔︀▨︁□︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏
> ▕□︀▨︁□︀▨︁♚︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁□︀♙︁♛︀▨︁□︀▨︁▏
> ▕▨︁□︀♕︁□︀▨︁♖︀▨︁□︀▏
> ▝▔▔▔▔▔▔▔▔▘
>
> It even looks like one. That’s a meaningful pattern. A kind of writing
> system.
>

For me it looks like ASCII art, a hack mixing various characters intended
for different uses and ignoring all semantics, only working because it
reuses similar-looking glyphs instead of being an actual encoding.
That represetnation is absultely not semantically coherent.

If we want to have true checkboard cells, we need characters specifically
for them, and in them we'll place (or not) chess pieces or any other
suitable symbol or letter. This means creating clusters (cell+ZWJ+piece).
This will be coherent.

If we want to have borders for boards, we need coherent characters for them
(we do not expct them to be combined with pieces, just that they will
properly glue with cells in the middle of the board, and that their metric
match them in suitable fonts).

The fact that legacy renderers or fonts won't display that correctly is
definitely not an argument. Many scripts still have problems being
represented with legacy renderers or fonts. But the encoding is made to be
coherent semantically. Fonts and rederers will adapt their properties to
render what is semantically wanted and that will be also pleasing to read,
and they still will be able to use various variants (e.g. emoji styles for
pieces, possibly with 3D effects and colors, possibly animated pieces, or
alternate decorative patterns in board cells, possibly photographic-based,
such as wood, marble, grass, sand, glass, iron...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20170404/2fd92541/attachment.html>