Re: Proposal to add standardized variation sequences for chess notation

2017-04-06 14:57 GMT+02:00 Michael Everson <everson_at_evertype.com>:

> On 6 Apr 2017, at 11:00, Christoph Päper <christoph.paeper_at_crissov.de>
> wrote:
> >
> > Michael Everson <everson_at_evertype.com>:
> >>
> >> Standardized variation sequences are the best way to achieve this
> simply and without needless duplication. :-)
> >
> > I still agree with this assertion.
>
> So do I.. ;-)
>
> >> Yes but you still want it to be reasonably legible when the OpenType
> ligatures fail.
> >
> > This is were I don't follow.
>
> Why wouldn’t you want it to be reasonably legible when the OpenType
> ligatures can’t be displayed?
>
> ▗▁▁▁▁▁▁▁▁▖
> ▕□︀▨︁□︀▨︁□︀▨︁♞︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁♔︀▨︁□︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏
> ▕□︀▨︁□︀▨︁♚︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁□︀♙︁♛︀▨︁□︀▨︁▏
> ▕▨︁□︀♕︁□︀▨︁♖︀▨︁□︀▏
> ▝▔▔▔▔▔▔▔▔▘
> is far better than this:
> ▗▁▁▁▁▁▁▁▁▖
> ▕□︀□︀□︀□︀□︀□︀♞︀□︀▏
> ▕□︀□︀□︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀♔︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀□︀□︀□︀♘︀□︀□︀▏
> ▕□︀□︀□︀□︀♚︀□︀□︀□︀▏
> ▕□︀□︀□︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀□︀♙︁♛︀□︀□︀□︀▏<< Is it the pawn or the queen that’s on the black
> square?
> ▕□︀□︀♕︁□︀□︀♖︀□︀□︀▏
> ▝▔▔▔▔▔▔▔▔▘
>
> > It *looks* far better in a multi-line plain text environment, but that's
> a glyphic/typographic/stylistic argument.
>
> It’s an argument for legibility.
>

And an argument for rendering purpose only; the actual 2D layout of chess
diagrams is not part of Unicode and does not have to be encoded. Unicode
is not a glyph encoding standard. I still think this is a hack, similar to
ASCII art and legacy emojis made of ASCII punctuations like :-) or more
complex pseudo-emojis using multiple rows (that do not render correctly
when they depend on specific font designs and metrics.)

I am still convinced that it does not matter if a legacy rendering will not
show white vs. black cells because characte"rs are not rendered in a
monospaced font. The argument exposed for checkered boards here would not
apply for many other boards that typically don't have checkered layouts
(including for example for playing shogi or go).

If we want to add something to represent board cells/tiles in addition to
pieces, that encoding should be coherent and not choosing randomly some
characters that were not even designed to align with similar metrics (such
as ▨︁ and □︀ here!) and not really intended to represent (optionally
colored) cells in a grid.

As well this will not work with other layouts (including shogi that has
variants where cells are triangular: you cannot reliably represent them
using rows filled with △▽△▽. These characters have implicit internal
leading and trailing bearings both horizontally and vertically and cannot
have metrics correctly set without breaking other notations that would
depend on these bearings, for example in mathematic formulas where they are
separated symbols). So you cannot expect rows in rectangular grid patterns
made with ▨︁ and □︀ to look correct... unless they are each one modified
with a variant selector saying they should use the full character cell (and
there will still be problems with △▽ because they will actually need to
cover more than their rectangular cells with twho corners extending outside
of it with additional kerning, not suitable for mathematics).

And the poroblem with such grid patterns is more generic than just chess
diagrams. We should be able to represent directly at least several well
known patterns of cells/tiles (optionally colored when this matters), and
then be able to combine them with any chacter/cluster inside them (for
example for classic crosswords, Scrabble, triominos and similar games). We
need a way to represent grids made with square/rectangular cells, or
triangular/hexagonal cells (for triangular and hexagonal cells we need
additional half-cells to properly align rows at least at start or rows, and
hexagonal cells will partly extend over the previous and next row

So I would prefer a proposal to:
* add specific symbol characters for these common patterns of cells
(rectangular/square, triangular, hexagonal), plus half-cells for use at
start and end of rows (if rows are not aligned vertically but in create
triangular layouts),
* optionally followed by some variant selectors for mapping some semantic
colors on them (semantic color means "light" and "dark" may be "white" and
"black, or "ivory" and "wood", or "yellow" and "red", or
"empty/transparent" vs. "hatched" with monochromatic rendering where colors
are replaced by fill patterns such as ///, or dots with some density; we
should have about 8 semantic colors, representable with actual colors or
grey or fill patterns). The common "black square" and "white square" (the
white version would be the default semantic color and would not need any
additional variant).
* and then use ZWJ to combine them with letters/symbols to be centered
within them (possibly some extended clusters such as
letters+combining subscript digits in Scrabble)

The base set of the first set for cells should be based on old wellknown
"block graphic" characters used in various legacy computers or
teletext/videotex (where characters were all monospaced, so they would line
up properly). But Unicode still lacks many usefull characters for this
purpose (the only exception was for those from IBM PC in "line-drawing"
from codepage 437, but the set has been left largely incomplete and these
characters are still not suitable for all we need (the lines are all
passing through the center of cells, there's no support for
horizontal/vertical lines bordering cells, and nothing for diagonals)

The only new thing that did not exist in legacy charset was the possibility
of combining cells and symbols within them (but these legacy displays could
use background colors for representing cells)

A set of suitable symbols for use with grids in various games is still
highly wanted, independantly of pieces/symbols that will be rendered in
them. For now only gobans are partly supported (using code 437 line drawing
characters for empty cells, and the encoded white and black stones when
they occupy a cell position, but there's no way to indicate they should
arrange in grids with suitable metrics)
Received on Thu Apr 06 2017 - 12:44:28 CDT