Purpose of and rationale behind Go Markers U+2686 to U+2689

[Garth Wallace]

On Fri, Mar 18, 2016 at 1:08 AM, Philippe Verdy <verdy_p at wanadoo.fr> wrote:
> That's a smart idea... Note that you could encode the middle digits so that
> their enclosure at top and bottom are by default only horizontal (no arcs of
> circle) when shown in isolation, and the left and right parts are just
> connecting by default horizontally to the top and bottom position of the
> middle digits. Allowing arbitrary number of characters. In order to create a
> real circle, you could use a joiner control to given a hint the renderer
> that he can create a ligature (possibly reducing the size of digits, or
> changing the dimension and shape of the connected segments so that they'll
> draw a circle instead of a "cartouche" rounded at start and end.

Since left-right pairs and left-middle-right triples are intended to
be used together, ZWJs would be redundant.

I'm not sure about extending it to an arbitrary number of enclosed
digits. It seems like that would require special support from
rendering. Supporting only a well-defined set of combinations would
work with just OpenType ligature lookup tables (and wouldn't even
necessarily require ligatures in all cases).

> You could even set the enclosing as a combining character around existing
> digits (even if those digits are not symbols by themselves, the combining
> character has this property, an idea similar to the arrow combining
> characters at top or bottom for mathematics notations), so that the content
> of the "circle" or "cartouche".
>
> The enclosure could also be something else than a circle (or arcs of
> circle): it could be a rectangle, hintable with joiners (like with circles)
> to create an enclosing square, or a rounded rectangle (hintable to create a
> rounded square).

I thought combining characters would not be suitable for things like
white text on black.

> The enclosure shapes could be white or black, or could be drawn with double
> strokes. This is in fact similar to the combining low line or top line which
> are joining by default.
>
> However using a joiner between them instructs not really to join the
> top/bottom line (which is already the expected behavior for these low/top
> lines) but to create a ligature between the base characters in the middle.
> Then to create double enclosure, just "stack" several combining characters
> (in the order from inside to outside: the combining characters for
> enclosures should have the same high value for their combining class so that
> their relative order is kept, or could have combining class 0).

Double enclosure? I'm not sure what the purpose of that would be. This
is getting into styling territory, I think.

> The issues with line breaking (if you can use these combining around all
> characters, inclusing spaces, can be solved using unbreakable characters.

Line breaking isn't really a problem that I can see with the Quivira
model. If they're given the usual line breaking properties for
symbols, the Unicode line breaking algorithm would prevent a break
between halves. East Asian vertical text is another story. In a font
that just uses kerning to join halves (as Quivira does) you'd end up
with the left half on top of the right in vertical text. I'm not sure
how ligatures are handled in vertical text.