825504 - MathML-fonts extension no longer works under linux

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Bill Gianopoulos [:WG9s]]

Since the landing of bug 841442, Fred Wang's MathML-fonts extension no longer works under Linux.  It still works just fine under Windows and Android.

Comment 1

[Bill Gianopoulos [:WG9s]]

(In reply to Bill Gianopoulos [:WG9s] from comment #0)
> Since the landing of bug 841442, Fred Wang's MathML-fonts extension no
                       ^^^^^^^^^^
                       bug 821442
> longer works under Linux.  It still works just fine under Windows and
> Android.

Comment 2

[Bill Gianopoulos [:WG9s]]

This extension works by adding a css file to all pages that specifies @font-face rules with local URI's.  So my guess would be that this patch somehow broke @font-face with local URI's under Linux.

Comment 3

[Jonathan Kew [:jfkthame]]

Hmm, that sounds possible, except that I'm pretty sure we have existing reftests for @font-face with src:local, so we should have seen failures if that broke. But maybe some subtle change in the behavior is disrupting things for the extension.

Comment 4

[Jonathan Kew [:jfkthame]]

Ah, wait, you didn't say rules with "src:local(...)" but "local URI's" ... what exactly do those URIs look like? Maybe that's something we don't have test coverage for. Could you put together a minimal testcase for that functionality?

Comment 5

[Bill Gianopoulos [:WG9s]]

Actually they do.  They look like this:

@font-face {
  font-family: 'STIXGeneral';
  src: local('STIXGeneral-Regular'), local('STIXGeneral Regular'), url('MathML-fonts/STIX/STIXGeneral-Regular.woff');
  font-weight: normal;
  font-style: normal;

as an example.

Oh but then i think it is the one with url('MathML-fonts/STIX/STIXGeneral-Regular.woff'); that actually matches.

Hmm.

Comment 6

[Jonathan Kew [:jfkthame]]

Yes - the local(...) sources would only match if the STIXGeneral font is installed locally (i.e., visible to fontconfig). The url(...) one is presumably supposed to load a font that's shipped as part of the extension, but maybe we broke the use of stylesheet-relative paths there.

Comment 7

[Bill Gianopoulos [:WG9s]]

But then this could also be the classic works in windows not in Linux of a case sensitive vs. case-insensitive matching on the family name.

Comment 8

[Bill Gianopoulos [:WG9s]]

So far it looks like all the filename references are case-correct.

Comment 9

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

If I understand correctly, you're expecting the fonts from the "local" url() to be used but they are not. On the torture test

https://developer.mozilla.org/en-US/docs/Mozilla_MathML_Project/MathML_Torture_Test

I guess the <mo> characters (summation symbols, square roots etc) do not render correctly. But when you change the selected font, do you still get different styles for math text (variables, numbers...)? If so, I suspect the problem comes from the changes to

layout/mathml/nsMathMLChar.cpp

Comment 10

[Bill Gianopoulos [:WG9s]]

(In reply to Frédéric Wang (:fredw) from comment #9)
> If I understand correctly, you're expecting the fonts from the "local" url()
> to be used but they are not. On the torture test
> 

No.  I am expecting your test here https://developer.mozilla.org/docs/Mozilla_MathML_Project/Fonts/Test to pass, yet it fails.

Comment 11

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

(In reply to Bill Gianopoulos [:WG9s] from comment #10)
> No.  I am expecting your test here
> https://developer.mozilla.org/docs/Mozilla_MathML_Project/Fonts/Test to
> pass, yet it fails.

This tests <mo> characters only. Can you check whether the @font-face rules are applied to math text in general?

Comment 12

[Bill Gianopoulos [:WG9s]]

(In reply to Frédéric Wang (:fredw) from comment #9)
> If I understand correctly, you're expecting the fonts from the "local" url()
> to be used but they are not. On the torture test
> 
> https://developer.mozilla.org/en-US/docs/Mozilla_MathML_Project/
> MathML_Torture_Test
> 
> I guess the <mo> characters (summation symbols, square roots etc) do not
> render correctly. But when you change the selected font, do you still get
> different styles for math text (variables, numbers...)? If so, I suspect the
> problem comes from the changes to
> 
> layout/mathml/nsMathMLChar.cpp

Except that changes their don't look Linux specific at all.

Comment 13

[Bill Gianopoulos [:WG9s]]

(In reply to Frédéric Wang (:fredw) from comment #11)
> (In reply to Bill Gianopoulos [:WG9s] from comment #10)
> > No.  I am expecting your test here
> > https://developer.mozilla.org/docs/Mozilla_MathML_Project/Fonts/Test to
> > pass, yet it fails.
> 
> This tests <mo> characters only. Can you check whether the @font-face rules
> are applied to math text in general?

Do you have a specific test I can do to show this?

I can report that comparing A version of Firefox where the extension works with current nightly on the Torture test using Default font, the following test look obviously different:

Test     Difference
8,14,23  Curved braces have flat sides
10,12,21 Sigma looks like wrong font
14       not enough space around vertical bar
16,17,21 Integral thicker less tall and less slanted
19,22    over and under braces use incorrect font

The resultant display looks the same as if I disable the extension on the Firefox version where it works correctly.

Comment 14

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

Attachment: Screenshot of the torture test

You must verify whether changing the selected font really give different rendering for the text (other than the one drawn with nsMathMLChar's). For example, here is a screenshot of test 3 with different fonts Asana, STIX and MathJax (from left to right). You can notice that the aspect of the letters is slightly different.

You can also try to compare

<p style="font-family: STIXGeneral, monospace;">ABCDEF</p>

against 

<p style="font-family: monospace;">ABCDEF</p>

to see if the add-on is able to pick the STIXGeneral font from the url('...') when you don't have it installed on your system.

Comment 15

[Bill Gianopoulos [:WG9s]]

(In reply to Frédéric Wang (:fredw) from comment #14)
> You can also try to compare
> 
> <p style="font-family: STIXGeneral, monospace;">ABCDEF</p>
> 
> against 
> 
> <p style="font-family: monospace;">ABCDEF</p>
> 
> to see if the add-on is able to pick the STIXGeneral font from the
> url('...') when you don't have it installed on your system.

Not sure if this is what is causing the issue, but trying this pointed out a real issue here:
<p style="font-family: STIXGeneral, monospace;">ABCDEF</p>

Doe NOT end up using monospace if STIXGeneral is not installed.

Comment 16

[Bill Gianopoulos [:WG9s]]

To make it clear:

<p style="font-family: NoSuchFont, monospace;">ABCDEF</p>

displays completely differently than:

<p style="font-family: monospace;">ABCDEF</p>

Comment 17

[Bill Gianopoulos [:WG9s]]

Attachment: Test suggested in comment 14

Comment 18

[Bill Gianopoulos [:WG9s]]

Attachment: Screenshot of running this test

Something is odd here.  This is a result of running the above testcase without the extension installed and with no STIX fonts installed.

Oddly, Google Chrome displays this testcase very similarly.

However, Opera, seemingly correctly, displays all three text lines identically.

Comment 19

[Jonathan Kew [:jfkthame]]

It looks like you're getting the same (monospaced) font in all three lines, but with different sizing. That's probably because the default font size for monospace is 13px, while it's 16px for the default serif and sans-serif styles. But you only get the monospace default size if monospace is the first font family listed.

You could verify (and "fix") this by explicitly setting the font-size in your CSS rather than relying on the browser's default, as that may vary for the different CSS generics.

So I think that's unrelated to the MathML extension problem, and probably isn't a bug at all - it's the expected result given the default font/size settings.

Comment 20

[Bill Gianopoulos [:WG9s]]

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> It looks like you're getting the same (monospaced) font in all three lines,
> but with different sizing. That's probably because the default font size for
> monospace is 13px, while it's 16px for the default serif and sans-serif
> styles. But you only get the monospace default size if monospace is the
> first font family listed.
> 
> You could verify (and "fix") this by explicitly setting the font-size in
> your CSS rather than relying on the browser's default, as that may vary for
> the different CSS generics.
> 
> So I think that's unrelated to the MathML extension problem, and probably
> isn't a bug at all - it's the expected result given the default font/size
> settings.

Thanks for the explanation and a way to go back to testing the real issue.  I do, however think this is still a bug (just not this bug).  I really think the default sizing should either apply always or only apply if none of the specified fonts are present.  It being dependent on the first specified font being present makes little or no logical sense.

Comment 21

[[Baboo]]

(In reply to Bill Gianopoulos [:WG9s] from comment #20)
> I do, however think this is still a bug (just not this bug).
Indeed, it's ancient bug 175415 (possible "solution" would be bug 328621).

Comment 22

[Bill Gianopoulos [:WG9s]]

(In reply to Frédéric Wang (:fredw) from comment #14)
> Created attachment 696717 [details]
> Screenshot of the torture test
> 
> You must verify whether changing the selected font really give different
> rendering for the text (other than the one drawn with nsMathMLChar's). For
> example, here is a screenshot of test 3 with different fonts Asana, STIX and
> MathJax (from left to right). You can notice that the aspect of the letters
> is slightly different.

OK It appears that it is rendering test 3 correctly for all 3 font cases using the extension and current nightlies.

> 
> You can also try to compare
> 
> <p style="font-family: STIXGeneral, monospace;">ABCDEF</p>
> 
> against 
> 
> <p style="font-family: monospace;">ABCDEF</p>
> 
> to see if the add-on is able to pick the STIXGeneral font from the
> url('...') when you don't have it installed on your system.

This test also worked correctly after I changed it to specify a font size to make it obvious what was going on.  Both lines displayed identically without the extensions and used different fonts with the extension installed.  I also tried the test with the release version of Firefox (where the extension is known to work correctly) and the fonts seemed to match between the Release and Nightly version.

SO, it appears you are correct, and this seems to only effect <mo> characters.

Comment 23

[Jonathan Kew [:jfkthame]]

(In reply to Bill Gianopoulos [:WG9s] from comment #12)
> (In reply to Frédéric Wang (:fredw) from comment #9)
> > I guess the <mo> characters (summation symbols, square roots etc) do not
> > render correctly. But when you change the selected font, do you still get
> > different styles for math text (variables, numbers...)? If so, I suspect the
> > problem comes from the changes to
> > 
> > layout/mathml/nsMathMLChar.cpp
> 
> Except that changes their don't look Linux specific at all.

The root of the problem is that for user fonts, the implementation of gfxPangoFontGroup::GetFamilyNameAt() is a bit broken. As a result, the code mentioned in nsMathMLChar.cpp, which uses GetFamilyNameAt(), doesn't believe it has found the font it wanted and so doesn't apply it in the rendering context.

I'm thinking about possible ways to fix this...

Comment 24

[Jonathan Kew [:jfkthame]]

Attachment: fix gfxPangoFontGroup::FindFamilyNameAt for user fonts, to resolve MathML fonts breakage

Given that we can no longer reliably get the family name directly from a font entry, and the pango font group code doesn't manage the list of families and faces in the same way as other backends (because of its use of fontconfig patterns), the implementation of GetFamilyNameAt there relied on retrieving the family name from the appropriate Fc pattern. That's fine for normally-installed fonts, but it doesn't work for user fonts, which may be known by a family name quite unrelated to what's in the font data or the pattern. To work around this, we can go back to the user font set and look for a family that has a reference to the entry in question. This is theoretically a bit more expensive, but it shouldn't matter in practice as there are not normally huge numbers of user fonts in the set, and FindFamilyNameAt is not heavily used.

Comment 25

[Jonathan Kew [:jfkthame]]

Tryserver build in progress at https://tbpl.mozilla.org/?tree=Try&rev=3ee60a67981e; Bill, when this is ready, if you could verify that it fixes the problems you've seen, that'd be great.

Comment 26

[Bill Gianopoulos [:WG9s]]

(In reply to Jonathan Kew (:jfkthame) from comment #25)
> Tryserver build in progress at
> https://tbpl.mozilla.org/?tree=Try&rev=3ee60a67981e; Bill, when this is
> ready, if you could verify that it fixes the problems you've seen, that'd be
> great.

This fixes all the issues I was seeing.

Comment 27

[Bill Gianopoulos [:WG9s]]

I also re-spun my builds for today (available at http://www.wg9s.com/mozilla/firefox/ )with my normal extra MathML patches to include this fix.

Comment 28

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a38c72b27bf7

Comment 29

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/a38c72b27bf7