1670581 - Firefox doesn't use non-breaking hyphen from webfont

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[quasicomputational]

Reproduction steps:

1. Download https://github.com/adobe-fonts/source-serif-pro/raw/release/WOFF2/TTF/SourceSerifPro-Regular.ttf.woff2 as SourceSerifPro-Regular.ttf.woff2.
2. In the same directory, save this HTML:

<!DOCTYPE html>
<meta charset=utf-8>
<style>
@font-face {
  font-family: "SourceSerifPro";
  src: url("SourceSerifPro-Regular.ttf.woff2");
}
:root {
  font-family: "SourceSerifPro", monospace;
  font-size: 2rem;
}
</style>
Foo&hyphen;bar&#x2011;baz.

3. Open that HTML file.

Observed behaviour: that the two hyphens look different and that, according to devtools, they are in fact using different fonts.

Expected behaviour: both hyphens would use glyphs from the webfont and hence would look identical.

The font does contain U+2011 (NON-BREAKING HYPHEN); Chrome displays the two hyphens with the same font. This doesn't seem to be WOFF2 related, since the TTF from the same source also shows the same behaviour.

Comment 1

[Jonathan Kew [:jfkthame]]

(In reply to quasicomputational from comment #0)

Observed behaviour: that the two hyphens look different and that, according to devtools, they are in fact using different fonts.

Agreed, this is what I see.

Expected behaviour: both hyphens would use glyphs from the webfont and hence would look identical.

This would be "expected" if the webfont supports both characters, but....

The font does contain U+2011 (NON-BREAKING HYPHEN); Chrome displays the two hyphens with the same font. This doesn't seem to be WOFF2 related, since the TTF from the same source also shows the same behaviour.

No, this font in fact does not support U+2011! Here's an excerpt from the cmap table (exported using TTX):

      <map code="0x1ef9" name="uni1EF9"/><!-- LATIN SMALL LETTER Y WITH TILDE -->
      <map code="0x2007" name="uni2007"/><!-- FIGURE SPACE -->
      <map code="0x2010" name="hyphen"/><!-- HYPHEN -->
      <map code="0x2012" name="figuredash"/><!-- FIGURE DASH -->
      <map code="0x2013" name="endash"/><!-- EN DASH -->
      <map code="0x2014" name="emdash"/><!-- EM DASH -->

Note the absence of U+2011.

I guess Chrome may be using a fallback substitution whereby it uses U+2012 (or perhaps U+002D, as it's more likely to be available in a font with limited repertoire) in place of U+2011 when not available in the font.

So this is fundamentally an issue with the font. But we might want to add some fallbacks here, to give a better user experience in such cases.

Comment 2

[quasicomputational]

Yeah, I came to the same conclusion as you after further investigation - font problem, and Chromium is doing some clever fallback.

We crossed in flight - I was going to mark as invalid, but having clever fallbacks might be a good idea if only for Web compatibility, because I'm sure someone, somewhere will depend on what Chromium is doing here.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1670581 - Fall back to ASCII hyphen-minus if Unicode hyphen character is not supported by the chosen font. r=m_kato

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1670581 - Add a reftest for Unicode hyphen fallback. r=m_kato

Depends on D93208

Comment 5

[Jonathan Kew [:jfkthame]]

I think at least using HYPHEN-MINUS as a substitute for U+2010 and U+2011 (if not present in the font) makes sense. Assuming this doesn't result in any unexpected problems, we may want to come up with a somewhat more extensive table of fallbacks.

Probably anything that has a singleton canonical decomposition in Unicode (such as U+212B ANGSTROM SIGN -> U+00C5 CAPITAL A WITH RING, and similar cases) could reasonably be substituted, except for the "CJK COMPATIBILITY IDEOGRAPHS" block which are known to have undesirable normalization behavior. There may also be a few other candidates that don't have official equivalences yet can be expected to have identical glyphs.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bde48ea621a2
Fall back to ASCII hyphen-minus if Unicode hyphen character is not supported by the chosen font. r=m_kato
https://hg.mozilla.org/integration/autoland/rev/6122ff2a25ce
Add a reftest for Unicode hyphen fallback. r=m_kato

Comment 7

[Tom S. (please needinfo tschuster)]

I am not sure if the license for SourceSerifPro allows this usage in a test.

Comment 8

[Jonathan Kew [:jfkthame]]

It's OFL-licensed, isn't it? AFAIK that's fine (and not the first OFL-licensed font we have, fwiw).

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e820249c4b87
set 3 web platform reftests as expected passes. a=unexpected-pass DONTBUILD CLOSED TREE

Comment 10

[Jonathan Kew [:jfkthame]]

(In reply to Pulsebot from comment #9)

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e820249c4b87
set 3 web platform reftests as expected passes. a=unexpected-pass DONTBUILD
CLOSED TREE

Thanks - sorry, I didn't realize there were "unrelated" tests that were accidentally depending on this.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/d95aab08e480
set 3 web platform reftests as expected passes. a=unexpected-pass

Comment 12

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/bde48ea621a2
https://hg.mozilla.org/mozilla-central/rev/6122ff2a25ce
https://hg.mozilla.org/mozilla-central/rev/d95aab08e480

Comment 13

[Sandor Molnar[:smolnar]]

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