On 6 Apr 2017, at 18:43, Philippe Verdy <verdy_p_at_wanadoo.fr> wrote:
>> It’s an argument for legibility.
>
> And an argument for rendering purpose only;
Why? Shouldn’t human beings be able to read things that are rendered?
> the actual 2D layout of chess diagrams is not part of Unicode
The chesspiece characters are. And the chess community are not using those characters, but rather ASCII hacks, because there is no robust higher level protocol that can help them do what they need to do.
> and does not have to be encoded.
Why shouldn’t the chess community be able to use the Universal Character Set for their data? And what do you care? If you don’t care about chess or chess data, then you don’t have to use the chesspiece characters or the variation sequences which permit the additional functionality that is needed.
> Unicode is not a glyph encoding standard.
The Universal Character Set contains Variation Selectors designed to permit encoded characters to have specific glyph variants for certain purposes. This proposal makes use of them.
> I still think this is a hack,
The hack is the set of incompatible ASCII hacks used currently by the chess community. This proposal allows them to do the same work in an interchangeable way with UCS characters.
> similar to ASCII art
To the degree that lead-type chessboard typography is the equivalent of “ASCII art”, that is a fair enough description. It’s “UCS art”. And there is nothing wrong with that.
> 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.)
So, you’re saying, you don’t know what you’re talking about.
> 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.
Monowidth fonts are not required for legible fallback. And according to this scheme, proportional fonts also give legible fallback. It may not quite as legible, if the chesspiece glyphs are proportional, but it isn’t all that bad. I have provided a number of sample images already. There are also some in the proposal.
> 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).
So what? Shogi and gō are different things and the graphic notation for them is different from the graphic notation for chess. This proposal is for chess.
> If we want to add something to represent board cells/tiles in addition to pieces, that encoding should be coherent
This proposal for standardized variation sequences is coherent. It might help if you were to read it.
> 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.
I didn’t choose those characters randomly. I chose them with foresight and care. They are graphic symbols representing, in one case, a white square, and in the other, a square with a particular diagonal fill. Amazingly, these are graphic characters which can be used for … the representation of graphic characters. And with Variation Selectors, chessboard-suitable glyphs can be evoked, and the characters can be used for the purposes outlined in the proposal.
That’s what Variation Selectors are for.
> As well this will not work with other layouts (including shogi that has variants where cells are triangular:
There, there, Mr Verdy. It’s all right. It’s not supposed to work with shogi. It’s a proposal for chess. If it had been a proposal for shogi, perhaps it would, you know, mention shogi.
> you cannot reliably represent them using rows filled with △▽△▽. These characters have implicit internal leading and trailing bearings
Characters do not have leading and trailing bearings. Glyphs do.
> 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).
This proposal doesn’t have anything to do with shogi triangles. This proposal is about chess notation. This proposal solves a problem, that people setting
Please read the proposal.
> 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
Um, Mr Verdy? READ THE BLOODY PROPOSAL. LOOK AT THE PICTURES IN THE PROPOSAL. TRY TO UNDERSTAND THE PROPOSAL.
Thanks.
(I’ll help you out a little. You see, the proposal does modify ▨︁ and □︀ with Variant Selectors in order to ensure that rows in rectangular grid patterns made with ▨︁ and □︀ look correct. The examples in the proposal were made with fonds using the base characters and VS sequences proposed.)
> (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 ▽ have nothing to do with this proposal, because those shapes are not used in Chess. Actually, I don’t think they have anything to do with shogi, either. None of the boards on the Wikipedia pages about shogi (in English, French, or Japanese) have any triangle-shaped board cells on them.
What’s the French for “red herring”?
> And the poroblem with such grid patterns is more generic than just chess diagrams.
All symbol systems have potential similarities to one another.
> 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).
I don’t need to do that. I need a simple way to use the UCS to do what people have been doing with chess data for
> 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
I don’t even know if all of that’s feasible in fonts.
> 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),
You can write proposals for anything you want to.
> * 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).
"The more you overtick the plumbing, the easier it is to stop up the drain.” — Cmdr Montgomery Scott.
> * 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)
Scrabble. My word.
No. The present proposal meets a particular need: To enable the UCS to be able to set chess diagrams.
Michael Everson
Received on Fri Apr 07 2017 - 17:42:46 CDT
This archive was generated by hypermail 2.2.0 : Fri Apr 07 2017 - 17:42:46 CDT