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

Fri Mar 18 03:08:50 CDT 2016

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.

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).

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).

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

Note that this addition would create a disunification with existing
enclosed characters which are already ligatured into a single symbol (they
won't be canonically equivalent, using only the decomposition properties),
but this can be solved by adding another property ("ligature
decomposition"), and mapping the existing enclosed characters to their
"ligature decomposition" using normal base characters, the new combining
characters for enclosure and the joining control between them. those
mappings can be in a new properties file (which could then be useful for
collation so that the "enclosed 79" symbol would collate like "79").

Advantage: with these, you can now enclose various numbers (not just
natural integers) or abbreviations (e.g. chemical Symbols like "Au" for
gold), or astrological symbols, or arbitrary words (using them to enclose
full sentences would not be very practicle, but their use to enclose a
person name such as the name of a Egyptian king "Ramses" is possible, even
outside the context of Egyptian hieroglyphs)... It could be used to enclose
a temperature such as "10°C", or a section heading number "1.1".

And this is much less limited than the (very quirky) use of CSS or styles
(in rich text or HTML) to add surrounding "borders" as the shapes are less
restricted (in CSS you can create rounded borders). Some new shapes are
possible such as diagonal left and right sides, or mixing a rounded left
side and a square right side (though in this case it would be hard to use
joiners and expect a ligature to be created for the enclosing shape (for
example expect a triangular enclosure created by the ligature of two
diagonal sides and horizontal top/bottom for characters in the middle,
because this would absolutely require resizing all characters in the middle
to preserve a consistent line height; but this is possible for pairs of
base characters inside the enclosure).

Note : the enclosing ligature "joiner" control is not the same as the one
for joining base characters, as the intent is to join the enclosing shape
fragments (possibly by reducing the size and repositioning the all
characters in the middle), as characters in the middle are not
ligatured themselves (if you enclose "AE" in such shapes created with
combining characters, it should not produce a "AE" letter in the final
enclosing shape.

2016-03-18 5:18 GMT+01:00 Garth Wallace <gwalla at gmail.com>:

> There's another strategy for dealing with enclosed numbers, which is
> taken by the font Quivira in its PUA: encoding separate
> left-half-circle-enclosed and right-half-circle-enclosed digits. This
> would require 20 characters to cover the double digit range 00–99.
> Enclosed three digit numbers would require an additional 30 for left,
> center, and right thirds, though it may be possible to reuse the left
> and right half circle enclosed digits and assume that fonts will
> provide left half-center third-right half ligatures (Quivira provides
> "middle parts" though the result is a stadium instead of a true
> circle). It should be possible to do the same for enclosed ideographic
> numbers, I think.
>
> The problems I can see with this are confusability with the already
> encoded atomic enclosed numbers, and breaking in vertical text.
>
> On Wed, Mar 16, 2016 at 5:45 PM, Andrew West <andrewcwest at gmail.com>
> wrote:
> > Hi Frédéric,
> >
> > The historic use of ideographic numbers for marking Go moves are
> > discussed in the latest draft of my document:
> >
> > http://www.babelstone.co.uk/Unicode/GoNotation.pdf
> >
> > Andrew
> >
> >
> > On 16 March 2016 at 13:35, Frédéric Grosshans
> > <frederic.grosshans at gmail.com> wrote:
> >> Le 15/03/2016 22:21, Andrew West a écrit :
> >>>
> >>>
> >>> Possibly.  I certainly have very little expectation that a proposal to
> >>> complete both sets to 999 (or even 399) would have any chance of
> >>> success.
> >>
> >> And then, there are also the historical example of ideographic numbers
> used
> >> for the same purpose in historic texts (like here
> >> http://sns.91ddcc.com/t/54057, here
> http://pmgs.kongfz.com/item_pic_464349/
> >> or here
> >>
> http://www.weibo.com/p/1001593905063666976890?from=page_100106_profile&wvr=6&mod=wenzhangmod
> >> ).
> >>
> >> The above has been found with a quick google search, and I have no idea
> >> whether these symbols were used in the running text or not.
> >>
> >>   Frédéric
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20160318/ab053e60/attachment.html>