On 5 Apr 2017, at 04:50, Richard Wordingham <richard.wording...@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
