Re: Proposal to add standardized variation sequences for chess notation

[Garth Wallace]

On Thu, Apr 6, 2017 at 5:19 AM, Christoph Päper  wrote:

> Mark Davis ☕️ :
> >
> > I'm looking forward to similar postings on checkers and go pieces. (...)
> > And I'm looking also forward to the ♖+ZWJ+⬛️  (etc) proposal.
>
> Well, actually ...
>
> Garth Wallace made an important observation in
> :
>
> >> Currently, chess fonts can be (roughly) divided into "diagram fonts" and
> >> "notation fonts".
>
> The major goal of Michael Everson's proposal to introduce standardized
> sequences
> with variant selectors 1 and 2 (U+FE00/1) for chess piece characters
> (primarily
> U+2654-F), as far as I understand it, is to assure "diagram" glyph design.
> This
> means fixed-width figurines centered in the character cell, with means for
> square color and board border elements (incl. labels), whereas "notation"
> style
> usually has proportional figurines sitting on the baseline.
>
>
This is all correct.


> The square color is ignored in standard chess notation, where fields are
> conventionally known by their alphabetic column index ("file", A-H for a
> standard checkerboard) and numeric row index ("rank", 1-8), i.e. A1
> through H8,
> which are virtually never styled as "⬛A1", "◻B1", "B2"
> whereas figurine charactres may either augment or substitute conventional
> letter
> symbols.
>

Usually substitute, but yes.


>
>   - Black/dark squares are those whose file and rank are either both odd
> or both
> even.
>   - White/light squares are those whose file is odd and rank is even, or
> vice
> versa.
>
> Corollary: The glyph background is almost only important within diagram
> notation.
>

Yes, this is acknowledged in the proposal.


>
> Diagrams may only show select squares, so the color of the first or last
> one and
> hence intermediate ones cannot necessarily be deduced from the immediate
> context. (They may be implied by row and column labels, which is simple
> for a
> sighted human reader, but complex for computers and blind readers.)
>

Also, I believe that existing fonts and text rendering systems cannot tell
what is above or below the current line, so there is no way to determine
what the background should be based on rows.

Although Michael Everson readily dismisses any connection to emojis, e.g.
> L2/16-021 or L2/16-087+088, and hence the Emoji and Emoji_Presentation
> character
> properties as well as sequences with variation selectors 15 and 16
> (U+FE0E/F),
> 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 in small U+25AA/B,
> medium-small
> U+25FE/D, medium U+25FC/B and large U+2B1B/C. The last ones would probably
> be
> preferred. Only the first ones are default text style characters. The
> characters
> for empty squares from the proposal, U+25A8/1, have no emoji
> representation yet.
> I've suggested to use the hatching characters U+25Ax for their colors as in
> heraldic tinctures, which relate U+25A8 to Purple ("purpure").
>

The only connection this has with emoji is that it uses the variation
selector system. Emoji is a means of indicating full-color embedded images,
and usually rely on rendering or interpreting systems that substitute
graphics, or various non-standardized font extentions. None of that is
necessary, orrelevant, to chess diagrams.

I don't believe emoji are even necessarily fixed-width. That's incidental
(and I think some implementations of the flags are wider than 1em).


> 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?

Re: PETSCII mapping?

[Philippe Verdy]

This 2x3 block graphic set was also part of Videotex/Teletext/Antiope
standards in Europe (used on PCs, dedicated terminals, and TV programs, and
still supported in more recent teletext technologies, even if many smart
TVs offer other interactive protocols based on web standards, or possibly
embedding an HTML/CSS/Javascript rendering engine, sometimes even with
Android SDK support for applications). It has even been implemented in some
TV networks in US.
Before graphic displays became widespread (when the EGA standard started
being added, then when non-monochromatic monitors appeared almost
immediately after it), almost all text terminals had such minimal support
for such "mosaic" graphics. Only the original IBM PC had a much more
limited set, using 1x2 blocks, while using box-drawing graphic subset in
their legacy codepages.
The original IBM logo was made of these 1x2 blocks

2017-04-07 3:19 GMT+02:00 Mark E. Shoulson :

> On 04/06/2017 08:07 AM, Rebecca T wrote:
>
>> Here’s a copy of the Teletext character set; it includes box-drawing
>> characters
>> for all combinations of a 2×3 grid of cells. 2⁶ = 64 characters, so we
>> might
>> need a new block.
>>
>> [1]: http://www.galax.xyz/TELETEXT/CHARSET.HTM
>>
>> My old TRS-80 also did "graphics" like this, with 64 2×3 cells. That was
> even how it did it when you were setting individual blocks.  The smallest
> "pixel" you could control in graphics was one of these ⅙ths of a character
> cell, and wouldn't you know it? As soon as you set one in a cell occupied
> by some other character, the other character would disappear.
>
> Not positive these count as plain text, but there's a decent argument for
> it.
>
> ~mark
>
>

Re: PETSCII mapping?

[Mark E. Shoulson]

On 04/06/2017 08:07 AM, Rebecca T wrote:
Here’s a copy of the Teletext character set; it includes box-drawing 
characters
for all combinations of a 2×3 grid of cells. 2⁶ = 64 characters, so we 
might

need a new block.

[1]: http://www.galax.xyz/TELETEXT/CHARSET.HTM

My old TRS-80 also did "graphics" like this, with 64 2×3 cells. That was 
even how it did it when you were setting individual blocks.  The 
smallest "pixel" you could control in graphics was one of these ⅙ths of 
a character cell, and wouldn't you know it? As soon as you set one in a 
cell occupied by some other character, the other character would disappear.


Not positive these count as plain text, but there's a decent argument 
for it.


~mark

Re: PETSCII mapping?

[Mark E. Shoulson]

On 04/05/2017 05:25 PM, Rebecca T wrote:


As time goes on, “not in widespread use” will become a flimsier and 
flimsier

argument against inclusion
Indeed.  This is the chicken-and-egg problem, and you are not the first 
to (rightly) point it out as a flimsy excuse.  Thanks for bringing it up 
again, though: people still seem to go back to it a lot.


~mark

Re: PETSCII mapping?

[Rebecca T]

Count me in!

I’m partial for one large unified proposal, FWIW.

On Thu, Apr 6, 2017 at 2:24 PM, Rebecca Bettencourt 
wrote:

> On Thu, Apr 6, 2017 at 10:43 AM, Doug Ewell  wrote:
>
>> Michael Everson wrote:
>>
>> > Everybody interested, raise your hand…
>>
>> I'm in. 
>
>
> I'm in as well of course.
>
>
>> Rebecca Bettencourt wrote:
>>
>> > The question is, do we want to add these missing graphics characters
>> > incrementally, platform by platform, or put together a larger proposal
>> > for, say, one big Block Elements Extended block?
>>
>> I would guess the latter. There's no tremendous rush; there should be
>> time to do a proper analysis of target platforms, evaluate which
>> proposed characters should be unified with existing or other proposed
>> characters, and so forth.
>>
>> Of course there's no guarantee this will be the last request ever for
>> 8-bit computer compatibility characters, but there doesn't seem much
>> point in intentionally dragging the process out, platform by platform.
>>
>
> You make a good point. I'm in either way. :)
>
>

Re: Coloured Punctuation and Annotation

[Asmus Freytag]

  
  
On 4/6/2017 11:21 AM, Richard
  Wordingham wrote:


  If "text presentations" have to be monochrome, as Asmus claims,

While it appears possible, after Khaled's
demonstration, I still think that the use of "white ink" instead
of the "white" parts of a character being treated "transparent"
is far from standard text presentation. (And I've yet to see an
example that's motivated by anything other than emoji).
  
And as far as plain text is concerned, despite
the capabilities demonstrated, the overwhelming majority of it
is still monochrome (and apparently it takes application support
to handle the color table in OpenType, making any fallback in
non-supporting applications monochrome again).
If you feel better, just replace "have to"
by "nearly universally are" and move on.
A./
  


  

Re: Coloured Punctuation and Annotation

[William_J_G Overington]

Michael Everson wrote:

> No. Here is an example of a font available in two variants. In one variant, 
> all those grey swirls are fused to the letters, and it can all be printed in 
> black or one colour ink. 

> http://cdn.myfonts.net/s/aw/original/255/0/131020.png 

> There is also a second set of fonts included which separates the swirls from 
> the letters, and those can be used in typesetting to get the two-colour 
> effect you see here. That can’t really be done using standard encoding. You’d 
> probably see IIVVOORRYY in the backing store for that word, with every other 
> letter being set in the letter font and the swirl font. 

Richard Wordingham mentioned the following.

> The third glyph would use 'index' 0x to specify that it be displayed in 
> the foreground colour.

If the OpenType specification were augmented so that 'index' 0xFFFE were to 
specify that the appropriate part of the glyph be displayed in the "first 
decoration colour", a colour specified in the application program and not in 
the font; and an application program were augmented so that an end user were 
able to choose first decoration colour as well as choosing foreground colour, 
then would that produce the result for which Michael is looking?

William Overington

Thursday 6 April 2017

Re: Coloured Punctuation and Annotation

[Richard Wordingham]

On Thu, 6 Apr 2017 01:19:42 -0400
Rebecca T <637...@gmail.com> wrote:

> ... and
> aside from usage I see
> no difference between U+1F989 OWL 黎 and U+13153 EGYPTIAN HIEROGLYPH
> G017 ㅓ.

OWL does not have a prescribed attitude.  On the other hand, if G017
were not body side on and head face on, I am not sure it would be
readable.  Additionally, which way the body is oriented is generally
important.

Richard.

Re: PETSCII mapping?

[Rebecca Bettencourt]

On Thu, Apr 6, 2017 at 10:43 AM, Doug Ewell  wrote:

> Michael Everson wrote:
>
> > Everybody interested, raise your hand…
>
> I'm in. 


I'm in as well of course.


> Rebecca Bettencourt wrote:
>
> > The question is, do we want to add these missing graphics characters
> > incrementally, platform by platform, or put together a larger proposal
> > for, say, one big Block Elements Extended block?
>
> I would guess the latter. There's no tremendous rush; there should be
> time to do a proper analysis of target platforms, evaluate which
> proposed characters should be unified with existing or other proposed
> characters, and so forth.
>
> Of course there's no guarantee this will be the last request ever for
> 8-bit computer compatibility characters, but there doesn't seem much
> point in intentionally dragging the process out, platform by platform.
>

You make a good point. I'm in either way. :)

Re: Coloured Punctuation and Annotation

[Richard Wordingham]

On Thu, 6 Apr 2017 11:34:47 +0100 (BST)
William_J_G Overington  wrote:

> The following post may be of interest.
> 
> http://www.unicode.org/mail-arch/unicode-ml/y2002-m06/0337.html
> 
> It is part of a thread from 2002 about the possibility of chromatic
> fonts.
> 
> I wonder if it would be possible please for Unicode to have a
> Chromatic property that works exactly like the emoji property in the
> sense of expressing that a colour version of the glyph is being
> requested so that characters such as the one to which Daniel refers
> in his post linked above can be listed in The Unicode Standard as
> having a variation selector for a Chromatic version as that would be
> a respectful terminology for characters used in such applications.

Well, who thinks Khaled's example
(http://www.amirifont.org/fatiha-colored.html) is a "text presentation"
and who thinks it is an "emoji presentation"? I think it's a text
presentation.

If "text presentations" have to be monochrome, as Asmus claims, I think
the UTC ought to effectively change the emoji property from a binary
property to an enumerated property with values like "monochrome",
"multicolour", and "emoji".  There might be technical problems, but I
suspect the the emoji property is be covered by Unicode stability
guarantees.  The property is in no way part of the Unicode standard.

However, it is probably something best left to a higher order protocol
- as may be done for some emoji.  Individual requests would have to be
justified on a character by character basis.

Richard.

Re: Eszett variation sequence

[MacCampus]

Actually, the Berlin street signs are well-known cases of using the alternate 
form of the German sharp s. I personally have never seen a straight y in German 
usage anywhere else. For me, both cases can sufficiently being taken care of 
using OpenType features or simply a dedicated font, as is the case with the 
lettering in Berlin. 

The German Wikipedia article on the „ß“ (https://de.wikipedia.org/wiki/ß) names 
the author of the font (Herbert Thannhäuser); in the English version on the 
letter, this information is missing. The article dedicated to Herbert 
Thannhäuser personally (https://de.wikipedia.org/wiki/Herbert_Thannhaeuser; 
German Wikipedia only) makes it clear that the font used in Berlin was 
especially commissioned from him, so it was probably more a one-off design.

Am 06.04.2017 um 15:26 schrieb Michael Everson :

> 
> http://evertype.com/standards/unicode-list/seydlitzstr.jpg
> 
> Do you think we should encode a Latin straight y (like the Cyrillic one) so 
> we can write Seүdlitzstraſʒe?
> 
>> 
>> Would it make sense to propose standardized variation sequences for these 
>> styles or should this be left to font features like `cv##` or `calt` in 
>> Opentype?
> 


Sebastian Kempgen
MacCampus®
Germany

Re: PETSCII mapping?

[Doug Ewell]

Michael Everson wrote:

> Everybody interested, raise your hand…

I'm in. 

Rebecca Bettencourt wrote:

> The question is, do we want to add these missing graphics characters
> incrementally, platform by platform, or put together a larger proposal
> for, say, one big Block Elements Extended block?

I would guess the latter. There's no tremendous rush; there should be
time to do a proper analysis of target platforms, evaluate which
proposed characters should be unified with existing or other proposed
characters, and so forth.

Of course there's no guarantee this will be the last request ever for
8-bit computer compatibility characters, but there doesn't seem much
point in intentionally dragging the process out, platform by platform.
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Proposal to add standardized variation sequences for chess notation

[Philippe Verdy]

2017-04-06 14:57 GMT+02:00 Michael Everson :

> On 6 Apr 2017, at 11:00, Christoph Päper 
> wrote:
> >
> > Michael Everson :
> >>
> >> Standardized variation sequences are the best way to achieve this
> simply and without needless duplication. :-)
> >
> > I still agree with this assertion.
>
> So do I.. ;-)
>
> >> Yes but you still want it to be reasonably legible when the OpenType
> ligatures fail.
> >
> > This is were I don't follow.
>
> Why wouldn’t you want it to be reasonably legible when the OpenType
> ligatures can’t be displayed?
>
> ▗▖
> ▕□︀▨︁□︀▨︁□︀▨︁♞︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁♔︀▨︁□︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏
> ▕□︀▨︁□︀▨︁♚︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁□︀♙︁♛︀▨︁□︀▨︁▏
> ▕▨︁□︀♕︁□︀▨︁♖︀▨︁□︀▏
> ▝▘
> is far better than this:
> ▗▖
> ▕□︀□︀□︀□︀□︀□︀♞︀□︀▏
> ▕□︀□︀□︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀♔︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀□︀□︀□︀♘︀□︀□︀▏
> ▕□︀□︀□︀□︀♚︀□︀□︀□︀▏
> ▕□︀□︀□︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀□︀♙︁♛︀□︀□︀□︀▏<< Is it the pawn or the queen that’s on the black
> square?
> ▕□︀□︀♕︁□︀□︀♖︀□︀□︀▏
> ▝▘
>
> > It *looks* far better in a multi-line plain text environment, but that's
> a glyphic/typographic/stylistic argument.
>
> It’s an argument for legibility.
>

And an argument for rendering purpose only; the actual 2D layout of chess
diagrams is not part of Unicode and does not have  to be encoded. Unicode
is not a glyph encoding standard. I still think this is a hack, similar to
ASCII art and legacy emojis made of ASCII punctuations like :-) or more
complex pseudo-emojis using multiple rows (that do not render correctly
when they depend on specific font designs and metrics.)

I am still convinced that it does not matter if a legacy rendering will not
show white vs. black cells because characte"rs are not rendered in a
monospaced font. The argument exposed for checkered boards here would not
apply for many other boards that typically don't have checkered layouts
(including for example for playing shogi or go).

If we want to add something to represent board cells/tiles in addition to
pieces, that encoding should be coherent and not choosing randomly some
characters that were not even designed to align with similar metrics (such
as ▨︁ and □︀ here!) and not really intended to represent (optionally
colored) cells in a grid.

As well this will not work with other layouts (including shogi that has
variants where cells are triangular: you cannot reliably represent them
using rows filled with △▽△▽. These characters have implicit internal
leading and trailing bearings both horizontally and vertically and cannot
have metrics correctly set without breaking other notations that would
depend on these bearings, for example in mathematic formulas where they are
separated symbols). So you cannot expect rows in rectangular grid patterns
made with ▨︁ and □︀ to look correct... unless they are each one modified
with a variant selector saying they should use the full character cell (and
there will still be problems with △▽ because they will actually need to
cover more than their rectangular cells with twho corners extending outside
of it with additional kerning, not suitable for mathematics).

And the poroblem with such grid patterns is more generic than just chess
diagrams. We should be able to represent directly at least several well
known patterns of cells/tiles (optionally colored when this matters), and
then be able to combine them with any chacter/cluster inside them (for
example for classic crosswords, Scrabble, triominos and similar games). We
need a way to represent grids made with square/rectangular cells, or
triangular/hexagonal cells (for triangular and hexagonal cells we need
additional half-cells to properly align rows at least at start or rows, and
hexagonal cells will partly extend over the previous and next row

So I would prefer a proposal to:
* add specific symbol characters for these common patterns of cells
(rectangular/square, triangular, hexagonal), plus half-cells for use at
start and end of rows (if rows are not aligned vertically but in create
triangular layouts),
* optionally followed by some variant selectors for mapping some semantic
colors on them (semantic color means "light" and "dark" may be "white" and
"black, or "ivory" and "wood", or "yellow" and "red", or
"empty/transparent" vs. "hatched" with monochromatic rendering where colors
are replaced by fill patterns such as ///, or dots with some density; we
should have about 8 semantic colors, representable with actual colors or
grey or fill patterns). The common "black square" and "white square" (the
white version would be the default semantic color and would not need any
additional variant).
* and then use ZWJ to combine them with letters/symbols to be centered
within them (possibly some extended clusters such as
letters+combining subscript digits in Scrabble)

The base set of the first set for cells should be based on old wellknown
"block graphic" characters used in 

Re: PETSCII mapping?

[Rebecca Bettencourt]

On Thu, Apr 6, 2017 at 5:25 AM, Michael Everson 
wrote:

> At some point this should be taken off the main list since discussion will
> get very detailed very quickly.
>

I agree. How should we get all the interested parties together?

Re: Standaridized variation sequences for the Desert alphabet?

[Mark Davis ☕️]

Mark

On Thu, Apr 6, 2017 at 6:11 PM, Michael Everson 
wrote:

> On 6 Apr 2017, at 16:05, Mark Davis ☕️  wrote:
>
> >> I just get frustrated when everyone including the veterans seems to
> forget every bit of precedent that we have for the useful encoding of
> characters.
> >
> > ​Nobody's forgetting anything. ​Simply because people disagree with you
> doesn't mean they are forgetful or stupid. One could just as well respond
> that you are forgetting that Unicode is not a glyph standard. Merely
> because a character have multiple shapes is not grounds for disunifying it.
>
> The ignoring of reasonable precedent does not make the UTC seem
> reasonable. In terms of Deseret, the suggestion that characters Ѕ/Ћ/Ѓ/Љ
> with a stroke derived from І are glyph variants of one another simply
> makes no sense at all. We have honed over many years our understanding of
> writing systems, and saying “Oh, Љ-with-stroke and Ѓ-with stroke are
> variant shapes of the same thing”… Anyone can see that this is not true.
>

​"Anyone" doesn't matter. What matters is users of Deseret, not you, not
me. If knowledgeable users of Deseret recognize two shapes as representing
the same character, that is what matters. Similarly, users of Fraktur will
recognize that *very* different shapes represent the same Latin character,
while some very similar (to other's eyes) shapes represent different
characters (some of the capitals, for example).
​

>
> The vexing thing is that one can never rely on consistency in the UTC’s
> approaches to any proposal. I have discussed this with other successful and
> prolific proposal writers. It’s always a coin-toss as to how a proposal
> will be viewed.
>
> The recent instance of adding attested capital letters for ʂ and ʐ is a
> perfect example. We have seen before some desire to see evidence for casing
> pairs (though often it has not been sought.) We have never before seen
> evidence for casing pairs to be thrown out. Case, of course, is a function
> of the Latin script, just as it is of Greek and Cyrillic and Armenian and
> Cherokee and both Georgian scripts and others. The UTC’s refusal to encode
> attested capitals for ʂ and ʐ simply makes no sense.
>

​To you.
​

>
> Your statement "Merely because a character have multiple shapes is not
> grounds for disunifying it” suggests an underlying view that "everything is
> already encoded and additions are disunifications”.


​No, not at all. That is a false dichotomy.


> I do not subscribe to this view.
>


​

>
> Michael Everson

Re: PETSCII mapping?

[Michael Everson]

On 6 Apr 2017, at 17:36, Rebecca Bettencourt  wrote:
> 
> At some point this should be taken off the main list since discussion will 
> get very detailed very quickly.
> 
> I agree. How should we get all the interested parties together?

Everybody interested, raise your hand…

Michael Everson

Re: Proposal to add standardized variation sequences for chess notation

[Michael Everson]

On 6 Apr 2017, at 17:24, Kent Karlsson  wrote:

> One in one single font (according to your current proposal), one can only 
> have EITHER terminal emulator version, OR chess border version. Not both. 
> Using variant selectors for the chess border variants allow for both glyph 
> variants. Maybe it does not make much difference in a proportional font. But 
> for a "mono-width" font the terminal emulator versions for these border 
> characters would be "narrow", but the chess border versions should be 
> "fullwidh"/"square" (compare CJK in terminals; double the width of, e.g., 
> Latin characters).

Hm. Time for me to put VS support into Everson Mono, than, and see what 
happens. But I think you’re probably right, though. 

Tak for hjælpet.

Michael Everson

Re: PETSCII mapping?

[Rebecca Bettencourt]

The Teletext set of 2x3 block characters also covers a significant chunk of
the TRS-80 and CoCo character sets:

http://www.kreativekorp.com/software/fonts/trs80.shtml

I have been thinking of proposing those characters for a while, actually,
and that would have been my next proposal after PETSCII. :) The question
is, do we want to add these missing graphics characters incrementally,
platform by platform, or put together a larger proposal for, say, one big
Block Elements Extended block? My first thought is that an incremental
approach would make it easier to get characters into the standard, but what
do I know.


-- Rebecca Bettencourt

On Thu, Apr 6, 2017 at 5:07 AM, Rebecca T <637...@gmail.com> wrote:

> Here’s a copy of the Teletext character set; it includes box-drawing
> characters
> for all combinations of a 2×3 grid of cells. 2⁶ = 64 characters, so we
> might
> need a new block.
>
> [1]: http://www.galax.xyz/TELETEXT/CHARSET.HTM
>
>

Re: Proposal to add standardized variation sequences for chess notation

[Kent Karlsson]

Den 2017-04-06 03:05, skrev "Michael Everson" :

> On 6 Apr 2017, at 01:54, Kent Karlsson  wrote:
> 
 - some bidi fix [preferably making the box/border drawing characters bidi
 "L", if possible; otherwise a caveat that if there is an expectation to
 paste in such a board into an RTL document, bidi controls need be used to
 LTR the board]).
>>> 
>>> I donąt know if there is a problem here and am not able to offer a solution
>>> if there is. I donąt object to a solution, if there is a problem.
>> 
>> I would think
> 
> Come on. This is a serious proposal.

I agree! ;-)

> I'm glad you support it, but if you are
> going to raise an issue like this, "I would think and guess about a problem"
> isn't the same as "I have tried and here's an actual problem".

I apologise for my slightly cautious way of expressing myself...

All the characters in the "chess board lines" (apart from spaces, if any),
are of bidi category ON or NSM. So there is no character that "sets" a bidi
direction of the lines ("paragraphs"). So if the bidi setting for display is
set to default to RTL, each of the chess board lines will be reversed in
display. Now, since the border characters are not mirrored, the left and
right side of the board side lines will be somewhat botched. Which is very
visible in that it is ugly. (And I guess(!) the reader will notice that...)

I'm not a bidi expert, but I know that much about bidi (and so should
you...).

> Roozbeh, there's an issue that might benefit from your expertise. Can you look
> into it? Discussion needn't occur here, but offline with Kent and me, if you
> prefer. 
> 
>> that anyone pasting a chess board (ŕ la your proposal) to an RTL context will
>> see that something went amiss,
> 
> Will they? Why?

Since the border characters are not mirrored (they do not have the
mirroring property), the left and right side of the chess board side
lines will be somewhat botched. Which is visible/ugly. Indeed, the entire
chess board will be mirrored (though none of the individual glyphs), but,
though visible, that whole-mirroring (line reversal) is easier to miss.

>> and also know enough about bidi to set the bidi context to LTR for the chess
>> board(s),
> 
> RTL users understand the problems of cutting and pasting LTR text and symbols,
> certainly. LTR users don't.
> 
>> either by some setting, or by inserting bidi control characters.
> 
> Well, if there's a problem it should be well-defined so it can be tackled.
> 
>> So a small caveat is all that is necessary. Like: "The chess boards are
>> assumed to be set in a left-to-right bidi context."
> 
> THAT I can put into the document, but since chess is as important in both the
> RTL and LTR worlds, it would be good to know what's what.

See above.

/Kent K

> Thank you again for your thoughtfulness,
> 
> Michael

Re: Proposal to add standardized variation sequences for chess notation

[Kent Karlsson]

Den 2017-04-06 03:08, skrev "Michael Everson" :

> On 6 Apr 2017, at 02:05, Kent Karlsson  wrote:
> 
>>> Do generic font makers intend to support both graphic terminal emulation and
>>> chess?
>> 
>> I don't know. But it should not be impossible to do so.
> 
> And you think the proposal as it does leads to that?

Yes. One in one single font (according to your current proposal), one can
only have EITHER terminal emulator version, OR chess border version. Not
both. Using variant selectors for the chess border variants allow for both
glyph variants. Maybe it does not make much difference in a proportional
font. But for a "mono-width" font the terminal emulator versions for these
border characters would be "narrow", but the chess border versions should
be "fullwidh"/"square" (compare CJK in terminals; double the width of, e.g.,
Latin characters).

>>> Should chess font makers be burdened with graphic terminal emulation glyphs
>>> they know nothing about?
>> 
>> If it is really a chess font, they can just use the glyphs for the chess
>> variety also as the "plain" (terminal emulator variety), and it would not
>> matter (as long as no-one insist on using it for terminal emulation).
> 
> Ha, so you¹re saying it¹s mostly for things like Everson Mono that it mattersŠ
> ;-)

Yes (but there are other fonts than Everson Mono that are suitable for
terminal emulators...).

There are still people who read (plain text) emails in terminal emulators
(or other email clients that cannot handle font switching inside an email,
and may have selected a "terminal emulator" font for viewing emails). Though
"mono-width", the chess board glyphs should be "fullwidth"...

/Kent K


>> All that is needed for that is a manoeuvre to copy a few glyphs within the
>> font (when creating the font). I guess that is not very hardŠ
> 
> It is not.
> 
> Michael Everson

Re: Standaridized variation sequences for the Desert alphabet?

[Michael Everson]

On 6 Apr 2017, at 16:05, Mark Davis ☕️  wrote:

>> I just get frustrated when everyone including the veterans seems to forget 
>> every bit of precedent that we have for the useful encoding of characters.
> 
> ​Nobody's forgetting anything. ​Simply because people disagree with you 
> doesn't mean they are forgetful or stupid. One could just as well respond 
> that you are forgetting that Unicode is not a glyph standard. Merely because 
> a character have multiple shapes is not grounds for disunifying it.

The ignoring of reasonable precedent does not make the UTC seem reasonable. In 
terms of Deseret, the suggestion that characters Ѕ/Ћ/Ѓ/Љ with a stroke derived 
from І are glyph variants of one another simply makes no sense at all. We have 
honed over many years our understanding of writing systems, and saying “Oh, 
Љ-with-stroke and Ѓ-with stroke are variant shapes of the same thing”… Anyone 
can see that this is not true. 

The vexing thing is that one can never rely on consistency in the UTC’s 
approaches to any proposal. I have discussed this with other successful and 
prolific proposal writers. It’s always a coin-toss as to how a proposal will be 
viewed. 

The recent instance of adding attested capital letters for ʂ and ʐ is a perfect 
example. We have seen before some desire to see evidence for casing pairs 
(though often it has not been sought.) We have never before seen evidence for 
casing pairs to be thrown out. Case, of course, is a function of the Latin 
script, just as it is of Greek and Cyrillic and Armenian and Cherokee and both 
Georgian scripts and others. The UTC’s refusal to encode attested capitals for 
ʂ and ʐ simply makes no sense. 

Your statement "Merely because a character have multiple shapes is not grounds 
for disunifying it” suggests an underlying view that "everything is already 
encoded and additions are disunifications”. I do not subscribe to this view. 

Michael Everson

Re: Proposal to add standardized variation sequences for chess notation

[Doug Ewell]

Michael Everson wrote:

> Leaving out the de-facto flag of Northern Ireland wasn’t very wise
> either,

Nor over a thousand flags of regions that don't happen to compete
independently in international sports. But anyway. 
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Standaridized variation sequences for the Desert alphabet?

[Mark Davis ☕️]

On Thu, Apr 6, 2017 at 4:07 PM, Michael Everson 
wrote:

> I just get frustrated when everyone including the veterans seems to forget
> every bit of precedent that we have for the useful encoding of characters.
>

​Nobody's forgetting anything. ​Simply because people disagree with you
doesn't mean they are forgetful or stupid. One could just as well respond
that you are forgetting that Unicode is *not* a glyph standard. Merely
because a character have multiple shapes is not grounds for disunifying it.

Mark

Re: Proposal to add standardized variation sequences for chess notation

[William_J_G Overington]

Here is a link to a chess-type board in a garden in France shown in Google 
Street View.

https://www.google.co.uk/maps/@47.1030089,0.3209105,3a,75y,24.39h,75.31t/data=!3m6!1e1!3m4!1sb0b73sCdjBaGofBYjXOy8Q!2e0!7i13312!8i6656

One can move around the board within Google Street View.

How could we encode that? :-)

I know that in reality that we probably would not, but it is an interesting 
thought experiment?

Just for encoding fun!

William Overington

Thursday 6 April 2017

Re: Coloured Punctuation and Annotation

[William_J_G Overington]

The following post may be of interest.

http://www.unicode.org/mail-arch/unicode-ml/y2002-m06/0337.html

It is part of a thread from 2002 about the possibility of chromatic fonts.

I wonder if it would be possible please for Unicode to have a Chromatic 
property that works exactly like the emoji property in the sense of expressing 
that a colour version of the glyph is being requested so that characters such 
as the one to which Daniel refers in his post linked above can be listed in The 
Unicode Standard as having a variation selector for a Chromatic version as that 
would be a respectful terminology for characters used in such applications.

I also found this post of mine.

http://unicode.org/mail-arch/unicode-ml/y2002-m06/0403.html

Something to think about?

William Overington

Thursday 6 April 2017

Re: Standaridized variation sequences for the Desert alphabet?

[Michael Everson]

On 6 Apr 2017, at 08:01, Martin J. Dürst  wrote:

> Hello Michael,

Hi Martin.

>> It’s as though you’d not participated in this work for many years, really.
> 
> Well, looking back, my time commitment to Unicode has definitely varied over 
> the years. But that might be true for everybody.

I just get frustrated when everyone including the veterans seems to forget 
every bit of precedent that we have for the useful encoding of characters. 

> What's more important is that Unicode covers such a wide range of areas, and 
> not everybody has the same experience or knowledge. If we did, we wouldn't 
> need to work together; it would be okay to just have one of us. Indeed, 
> what's really very valuable and interesting in this work is the many very 
> varied backgrounds and experiences everybody has.

I do not disagree, particularly. 

>>> - That suggests that IF this script is in current use,
>> 
>> You don’t even know? You’re kidding, right?
> 
> Everything is relative. And without being part of the user community, it's 
> difficult to make any guesses.

Hm, but you did make a guess. 

>> Yeah, it doesn’t “seem” anything but a whole lot of special pleading to 
>> bolster your rigid view that the glyphs in question can be interchangeable 
>> because of the sounds they may represent.
> 
> I don't remember every claiming that the glyphs must be used interchangeably, 
> only that we should carefully examine whether they are or not, and that 
> because they represent the same sound (in a phonetic alphabet, as it is)

We don’t encode sounds, we encode writing systems, the marks on paper, and in 
Latinate scripts (I’ll ignore CJK) we have never unified characters which are 
formed of historical ligatures like these… I guess ſs and ſʒ might possibly be 
the exception, but I think nobody would find a use for distinguishing them. 

> and are shown in the same position in alphabet tables, we shouldn't a priori 
> exclude such a possibility.

As it happens, at least one writer used the Ѕ-with-stroke (encoded for /ju;/) 
for /ɔɪ/, but I wouldn’t substitute the Љ-with-stroke (Ц) for it in a 
diplomatic transcription. Normalized spelling is something else, but the 
orthography of Deseret manuscripts themselves is what it is. Subtle things like 
the dialect of writers can be gleaned from them, and letterforms may help to 
date a text. 

>>> - There may not be enough information to understand how the creators and 
>>> early users of the script saw this issue,
>> 
>> Um, yeah. As if there were for Phoenician, or Luwian hieroglyphs, right?
> 
> Well, there's well over an order of magnitude difference in the time scales 
> involved. The language that Deseret is used to write is still in active use, 
> including in this very discussion. Quite different from Phoenician or Luwian 
> hieroglyphs.

The language is still in use, but we have no access to the minds of the dead 
users of Deseret unless they write about their orthographic practices 
explicitly. Accurate transcription can tell us if the speaker was from Boston 
or Britain, if for instance they regularly drop -r- in words like “start”. 

> In addition, we have meta-information such as alphabet tables, which we may 
> not have for the scripts you mention, as well as the fact that printing 
> technology may have forced a better identification of what's a character and 
> what not than inscriptions and other older technologies.

Well, we know there was a script reform in Deseret with regard to these and 
some other characters. 

>> Nobody worried about the number of modern users of the Insular letters we 
>> encoded. Why put such a constraints on users of Deseret? Ꝺꝺ Ꝼꝼ Ᵹᵹ Ꝿ Ꞃꞃ Ꞅꞅ Ꞇꞇ.
> 
> Because it's modern users, and future users, not users some hundred years or 
> so ago, that will use the encoding. In the case of Insular letters, my guess 
> is that nobody wants to translate/transcribe xkcd, for example, whereas there 
> is such a transcription for Deseret:
> http://www.deseretalphabet.info/XKCD/

Modern users use the insular letterforms for accurate representation of some 
texts. John does the XKCD transcriptions, I believe, and he doesn’t use the 
diphthong letters anyway, and that’s his orthographic practice. 

>> Most readers and writers of Deseret today use the shapes that are in their 
>> fonts, which are those in the Unicode charts, and most texts published today 
>> don’t use the EW and OI ligatures at all, because that’s John Jenkins’ 
>> editorial practice.
> 
> So I was wrong to write "modern practitioners", and should have written 
> "modern publishers" or "modern published texts". Or is the impression that I 
> get from what you wrote above wrong that most texts published these days are 
> edited by John, or by people following his practice?

John is active in the area of making and publishing modern editions in Deseret. 
Ken has worked in the area of manuscripts and their represntation. 

> I don't remember denying the value of 

Re: Proposal to add standardized variation sequences for chess notation

[Michael Everson]

On 6 Apr 2017, at 13:19, Christoph Päper  wrote:
> 
> Although Michael Everson readily dismisses any connection to emojis, e.g. 
> L2/16-021 or L2/16-087+088, and hence the Emoji and Emoji_Presentation 
> character properties as well as sequences with variation selectors 15 and 16 
> (U+FE0E/F), normal emoji design actually matches "diagram" notation quite 
> nicely in that all emoji glyphs are rendered within an (ideographic / em) 
> square. 

No, no. Emojis are something else very specific and very expensive with 
implications for vendors and having to do with colour. Look at zero:

U+0030 - 0 - DIGIT ZERO
U+0030 FE00 - 0︀ - short diagonal stroke form
U+0030 FE0E - 0︎ - text style
U+0030 FE0F - 0️ - emoji style

Emoji is something else. Emoji is a fine thing, but it’s not chessboard 
typesetting. 

Michael Everson

Re: Proposal to add standardized variation sequences for chess notation

[Christoph Päper]

> Michael Everson  hat am 6. April 2017 um 14:57
> geschrieben:
> 
>> That's what this proposal is all about. It's a good and sound proposal,
>> except for the empty square.
> 
> Do you mean “except for the light and dark squares without a piece on them” or
> “except for the light square without a piece on it”?

I meant "except for the squares without a piece on them".
 
> What is your specific counter-proposal?

Either VS-16 and Emoji property for pieces, being used with U+2B1B/C as empty
squares, as explained in a subsequent message,
or VS-1 and VS-2 sequences with a single codepoint to represent an empty square
(consistent with pieces).

Re: Eszett variation sequence

[Michael Everson]

Can you give an example of any font which has two glyphs in it for ß?

I mean, I was in Berlin and I took this picture:

http://evertype.com/standards/unicode-list/seydlitzstr.jpg

Do you think we should encode a Latin straight y (like the Cyrillic one) so we 
can write Seүdlitzstraſʒe?

> On 6 Apr 2017, at 13:37, Christoph Päper  wrote:
> 
> U+00DF Latin Letter Sharp S ⟨ß⟩ has at least two rather different visual 
> styles resulting from a ligature of either long and round lowercase S, ⟨ſs⟩, 
> or of long S and normal or tailed lowercase Z, ⟨ſz⟩ or ⟨ſʒ⟩. Most modern 
> typeface designs follow the first style and sometimes the right-hand side is 
> quite distinct from the shape of the round S in the same font. In some cases 
> it makes sense to distinguish the glyphic origins, because, by orthographic 
> or graphotactic means, for instance, an _sz_ digraph is appropriate in 
> different places than an _ss_ repeated letter.
> 
> Would it make sense to propose standardized variation sequences for these 
> styles or should this be left to font features like `cv##` or `calt` in 
> Opentype?

Re: Proposal to add standardized variation sequences for chess notation

[Michael Everson]

On 6 Apr 2017, at 11:00, Christoph Päper  wrote:
> 
> Michael Everson :
>> 
>> Standardized variation sequences are the best way to achieve this simply and 
>> without needless duplication. :-)
> 
> I still agree with this assertion.

So do I.. ;-)

>> Yes but you still want it to be reasonably legible when the OpenType 
>> ligatures fail.
> 
> This is were I don't follow.

Why wouldn’t you want it to be reasonably legible when the OpenType ligatures 
can’t be displayed?

▗▖
▕□︀▨︁□︀▨︁□︀▨︁♞︀▨︁▏
▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
▕□︀▨︁♔︀▨︁□︀▨︁□︀▨︁▏
▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏
▕□︀▨︁□︀▨︁♚︀▨︁□︀▨︁▏
▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
▕□︀▨︁□︀♙︁♛︀▨︁□︀▨︁▏
▕▨︁□︀♕︁□︀▨︁♖︀▨︁□︀▏
▝▘
is far better than this:
▗▖
▕□︀□︀□︀□︀□︀□︀♞︀□︀▏
▕□︀□︀□︀□︀□︀□︀□︀□︀▏
▕□︀□︀♔︀□︀□︀□︀□︀□︀▏
▕□︀□︀□︀□︀□︀♘︀□︀□︀▏
▕□︀□︀□︀□︀♚︀□︀□︀□︀▏
▕□︀□︀□︀□︀□︀□︀□︀□︀▏
▕□︀□︀□︀♙︁♛︀□︀□︀□︀▏<< Is it the pawn or the queen that’s on the black square?
▕□︀□︀♕︁□︀□︀♖︀□︀□︀▏
▝▘

> It *looks* far better in a multi-line plain text environment, but that's a 
> glyphic/typographic/stylistic argument.

It’s an argument for legibility. 

> The semantics conveyed are redundantly encoded this way, so I wouldn't say it 
> was far better. This alternating pattern is far more redundant than, say, 
> pairs of opening and closing characters (brackets, quotation marks).

It’s not redundant to the reader. The reader of the second one has to remember 
that the dark square is the lower left, and then count in order to know the 
colour of any given square. The reader of the first one doesn’t have to do 
this, because we have both ▨︁ and □︀, two encoded characters, and we use them 
for convenience. 

> Aside, good fallback isn't something the UTC seems to be concerned with 
> lately, 

Inconsistency on the part of the UTC is not my concern. I have to 

> see emoji subregion flags that are all represented by Waving Black Flag in 
> legacy implementations (possibly followed by TOFU).

Yes, well, that’s an example of a decision that didn’t have good oversight or 
feedback, perhaps. I do know that falling back to a black flag rather than to 
the Union flag for Wales, England, and Scotland doesn’t seem very sensible. 
Leaving out the de-facto flag of Northern Ireland wasn’t very wise either, 
though nobody asked the UK or Irish representatives of SC2 their opinion about 
it. 

>> See? To parse this one you have to remember which of the white squares are 
>> the alternating black ones.
> 
> No, you only have to remember that A1, i.e. the lower left square initially 
> occupied by a white rook, is black.

You have to remember that, and then you have to count every other square in 
whatever direction to know what colour a given square is. That’s not very 
user-friendly. And it’s easy to be user friendly. Just use both ▨︁ and □︀. 

> For legal moves, the color pattern hardly matters, unless - regarding pawns - 
> it was common practice to render the board turned, i.e. with the white player 
> not at the bottom, but at the top (or left or right) side, and without 
> alphabetic column and numeric row labels. 

For legal moves, no. But this is text. The table is meant to be read. Since it 
is, good fallback is better than bad fallback. 

>> The colour of the matrix is NOT redundant for a human reader.
> 
> That's what this proposal is all about. It's a good and sound proposal, 
> except for the empty square.

Do you mean “except for the light and dark squares without a piece on them” or 
“except for the light square without a piece on it”? The convention is to have 
two alternating shades on the squares and there’s no advantage to the human 
reader to quash this distinction. 

What is your specific counter-proposal?

Michael Everson

Re: PETSCII mapping?

[Michael Everson]

On 6 Apr 2017, at 04:32, Rebecca Bettencourt  wrote:

> We do have to provide Unicode with fonts, I believe. We can use an existing 
> C64 font, such as Pet Me. Or, we can create a new font with vectorized 
> versions of the characters.

I’ll help with that; we should harmonize with other characters in the standard.

At some point this should be taken off the main list since discussion will get 
very detailed very quickly.

Michael Everson

Re: Coloured Punctuation and Annotation

[Michael Everson]

> On 6 Apr 2017, at 05:41, Richard Wordingham  
> wrote:
> 
> On Thu, 6 Apr 2017 01:11:09 +0100
> Michael Everson  wrote:
> 
>> On 5 Apr 2017, at 22:48, Richard Wordingham
>>  wrote:
>> 
>>> I tried to read it from UTS#51 ‘Unicode Emoji', which is not part of TUS, 
>>> but I couldn't deduce that a font that enables U+10B99 PSALTER PAHLAVI 
>>> SECTION MARK to have exactly two (as opposed to none or four) red dots is 
>>> in breach of the guidelines therein. 
>> 
>> Kindly explain how ANY font could do this.
> 
> Is this a trick question?

No. Here is an example of a font available in two variants. In one variant, all 
those grey swirls are fused to the letters, and it can all be printed in black 
or one colour ink. http://cdn.myfonts.net/s/aw/original/255/0/131020.png 

There is also a second set of fonts included which separates the swirls from 
the letters, and those can be used in typesetting to get the two-colour effect 
you see here. That can’t really be done using standard encoding. You’d probably 
see IIVVOORRYY in the backing store for that word, with every other letter 
being set in the letter font and the swirl font. 

Emoji-style colour fonts use other mechanisms for colour.

Michael Everson

Eszett variation sequence

[Christoph Päper]

U+00DF Latin Letter Sharp S ⟨ß⟩ has at least two rather different visual styles
resulting from a ligature of either long and round lowercase S, ⟨ſs⟩, or of long
S and normal or tailed lowercase Z, ⟨ſz⟩ or ⟨ſʒ⟩. Most modern typeface designs
follow the first style and sometimes the right-hand side is quite distinct from
the shape of the round S in the same font. In some cases it makes sense to
distinguish the glyphic origins, because, by orthographic or graphotactic means,
for instance, an _sz_ digraph is appropriate in different places than an _ss_
repeated letter.

Would it make sense to propose standardized variation sequences for these styles
or should this be left to font features like `cv##` or `calt` in Opentype?

Re: Proposal to add standardized variation sequences for chess notation

[Christoph Päper]

Mark Davis ☕️ :
> 
> I'm looking forward to similar postings on checkers and go pieces. (...)
> And I'm looking also forward to the ♖+ZWJ+⬛️  (etc) proposal.

Well, actually ...

Garth Wallace made an important observation in
: 

>> Currently, chess fonts can be (roughly) divided into "diagram fonts" and
>> "notation fonts".

The major goal of Michael Everson's proposal to introduce standardized sequences
with variant selectors 1 and 2 (U+FE00/1) for chess piece characters (primarily
U+2654-F), as far as I understand it, is to assure "diagram" glyph design. This
means fixed-width figurines centered in the character cell, with means for
square color and board border elements (incl. labels), whereas "notation" style
usually has proportional figurines sitting on the baseline. 

The square color is ignored in standard chess notation, where fields are
conventionally known by their alphabetic column index ("file", A-H for a
standard checkerboard) and numeric row index ("rank", 1-8), i.e. A1 through H8,
which are virtually never styled as "⬛A1", "◻B1", "B2"
whereas figurine charactres may either augment or substitute conventional letter
symbols.

  - Black/dark squares are those whose file and rank are either both odd or both
even. 
  - White/light squares are those whose file is odd and rank is even, or vice
versa. 

Corollary: The glyph background is almost only important within diagram
notation.

Diagrams may only show select squares, so the color of the first or last one and
hence intermediate ones cannot necessarily be deduced from the immediate
context. (They may be implied by row and column labels, which is simple for a
sighted human reader, but complex for computers and blind readers.)

Although Michael Everson readily dismisses any connection to emojis, e.g.
L2/16-021 or L2/16-087+088, and hence the Emoji and Emoji_Presentation character
properties as well as sequences with variation selectors 15 and 16 (U+FE0E/F),
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 in small U+25AA/B, medium-small
U+25FE/D, medium U+25FC/B and large U+2B1B/C. The last ones would probably be
preferred. Only the first ones are default text style characters. The characters
for empty squares from the proposal, U+25A8/1, have no emoji representation yet.
I've suggested to use the hatching characters U+25Ax for their colors as in
heraldic tinctures, which relate U+25A8 to Purple ("purpure").

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.

A font intended for print wouldn't have to use any fancy colors or effects for
emoji glyphs, but only infer the centered squared presentation from a variation
selector, so it could still use proportional glyph in running text.

In conclusion, although I support the proposal in principle, I strongly suggest
to consider to use established VS-16 and implicit contextual backgrounds instead
of arbitrary VS-1 and VS-2 with explicit backgrounds.

(With only VS-16, my previous remarks about the representation of empty squares
would be somewhat moot. Technically, it's still redundant, but at least it would
be consistent.)

References
--

- L2/16-021: http://unicode.org/L2/L2016/16021-game-pieces-emoji.pdf
- L2/16-087: http://unicode.org/L2/L2016/16087-provisional-value-for-emoji.pdf
- L2/16-088: http://unicode.org/L2/L2016/16088-chars-for-emoji-provisional.pdf
  *
https://docs.google.com/spreadsheets/d/1-XLoueD__NZtOPNz4bWl_HwOmwGIt_6aEaWV-l_I0UQ/
(broken)
  *
https://docs.google.com/spreadsheets/d/1txhi8XYKFMkCaOOFMI2z1tQkNwhzkUN-htofj-oJ1GM/
(original)
  *
https://docs.google.com/spreadsheets/d/1KQDH9uArJr-8m4UvAEd02ixaX_-wauSwjy9qYCwIOvE/
(extended)
- Hatching colors: https://github.com/Crissov/unicode-proposals/issues/222 etc.

Re: Proposal to add standardized variation sequences for chess notation

[Michael Everson]

On 6 Apr 2017, at 04:24, Martin J. Dürst  wrote:

>> http://evertype.com/standards/unicode-list/looking-glass-yellow-blue.png
> 
> [OT]
> It looks neat. But I noticed three very small gaps in each of the top and 
> bottom borders.

I have not done anything to optimize display in these fonts. They were 
proof-of-concept fonts for the sequences. It’s easy to fix those… just drag the 
glyph and make it a bit longer. One does the same thing in Arabic fonts. 

> Also, it's probably not the best choice of colors, because my eyes tend to 
> associate the yellow figures with white, and the blue ones with black, but 
> thinking it through makes it clear that it's the other way round.

I just picked the process colours cyan and yellow, but it was Richard who had 
specified the colours: “Now, what happens to the two scheme if rendered with 
yellow text ('foreground') on a blue background?" 

Michael Everson

Re: PETSCII mapping?

[Rebecca T]

Here’s a copy of the Teletext character set; it includes box-drawing
characters
for all combinations of a 2×3 grid of cells. 2⁶ = 64 characters, so we might
need a new block.

[1]: http://www.galax.xyz/TELETEXT/CHARSET.HTM

Re: Coloured Punctuation and Annotation

[Philippe Verdy]

Nice effectively, even if there are some geometric glitches in the first
complex (wide) ligature for their black horizontal strokes at the bottom (I
don't understand why they are partly broken, possibly caused by even/odd
filling rules or some incorrect hinting reducing the widths to zero.

2017-04-06 13:08 GMT+02:00 Khaled Hosny :

> On Thu, Apr 06, 2017 at 12:50:02PM +0200, Werner LEMBERG wrote:
> >
> > > This page should show colored Hamza, diacritical dots and vowel
> > > marks on web browsers that support MS color font format (currently
> > > Firefox, Edge, and Internet Expoler on latest Windows 10):
> > > http://www.amirifont.org/fatiha-colored.html
> > >
> > > No special markup have been used, the color information is embedded
> > > in a regular OpenType font.
> >
> > Very nice!  It als works with Firefox on my GNU/Linux box.
>
> I think I worded this vaguely, it works with Firefox on all platforms
> (even on Android), the Windows 10 restriction is for Internet Expoler
> only.
>
> Regards,
> Khaled
>

Re: Implementation of ideographic description characters

[Philippe Verdy]

What is demonstrated here is how to build a CID-keyed font supporting the
the "unencoded glyphs" using IDS pseudo-encoding + OpenType "ccmp" (or
alternatively "liga") feature. It speaks about an Adobe registry ("ROS")
for some supported lexical dictionnaries, where encoded codepoints or
unencoded glyphs (CID-key) can be mapped to subsets implementable in
conforming fonts. http://blogs.adobe.com/CCJKType/2012/05/sp-ai0-ros.html

It does not demonstrate how you can convert multiple glyphs and alter their
metrics and placement to create composite glyphs. The actual composite
glyphs are still manually tuned to build fonts. There are some attempts to
generate composite glyphs automatically, but this has still always failed
with traditional (serif-style) fonts. There's some limited success with
simplified glyphs (not using strokes with variable weight), but the
generated glyphs are ugly because of their uneven stroke width (the
smallest parts are difficult to read, the larger ones are too bold and
should have their metrics reduced).

The assumption that width and height metrics are equal for all parts of a
single IDS composite gives wrong results. You need first to determine how
many subcolumns and ahow many subrows will tile the general composition
square then assign seaprate "weights" to subcolumns and subrows by counting
the number of stokes that interact on that dimension in the same
subcolumn/subrow. With these weights you can then properly distribute the
effective width of subcolumns, and effective height of subrows. With the
total "weights" computed separate for each dimension, you then need to take
its maximum value and make sure that stroke widths will not exceed this
value.

Then you can place the glyphs in subcolumns/subrows, but you also need to
be able to determine parts of strokes that are allowed to exceed their
subcolumn/subrow limit : generally this is the thinest ending nodes of the
stroke, which may "touch" (intersect) some other strokes provided the
colliding strokes are not parallel or nearly paralell so that their area of
intersection will remain in a radius significantly smaller than the average
stroke width).

Such algorithm is not implementable directly in fonts, but it should be
possible to instruct some complex metrics in base glyphs to allow some
nodes to move slightly outside their definition box in a prefered
direction. When glyphs are heavily narrowed horizontally or flattened
vertically in their final rendering box (their size ratio is no longer a
square) you need more specific hinting. The situation becomes more complex
with some base glyphs for enclosure IDS (not just stacked side-by-side or
on top of each other), but things may become simpler if these base strokes
are themselves decomposed in IDS strings (using only side-by-side or
top-to-bottom + more basic strokes: the defined IDS dictionnary ignore
these subdecompositions because the standard IDS only use the encoded base
strokes and the subdecomposition of encoded base strokes would need special
codes for unencoded simple strokes.

But there's still no standard hinting in OpenType fonts to instruct CJK
glyphs so that their geometries may be properly adjusted while presxerving
the visual font weight and overall readability. So this requires specific
glyph renderers, and these glyph renderers are still not used by generic
text renderers. These algorithms are then used only as tools for generating
collections of glyphs in fonts in construction. Then complex glyphs are
manually tuned and various metrics are adjusted. Hinting instructions are
no logner present in the final (OpenType or SVG) fonts.


2017-04-06 9:28 GMT+02:00 gfb hjjhjh :

> Seems like Source Han Serif have just implemented such functionality? Or
> is this just partial. https://twitter.com/tualatrix/
> status/849178587680735232
>

Re: [Unicode] Re: Implementation of ideographic description characters

[suzuki toshiya]

Maybe, some precomposed glyphs (without standardized code points) are included
in the font, and the registered IDS strings are internally converted to the
glyph index to them, by ligature feature of OpenType. I guess, the
"composition"-like behaviour is just visible for the set of IDS registered in
the font, and the unregistered IDS string would not be displayed as single
composed glyph.

gfb hjjhjh wrote:
> Seems like Source Han Serif have just implemented such functionality? Or is 
> this just partial. https://twitter.com/tualatrix/status/849178587680735232
> 

Re: Coloured Punctuation and Annotation

[Khaled Hosny]

On Thu, Apr 06, 2017 at 12:50:02PM +0200, Werner LEMBERG wrote:
> 
> > This page should show colored Hamza, diacritical dots and vowel
> > marks on web browsers that support MS color font format (currently
> > Firefox, Edge, and Internet Expoler on latest Windows 10):
> > http://www.amirifont.org/fatiha-colored.html
> > 
> > No special markup have been used, the color information is embedded
> > in a regular OpenType font.
> 
> Very nice!  It als works with Firefox on my GNU/Linux box.

I think I worded this vaguely, it works with Firefox on all platforms
(even on Android), the Windows 10 restriction is for Internet Expoler
only.

Regards,
Khaled

Re: Coloured Punctuation and Annotation

[Werner LEMBERG]

> This page should show colored Hamza, diacritical dots and vowel
> marks on web browsers that support MS color font format (currently
> Firefox, Edge, and Internet Expoler on latest Windows 10):
> http://www.amirifont.org/fatiha-colored.html
> 
> No special markup have been used, the color information is embedded
> in a regular OpenType font.

Very nice!  It als works with Firefox on my GNU/Linux box.


Werner

Re: Proposal to add standardized variation sequences for chess notation

[Christoph Päper]

Michael Everson :
> 
> Standardized variation sequences are the best way to achieve this simply and
> without needless duplication. :-)

I still agree with this assertion.

> > The distinction between white/black background might be of a different
> > nature. If you have arranged everything in a grid with the correct matrix,
> > then the color of the background is perhaps redundant, given that there is a
> > uniform convention for it.
> 
> Yes but you still want it to be reasonably legible when the OpenType ligatures
> fail.

This is were I don't follow.

> ▗▖
> ▕□︀▨︁□︀▨︁□︀▨︁♞︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁♔︀▨︁□︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏
> ▕□︀▨︁□︀▨︁♚︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁□︀♙︁♛︀▨︁□︀▨︁▏
> ▕▨︁□︀♕︁□︀▨︁♖︀▨︁□︀▏
> ▝▘
> is far better than this:
> ▗▖
> ▕□︀□︀□︀□︀□︀□︀♞︀□︀▏
> ▕□︀□︀□︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀♔︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀□︀□︀□︀♘︀□︀□︀▏
> ▕□︀□︀□︀□︀♚︀□︀□︀□︀▏
> ▕□︀□︀□︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀□︀♙︁♛︀□︀□︀□︀▏<< Is it the pawn or the queen that’s on the black square?
> ▕□︀□︀♕︁□︀□︀♖︀□︀□︀▏
> ▝▘

It *looks* far better in a multi-line plain text environment, but that's a
glyphic/typographic/stylistic argument. The semantics conveyed are redundantly
encoded this way, so I wouldn't say it was far better. This alternating pattern
is far more redundant than, say, pairs of opening and closing characters
(brackets, quotation marks).

Aside, good fallback isn't something the UTC seems to be concerned with lately,
see emoji subregion flags that are all represented by Waving Black Flag in
legacy implementations (possibly followed by TOFU).

> See? To parse this one you have to remember which of the white squares are the
> alternating black ones.

No, you only have to remember that A1, i.e. the lower left square initially
occupied by a white rook, is black. For legal moves, the color pattern hardly
matters, unless - regarding pawns - it was common practice to render the board
turned, i.e. with the white player not at the bottom, but at the top (or left or
right) side, and without alphabetic column and numeric row labels. 

> The colour of the matrix is NOT redundant for a human reader.

That's what this proposal is all about. It's a good and sound proposal, except
for the empty square.

Re: Coloured Punctuation and Annotation

[Khaled Hosny]

On Wed, Apr 05, 2017 at 05:29:57PM -0700, Asmus Freytag wrote:
> On 4/5/2017 5:14 PM, Michael Everson wrote:
> > > On 5 Apr 2017, at 23:16, Asmus Freytag  wrote:
> > > 
> > > Do you have any examples of plain text that is rendered with parts of 
> > > characters having white (opaque) background?
> > > 
> > > I'm not aware of any
> > There are certainly MSS (in many languages) where some punctuation made of 
> > dots have some of the dots red and some black.
> 
> Agreed, those would be a challenge to reproduce with standard font
> technology and in plain text.

Not any more, thanks to Emoji!

This page should show colored Hamza, diacritical dots and vowel marks on
web browsers that support MS color font format (currently Firefox, Edge,
and Internet Expoler on latest Windows 10):
http://www.amirifont.org/fatiha-colored.html

No special markup have been used, the color information is embedded in
a regular OpenType font.

Regards,
Khaled

Re: PETSCII mapping?

[Alastair Houghton]

On 6 Apr 2017, at 08:25, Elias Mårtenson  wrote:
> 
> Wouldn't it make sense to get in touch with active Commodore 64 communities 
> to find out how people deal with this today? I'm sure there are use cases 
> that none of us have thought about.

Since most of the issue is graphics characters, and since that same problem 
affects PETSCII, ATASCII, the ZX80 set, and Teletext/Videotex/Viewdata (aka BBC 
Micro mode 7), would it be better to come up with a complete set of extra 
graphic characters that need to be encoded, and make it a proposal to “complete 
the set” of box drawing and graphics characters?  IMO the Teletext set is 
*much* more important than PETSCII or ATASCII; while there will very likely be 
text encoded in the latter two, there are significant volumes encoded in the 
Teletext set.  Quite a bit of data has already been lost (there are mirrors of 
old Prestel/Viewdata BBS systems, some of which have sadly lost all the 
graphics because of the lack of equivalent Unicode characters), and a lot of 
the rest is either encoded in a non-standard encoding or held as screen shots.

Also, it would be worth looking to see if there are any discussions from past 
attempts to get any of these things into the Unicode standard; I can’t imagine 
this is the first time anyone’s asked for more graphics characters.

Kind regards,

Alastair.

--
http://alastairs-place.net

Re: PETSCII mapping?

[Elias Mårtenson]

Wouldn't it make sense to get in touch with active Commodore 64 communities
to find out how people deal with this today? I'm sure there are use cases
that none of us have thought about.

Regards,
Elias

On 6 April 2017 at 15:19, Rebecca Bettencourt  wrote:

> I've completed my unified chart:
>
> https://docs.google.com/document/d/10RJKTNFZFEww0yRVPzPdeNnyC_
> PUkAMhn7OVB7YdTFc/edit?usp=sharing
>
> The result is either 20 or 24 characters to be encoded, depending on
> whether or not 4 of them should be unified with existing characters.
>
> 14 have fairly obvious names following a pattern established by existing
> characters:
>
> Left and Lower One Eighth Block
> Left and Upper One Eighth Block
> Right and Upper One Eighth Block
> Right and Lower One Eighth Block
> Left Half Medium Shade
> Lower Half Medium Shade
> Right One Quarter Block
> Right Three Eighths Block
> Upper One Quarter Block
> Upper Three Eighths Block
> Four-by-Four Checker Board
> Reverse Four-by-Four Checker Board
> Upper Left to Lower Right Fill
> Upper Right to Lower Left Fill
>
> 10 need some more thinking (they are all horizontal and vertical lines at
> various positions within the character cell; naming depends on if we want
> to unify some of them with the HORIZONTAL SCAN LINEs in the Miscellaneous
> Technical block).
>
>
>
>
>
>
>
> -- Rebecca Bettencourt
>
> On Wed, Apr 5, 2017 at 10:24 PM, Elias Mårtenson 
> wrote:
>
>> On 6 April 2017 at 11:32, Rebecca Bettencourt 
>> wrote:
>>
>> We do have to provide Unicode with fonts, I believe. We can use an
>>> existing C64 font, such as Pet Me. Or, we can create a new font with
>>> vectorized versions of the characters.
>>>
>>
>> Are there any existing C64 fonts with vectorised glyphs?
>>
>>
>>>  Then there is the issue of what to do with the text colour and style
>>> selectors. PETSCII has characters that indicate a colour change as well as
>>> reverse video. At least the reverse video one is important, as it's being
>>> used to construct new characters. For example, PETSCII only has a single
>>> character "half block" (top part filled). The way you represent a half
>>> block with the bottom part filled is to use the reverse video together with
>>> the former.
>>>

 It would probably make more sense to represent the reversed symbols as
 separate code points?

>>>
>>> I would actually leave the color-change and reverse-video characters to
>>> a higher-level protocol.
>>>
>>
>> For colour change, I definitely agree. The reverse video case is a bit
>> different since the resulting characters are very much separate symbols by
>> themselves.
>>
>> I think I need to take a closer look at existing C64 textual content to
>> see how it was actually being used in real life. I do recall that reverse
>> video was heavily used in file names, so there is definitely an argument
>> for introducing “COMBINING PETSCII REVERSE VIDEO”. It would be unfortunate
>> if higher-level markup is required to accurately represent the name of a
>> file stored on a C64 floppy disc.
>>
>> Regards,
>> Elias
>>
>
>

Re: Standaridized variation sequences for the Desert alphabet?

[David Starner]

On Thu, Apr 6, 2017 at 12:07 AM Martin J. Dürst 
wrote:

> And while we currently have no evidence that Deseret had developed a
> typographic tradition where some type styles would use one set of
> ligatures, and other styles would use another set, it wouldn't be
> possible to reject this possibility without actually trying to find
> evidence one way or another.
>

Deseret didn't really develop a typographic tradition at all. To quote
Wikipedia:

 At least four books were published in the new alphabet, all transcribed by
Orson Pratt and all using the Russell's House font: The First Deseret
Alphabet Reader (1868), The Second Deseret Alphabet Reader (1868), The Book
of Mormon (1869), and a Book of Mormon excerpt called First Nephi–Omni
(1869).

There's also a couple years where the Deseret News printed a short piece in
the Deseret alphabet in every issue, but in any case, these new glyphs
never had a metal type made for them and never saw print until modern times.

Re: PETSCII mapping?

[Rebecca Bettencourt]

I've completed my unified chart:

https://docs.google.com/document/d/10RJKTNFZFEww0yRVPzPdeNnyC_PUkAMhn7OVB7YdTFc/edit?usp=sharing

The result is either 20 or 24 characters to be encoded, depending on
whether or not 4 of them should be unified with existing characters.

14 have fairly obvious names following a pattern established by existing
characters:

Left and Lower One Eighth Block
Left and Upper One Eighth Block
Right and Upper One Eighth Block
Right and Lower One Eighth Block
Left Half Medium Shade
Lower Half Medium Shade
Right One Quarter Block
Right Three Eighths Block
Upper One Quarter Block
Upper Three Eighths Block
Four-by-Four Checker Board
Reverse Four-by-Four Checker Board
Upper Left to Lower Right Fill
Upper Right to Lower Left Fill

10 need some more thinking (they are all horizontal and vertical lines at
various positions within the character cell; naming depends on if we want
to unify some of them with the HORIZONTAL SCAN LINEs in the Miscellaneous
Technical block).







-- Rebecca Bettencourt

On Wed, Apr 5, 2017 at 10:24 PM, Elias Mårtenson  wrote:

> On 6 April 2017 at 11:32, Rebecca Bettencourt  wrote:
>
> We do have to provide Unicode with fonts, I believe. We can use an
>> existing C64 font, such as Pet Me. Or, we can create a new font with
>> vectorized versions of the characters.
>>
>
> Are there any existing C64 fonts with vectorised glyphs?
>
>
>>  Then there is the issue of what to do with the text colour and style
>> selectors. PETSCII has characters that indicate a colour change as well as
>> reverse video. At least the reverse video one is important, as it's being
>> used to construct new characters. For example, PETSCII only has a single
>> character "half block" (top part filled). The way you represent a half
>> block with the bottom part filled is to use the reverse video together with
>> the former.
>>
>>>
>>> It would probably make more sense to represent the reversed symbols as
>>> separate code points?
>>>
>>
>> I would actually leave the color-change and reverse-video characters to a
>> higher-level protocol.
>>
>
> For colour change, I definitely agree. The reverse video case is a bit
> different since the resulting characters are very much separate symbols by
> themselves.
>
> I think I need to take a closer look at existing C64 textual content to
> see how it was actually being used in real life. I do recall that reverse
> video was heavily used in file names, so there is definitely an argument
> for introducing “COMBINING PETSCII REVERSE VIDEO”. It would be unfortunate
> if higher-level markup is required to accurately represent the name of a
> file stored on a C64 floppy disc.
>
> Regards,
> Elias
>

Re: Standaridized variation sequences for the Desert alphabet?

[Martin J. Dürst]

Hello Michael,

[I started to write this mail quite some time ago. I decided to try to 
let things cool down a bit by waiting a day or two, but it has become 
more than a week now.]


On 2017/03/29 22:08, Michael Everson wrote:

Martin,

It’s as though you’d not participated in this work for many years, really.


Well, looking back, my time commitment to Unicode has definitely varied 
over the years. But that might be true for everybody.


What's more important is that Unicode covers such a wide range of areas, 
and not everybody has the same experience or knowledge. If we did, we 
wouldn't need to work together; it would be okay to just have one of us. 
Indeed, what's really very valuable and interesting in this work is the 
many very varied backgrounds and experiences everybody has.


In addition to variations in background, we also have a wide variety of 
ways of thinking, e.g. ranging from abstract to concrete, and so on.




On 29 Mar 2017, at 11:12, Martin J. Dürst  wrote:



- That suggests that IF this script is in current use,


You don’t even know? You’re kidding, right?


Everything is relative. And without being part of the user community, 
it's difficult to make any guesses.




- As far as we have heard (in the course of the discussion, after questioning 
claims made without such information), it seems that:


Yeah, it doesn’t “seem” anything but a whole lot of special pleading to bolster 
your rigid view that the glyphs in question can be interchangeable because of 
the sounds they may represent.


I don't remember every claiming that the glyphs must be used 
interchangeably, only that we should carefully examine whether they are 
or not, and that because they represent the same sound (in a phonetic 
alphabet, as it is) and are shown in the same position in alphabet 
tables, we shouldn't a priori exclude such a possibility.




 - There may not be enough information to understand how the creators and early 
users of the script saw this issue,


Um, yeah. As if there were for Phoenician, or Luwian hieroglyphs, right?


Well, there's well over an order of magnitude difference in the time 
scales involved. The language that Deseret is used to write is still in 
active use, including in this very discussion. Quite different from 
Phoenician or Luwian hieroglyphs.


In addition, we have meta-information such as alphabet tables, which we 
may not have for the scripts you mention, as well as the fact that 
printing technology may have forced a better identification of what's a 
character and what not than inscriptions and other older technologies.




 - Similarly, there seem to be not enough modern practitioners of the script 
using the ligatures that could shed any light on the question asked in the 
previous item in a historical context,


Completely irrelevant. Nobody worried about the number of modern users of the 
Insular letters we encoded. Why put such a constraints on users of Deseret? Ꝺꝺ 
Ꝼꝼ Ᵹᵹ Ꝿ Ꞃꞃ Ꞅꞅ Ꞇꞇ.


Because it's modern users, and future users, not users some hundred 
years or so ago, that will use the encoding. In the case of Insular 
letters, my guess is that nobody wants to translate/transcribe xkcd, for 
example, whereas there is such a transcription for Deseret:

http://www.deseretalphabet.info/XKCD/


first apparently because there are not that many modern practitioners at all, 
and second because modern practitioners seem to prefer spelling with individual 
letters rather than using the ligatures.


This is equally ridiculous. John Jenkins chooses not write the digraphs in the 
works which he transcribed, because that’s what *he* chooses. He doesn’t speak 
for anyone else who may choose to write in Deseret, and your assumption that 
“modern practitioners” do this is groundless.


You wrote:



Most readers and writers of Deseret today use the shapes that are in 
their fonts, which are those in the Unicode charts, and most texts 
published today don’t use the EW and OI ligatures at all, because that’s 
John Jenkins’ editorial practice.




So I was wrong to write "modern practitioners", and should have written 
"modern publishers" or "modern published texts". Or is the impression 
that I get from what you wrote above wrong that most texts published 
these days are edited by John, or by people following his practice?




It also ignores the fact that the script had a reform and that the value of 
separate encodings for the various characters is of value to those studying the 
provenance and orthographic practices of those who wrote Deseret when it was in 
active use.


I don't remember denying the value of separate encodings for historic 
research. I only wanted to make sure that present-day use isn't 
inconvenienced to make historic research easier. If the claims are 
correct that present-day usage is mostly a reconstruction based on the 
Unicode encoding and the Unicode sample glyphs, then I'm fine with 
helping historic research.



This is