Closed Bug 569195 Opened 14 years ago Closed 14 years ago

Add support for STIX Fonts 1.0

Categories

(Core :: MathML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a5
Tracking Status
status1.9.2 --- ?

People

(Reporter: fredw, Assigned: fredw)

References

Details

Attachments

(2 files, 3 obsolete files)

Attached patch STIXRelease (obsolete) — Splinter Review
STIX fonts have been released recently. Unfortunately, our support is broken because the names of STIXSize* fonts have changed. I attach a patch which is essentially just updating the names to match the release version. BTW, it also adds support for the STIXIntegrals* i.e. variants of slanted integral symbols. The documentation indicates that some Unicode code points have changed, but I've not checked yet if there are problems with that.

Note however, that the patch removes support for the Beta Version.
If we shipped both mathfontSTIXSize1.properties and mathfontSTIXSizeOneSym.properties, could we expect reasonable behavior with both only beta and only 1.0 fonts?
Attached patch Patch Beta+Release (obsolete) — Splinter Review
(In reply to comment #1)
> If we shipped both mathfontSTIXSize1.properties and
> mathfontSTIXSizeOneSym.properties, could we expect reasonable behavior with
> both only beta and only 1.0 fonts?

Yes, I think so. Here is a patch with duplicate *.properties files. Actually, there are not exactly the same: for some reason, the files STIXIntDis and STIXIntSma have the same name "STIXIntegrals" in the BETA version, so I'm not sure we can distinguish them (but I don't think it is too important...).
Assignee: nobody → fred.wang
Attachment #448516 - Flags: review?(karlt)
Comment on attachment 448516 [details] [diff] [review]
Patch Beta+Release

>+external.6 = STIXIntegrals

I'd feel more comfortable not using STIXIntegrals from the Beta fonts given that it could match any of 5 different fonts and results would likely differ on different systems.  I don't even know whether we can be certain that the font that is measured will be the font that is drawn.

>diff --git a/layout/mathml/mathfontSTIXSizeOneSym.properties b/layout/mathml/mathfontSTIXSizeOneSym.properties
>new file mode 100644
>--- /dev/null
>+++ b/layout/mathml/mathfontSTIXSizeOneSym.properties

Can you use
  hg cp --after mathfontSTIXSize1.properties mathfontSTIXSizeOneSym.properties
for this file, please?
(I guess you'll need "hg rm mathfontSTIXSizeOneSym.properties" first.)

>--- a/modules/libpref/src/init/all.js
>+++ b/modules/libpref/src/init/all.js

>-pref("font.mathfont-family", "STIXNonUnicode, STIXSize1, STIXGeneral, Standard Symbols L, DejaVu Sans, Cambria Math");
>+pref("font.mathfont-family", "STIXNonUnicode, STIXSizeOneSym, STIXSize1, STIXGeneral, Standard Symbols L, DejaVu Sans, Cambria Math");

There are some other font.mathfont-family pref settings in this file for different platforms.
Attachment #448516 - Flags: review?(karlt)
Out of interest, do you have an opinion re slanted or upright integrals?
(See Bug 407101 comment 0.)  STIX seems to default to the slanted glyphs, while Cambria Math uses more upright forms.  (Cambria Math glyphs are not as upright as the STIX upright glyphs, though.)
An option to consider is including the STIXGeneral size integral in the list of sizes, as STIXGeneral will not be considered if the page author specifies a different font-family.

Size 2 is used for largeops though
http://hg.mozilla.org/mozilla-central/annotate/7d5c3c3647c3/layout/mathml/nsMathMLChar.cpp#l1241
so we'd want to keep the "D" font in size position 2.
I guess that means we'd have to choose between "Sm" font and STIXGeneral for size position 1.

I'm not sure what's best here, just something to think about.
I think what gets put in position 1 will only affect displaystyle="false" integrals.
(In reply to comment #4)
> Out of interest, do you have an opinion re slanted or upright integrals?
> (See Bug 407101 comment 0.)  STIX seems to default to the slanted glyphs, while
> Cambria Math uses more upright forms.  (Cambria Math glyphs are not as upright
> as the STIX upright glyphs, though.)

When I handwrite integrals, I draw them upright and at least as high as the integrand (i.e. "stretchy"). Books/TeX seem to draw them slanted and "largeop". I think we should do like Books/TeX by default (that's what has been decided for MathML3: the integrals are no longer stretchy). So my idea is to use slanted by default and upright if someone sets stretchy=true. If the two concepts form/stretchiness are actually orthogonal, maybe we can add a -moz-integral-style CSS rule to allow user to draw integrals according to their preferences (don't know how difficult it would be to implement though).

http://en.wikipedia.org/wiki/Integral_symbol

(In reply to comment #5)
> An option to consider is including the STIXGeneral size integral in the list of
> sizes, as STIXGeneral will not be considered if the page author specifies a
> different font-family.
> 
> Size 2 is used for largeops though
> http://hg.mozilla.org/mozilla-central/annotate/7d5c3c3647c3/layout/mathml/nsMathMLChar.cpp#l1241
> so we'd want to keep the "D" font in size position 2.
> I guess that means we'd have to choose between "Sm" font and STIXGeneral for
> size position 1.
> 
> I'm not sure what's best here, just something to think about.
> I think what gets put in position 1 will only affect displaystyle="false"
> integrals.

With the scale-stretchy patch, we use a target size of sqrt(2) times the base char for largeops in displaystyle mode. Integrals seems to be a bit special: currently, the target size is twice larger in displaystyle mode and sqrt(2) times larger otherwise (*). Because the patch gives exact stretching, I was considering removing the ad hoc choice for the starting size. In that case, we could just do STIXGeneral at position 1, Sm at position 2 and D at position 3. The nearest size will be chosen and then scaled to the target size.

(*) BTW, I think what I'm doing in nsMathMLmo is wrong, I should not use this increase factor when stretchy=true and largeop=false for integrals...
(In reply to comment #6)
> Books/TeX seem to draw them slanted and "largeop".
> I think we should do like Books/TeX by default (that's what has been decided
> for MathML3: the integrals are no longer stretchy).

Sounds good to me.

> So my idea is to use
> slanted by default and upright if someone sets stretchy=true.

I'm not sure that's worth the effort, to be honest.

>                                                        In that case, we
> could just do STIXGeneral at position 1, Sm at position 2 and D at position 3.
> The nearest size will be chosen and then scaled to the target size.

IIRC there are currently some assumptions that positions are in increasing order of size.

Sm is smaller than STIXGeneral, and so, now that I think more about it, Sm is unlikely to get used (even with stretchy="true") given the vertical stretching algorithm that stretches to the height of the largest glyph at its regular size.
> Sm is smaller than STIXGeneral, and so, now that I think more about it, Sm is
> unlikely to get used (even with stretchy="true") given the vertical stretching
> algorithm that stretches to the height of the largest glyph at its regular
> size.

Yes, I was thinking Sm to be larger than STIXGeneral. If it is not the case, then we don't need to use it.
Attached patch Patch v. 3 (obsolete) — Splinter Review
Attachment #448350 - Attachment is obsolete: true
Attachment #448516 - Attachment is obsolete: true
Attachment #448848 - Flags: review?(karlt)
Comment on attachment 448848 [details] [diff] [review]
Patch v. 3

>+external.6 = STIXGeneral

>-\u222B = \u2320\uFFFD\u2321\u23AE\u222B # Integral, int
>+\u222B = \u2320\uFFFD\u2321\u23AE\u222B@6 # Integral, int

IIRC this size 0 position is actually used, so I wonder if you meant to put
this in the size 1 position.  (But anyway you are right in that the old value
wasn't good, because StixSize1 doesn't have a U+222B glyph.)

>+external.6 = STIXGeneral
>+external.7 = STIXIntegralsD

>+# Integrals
>+\u222B = \u2320\uFFFD\u2321\u23AE\u222B@6\u222B@7
>+\u222C = \uFFFD\uFFFD\uFFFD\uFFFD\u222C@6\u222C@7
...

Similarly here, I wonder whether we want \uFFFD for size 0 and @6 and @7 in
size 1 and size 2.

But this patch is good as is, thanks, either with or without that change.
Maybe it would make more sense to change nsMathMLChar (in another bug) to actually consider the size 0 position.
Attachment #448848 - Flags: review?(karlt) → review+
(In reply to comment #9)
> Created an attachment (id=448848) [details]
> Patch v. 3

Isn't this also required?

diff --git a/layout/mathml/Makefile.in b/layout/mathml/Makefile.in
--- a/layout/mathml/Makefile.in
+++ b/layout/mathml/Makefile.in
@@ -96,16 +96,17 @@ include $(topsrcdir)/config/config.mk
 FORCE_STATIC_LIB = 1
 
 include $(topsrcdir)/config/rules.mk
 
 font_properties = \
 	mathfontUnicode.properties \
 	mathfontSTIXNonUnicode.properties \
 	mathfontSTIXSize1.properties \
+	mathfontSTIXSizeOneSym.properties \
 	mathfontStandardSymbolsL.properties \
 	$(NULL)
 
 ifeq ($(TARGET_MD_ARCH),win32)
 font_properties += \
 	mathfontSymbol.properties
 endif
I think this needs to be checked into the trunk ASAP, and then, as long as no major issues are uncovered, this also needs to be checked into the 1.9.2 branch so that we are can stop perpetuating the distribution of the non-supported, incompatible with release version, beta version of these fonts.

The mathml projects site should then instead of having a link for downloading a copy of the beta version of the fonts from Mozilla, should just link to the STIX project site to get the official release fonts from the official source.
CCing some Camino people as a heads up that they will (I assume based on bug 406927) need some "project files" changes for mathfontSTIXSizeOneSym.properties.
I should have made my reasoning in my preceding post more clear.  I think that
now that now that there is a release version of the STIX fonts, our continued
reliance and distribution of the BETA version of these fonts in order from
MathML to work with the current release product is a bad direction from a legal
and political perspective.  Now that a release version of these fonts exist we
need to to support that with our release product as soon as we verify that we
can do so without introducing regressions in our MathML support.

Failure to do so, from a political perspective, puts us in a position of not
supporting the tremendous accomplishment of this project finally managing to
actually release the STIX fonts.

Worse still, failure to do so opens us up to legal action under the precedent
set when Sun successfully sued Microsoft for continuing to insist on using a
version of the JVM specification that Sun had deprecated and no longer
supported and no longer permitted to be referred to as JAVA.  I think Mozilla
would be in a bad legal position to continue to require, but worse yet
distribute the Beta version of these fonts, given that the the release version
is available.
(In reply to comment #13)
> CCing some Camino people as a heads up that they will (I assume based on bug
> 406927) need some "project files" changes for
> mathfontSTIXSizeOneSym.properties.

It would seem to be unfortunate that bug 406927 does not seem to actually include a patch for what need to be changed to make this work before.  Although I understand that since se know form this bug that this is going to cause a Camino issue, reaching out to them seems to be a reasonable thing to do.  However, it seems to me that they are causing their own issue by refusing to document the solution.  (Just my opinion, I could be wrong :-) ).
(In reply to comment #13)
> CCing some Camino people as a heads up that they will (I assume based on bug
> 406927) need some "project files" changes for
> mathfontSTIXSizeOneSym.properties.

Thanks for remembering, Karl :)  (Going forward, probably best bet is to cc me and Stuart Morgan (stuart.morgan+bugzilla); mento's not very active right now.)

_Adding_ (as opposed to renaming or removing) a new mathfont*.properties file won't break our build; those fonts just won't work until we ship the new properties file.  Also, at the moment we don't build on m-c (and won't until bug 570314 is resolved :( ), so don't worry about us for the m-c landing regardless.  I'll fix that up once we are building there, and I'll keep an eye out here for a potential 1.9.2 landing.

Bill, not sure why you're so agitated about cc'ing us; Karl did exactly what we had asked of him (and what we ask of other Gecko hackers who do similar sorts of things): just cc us to give us a heads up if there's potential breakage. :)  If there is breakage, we'll get a patch ready to prevent it; if there's not, we'll say so.
(In reply to comment #16)
> Bill, not sure why you're so agitated about cc'ing us; Karl did exactly what we
> had asked of him (and what we ask of other Gecko hackers who do similar sorts
> of things): just cc us to give us a heads up if there's potential breakage. :) 
> If there is breakage, we'll get a patch ready to prevent it; if there's not,
> we'll say so.

I was not agitated at all.  I think letting you know is exactly the right thing to do here.  Was just trying to say that if what needs to be done for Camino is something that we could be done by people adding other font properties files, then documenting the procedure in the other bug would have been helpful, so that when a MathML change occurs a more complete patch can be generated which would make things easier for Camino as well..  If that can't be done, then I guess just making sure you are made aware of when new font properties are landed is all that need so t be done.
(In reply to comment #17)
> I was not agitated at all.  

Oh, sorry; text-only communication :(

> Was just trying to say that if what needs to be done for Camino is
> something that we could be done by people adding other font properties files,
> then documenting the procedure in the other bug would have been helpful

Yeah, it's not something that can be done by folks without Xcode and a strong familiarity with Xcode projects ;)
> Isn't this also required?

Yes, of course. Thanks for pointing this out.

> IIRC this size 0 position is actually used, so I wonder if you meant to put
> this in the size 1 position.

I was not sure, but if it turns out that we keep our heuristic for largeop, then let's put \uFFFD at position 0.

> this also needs to be checked into the 1.9.2 branch

I don't know what is Mozilla's policy for checking into old branch. If we really need to do that, then I think we should either take patches from bug 407101 too or provide a specific patch for the 1.9.2 branch.
Attached patch Patch v4Splinter Review
Attachment #448848 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/535903851195

Doing something for 1.9.2 might be OK given the limited effects of the change.
Let's give it some time on trunk first anyway.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
(In reply to comment #22)
> http://hg.mozilla.org/mozilla-central/rev/535903851195
> 
> Doing something for 1.9.2 might be OK given the limited effects of the change.
> Let's give it some time on trunk first anyway.

Well, when I suggested this, I did not realize that bug 407101 had not landed on the branch because I mostly run trunk builds.  What I was really trying to say is that we should land what is necessary on the branch to make it so that updating from the Beta to the release STIX fonts does not regress any MathML rendering.  Then once that point is reached, we should change the MathML fonts page to point people to the STIX project page to download the release fonts rather than having a link to the beta fonts hosted off the Mozilla server.

Unfortunately, even after reaching that point, it is probably still necessary to support the use of the beta fonts for some time period because the beta fonts still seem to be included with many Linux Distributions.  However, it gets us out of what I think is a an undesirable position of continuing to be a distributor of the beta fonts because our release product requires them.
What are the odds of this work getting into the branch? Since the last discussion about this, the support on trunk has seen a good bit of testing and the 4.0 release has been significantly delayed.
I'm not sure that all the characters will stretch as expected without taking the changes to the operator dictionary. However, for *.properties file only, if I don't miss anything, the relevant bugs are: bug 407101, bug 569195, bug 594244.

Karl, do you think we should made a patch for the 1.9.2 branch?
It's not normally the kind of change that would be made on a branch,
but, if the change is restricted to input files and preferences, then it's a change that probably could be made on 1.9.2.

(In reply to comment #27)
> I'm not sure that all the characters will stretch as expected without taking
> the changes to the operator dictionary.

Is it the integrals that you are concerned about here?
If so, a 1.9.2 patch need not include those characters.

> However, for *.properties file only, if
> I don't miss anything, the relevant bugs are: bug 407101, bug 569195, bug
> 594244.

Yes, bug 594244 should be included before suggesting people use v1.0 STIX.

(In reply to comment #20)
> I don't know what is Mozilla's policy for checking into old branch. If we
> really need to do that, then I think we should either take patches from bug
> 407101 too or provide a specific patch for the 1.9.2 branch.

Can you remind me, please, what you want to include from bug 407101 (and why)?
I can't think of anything there that is related to differences in STIX font versions, or necessary for attachment 450332 [details] [diff] [review] here.
> Is it the integrals that you are concerned about here?
> If so, a 1.9.2 patch need not include those characters.

Yes, I was thinking about the integrals but also about other operators added in bug 407101. But actually it's not really a problem to add new operators in the *.properties without adding them in the operator dictionary (it's just useless because these changes won't have any effect). We can also have problems for n-ary ops added in attachment 412233 [details] [diff] [review] if we don't take attachment 442729 [details] [diff] [review].

> Can you remind me, please, what you want to include from bug 407101 (and why)?
> I can't think of anything there that is related to differences in STIX font
> versions, or necessary for attachment 450332 [details] [diff] [review] here.

I think all what I mean here is that the attachment of this bug applies on top of those from bug 407101, and so we need either to take them or adapt the attachment 450332 [details] [diff] [review] for 1.9.2. But the second option sounds fine to me and it avoids the issues mentioned above.
The reason I'd recommend this for 1.9.2 is that there is a popular understanding that Gecko uses STIX fonts for MathML, but most do not realize that version 1.0 has significant differences from the Beta release (which Gecko was crafted to use), and ideally people should be able to install the "final" release version without having to keep any Beta fonts around.

A 1.9.2 patch could be prepared that would touch only input files and preferences, adding one .properties file.  It would only affect behavior when version 1.0 STIX fonts are installed.
status1.9.2: --- → ?
Here is a version for the 1.9.2 branch.
The patch is untested.
Attachment #597783 - Flags: review?(karlt)
Comment on attachment 597783 [details] [diff] [review]
Patch for the 1.9.2 branch

End of life for Firefox 3.6 is April 24, so I don't know whether release drivers will take a patch now.  There is one more release planned for that branch so we can try.

However, if we take a patch, it should be a minimal patch, without changes to mathfontSTIXSize1.properties and without extra entries in the new file (unless you can explain or remind me why they are important).

Are you able to use hg copy (or hand edit a patch to have the copy lines that attachment 450332 [details] [diff] [review] does) please so that we can see any differences in the file for the newer fonts.
Attachment #597783 - Flags: review?(karlt) → review-
OK, I didn't know that the end of life for Firefox 3.6 was so soon.
I don't think it's worth continuing the work on this patch, then.
You need to log in before you can comment on or make changes to this bug.