414294 - ∥ (U+2225 PARALLEL TO) does not extend correctly

Status: RESOLVED FIXED

(Core :: MathML, defect)

Description

[distler]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008012701 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008012701 SeaMonkey/2.0a1pre

With latest nightly and the STIX fonts installed, the wrong glyph is used to stretch ∥ (∥)

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[distler]

Attachment: Test case

Comment 2

[distler]

Attachment: As rendered by latest nightly

Comment 3

[Karl Tomlinson (:karlt)]

U+2225 is meant to be represented by vertical lines it seems:
http://www.unicode.org/reports/tr25/tr25-9.html#_TocDelimiters

but a number of fonts on Mac provide glyphs with slanted lines:

AppleGothic.dfont
Hei.dfont
Haragino
STHeiti
#Gungseouche.dfont
#PCmyoungjo.dfont
#Pilgiche.dfont
AppleMyungjo.dfont
Kai.dfont
STFangSong
STSong
STKaiti

The following fonts have glyphs with vertical lines:

Apple LiGothic Medium.dfont
Osaka.dfont
LiHei Pro
Apple LiSung Light.dfont
Apple Symbols.ttf
BiauKai.dfont
LiSong Pro

The glyph from STIXGeneral should be used if the fonts are installed and STIXGeneral is in the "font.mathfont-family" preference.

But we should include Apple Symbols in the default "font.mathfont-family" preference, if the font fallback system is not necessarily going to choose a good font.

Comment 4

[Karl Tomlinson (:karlt)]

BTW, note that U+2225 PARALLEL TO is a binary operator
http://www.unicode.org/reports/tr25/tr25-9.html#_TocDelimiters

The appropriate character for fences it seems is U+2016 DOUBLE VERTICAL LINE.
The entity names corresponding to this character (Verbar and Vert, distinguished from single vertical line by the capital V) are not so helpful, so I'd suggest just using "‖".

This character may give better spacing (but I haven't tested).

Comment 5

[distler]

This is another case where resetting "font.mathfont-family" to the default value (instead of whatever was imported from the previous version) fixes the problem.

Good point about U+2016 versus U+2225, though...

Comment 6

[Karl Tomlinson (:karlt)]

I'd like this to render correctly even without STIX fonts installed.

Comment 7

[Karl Tomlinson (:karlt)]

Attachment: specify Apple Symbols in font-family

Comment 8

[Karl Tomlinson (:karlt)]

We should fix this up as it is visible on the MathML project start page:
http://www.mozilla.org/projects/mathml/start.xhtml
(and it is easy to fix).

Comment 9

[John Daggett (:jtd)]

Attachment: screenshot, comparison of double vertical line (2016) to parallel line op (2225)

I don't quite see a real use case for a stretch use of the parallel line op.  Some fonts seem to render the parallel line op as slanted lines.  A bit odd but I'm not sure I see that explicitly incorrect.

Comment 10

[John Daggett (:jtd)]

Example of Japanese junior-high geometry explanation:

http://www2.edu.ipa.go.jp/gz/e1math/e1hego/e1heg1/IPA-mat100.htm

Note the use of slanted line glyphs for the parallel-to op.

Comment 11

[Karl Tomlinson (:karlt)]

I'll remove the blocking request because the correct fix for the start page is to change the character there to U+2016 DOUBLE VERTICAL LINE.

Regarding the angle of U+2225 PARALLEL TO:

http://www.unicode.org/reports/tr25/tr25-9.html#_TocDelimiters
lists PARALLEL TO under "There are two series of characters that consist of one or more vertical lines and which have specific use in mathematics", and the reference glyphs use vertical lines (http://www.unicode.org/charts/PDF/U2200.pdf), and the entity is called "DoubleVerticalBar".

But there do seem to be examples of two U+002F SOLIDUS symbols being used to mean "is parallel to".
http://searchdatacenter.techtarget.com/sDefinition/0,,sid80_gci803019,00.html

Regarding the stretchiness:

http://www.unicode.org/reports/tr25/tr25-9.html#_TocDelimiters says "They too should be able to get taller if the elements they're between happen to be something like fractions".

But the non-normative MathML suggested operator dictionary lists ∥ (U+2225) without the stretchy attribute.
http://www.w3.org/TR/2003/REC-MathML2-20031021/appendixf.html

So another way to fix this bug is to change our operator dictionary to match that suggested in the spec.  (That's hoping not too many places have copied the start page or rely on that behavior.)

Comment 12

[Karl Tomlinson (:karlt)]

Note that MathWorld uses vertical lines, but they are not as tall as the operands.

http://mathworld.wolfram.com/Parallel.html

Comment 13

[Karl Tomlinson (:karlt)]

(In reply to comment #11)
> I'll remove the blocking request because the correct fix for the start page is
> to change the character there to U+2016 DOUBLE VERTICAL LINE.

Done.

Comment 14

[Karl Tomlinson (:karlt)]

Attachment: make infix parallel to non-stretchy

This removes the stretchiness of U+2225 PARALLEL TO when used as an infix
operator, which makes its treatment consistent with the non-normative MathML
suggested operator dictionary:

"∥" form="infix" lspace="thickmathspace" rspace="thickmathspace"

UTR #25 says "they always occur between two elements".  My intention is to
leave the prefix and postfix operator entries with stretchy:vertical in case
some people are using them as fences.

However, the prefix and postfix forms don't seem to be getting picked up from
the operator dictionary, so I'll need to look into that.

Comment 15

[Frédéric Wang (:fredw)]

> However, the prefix and postfix forms don't seem to be getting picked up from
> the operator dictionary, so I'll need to look into that.

Karl, can you try with attachment 415005 [details] [diff] [review] and something like
<mrow><mo>&DoubleVerticalBar;</mo><mi>v</mi><mo>&DoubleVerticalBar;</mo></mrow> ?

BTW, we are likely to have a similar issue with

operator.\u2223.infix (divides)
operator.\u2216.infix (set minus)
operator.\u002F.infix (solidus)

(non stretchy per MathML 3)

and 

operator.\u2044.infix (fraction slash)
operator.\u2215.infix (division slash)

(new stretchy entries)

Comment 16

[Frédéric Wang (:fredw)]

> UTR #25 says "they always occur between two elements".  My intention is to
> leave the prefix and postfix operator entries with stretchy:vertical in case
> some people are using them as fences.

In MathML3, the prefix and postfix forms are removed for u+2225.
The infix form is no longer stretchy.

operator.\u2225.infix = lspace:5 rspace:5 direction:vertical # parallel to

I suggest updating the operator dictionary with these properties for "parallel to", since the operator supposed to be used for fences is U+2016 DOUBLE VERTICAL LINE

Comment 17

[Frédéric Wang (:fredw)]

(In reply to comment #7)
> Created attachment 313998 [details] [diff] [review]
> specify Apple Symbols in font-family

BTW, do we still want this patch?

Comment 18

[Karl Tomlinson (:karlt)]

(In reply to comment #17)
> > specify Apple Symbols in font-family
> 
> BTW, do we still want this patch?

I don't know.  Let's leave it for now unless we find a new reason to add Apple Symbols.

Comment 19

[Karl Tomlinson (:karlt)]

(In reply to comment #16)
> In MathML3, the prefix and postfix forms are removed for u+2225.
> The infix form is no longer stretchy.
> 
> operator.\u2225.infix = lspace:5 rspace:5 direction:vertical # parallel to
> 
> I suggest updating the operator dictionary with these properties for "parallel
> to", since the operator supposed to be used for fences is U+2016 DOUBLE
> VERTICAL LINE

Dropping stretchy from 2225.infix sounds good to me.

Is there a good reason to remove the prefix and postfix forms?

AFAIK there isn't a good use can for the operator to be in a prefix or postfix position, but, if it is in that position, then treating as a fence is probably what the author intended.  I don't feel strongly about it though.

Comment 20

[Frédéric Wang (:fredw)]

> Dropping stretchy from 2225.infix sounds good to me.

I'll attach a patch for this and for some other entries which were not dealt with in bug 534970.

> 
> Is there a good reason to remove the prefix and postfix forms?
> 
> AFAIK there isn't a good use can for the operator to be in a prefix or postfix
> position, but, if it is in that position, then treating as a fence is probably
> what the author intended.  I don't feel strongly about it though.

OK, we can keep the obsolete entries for this case.
I guess the form should be detected correctly now, at least for markup such that the one in comment 15, and this should allow to resolve this bug.

Comment 21

[Frédéric Wang (:fredw)]

Attachment: fix conflicts and add entries for bars and quadruple arrows

Comment 22

[Karl Tomlinson (:karlt)]

Comment on attachment 526295 [details] [diff] [review]
fix conflicts and add entries for bars and quadruple arrows

http://www.w3.org/ is not responding right now, so I have to try again later.

>+operator.\u2044.infix = lspace:4 rspace:4 stretchy # fraction slash

>+operator.\u2215.infix = lspace:4 rspace:4 stretchy # division slash

Remind me please what the default value for "direction" means.
I wonder whether it would make sense to state this explicitly.

Comment 23

[Frédéric Wang (:fredw)]

> >+operator.\u2044.infix = lspace:4 rspace:4 stretchy # fraction slash
> 
> >+operator.\u2215.infix = lspace:4 rspace:4 stretchy # division slash
> 
> Remind me please what the default value for "direction" means.
> I wonder whether it would make sense to state this explicitly.

I think we wanted it to mean "both directions" at some point, but I don't believe it is implemented. For those operators it is a mistake, I should explicitly add direction:vertical

Comment 24

[Karl Tomlinson (:karlt)]

Comment on attachment 526295 [details] [diff] [review]
fix conflicts and add entries for bars and quadruple arrows

These all look right, but the one change I'm concerned about is the removal of stretchy from operator.\u005F.infix low line.

I don't know whether or not we correctly use the postfix form when the operator is in the script position of an munder or mover but I doubt we get the right postfix form for the (middle sibling) underscript of munderover.

I can't think of much harm that would come from leaving the default horizontal stretchy behaviour for \u005F.infix, so it seems best to leave that at this stage.

Comment 25

[Frédéric Wang (:fredw)]

Attachment: fix conflicts and add entries for bars and quadruple arrows (V2)

OK, let's leave the stretchiness of \u005F.infix for now.

Comment 26

[Boris Zbarsky [:bzbarsky]]

The attachment from comment 25 doesn't seem to apply on trunk....

Comment 27

[Frédéric Wang (:fredw)]

Attachment: fix conflicts and add entries for bars and quadruple arrows (V3)

Comment 28

[Frédéric Wang (:fredw)]

(In reply to comment #26)
> The attachment from comment 25 doesn't seem to apply on trunk....

Yes, sorry I forgot that I have a patch in my mercurial queues adding the "mirrorable" property for mathematical operators.

Comment 29

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/projects/cedar/rev/6b33a2e653ca

Frédéric, should the bug be assigned to you?

Comment 30

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/mozilla-central/rev/6b33a2e653ca