Closed Bug 1714197 Opened 3 years ago Closed 3 years ago

font-family "Helvetica" displays the "Compressed" variant if base variants not installed

Categories

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

Firefox 89
All
Windows
defect

Tracking

()

RESOLVED DUPLICATE of bug 1716433
Tracking Status
firefox-esr78 --- unaffected
firefox89 --- disabled
firefox90 --- fixed
firefox91 --- fixed

People

(Reporter: spam, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Attached image bugzilla-helvetica.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

  • I installed the "Helvetica Compressed" font, I did not install any other variants (Regular, Bold, etc.)

  • Visit a website that has "Helvetica" in its CSS font declarations, for example:
    https://world.openfoodfacts.org/
    font-family: "Helvetica Neue",Helvetica,Roboto,Arial,sans-serif

Actual results:

Since the Firefox 89 update (and in 90b1 too), when I visit sites that list "Helvetica" before any other system-installed fonts or fallbacks such as "sans-serif", the "Helvetica Compressed" font is used, which is quite unreadable.

Something has changed with the selection or prioritization of fonts, but I cannot find it in the v89 changelog.

Expected results:

Like in Firefox 88 and current Chrome 91, the "Arial" font should have been used in the example case: "Helvetica Neue", Helvetica, Roboto not installed, next working font should be Arial on Windows 10.

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core

Thanks for the report. Christoph, what exact "Helvetica Compressed" font have you installed? (Can you point to where it's available, for example?)

If it has the family name "Helvetica", it makes sense that it would be used for content that is styled with font-family: "Helvetica Neue",Helvetica,Roboto,Arial,sans-serif, in preference to Arial which is later in the font-family list.

So I suspect this may be behaving correctly, but it depends on exactly what naming data the installed font contains. (Still, if the behavior changed in Firefox 89, it would be good to understand why - I'd have expected things to be this way since long ago.)

Flags: needinfo?(spam)

It is a commercial font, I'll send it to you via email.

You are right that it is in the "Helvetica" family, also listed accordingly in the Windows Fonts settings.

Other (free) fonts such as the Roboto and Ubuntu font act similar to this v89 current behaviour, i.e. they would display the "Condensed" variant if only "Condensed" is installed, Chrome does behave the same in that case. Not sure why Helvetica Compressed is/was different.

Flags: needinfo?(spam)

I used TTX to examine the name table of the font, and it has some curious inconsistencies. It provides three copies of each name string, for different platform and encoding combinations. (See https://docs.microsoft.com/en-gb/typography/opentype/spec/name#platform-encoding-and-language-ids for the IDs involved here.)

First, platform ID 0 (Unicode), encoding ID 0 (Unicode 1.0 semantics—deprecated):

  <name>
    <namerecord nameID="0" platformID="0" platEncID="0" langID="0x0">
      Copyright (c) 1988 Adobe Systems Incorporated.  All Rights Reserved.Helvetica is a trademark of Linotype Company.
    </namerecord>
    <namerecord nameID="1" platformID="0" platEncID="0" langID="0x0">
      Helvetica
    </namerecord>
    <namerecord nameID="2" platformID="0" platEncID="0" langID="0x0">
      Compressed
    </namerecord>
    <namerecord nameID="3" platformID="0" platEncID="0" langID="0x0">
      Helvetica Compressed:1178633246
    </namerecord>
    <namerecord nameID="4" platformID="0" platEncID="0" langID="0x0">
      Helvetica Compressed
    </namerecord>
    <namerecord nameID="5" platformID="0" platEncID="0" langID="0x0">
      001.000
    </namerecord>
    <namerecord nameID="6" platformID="0" platEncID="0" langID="0x0">
      Helvetica-Compressed
    </namerecord>

Then we have platform ID 1 (Macintosh), encoding ID 0 (Roman):

    <namerecord nameID="0" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Copyright (c) 1988 Adobe Systems Incorporated.  All Rights Reserved.Helvetica is a trademark of Linotype Company.
    </namerecord>
    <namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Helvetica
    </namerecord>
    <namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Compressed
    </namerecord>
    <namerecord nameID="3" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Helvetica Compressed:1178633246
    </namerecord>
    <namerecord nameID="4" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Helvetica Compressed
    </namerecord>
    <namerecord nameID="5" platformID="1" platEncID="0" langID="0x0" unicode="True">
      001.000
    </namerecord>
    <namerecord nameID="6" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Helvetica-Compressed
    </namerecord>

And finally platform ID 3 (Windows), encoding ID 1 (Unicode BMP):

    <namerecord nameID="0" platformID="3" platEncID="1" langID="0x409">
      Copyright (c) 1988 Adobe Systems Incorporated.  All Rights Reserved.Helvetica is a trademark of Linotype Company.
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Helvetica Compressed
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
      Helvetica Compressed:1178633246
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
      Helvetica-Compressed
    </namerecord>
    <namerecord nameID="5" platformID="3" platEncID="1" langID="0x409">
      001.000
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
      Helvetica-Compressed
    </namerecord>
  </name>

The important entry here is name ID 1, the "Font Family" name. Note that the "Windows" platform version of this name is "Helvetica Compressed", while the "Unicode" and "Macintosh" versions of it are simply "Helvetica". I guess different font APIs may expose the font under different (or even multiple) family names, depending which of these strings they use. The fact that it appears as "Helvetica" in the Windows settings, though, matches the fact that Firefox recognizes it as "Helvetica", which we get from the DirectWrite font collection APIs.

(There's also an odd discrepancy in the "Full font" name, ID 4: is it hyphenated or space-separated? But I don't think that is relevant here.)

What does puzzle me is why it did not seem to work this way in previous versions. In testing, I can see it as "Helvetica" in the font list (in the Firefox settings), yet it doesn't get used for web content. The change in behavior seems to be associated with the new font management code that was enabled (for release versions) in bug 1694174.

It seems like for some reason Chrome doesn't use this font as "Helvetica", even though it recognizes that the name exists: I can see it in the Customize Fonts section of Settings. But if I try to choose it, what actually appears is the Arial substitute.

Windows includes a default font substitution in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes mapping Helvetica to Arial, doesn't it?

I see that there is some code accessing that registry key, so maybe something got broken there with the new font management code?

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Windows
Regressed by: 1694174
Hardware: Unspecified → All
Has Regression Range: --- → yes
See Also: → 1714318

The behavior may well have changed somewhat, yes. As currently written, the intention is that the Windows substitutes will only be used if the given font family is not available -- so on a default Windows install, font-family: Helvetica will use Arial as a substitute. But the reporter here does have a Helvetica family installed (albeit with only a Condensed face), and so the substitution is not used.

Looking at the older code, it appears that it used the substitutes in preference to actual installed fonts, so an installed Helvetica family (for example) would never have been used at all, unless the default Helvetica->Arial substitution in the registry was removed.

I'm inclined to think the new behavior here is more correct, although obviously it can come as a surprise if a user wasn't aware they had an actual Helvetica family (with only a partial, quirky set of styles) installed.

Severity: -- → S3

This issue is not windows-only. I had this in the past on rare Linux distro with not-so-good Helvetica included. This was fixed for me by installing Helvetica in user fonts dir. However, the similar issue become occur to me after upgrade to Firefox 89. This is described in related ticket.
#1714318

Set release status flags based on info from the regressing bug 1694174

I'm experiencing, in Linux, Debian, Stable, a similar issue. Pages with the first matching font-family entry being "Helvetica" show in a fixed font-size. If I remove the Helvetica item it works (on github, for example, the subsequent entry is Arial).
In the Developer tools -> Fonts, if I slide the Helvetica font size, it only changes the apparent line-height.

If I make my own local test.html file with body { font-family: Helvetica } it shows the same issue.

The entries for Helvetica (the only font listed in the page) are as follows (that helvR08-ISO8859-1.pcf.gz is from 2015):
Helvetica:style=Regular:stylelang=en,en:slant=0:weight=80:width=100:pixelsize=11:foundry=Adobe:antialias=False:file=/usr/share/fonts/X11/100dpi/helvR08-ISO8859-1.pcf.gz:index=0:outline=False:scalable=False:charset=0 20-7e a0-ff:lang=aa|ay|bi|br|ch|da|de|en|es|eu|fj|fo|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nds|nl|nn|no|nr|oc|om|pt|rm|sma|smj|so|sq|ss|st|sv|sw|tl|ts|uz|vo|wa|xh|yap|zu|an|fil|ht|jv|kj|kwm|li|ms|ng|pap-an|pap-aw|rn|rw|sc|sg|sn|su|za:fontversion=0:fontformat=PCF:decorative=False:postscriptname=Helvetica:color=False:symbol=False:variable=FalseHelvetica:style=Regular:stylelang=en,en:slant=0:weight=80:width=100:pixelsize=11:foundry=Adobe:antialias=False:file=/usr/share/fonts/X11/100dpi/helvR08.pcf.gz:index=0:outline=False:scalable=False:charset=0 20-7e a0-17e 186 189 18e 192 197 19a 19d 19f-1a1 1a7-1a8 1ae-1b0 1b5-1b6 1bb-1bc 1c0 1c2-1c3 1cd-1ed 1f0 1f4-1f5 1f8-21b 21e-21f 226-233 250 254 258-259 25f 265 275 279 287-289 28c-28e 29e 2bb-2bd 2c6-2cb 2cd-2cf 2d8-2dd 2ee 37e 384-385 387 3bc 1e00-1e99 1ea0-1ea1 1ea4-1ea7 1eaa-1eb1 1eb4-1eb9 1ebc-1ec1 1ec4-1ec7 1eca-1ecd 1ed0-1ed3 1ed6-1edd 1ee0-1ee5 1ee8-1eeb 1eee-1ef5 1ef8-1ef9 2000-200b 2010-2015 2018-2022 2026 2030 2039-203a 2044 2081-2083 20a5-20a6 20a9 20ac-20ad 2103 2109 2122 212a-212b 2132 2200 2203-2204 2212 2215 2219 2236 2259-225a 2260-2262 2264-2265 226e-2271:lang=aa|af|ast|ay|bi|br|bs|ca|ch|co|cs|cy|da|de|en|eo|es|et|eu|fi|fj|fo|fr|fur|fy|ga|gd|gl|gn|gv|haw|ho|hr|hu|ia|ig|id|ie|io|is|it|ki|kl|kw|la|lb|lt|lv|mg|mh|mi|mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|pl|pt|rm|ro|se|sk|sl|sm|sma|smj|smn|so|sq|ss|st|sv|sw|tk|tl|tn|to|tr|ts|uz|ve|vo|vot|wa|wen|wo|xh|yap|zu|an|crh|csb|fil|hsb|ht|jv|kj|ku-tr|kwm|lg|li|ms|na|ng|pap-an|pap-aw|qu|quz|rn|rw|sc|sg|sn|su|ty|za:fontversion=0:fontformat=PCF:decorative=False:postscriptname=Helvetica:color=False:symbol=False:variable=False

Oh, for me this also began in the latest 89 update.

That's bug 1714282, which is fixed in 90beta. For 89, you can avoid the problem by setting gfx.e10s.font-list.shared to false in the about:config settings (and re-launching Firefox).

The underlying issue in the original (Windows) report here has been filed more explicitly as bug 1716433, so I'm going to dupe this report forward; we can pursue it there, without the distraction of unrelated Linux font issues.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: