Ampersands in documentation are drawn incorrectly in some browser configurations

[nstoddard]

On my system, ampersands in the documentation are drawn incorrectly in Chrome: https://i.imgur.com/FmG93G5.png. I'm using Windows 7, 64-bit. This doesn't happen in Firefox.

I'm thinking this could be a bug in Chrome, but I haven't seen it on any other site. It seems to happen on any page generated with rustdoc. Ampersands in the examples aren't affected.

[nstoddard]

It looks like this is similar to #16372. I deleted the Source Code Pro font, which fixed it. Since I'm at least the second person to come across this issue, maybe we should try to find a more permanent solution. Is it possible for rustdoc to automatically download and use the most recent version of the font? If not, maybe this issue should at least be documented somewhere.

I'm still not sure why this issue was happening in Chrome but not Firefox.

[killercup]

Is there a reason why for the Source (\w*) Pro fonts the locally installed version is requested first, but not for Fira Sans (cf. rustdoc's main.css)? Are there many people who have those installed? (Even then, why not give Fira the same chance?)

If we are concerned about file sizes or compatibility, we should probably add woff2 (newer, smaller format) and eot (legacy IE format) versions of the fonts.

[ZobyTwo]

I dont have any of those fonts installed and still have the same issue (windows, chrome). I found (https://code.google.com/p/googlefontdirectory/issues/detail?id=178) which suggests that there is a newer version of the font which might fix the problem.

[azerupi]

It may be a good idea to use a CDN for the font's (like Google font) with a local fallback when the CDN can't be reached, for example when offline. This has a couple of advantages

• loading the latest version from the CDN
• parallel http request and thus faster load times
• if the font from the CDN has been loaded on another page, it will be cached and thus speed up the page load too.

It might be interesting to do that for jQuery too since it is the most downloaded js library there is a very high probability that it will already be in the browser cache.

[jonimake]

Still happening with Chrome 48.0.2564.103 m and Windows 10.

[jonas-schievink]

This is getting pretty annoying now, and this happens on basically the most common Windows configuration (plus, this issue is almost a year old now). Can't we just use another font for now?

[ghost]

I have this issue too, fresh Chrome on Win8.1.

I personally use a browser plugin to change the fonts on the documentation pages, but that's not an ideal solution.

Edit: I submitted an issue on this to Google Fonts.

[sateffen]

Hey,

I've got the same problem with the ampersands, and it makes the documentation very hard to read. After some time you can get used to it, but at first this not just sucks, it tells me to leave the page and never come back.

The solution to update the font on all of my computers is not acceptable for me. I have 2 win10 and 2 win7 machines having the same problem, all in chrome browser, and to be honest: I don't want to update my computers by hand, just for one website. Even if it's a chrome problem, there is a way to work around that problem.

Why not just remove the font, and use the other ones? DejaVu Sans Mono looks very clean and good, and it's been around for quite some time, so I guess it's glitch free?

[brson]

Let's just add another similar font at a higher priority. Help wanted.

[matthew-piziak]

The current hierarchy is already Source Code Pro > Menlo > Monaco > Consolas > DejaVu Sans Mono > Inconsolata > monospace, so removing Source Code Pro is probably sufficient.

[nagisa]

For all its worth we probably should just use monospace without any of those stuffs that come before it, because if anybody cares about fonts at least a little bit, their system will have monospace equal to something that looks good and has good glyph coverage (cough… Source Code Pro… cough) anyway 😉.

[matthew-piziak]

The disadvantage there is that we lose the ability to predict which font most people will have active (something which is useful for design). Moreover if Source Code Pro is their monospace default, this bug will continue to affect them.

[nagisa]

Moreover if Source Code Pro is their monospace default, this bug will continue to affect them.

Some old version of Source Code Pro obtained from the fishy source that google fonts is, which is getting more unlikely over time.

To make it clear, I’ve never been affected by this bug and SCP is set to be the default monospace font on my system. I would like to keep reading rustdoc in SCP, and couldn’t care about design or whatnot any less.

[matthew-piziak]

I understand your reasoning now.

[eternaleye]

Meanwhile, I agree with @nagisa regarding just using monospace because I have mine set to Inconsolata Go, and am similarly unmoved by "design" as an argument (especially given this mostly applies to... types and signatures, which were not carefully chosen to fit some form of web-first design).

[matthew-piziak]

Yep, I'm convinced. 👍

[nrc]

So looking at Rustdoc's CSS I find this : src: local('Source Code Pro'), url("SourceCodePro-Regular.woff") format('woff'); which seems to imply we'll use the local version of source code pro before the web font version. I think just removing the local clause will force using the web font and thus avoid the buggy old version of the font that some people have on their systems.

[Boddlnagg]

I've been affected by this bug multiple times, since something on my machine (Windows) seems to keep reinstalling an old version of Source Code Pro. I haven't been able to figure out what it is. @nrc's fix sounds like the right solution to me.

[sourcefrog]

See also /issues/34681, around a same-origin problem loading fonts from the doc tree on Firefox. It seems like just removing the local clause could make that happen more often?

[sourcefrog]

I made the change suggested by @nrc of removing use of the local font in . The results are in https://storage.googleapis.com/mbp-rust-builds/fonts/doc/std/index.html so perhaps people who can reproduce this can try that and report how it looks.