On Sun, Oct 9, 2016 at 4:03 AM Mark Davis ☕️ wrote:
> Essentially all of the game pieces that are in Unicode were added for
> compatibility with existing character sets. I'm guessing that there are
> hundreds to thousands of possible other symbols associated with games in
> one way or another,
On Sun, 9 Oct 2016 13:00:30 +0200, Mark Davis ☕️ wrote:
[…]
>
> I would recommend that any proposal for additional game symbols provide
> clear evidence for why those particular game symbols are required to be
> exchanged in plain text, in a way that many, many other possible game
> symbols are n
> On 9 Oct 2016, at 13:00, Mark Davis ☕️ wrote:
>
> Essentially all of the game pieces that are in Unicode were added for
> compatibility with existing character sets. I'm guessing that there are
> hundreds to thousands of possible other symbols associated with games in one
> way or another
Essentially all of the game pieces that are in Unicode were added for
compatibility with existing character sets. I'm guessing that there are
hundreds to thousands of possible other symbols associated with games in
one way or another, or that could be dug out of instruction manuals (eg,
http://ww
On Sat, Oct 8, 2016 at 9:31 AM, Philippe Verdy wrote:
> Markup for rotation is highly underdeveloped, and in this case for chess
> it has its own semantics, it's not just a presentation feature, possibly
> meant for playing on larger boards with more players than 2, and
> distinguished just like
Markup for rotation is highly underdeveloped, and in this case for chess it
has its own semantics, it's not just a presentation feature, possibly meant
for playing on larger boards with more players than 2, and distinguished
just like there's a distinction between white and black, or meant to signa
Looking at the image, the idea of the proposal is to include chess piece
symbols in all four 90° rotations? Wouldn't it be better to do this in
markup than in Unicode? I fear a combinatorial explosion if Unicode starts
including all the possible orientations of characters. (Maybe there's a
good rea
Sorry about the blank reply. Itchy trigger finger.
On Thu, Oct 6, 2016 at 2:28 PM, Ken Whistler wrote:
>
> On 10/6/2016 12:44 PM, Garth Wallace wrote:
>
> Some representatives of the WFCC have proposed alternate arrangements that
> assume there will be a need for bitwise operations to covert bet
On Thu, Oct 6, 2016 at 2:28 PM, Ken Whistler wrote:
>
> On 10/6/2016 12:44 PM, Garth Wallace wrote:
>
> Some representatives of the WFCC have proposed alternate arrangements that
> assume there will be a need for bitwise operations to covert between the
> existing chess symbols in the Miscellaneo
Except that it states at the very start of that file "this file should not be
parsed for machine-readable information."
On Fri, Oct 7, 2016 at 6:41 PM, Andrew West wrote:
> On 7 October 2016 at 23:31, Doug Ewell wrote:
> >
> > Well, "treacherous" is right. I'd hesitate to trust an algorithm to
On 7 October 2016 at 23:31, Doug Ewell wrote:
>
> Well, "treacherous" is right. I'd hesitate to trust an algorithm to
> recognize PLANCK CONSTANT as the character name that logically fits
> between MATHEMATICAL ITALIC SMALL G and MATHEMATICAL ITALIC SMALL I.
Well, it could be picked up from that
Andrew West wrote:
> Well, it could be picked up from that most treacherous of Unicode data
> files http://www.unicode.org/Public/UNIDATA/NamesList.txt
Even then, you have:
...
1D454 MATHEMATICAL ITALIC SMALL G
# 0067 latin small letter g
1D455
x (planck constant - 210E)
1D
Richard Wordingham wrote:
>> I can't find anything in the UCD that distinguishes one "font
>> variant" from another (UnicodeData.txt shown as an example):
>
> It's in that most treacherous of properties, the character's name.
Well, "treacherous" is right. I'd hesitate to trust an algorithm to
rec
On Fri, 07 Oct 2016 09:06:31 -0700
"Doug Ewell" wrote:
> Richard Wordingham wrote:
> > Perhaps there is just enough information in the UCD to allow
> > exhaustive, automated tests.
> I can't find anything in the UCD that distinguishes one "font variant"
> from another (UnicodeData.txt shown as
> On 7 Oct 2016, at 18:06, Doug Ewell wrote:
> I can't find anything in the UCD that distinguishes one "font variant"
> from another (UnicodeData.txt shown as an example):
>
> 1D400;MATHEMATICAL BOLD CAPITAL A;Lu;0;L; 0041N;
> 1D434;MATHEMATICAL ITALIC CAPITAL A;Lu;0;L; 0041N;
>
Richard Wordingham wrote:
> Yes, it's a trade-off. The application I had in mind is converting
> between mathematical letter variants and their 'plain' forms.
Long-time list members might remember a Windows utility I wrote to
convert between normal Unicode text and Mathematical Alphanumeric
Symbo
> On 7 Oct 2016, at 09:27, Garth Wallace wrote:
>
> Unicode doesn't really address chess piece properties like white/black beyond
> naming conventions.
>From the formal point of view, Unicode only assigns character numbers (code
>points), which gets a binary representation first when encoded,
On Thu, Oct 6, 2016 at 5:42 PM, Shawn Steele
wrote:
> Presumably a table-based approach would merely require rerunning the
> table-building script from the UCD when new versions were released.
>
For casing, sure, but that's not really relevant in this context, since
Unicode doesn't really addres
On Thu, 6 Oct 2016 21:18:15 -0400
Oren Watson wrote:
> On Thu, Oct 6, 2016 at 8:28 PM, Richard Wordingham <
> richard.wording...@ntlworld.com> wrote:
> > Yes, it's a trade-off. The application I had in mind is converting
> > between mathematical letter variants and their 'plain' forms.
> > Perh
That application is hindered by the fact that
are unallocated
characters, forming gaps in the otherwise contiguous mathematical
alphabets.
On Thu, Oct 6, 2016 at 8:28 PM, Richard Wordingham <
richard.wording...@ntlworld.com> wrote:
> On Thu, 6 Oct 2016 16:54:21 -0700
> K
On Thu, 6 Oct 2016 16:54:21 -0700
Ken Whistler wrote:
> On 10/6/2016 4:32 PM, Richard Wordingham wrote:
> > The
> > problem is that manually constructed lookup tables are prone to
> > human error.
>
> ... as are manually constructed algorithms that attempt to take
> advantage of sub-ranges of c
On 10/6/2016 4:32 PM, Richard Wordingham wrote:
The
problem is that manually constructed lookup tables are prone to human
error.
... as are manually constructed algorithms that attempt to take
advantage of sub-ranges of case pair adjacency in the Unicode code
charts to do casing with bit ar
On Thu, 6 Oct 2016 12:44:05 -0700
Garth Wallace wrote:
> Other than converting between UTFs, is bit arithmetic commonly
> performed on Unicode characters? I was under the impression that it's
> a rarity if it is done at all.
It's possible to use it for the bulk of case folding, especially if the
On 10/6/2016 12:44 PM, Garth Wallace wrote:
Some representatives of the WFCC have proposed alternate arrangements
that assume there will be a need for bitwise operations to covert
between the existing chess symbols in the Miscellaneous Symbols block
and related symbols in the new block. I don'
As far as we know, arithmetic is performed only in
- subsets of decimal digits in ASCII and for a dozen of scripts and
converting automatically between them using a single additive constant for
the 10 digits.
- Basic Latin/ASCII for mapping lettercases and mapping non-decimal digits
(adding 6 start
On 10/6/2016 12:44 PM, Garth Wallace
wrote:
Other than converting between UTFs, is bit
arithmetic commonly performed on Unicode characters? I was under
the impression that it's a rarity if it is done at all.
I've been workin
Other than converting between UTFs, is bit arithmetic commonly performed on
Unicode characters? I was under the impression that it's a rarity if it is
done at all.
I've been working on a proposal for additional chess symbols used in chess
problems and variant games, and I've been in communication
27 matches
Mail list logo
