1545317 - odd spacing of quote character in Source Serif Pro on Linux

Status: RESOLVED INVALID

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

Description

[Cameron McCormack (:heycam)]

Attachment: screen shot of Nightly

I'm on Linux but I haven't tested other platforms. In https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.flatten the last paragraph has the sentence:

Here we see that flatten() does not perform a "deep" flatten.

In Nightly, the quote character overlaps with the "d" of "deep". In Chrome it does not.

See the attached screen shot.

Comment 1

[Cameron McCormack (:heycam)]

Attachment: screen shot of Chrome

Comment 2

[Cameron McCormack (:heycam)]

On macOS it looks OK.

Comment 3

[Jonathan Kew [:jfkthame]]

Curious. Do you have a version of Source Serif Pro installed locally on your Linux machine, or is it using the webfont from doc.rust-lang.org?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I can also repro this. I don't have any Source Serif Pro font installed locally.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

I can also repro this. I don't have any Source Serif Pro font installed locally.

Same here (on Ubuntu 19.04).

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: (font for use in testcase)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 on dholbert's machine

testcase 1 reproduces this for me. Here's a screenshot in Nightly.

(In Chrome, I get expected rendering, just like in Cameron's original screenshots)

Comment 9

[Daniel Holbert [:dholbert]]

I can't repro in Firefox 66 on Windows 10 or on MacOS, so this seems to be linux-specific.

Also: on linux, I can reproduce at least as far back as Firefox Nightly 2012-06-01 (version 15). So, linux-specific and not a regression (or not a recent one at least). --> seems like a P3

Comment 10

[Jonathan Kew [:jfkthame]]

This appears to be a bug in freetype, I think -- somehow, it's returning an incorrect advance width for the double-quote glyph (looks like it's giving us the advance of the single-quote, perhaps triggered by how the double-quote is constructed as a composite glyph with two single-quote components).

I see the same incorrect advance for the double-quote if I install that font and use it in gedit, for example.

Other applications may or may not be affected, depending how they access glyph advances.

Comment 11

[Jonathan Kew [:jfkthame]]

Confirmed that this also reproduces with the ftstring demo program from freetype2-demos.

Besides the ASCII double-quote, other characters such as “” (U+201C/U+201D) and … (U+2026) are also affected; I'm still guessing this is triggered by the composite-glyph construction used for these characters in the font.

Comment 12

[Jonathan Kew [:jfkthame]]

Aha - no, it's not a freetype bug, it's a font bug.

Dumping the 'glyf' table from the attached font, we find entries like this:

    <TTGlyph name="quotedbl" xMin="40" yMin="395" xMax="407" yMax="729">
      <component glyphName="quotesingle" x="0" y="0" flags="0x204"/>
      <component glyphName="quotesingle" x="211" y="0" flags="0x4"/>
    </TTGlyph>

Note the flags value on the first component. Checking the OpenType spec[1] for composite glyphs:

Mask	Name	Description
0x0200	USE_MY_METRICS	Bit 9: If set, this forces the aw and lsb (and rsb) for the composite to be equal to those from this original glyph. This works for hinted and unhinted characters.

So freetype is correct to use the advance width of quotesingle and apply it to quotedbl as well, etc. Applications that don't do this, and instead use the advance of quotedbl from the hmtx table, are in fact failing to respect this detail of the spec.

[1] https://docs.microsoft.com/en-gb/typography/opentype/spec/glyf#composite-glyph-description

Comment 13

[Jonathan Kew [:jfkthame]]

It looks like this is fixed in the latest files on github; see https://github.com/adobe-fonts/source-serif-pro/releases.

Comment 14

[Daniel Holbert [:dholbert]]

Sounds like this is a bug in the font file itself and is INVALID as a Firefox bug, then.

We should probably notify the folks behind https://doc.rust-lang.org/ of this issue and see if they can use an updated version of that font, per comment 13.

The current busted fonts are (at least):
https://doc.rust-lang.org/SourceSerifPro-Regular.ttf.woff
https://doc.rust-lang.org/SourceSerifPro-Bold.ttf.woff

Manish, perhaps you know who/where we might about getting those ^^ font files to be replaced with the updated versions?

Comment 15

[Manish Goregaokar [:manishearth]]

I just went ahead and made a pull request to update them: https://github.com/rust-lang/rust/pull/60146

Comment 16

[Cameron McCormack (:heycam)]

Jonathan, is there a good place we can add tests for OpenType font issues like this, so that other browsers will notice their error? Could we add a WPT for this for example?

Comment 17

[Jonathan Kew [:jfkthame]]

In principle, we could construct a reftest (for example) using a test font that exhibits this anomaly, to detect which browsers respect the USE_MY_METRICS flag and which just use the separate metrics of the composite.

I'm not really sure it's worth pursuing, though. This was really a font bug, and was fixed in the font when it was noticed there. The "bug" in some browsers (that did not have the bad rendering) is that they don't pay attention to the USE_MY_METRICS flag, but I think that flag is largely obsolete; it comes from the early days of TrueType when all sorts of tricks were being used to save a byte here and a cycle there on old 68000 or 8086 chips. I doubt more modern font renderers that now simply compute metrics from the 'hmtx' table in all cases will care to retrofit a special case to check this flag and potentially short-circuit a couple of computations.

Probably the OpenType spec should be updated to clarify that USE_MY_METRICS should only be set for a component whose metrics do in fact match the metrics of the composite; it should not be used to make a component override those metrics, and rendering engines may ignore this if attempted.