Re: Proposal to add standardized variation sequences for chess notation

On Fri, Apr 7, 2017 at 3:17 PM, Christoph Päper <christoph.paeper_at_crissov.de
> wrote:

> Garth Wallace <gwalla_at_gmail.com>:
> > On Thu, Apr 6, 2017 at 5:19 AM, Christoph Päper <
> christoph.paeper_at_crissov.de>
> > wrote:
> >
> > > Although Michael Everson readily dismisses any connection to emojis,
> (...)
> > > normal emoji design actually matches "diagram" notation quite nicely
> in
> > > that all
> > > emoji glyphs are rendered within an (ideographic / em) square. Black
> and
> > > white
> > > squares are also already available as emojis (...)
> >
> > The only connection this has with emoji is that it uses the variation
> selector
> > system.
>
> As I've shown, that's not the *only* connection.
>
> > Emoji is a means of indicating full-color embedded images,
>
> That may be how they are often conceived. It's not quite true, though. The
> first
> sentence of UTS#51 reads:
>
> Emoji are pictographs (pictorial symbols) that are typically presented
> in a
> colorful cartoon form and used inline in text.
>
> That sounds similar, but is different in an important detail: the scope,
> active
> vs. passive. Emojis do not reference images, but systems present them as
> images.
>

My point is that the features that distinguish emoji from other symbols in
Unicode are not required, and in many cases not desired, for typesetting
chess diagrams. It complicates things for no reason.

> > ... and usually rely on rendering or interpreting systems that
> substitute
> > graphics,
>
> Such systems are widespread, but emojis don't rely on them since they are
> true
> characters.
> Symbol fonts like Font Awesome, for instance, are usually PUA-only,
> although
> they should be using codepoints of existing emojis and other symbols as
> much as
> possible for fallback and interoperability reasons. They don't because
> they'd
> risk that some of their consistent, monochrome glyphs would be replaced
> with a
> colorful picture by an overly aggressive system.
>

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.

> > or various non-standardized font extentions.
>
> Opentype 1.8 standardizes as many as four approaches to colorful glyphs.
>

Four currently non-interoperable approaches, AIUI. But this isn't really
relevant here anyway.

> > None of that is necessary, or relevant, to chess diagrams.
>
> Chess diagrams (unlike chess notation) are often rendered as graphics, not
> text.
> Board and glyphs may have fancy designs and colors, e.g. wooden fields. You
> would get that for free with emoji presentation, but fonts would not have
> to use
> more than two colors. Note that "white" chess pieces should usually not be
> rendered as outlines only, i.e. with transparent eyes, but with a solid
> whitish
> interior. Almost all other pre-emoji characters with "White" in their
> standard
> name are hollow. "Black" means always 'solid', but the actual color can be
> any
> (including white), although text is still mostly typeset in a blackish
> color.
>

Chess diagrams *are* often rendered as graphics. When people want things
like wood grain squares, they use graphics.

Chess diagrams are *also* frequently typeset with fonts, using the same
means as text. When doing so, the results are monochrome, with diagonal
hatching for the dark squares. This is well established practice. Full
color display of conventionally typeset diagrams would not be expected
behavior, nor, in many cases such as publishing, would it be welcome
behavior. It's the wrong tool for the job.

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 don't believe emoji are even necessarily fixed-width.
>
> In all existing implementations they are. They are even always square. I'm
> not
> sure whether their em square always matches the sinographic ("ideographic")
> square, but it seems as if it usually does.
>

Doesn't matter. My point was that fixed width is not an inherent quality of
emoji, it's just common. You can't rely on it, and it is not a commonality
*in principle* with chess diagram typesetting, just a coincidence.

> > > Without the need for ZWJ sequences, Opentype fonts can employ their
> > > Contextual
> > > Alternates `calt` feature to select the correct background color in
> diagram
> > > notation: In a sequence of up to eight chess pieces without an empty
> square
> > > with
> > > explicit color, an initial U+2656-FE0F White Rook, U+2654-FE0F White
> King,
> > > U+265B-FE0F Black Queen or U+265F-FE0F Black Pawn would default to a
> black
> > > background, U+2659-FE0F White Pawn, U+2655 White Queen, U+265A-FE0F
> Black
> > > King
> > > or U+265C-FE0F Black Rook to a white background. Other than that, each
> > > character
> > > uses the alternate glyph with opposing background color from its
> preceding
> > > (left-side) glyph. The empty squares work as explicit anchors.
> >
> > I don't see how this would work. Any row with a white rook on the first
> file
> > would start with a black background? What?
>
> Usually empty squares would determine the backgrounds of adjacent pieces,
> but if
> you have a line of adjacent chess pieces (up to 8 by standard rules)
> without any
> empty square (e.g. before the first move), there would need to be some
> kind of
> heuristic. I chose the colors of pieces that do not come in pairs (i.e.
> King and
> Queen) and of the left-most figurines (Rook and Pawn) for a board with
> white at
> the bottom, because that is the most common orientation. If you want, I
> could
> write and post the code in Adobe OT feature file notation required for
> `calt` to
> demonstrate that this would yield results as expected for all full-size 8*8
> diagrams and even for many detail diagrams of a section of the board.
>

I suppose a guess with a 50/50 chance of being wrong is still considered a
heuristic, of sorts. I would like to see your proof of concept (I'm not
interested in the code, I'd like to see the results you get) since I'm very
skeptical that this would work reliably in practice.

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.
Received on Fri Apr 07 2017 - 22:54:38 CDT