On 10 Apr 2017, at 09:49, Christoph Päper <christoph.paeper_at_crissov.de> wrote:
> If Unicode chess diagrams used VS-16 instead of VS-1 and VS-2, users could one day choose a font that fakes marble, wood, glass, steel or just some random color or even animation for pieces and board squares. Since this kind of customization is a common feature in chess applications, I'd expect it to be a welcome feature for textual diagrams as well, even if it's not used (much) in print books. Within the web ecosystem that relies upon CSS for styling, authors and readers could very well and easily use different designs. With non-emoji chess characters, the differences would mostly be limited to glyph outlines.
Well, no.
> Is that "no reason”?
Yes. If the UTC wants to make chess characters into emoji then they can do that. Garth and I are not asking for it. We're asking for interchangeability and stability in representing chess diagram data. This is not the same thing as what you are talking about, and so it is not relevant to the proposal.
>> And risking that some consistent monochrome glyphs would be replaced with colorful pictures by overly aggressive systems is also something that should be avoided with the chess symbols.
>
> VS-15 should be better at that than any other variation selector.
That just tells the glyph to be the text glyph from the code charts. That ignores completely the piece-on-square glyphs the proposal requires. You’re talking about something irrelevant to the proposal. Christoph. It’s not helpful.
As Garth says:
>> Look, this proposal is not about "Wouldn't it be a neat idea if we could make chess diagrams in text?" People had that neat idea before they had the neat idea for Unicode, or for computers for that matter. This is about removing a barrier to people using Unicode instead of various mutually-incompatible dingbat fonts for something they already regularly do.
>
> I understand that perfectly well. Currently, Unicode chess pieces are only well-suited for figurine notation, not for 2D diagrams. I even agree with the approach to use variation selectors.
Thank you.
> I just think that there would be significant positive synergy from reusing the infrastructure already established for emojis.
I think this is a huge distraction from the simple and robust proposal made. Emoji is a different kind of thing.
>> One nice thing about the existing VS proposal is that it does not require any heuristics at all. Each square is explicitly marked as light or dark, with no guessing needed.
>
> The UI/UX drawback is that authors have to explicitly mark every field — unless you put the heuristics there.
Yes. Authors should have to explicitly mark every field. That gives a consistent number of encoded characters for each square, which helps to facilitate fallback reading when the ligation is not available.
OK, nothing new has been offered on this topic for a long time. Thank you for your support of the VS proposal, Christoph. Your supplementary proposals didn’t make it better to achieve the goal: to remove the barrier to people using Unicode instead of various mutually-incompatible dingbat fonts for something they already regularly do.
Michael Everson
Received on Mon Apr 10 2017 - 05:31:25 CDT
This archive was generated by hypermail 2.2.0 : Mon Apr 10 2017 - 05:31:25 CDT