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

RESOLVED FIXED in mozilla6

Status

()

Core
MathML
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: distler, Assigned: fredw)

Tracking

Trunk
mozilla6
PowerPC
Mac OS X
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 3 obsolete attachments)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
Created attachment 299660 [details]
Test case
(Reporter)

Comment 2

9 years ago
Created attachment 299661 [details]
As rendered by latest nightly
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.
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).
(Reporter)

Comment 5

9 years ago
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...
(Reporter)

Updated

9 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
I'd like this to render correctly even without STIX fonts installed.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 313998 [details] [diff] [review]
specify Apple Symbols in font-family
Assignee: nobody → mozbugz
Status: NEW → ASSIGNED
Attachment #313998 - Flags: review?(jdaggett)
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).
Flags: blocking1.9?

Comment 9

9 years ago
Created attachment 314004 [details]
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

9 years ago
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.
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.)
Flags: blocking1.9?
Note that MathWorld uses vertical lines, but they are not as tall as the operands.

http://mathworld.wolfram.com/Parallel.html
Attachment #313998 - Flags: review?(jdaggett)
(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.
Created attachment 330189 [details] [diff] [review]
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.
Depends on: 534970
Summary: ∥ does not extend correctly → ∥ (U+2225 PARALLEL TO) does not extend correctly
(Assignee)

Comment 15

7 years ago
> 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)
(Assignee)

Comment 16

6 years ago
> 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
(Assignee)

Comment 17

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

BTW, do we still want this patch?
(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.
(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.
(Assignee)

Comment 20

6 years ago
> 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.
(Assignee)

Comment 21

6 years ago
Created attachment 526295 [details] [diff] [review]
fix conflicts and add entries for bars and quadruple arrows
Attachment #330189 - Attachment is obsolete: true
Attachment #526295 - Flags: review?(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.
(Assignee)

Comment 23

6 years ago
> >+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 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.
(Assignee)

Comment 25

6 years ago
Created attachment 528091 [details] [diff] [review]
fix conflicts and add entries for bars and quadruple arrows (V2)

OK, let's leave the stretchiness of \u005F.infix for now.
Attachment #526295 - Attachment is obsolete: true
Attachment #528091 - Flags: review?(karlt)
Attachment #526295 - Flags: review?(karlt)
Attachment #528091 - Flags: review?(karlt) → review+
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
Whiteboard: [please land attachment 528091]
The attachment from comment 25 doesn't seem to apply on trunk....
(Assignee)

Comment 27

6 years ago
Created attachment 529208 [details] [diff] [review]
fix conflicts and add entries for bars and quadruple arrows (V3)
Attachment #528091 - Attachment is obsolete: true
(Assignee)

Comment 28

6 years ago
(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.
Whiteboard: [please land attachment 528091] → [please land attachment 529208]
http://hg.mozilla.org/projects/cedar/rev/6b33a2e653ca

Frédéric, should the bug be assigned to you?
Flags: in-testsuite?
Keywords: checkin-needed
Whiteboard: [please land attachment 529208] → [fixed-in-cedar]
Assignee: karlt → fred.wang
http://hg.mozilla.org/mozilla-central/rev/6b33a2e653ca
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-cedar]
Target Milestone: --- → mozilla6
You need to log in before you can comment on or make changes to this bug.