12

None of the following are bolding the word inversion Inversion, Inversion or Inversion.

None of the following are italicizing the word inversion Inversion, Inversion or Inversion.

My answer is found here: https://music.stackexchange.com/a/67050/48192

I'm using Chrome on Windows 10.

17
  • 7
    Looks fine to me... What browser/os are you using?
    – Catija
    Feb 18, 2018 at 20:41
  • This is how it looks in Chrome: i.stack.imgur.com/iCP9j.png What is the issue?
    – rene
    Feb 18, 2018 at 20:45
  • Interestingly I'm not seeing any bold or italics. I'm on Windows 10 using Chrome, Firefox or Internet Explorer.
    – ChrisF Mod
    Feb 18, 2018 at 20:48
  • It only appears to be a problem with Music/that question for me. I'm seeing the bold and italic here and elsewhere.
    – ChrisF Mod
    Feb 18, 2018 at 20:53
  • I am using Chrome in Win 10. Rene thanks for the screen capture. It is interesting that I cannot see this formatting, but you can. Thanks! Chris So it's not just me. Hmmm... Feb 18, 2018 at 20:59
  • Huh. I don't see any bold or italics in that Music answer either. Weird. (Chrome 64.0.3282.167 on Windows 10)
    – Adam Lear StaffMod
    Feb 18, 2018 at 21:12
  • The bolding looks fine from the Android app. Feb 18, 2018 at 21:13
  • @AdamLear My earlier screenshot is made on a ... Windows 10 box with Chrome 64.0.3282.167 ... It must be something else then... In which timezone are you?
    – rene
    Feb 18, 2018 at 21:20
  • @rene Eastern US. The post looks like this to me: i.stack.imgur.com/PxPVb.png. Nothing immediately obvious in the console - no font loading errors, the HTML markup is correct, etc.
    – Adam Lear StaffMod
    Feb 18, 2018 at 21:25
  • 3
    Time for a disclaimer then: This answer is best viewed in the CET timezome ....
    – rene
    Feb 18, 2018 at 21:29
  • Weird, even the headers are less bold. @AdamLear
    – Catija
    Feb 18, 2018 at 21:45
  • I use windows 10 with Edge 41 and I can see it fine - i.stack.imgur.com/hm6en.png Feb 18, 2018 at 22:00
  • Try disabling all browser extensions. Does it look fine? Feb 18, 2018 at 23:32
  • @Ano I tried it in Firefox and IE and incognito mode in Chrome. I don't believe I have any extensions running in any of those and I still can't see the bold and italic.
    – ChrisF Mod
    Feb 18, 2018 at 23:56
  • @AdamLear I'm afraid part of the CSS is dead again. Feb 19, 2018 at 3:18

3 Answers 3

9

We had a similar issue on Graphic Design, it had to do with having OpenSans installed locally on the computer. Just uninstall the local version of OpenSans to fix it.

To uninstall OpenSans from Windows, open Control Panel -> Apperance and Personalization -> Fonts. Look for OpenSans and hit "Delete" in the right-click menu.

Click to see full image


It worked for me, so just as a test, I re-installed OpenSans and it stopped working again.


Sites that use OpenSans will have this issue: (feel free to add)

9
  • How do I uninstall the local version of the font? Feb 20, 2018 at 2:35
  • Open Fonts folder in Control panel and delete OpneSans
    – Welz
    Feb 20, 2018 at 2:39
  • Confirmed. I deleted OpenSans from my computer and bold and italic is back. Feb 20, 2018 at 3:18
  • Now to get SE to fix that...
    – Welz
    Feb 20, 2018 at 3:20
  • Why would this happen? Would Stack Exchange fix this?
    – Ooker
    Mar 1, 2018 at 9:10
  • @Ooker I'm not sure, I would hope so...
    – Welz
    Mar 1, 2018 at 11:31
  • This is an old, old problem that just keeps rearing its head in different scenarios; see also Roboto on Ubuntu. Ideally, your browser will choose a font that matches what the page calls for, but this seems to break if you have the family but not all the faces.
    – Shog9
    Mar 5, 2018 at 17:14
  • 2
    @Shog that's not entirely true, the problem is the local() part of the @font-face rules. You're explicitly looking for a local copy of the font first, but the way the font names are resolved depends a lot on platform and font so in a lot of cases you're looking for the wrong font
    – Cai
    Mar 6, 2018 at 9:17
  • @Shog9: Actually, it seems to be a bug in both SE's style sheet as well as in Chrome (and also in some versions of the Open Sans font itself). See the answer I just posted for details. Mar 9, 2018 at 19:09
3

The problem is (at least partly) the way the fonts are declared in the CSS. Each weight is defined in an @font-face rule, which loads the correct font file from the server but also includes a local() value which looks for a locally installed version of the font first. Like so...

The problem being that each weight is only given the same generic family name. How the font name is resolved locally varies depending on the platform and font, so declaring just the generic family name causes problems (the full family name and the PostScript name would need to be included at least).

Explicitly looking for a local version isn't usually a good idea though, exactly for this reason; your handing over control of what fonts are being loaded to the OS, font managers etc., which can (as they are here) serve a completely different font...

So removing the local() values should fix the problem (open up Dev Tools and just delete the whole local() part of each @font-face rule in primary.css to see for yourself).

5
  • If I understand the SO post your referenced (and the W3C documentation it references in turn) correctly, the bug is that the string inside local() should really be the full font name, including the style and/or weight, e.g. local(Open Sans Bold Italic) for, well, Open Sans Bold Italic. And the src really should also include the PostScript name (e.g. local(OpenSans-BoldItalic)) to work consistently on all operating systems. Mar 8, 2018 at 13:15
  • @IlmariKaronen yes, that's about right. The main point being that it depends on platform; IIRC (and I may be wrong) MacOS always uses the PostScript name and Windows uses either the PS name or the full name depending on font format.
    – Cai
    Mar 8, 2018 at 13:22
  • Ah yes (from the W3C spec) "The Postscript name is the commonly used key for all fonts on OSX and for Postscript CFF fonts under Windows. The full font name (nameID = 4) is used as a unique key for fonts with TrueType glyphs on Windows"
    – Cai
    Mar 8, 2018 at 13:26
  • Ps. Here's the CSS that Google Fonts generates for the Open Sans family. It is indeed using the full names (and PostScript names) for each face in local(). Mar 8, 2018 at 13:48
  • However, I also found a Chromium bug report saying that Chrome is currently doing the local() font name matching wrong. That said, using the correct CSS with Chrome just causes it to always use the webfont versions for the non-regular faces, which seems pretty harmless. And presumably, eventually the bug will be fixed. Mar 8, 2018 at 13:49
1

As Cai notes, the underlying cause of this bug is that the @font-face rules in the Stack Exchange style sheet are broken according to the W3C spec, which clearly states (emphasis mine) that:

For OpenType and TrueType fonts, this string is used to match only the Postscript name or the full font name in the name table of locally available fonts.

The full font names of the bold and italic faces of Open Sans are "Open Sans Bold" and "Open Sans Italic" (and their respective PostScript names are "OpenSans-Bold" and "OpenSans-Italic"), so the string local(Open Sans), as used in the Stack Exchange style sheet, will (on conformant browsers) never match either of them. In the best case, this simply leads to the fallback web fonts being used; in the worst case, it may cause the wrong (i.e. not bold/italic) face to be picked instead.


That said, the reason why this bug seems so hard to diagnose is that triggering the "worst case" above requires an odd combination of circumstances:

  1. First of all, the user must obviously have Open Sans installed locally; otherwise the correctly specified web fonts will simply get used.

  2. Second, either the user's browser or their copy of the Open Sans font must be buggy in a way that causes the local(Open Sans) name to incorrectly match the regular face of the font (rather than failing to match at all, as it really should).

So far, I've found two ways to trigger the second condition:

  • There are several different versions of Open Sans Regular floating around on the web. The one currently downloadable from Google Fonts has the full name "Open Sans Regular" (and the PostScript name "OpenSans-Regular"), the version string "Version 1.10", the unique font ID "1.10;1ASC;OpenSans-Regular" and the version number 72155. This version does not trigger the bug on conformant browsers.

    However, the version of Open Sans Regular available from many other sites (such as 1001 Fonts, to name just one example) instead has the full name "Open Sans" (and the PostScript name "OpenSans") without the "Regular" suffix. Confusingly, this version also carries the version string "Version 1.10", but it has the unique ID "Ascender - Open Sans Build 100" and the version number 72090. This version does have a full name matching local(Open Sans), and thus triggers the worst-case behavior on conformant browsers such as Firefox.

  • Separately, Chrome (and possibly other browsers based on the Chromium codebase) suffers from a known bug where it incorrectly matches local() against the family name instead of the full font name. Thus, having any version of Open Sans locally installed will trigger the worst-case behavior on Chrome.

Either way, to fix this bug, the SE style sheet should be fixed so that it correctly specifies the full name (and the PostScript name) of each local font face in local(). Here's an example of the correct syntax, courtesy of Google Fonts:

@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans Regular'), local('OpenSans-Regular'), url(...) format('woff2');
}
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 700;
  src: local('Open Sans Bold'), local('OpenSans-Bold'), url(...) format('woff2');
}
@font-face {
  font-family: 'Open Sans';
  font-style: italic;
  font-weight: 400;
  src: local('Open Sans Italic'), local('OpenSans-Italic'), url(...) format('woff2');
}
@font-face {
  font-family: 'Open Sans';
  font-style: italic;
  font-weight: 700;
  src: local('Open Sans Bold Italic'), local('OpenSans-BoldItalic'), url(...) format('woff2');
}

(Webfont URLs and extra rules for non-Latin subsets omitted for brevity.)

Note that, due to the aforementioned Chromium bug, using this corrected CSS will cause current Chrome versions to never make use of any locally installed copy of Open Sans. However, this is still better than the current behavior, where having a locally installed copy of Open Sans will break bold and italic text on Chrome.


Ps. One possible workaround for this Chrome bug might be to get rid of the local() font sources entirely and rename the CSS font family defined by the @font-face rules to some custom name like "Open Sans (WOFF)", like this:

@font-face {
  font-family: 'Open Sans (WOFF)';
  font-style: normal;
  font-weight: 400;
  src: url(...) format('woff2'); /* NOTE: no local() here! */
}
@font-face {
  font-family: 'Open Sans (WOFF)';
  font-style: normal;
  font-weight: 700;
  src: url(...) format('woff2');
}
@font-face {
  font-family: 'Open Sans (WOFF)';
  font-style: italic;
  font-weight: 400;
  src: url(...) format('woff2');
}
@font-face {
  font-family: 'Open Sans (WOFF)';
  font-style: italic;
  font-weight: 700;
  src: url(...) format('woff2');
}

Any font or font-family properties referencing Open Sans elsewhere in the style sheet could then be changed to look something like this:

html, body {
  font-family: 'Open Sans', 'Open Sans (WOFF)', 'Helvetica Neue', Helvetica, Arial, sans-serif;
  font-size: 13px;
  line-height: 1.30769231;
  color: #242729
}

In have not yet tested this, but in principle this should make Chrome (as well as other, conformant browsers like Firefox) prefer to use the locally installed Open Sans font, if any (but without triggering the broken local() matching), and only fall back to the custom "Open Sans (WOFF)" family if no local Open Sans is found. If the webfont cannot be downloaded either, the browsers should then try the other listed fallback font families.


Or, alternatively, SE could simply decide that webfonts are the future and drop local fonts (except for the generic serif / sans-serif / monospace fallbacks) from their style sheet entirely. While this would IMO be a suboptimal solution, it probably would be the path of least effort.

After all, the fact that this bug has not been reported more often than it has been kind of suggests that very few SE users (or at least, very few people using SE on Chrome) actually have Open Sans installed locally, and that the webfont is working fine for most people.

(That said, it should be noted that Open Sans and other webfonts are currently only used on a handful of smaller SE sites. The really big sites like SO don't currently use @font-face or webfonts at all, and introducing them to those sites might create a whole new set of bandwidth issues.)


BTW, assuming that no unexpected issues turn up, the next version of my SOUP user script / browser extension will include a workaround for this bug that simply overrides the broken SE @font-face rules with those from Google Fonts. It's already available for testing in the SOUP development branch, and seems to be working fine (with the caveats regarding Chrome noted above).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .