Proposal to add standardized variation sequences for chess notation

[Michael Everson]

On 5 Apr 2017, at 04:50, Richard Wordingham <richard.wordingham at ntlworld.com> wrote:

>> Why would anyone make a font that supports the variants for drawing chessboards (which require the encoded characters 2654..265F) not put in glyphs for those? 
> 
> A stop-gap font based on poor glyphs comes to mind.

For pity’s sake. Yes, people can make and distribute crappy fonts. What are you on about? This is not serious criticism and what you suggest is no realistic scenario. 

> Is this a sequence for the GSUB table or for the cmap table?  

It’s the OpenType table. I said this already, twice. The entries are:

	sub uni2654 uniFE00 by uni2654FE00 ;
	sub uni2654 uniFE01 by uni2654FE01 ;
	sub uni2655 uniFE00 by uni2655FE00 ;
	sub uni2655 uniFE01 by uni2655FE01 ;

and so on.

> The font I have in mind would have no entry for U+2654 in its cmap format 4 subtable but would, following the proposal you put up on Saturday, have entries for <U+2654, U+FE00> and <U+2654, U+FE01> in its cmap format 14 subtable.

OK, to hell with the cmap format 14 table. I don’t know what this is. I didn’t edit any such a table. I have text in my proposal about that because I took it from a proposal for Variation Sequences by Ken Lunde. I thought that was the same as the mechanism which I used to create the tables in my font, which worked, and worked well. I have implemented it. I would use my fonts (with variation selectors) in print and I would distribute the fonts. 

PLEASE LOOK. You have said that you would add <U+2654, U+FE00> and <U+2654, U+FE01> and that’s JUST what I have in my opentype table. So you and I are doing the same thing. 

> This approach is entirely consistent with the conception of variation sequences as pseudo-encoding.

No, it’s a way of showing a particular glyph for an underlying base character. 

> I could make such a font (for one chesspiece), but it would take at least an evening.

I’ve done it for three fonts already, Ludus, Condal, and William’s Quest font. 

> Now, I have sought advice on the OpenType list, and have received the opinion of one person, to wit that if I have a glyph mapping for
> <U+2654, U+FE00>, I am obliged to have a genuine mapping for U+2654, i.e. not a map to .notdef.

Didn’t I say this just yesterday? U+2654 displays the character glyph on its own. With U+FE00 the font displays that glyph on an em-square sized background suitable for use as “chesspiece on light square” and with U+FE01 the font displays that glyph on an em-square sized background suitable for use as “chesspiece on dark square”. A font which says that it is suitable to set chessboards has to have all three glyphs in it. In some fonts the first two MIGHT be the same but they do not HAVE to be because the “piece on a light square” may be designed to be inappropriately wide, or have the chesspiece glyph at a different height vis à vis the baseline, for the one glyph to suit both. 

Is this unclear? I have tried to explain it clearly. 

Does this differ from whatever it is you’re talking about? Because it sounds like it’s just exactly what you’re talking about. 

> On the basis of this advice, the font writer therefore has three choices - expose his poor, possibly proportionally spaced glyphs for use as default U+2654 (probably the best choice), make the glyph for <U+2654 U+FE00> the default glyph (not a disastrous choice), or make the glyph for <U+2654, U+FE01> the default glyph (a malevolent choice in my view).

Look, Richard, I didn’t invent variation selectors. Variation Selectors are used for lots of maths characters, a whole bunch of Myanmar characters, and 310 emojis. FOR NONE OF THOSE OTHER PROPOSALS has anybody wrung their hands saying that “oh gosh, there might be ugly glyphs in the font, so we shouldn’t use Variation Selectors 

Plain chess pieces for use within text may often be proportionally-spaced, and there is nothing wrong or poor or undesirable about that. Anyone wanting to support such glyphs has been able to do so since Unicode 1.1. All right? THat’s the status quo for chess characters in the standard.

It’s not possible to use proportionally-spaced fonts to set chessboards, because those have to have mono-width squares.

We could treble the number of chess fonts in the standard from 12 to 36 (and from 84 to 252 for the current set of fairy chess characters in another proposal) but this isn’t a good idea. We don’t need 288 chess characters encoded. We need 96. *I* say this, and I’m a notorious splitter. First, in discussions with UTC representatives in previous years, I understand that this is not desirable. Second, it’s not necessary, because variation selectors work well (I have implemented it as proof) and because board squares are, essentially, a special rendering shape (glyph) for the chess pieces. 

> If one has no control over the fallback sequence for glyphs, arguably the situation for truly 'plain text', then the escape root for plain
> text is to have the font with good chess glyphs for use in running text declare that it has the glyph for such use.

Richard, I’ve shown some examples of the Looking-Glass problem where the VS sequences are ignored. Did you see these? Why don’t you refer to them. You’re talking in the abstract as though you haven’t read the proposal or looked at the examples it gives. In Figure 3, you can see the base glyphs in the font which might be used for any purpose. For the special purpose of setting a chessboard, you need to use the VS sequences. If your font or your app can’t display that, that’s a problem, but that is no different for ANY app or font that can’t display fi/fl ligatures, or maths characters with VS, or Myanmar characters with VS, or emoji characters either in colour or black-and-white with or without ligatures. Why is this such a dreadful problem for chess when it’s not for any of the other character types which use VS sequences?

You haven’t explained this inchoate worry of yours. My proposal admits freely that VS-derived glyphs for chessboards might fail in some environments (but also shows that a board set using this scheme is still legible by humans and parseable by software even if the good display may fail. 

But the point is that chess fonts are specialized fonts, and if people want to set chess problems they need special chess fonts. Such fonts exist right now, but only with conflicting ASCII encodings. THAT is worse that maybe some fonts having ugly glyphs or maybe some environments can’t display OpenType sequences properly. THAT is the problem that is solved by this proposal. 

> That requires the definition of a variation sequence to force the choice of suitable glyph.

These sequences are what the proposal gives. Why are you saying this?

> Now, having to use variation sequences for chess pieces in plain text is unfortunate,

No, it isn’t. It’s a better idea to use those for 96 chess characters than to have to get the committees to accept 288 chess characters (which I very much doubt they will) which by the way also puts off a solution for chess for another two years. 

> but should also work with existing fonts supporting chess pieces.

It can, if and only if the makers of those fonts add the new glyphs and new VS sequences to their fonts. This is also true for maths fonts, for Myanmar fonts, and for emoji fonts. 

> There would be transitional effects as existing fonts were modified to declare that they supported this variation sequence - the effects of font fallback would vary as the new fonts were added to the system.

Yes, that is what will happen if this proposal is selected. No fonts are magically altered. 

Are you supporting my proposal or objecting to it? I can’t even tell any more. 

>> But nobody making a chess font with actual support for chess would dothat. 
> 
> Note that the font I have in mind is just supporting chessboards. The idea would be that other fonts would be used for high quality rendering.

WHAT? What does this mean? Who would make a font supporting just chessboards and not supporting display of chess characters otherwise? Anyway you can’t. You can't even MAKE a substitution table if the base characters aren’t in the font. FontLab complains and then politely asks if you want to add the glyphs to the font, and when you say Yes (which you must if you want your OT sequences to work) then it puts those characters in the font so you can put glyphs into them. Is this explained clearly enough for you? If you’re worrying about whether the font designer will bother to make NICE glyphs for those characters, well, that is up to the wit of the font designer. And that has nothing to do with the proposal. 



> 
>> Nothing prevents someone from drawing the 16 Myanmar base characters
>> with rings at the ends of their glyphs even though now VS are being
>> recommended for that presentation. Is it legitimate to do that? Of
>> course it is.
> 
> You seem to be declaring that it would not be wrong for chess piece characters in running text to be automatically depicted with dark chess square backgrounds.

If a font designer is perverse enough to do that, his font won’t be nice and nobody will use it. It is possible for someone to depict chess piece characters in running text with dark chess square backgrounds, but since that’s not the convention for doing so, nobody would like the font and nobody would use it. 

>> Can you identify an actual problem? 
> 
> See above.

You failed to identify an actual problem with the proposal. 

The actual problem is (1) chess fonts aren’t using unicode characters (2) VS selectors can help provide a standardized way that enables chess fonts to do so and (3) the proposal gives a mechanism for doing that which will work in environments where VS substitution glyphs are supported. 

Michael Everson