setminus vs. smallsetminus

[Will Robertson]

Hi Barbara et al.,

The issue of "U+2216 SET MINUS" vs "U+29F5 REVERSE SOLIDUS OPERATOR" has come up again:

http://github.com/wspr/unicode-math/issues/181

To summarise, this is TeX:

[Barbara Beeton]

hi, will,

The issue of "U+2216 SET MINUS" vs "U+29F5 REVERSE SOLIDUS OPERATOR"
has come up again:

http://github.com/wspr/unicode-math/issues/181

[...]

i'm out of town, and don't have access to
my records. i really have to research this,
as it was also a matter for considerable
discussion at the utc. i'll be back in the
office after may 24, and will follow up then.

thanks for the references to check.
-- bb

[David Carlisle]

mathml , the xml entity spec, and html5  make setminus and smallsetminus  be the same thing (2216)
possibly because we didn't notice 29f5 when it was added, or possibly consciously,. I can't remember.

It's probably best not to (ever) change (any) entity definitions so probably we are stuck with the mathml/html definitions as they are so this is probably something that could be mentioned in documentation somewhere....

the sample unicode pdf charts show 29f5 as taller and steeper than 2216. and in particular there is a strong implication that 29f5 should match 29f6 and 29f7 in size/slope.



David

And this is STIX and Cambria:




(My Cambria Math is old -- hence the missing glyph -- but I believe it's still the same design now.)

What makes this argument difficult is that it's not clear what Unicode means by "reverse solidus operator".

As pointed out by Aditya, the current STIX mapping (inherited by unicode-math) is

0x2216 -> \smallsetminus
0x29F5 -> \setminus

Looking at what's shown above, I think we can start with the following assumption:

*  \setminus and Unicode's SET MINUS should be the same glyph -- the large one

Therefore, it seems sensible that the choice made by STIX is backwards (and Cambria is "correct"): U+2216 should be the large one, and \setminus should map to it.

I believe that ConTeXt currently patches the STIX fonts when they're loaded to swap these troublesome glyphs. I'd like to fix this upstream so this isn't necessary.

-- Will


--
You received this message because you are subscribed to the Google Groups "Unicode maths for TeX" group: <http://groups.google.com/group/unimath>. To post to this group, send email to <uni...@googlegroups.com>.

--
http://dpcarlisle.blogspot.com/

[Will Robertson]

On 15/05/2011, at 11:33 PM, David Carlisle wrote:

> mathml , the xml entity spec, and html5 make setminus and smallsetminus be the same thing (2216)
> possibly because we didn't notice 29f5 when it was added, or possibly consciously,. I can't remember.

This leaves open the possibility that \setminus vs \smallsetminus should be considered only stylistic variations that could be handled by an OpenType feature.

> It's probably best not to (ever) change (any) entity definitions so probably we are stuck with the mathml/html definitions as they are so this is probably something that could be mentioned in documentation somewhere....

I tend to agree. Also, whose/which documentation?

In that case if \smallsetminus is declared to *not* be a stylistic variation on \setminus (i.e., if they are to be used independently in the same source material) I'd suggest adding a new glyph to Unicode and a new entity for mathml/html.

> the sample unicode pdf charts show 29f5 as taller and steeper than 2216. and in particular there is a strong implication that 29f5 should match 29f6 and 29f7 in size/slope.

Not to mention 2afd double solidus operator et al. ... oh. would you look at that:

FE68 - SMALL REVERSE SOLIDUS

So I guess there's our \smallsetminus ? It seems to be included generally in Asian fonts but it appears to have some sort of mathematical aspect to it:

• Unicode 1.0 Name: SMALL BACKSLASH
• Extended Properties:
Other_Math
• Derived Core Properties:
Math
Grapheme_Base
• Script: Common
• Block: Small Form Variants

(I'm no expert in how these are supposed to be interpreted.)

It might seem crazy but the most coherent suggestion (for Unicode math and a TeX based interface for it) I can see right now is:

* unify 2216 and 29f5 as already done in mathml/html
* use fe68 for \smallsetminus
* move the glyphs around in STIX to reflect this

-- Will

[David Carlisle]

Will wrote

* unify 2216 and 29f5 as already done in mathml/html

It's probably what you meant, but mathml/html don't unify those code points (they would be considered different operators as far as mathml ever considers anything) but what it does do is unify the named entities setminus and smalsetminus (unifying them both as 2216)

David

[Barbara Beeton]

On Sun, 15 May 2011, Will Robertson wrote:

On 15/05/2011, at 11:33 PM, David Carlisle wrote:

> mathml , the xml entity spec, and html5 make setminus and smallsetminus be the same thing (2216)
> possibly because we didn't notice 29f5 when it was added, or possibly consciously,. I can't remember.

This leaves open the possibility that \setminus vs \smallsetminus should be considered only stylistic variations that could be handled by an OpenType feature.

please wait until i can check the records
before deciding anything.

> It's probably best not to (ever) change (any) entity definitions so probably we are stuck with the mathml/html definitions as they are so this is probably something that could be mentioned in documentation somewhere....

I tend to agree. Also, whose/which documentation?

In that case if \smallsetminus is declared to *not* be a stylistic variation on \setminus (i.e., if they are to be used independently in the same source material) I'd suggest adding a new glyph to Unicode and a new entity for mathml/html.

unicode has already added the "second" glyph.
they won't add another without published
evidence that there is really a third one.

> the sample unicode pdf charts show 29f5 as taller and steeper than 2216. and in particular there is a strong implication that 29f5 should match 29f6 and 29f7 in size/slope.

Not to mention 2afd double solidus operator et al. ... oh. would you look at that:

FE68 - SMALL REVERSE SOLIDUS

So I guess there's our \smallsetminus ? It seems to be included generally in Asian fonts but it appears to have some sort of mathematical aspect to it:

i can tell yiou without checking anything that
FE68 is *not* the \smallsetminus. the
set minus has a 45 degree slope; backslash has
a different slope. also, the asian blocks in
unicode are *not* to be used for "regular"
math. please don't even think of going there.
i can give more detail when i (1) have access
to my records of utc discussions, and (2) am
connected to a real, reliable internet link.

? Unicode 1.0 Name: SMALL BACKSLASH
? Extended Properties:
Other_Math
? Derived Core Properties:
Math
Grapheme_Base
? Script: Common
? Block: Small Form Variants

(I'm no expert in how these are supposed to be interpreted.)

It might seem crazy but the most coherent suggestion (for Unicode math and a TeX based interface for it) I can see right now is:

* unify 2216 and 29f5 as already done in mathml/html

this negates some pretty hard bargaining
with the utc.

* use fe68 for \smallsetminus

no, please. i'll go through this in more
detail when i'm not on an isolated island.

* move the glyphs around in STIX to reflect this

i'm not totally opposed to this, but i
really need to see what has gone before.

please be patient.
-- Will

-- bb

[Will Robertson]

(Sent quickly. Please excuse brevity.)

On 16/05/2011, at 7:29 AM, Barbara Beeton <b...@ams.org> wrote:

> i can tell yiou without checking anything that
> FE68 is *not* the \smallsetminus.

Okay, that's good to know :-)

> i can give more detail when i (1) have access
> to my records of utc discussions, and (2) am
> connected to a real, reliable internet link.

No problem -- i was merely idly speculating. Nothing has shifted into motion.

Many thanks,
Will

[David Carlisle]

setminus and smallsetminus in MathMLs past and present.....

mathml1: setminus is 2216, smallsetminus is a PUA character E844

http://www.w3.org/TR/REC-MathML/chap6/byalpha.html


mathml2 1st edn somewhat speculatively proposed the small variant to be accesed via the variant selector character

  U02216-0FE00

http://www.w3.org/TR/2001/REC-MathML2-20010221/byalpha.html


mathml2 2nd edition they both use 2216
http://www.w3.org/TR/2003/REC-MathML2-20031021/byalpha.html
(there was a conscious effort here to only use VS1 in ways listed in Unicode Tr 25)


mathml3 follows mathml2 2nd ed

html5 follows mathml3.


So what I think happened, from the mathml side of things at least, is that compatibility reasons meant we didn't want to change setminus from 2216, but when a new character was added, it was larger rather than smaller than 2216 so we couldn't use that for smallsetminus so (as in several other cases) just gave up on the variant and used  both names (and the iso names setmn and ssetmn)  for the same character,

entity names are anyway somewhat deprecated in mathml, so the recommendation is always to access the character data or numeric reference directly so #2216 or #29f5 depending what the user wants. Both characters appear in the mathml3 operator dictionary, but only the former has any entity name associated.

Of course this just punted the problem of what glyphs to use and what names to use in other interfaces to someone else:-)

David
--
http://dpcarlisle.blogspot.com/