2017-04-06 14:57 GMT+02:00 Michael Everson <ever...@evertype.com>: > On 6 Apr 2017, at 11:00, Christoph Päper <christoph.pae...@crissov.de> > wrote: > > > > Michael Everson <ever...@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)