rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
99.2k stars 12.81k forks source link

rust-lang.org and crate documentation pages require "fira" font #19257

Closed rnd42 closed 9 years ago

rnd42 commented 10 years ago

I've actually had this problem for a while now but just decided to troubleshoot it. So here's what I was initially seeing:

no-font

Then i found and disabled a single CSS rule and got this:

no-css-rule

I would file this issue with the rust-lang/rust-www repository but then I had the same problem with viewing documentation pages from 3rd-party crates hosted on Github so I'm assuming it's Rust's documentation generator itself that is generating this CSS rule. I have installed the "fira" font from the ArchLinux AUR and no longer have to disable the CSS rule, but there really should be a fall-back font set. In case it's relevant I'm running ArchLinux x86_64, Gnome 3.14.2 and Firefox 33.1.1.

tomjakubowski commented 10 years ago

That's very odd, because there are several fallback fonts, including the fallback of fallbacks sans-serif, and Fira Sans should be loaded as a @font-face font. If Fira fails to load for whatever reason (including if you have disabled @font-face in your browser or with an extension), sans-serif as a fallback should still show something reasonable.

adam-frisby commented 10 years ago

I don't think this is a problem with the fallback. What your first screenshot looks like is what the page looks like in Firefox before the fonts download.

What might be useful is the "Network" tab and make sure to do a hard refresh (Ctrl + F5)

(Although it might not attempt to download the font at all now you have it installed)

rnd42 commented 10 years ago

I agree that the CSS rule seems like it should work fine. I uninstalled "Fira" to troubleshoot this further. You mentioned that the font should be downloaded which made me realize I should check NoScript, but it doesn't show any blocked resources... So just to be extra safe I disabled ALL extensions but I'm still getting invisible text. So here is a screen shot of my "Network" tab with all extensions disabled after a hard refresh:

network-tab

Just to be thorough I tried this from Google Chrome but that displays the page without text as well. I even tried changing my GTK+ and Firefox themes in case it was just inheriting some white text rule from there, but it didn't have any effect. Just incase you want an example of 3rd-party documentation with similar issues here's a screenshot from https://hyperium.github.io/hyper/hyper/index.html with the networking tab open (Note that the SourceSerifPro-Regular font seems to download and display fine):

hyper-docs

And with the CSS rule mentioning "Fira" disabled:

hyper-fira-disabled

steveklabnik commented 10 years ago

This has been a persistent problem in Chrome, I know there were some previous tickets about it. Havne't been able to diagnose a root cause :/

mahkoh commented 10 years ago

The root cause is that simply using the system fonts isn't considered webscale enough for a hip language such as rust.

steveklabnik commented 10 years ago

Not helpful.

tomjakubowski commented 10 years ago

@steveklabnik do you know if this has been a persistent problem in Firefox as well? Looks like @rnd42 sees it in both Chrome and Firefox.

MatejLach commented 10 years ago

I can confirm this problem in Chrome as well as Firefox when I don't have the Fira Sans fonts installed. Also, I don't have @font-face disabled. I think the bigger problem arising from this is that rustdoc documentation won't show up properly without having these fonts, making rustdoc somewhat problematic within intranets etc. Funnily enough, on mobile Chrome (Android 5.0), it works fine, which would suggest that the mobile CSS is written correctly, because Android doesn't have Fira Sans and so the fallback kicks in as it should. Maybe comparing the mobile/desktop css in the relevant sections will provide some leads.

tomjakubowski commented 10 years ago

As another data point I don't have any Fira fonts installed on either of my Arch Linux boxes and the font loads and page renders fine for me in both Firefox 31 and Chromium 39.

steveklabnik commented 10 years ago

@tomjakubowski I was pretty sure it was just Chrome, but I didn't see that someone also reported a Firefox.

I use Firefox with basically no fonts installed and it works just fine on Debian Jessie.

steveklabnik commented 10 years ago

@MatejLach I still believe this has something to do with a corrupted local font install, which the browser doesn't realize is corrupted. I could be wrong, though.

MatejLach commented 10 years ago

@steveklabnik I don't know about the corrupted fonts thing, since for me it happens consistently across 2 arch machines and only on rust-lang.org, which would suggest that the problem isn't on my side, although I could not verify it 100%.

steveklabnik commented 10 years ago

Ahhh interesting.

tomjakubowski commented 10 years ago

@tomjakubowski I was pretty sure it was just Chrome, but I didn't see that someone also reported a Firefox.

That was reported in the OP of this issue :smile:

adrientetar commented 10 years ago

Funnily enough, on mobile Chrome (Android 5.0), it works fine, which would suggest that the mobile CSS is written correctly, because Android doesn't have Fira Sans and so the fallback kicks in as it should.

  • The same CSS is used regardless of the client afaict.
  • It works for me under Ubuntu and Windows (7, 8.1).

Can you specify on which OS (or distro) you are

MatejLach commented 10 years ago

@adrientetar On my desktop and laptop I use Arch x64, which isn't saying much since Arch doesn't come with any fonts preinstalled, so I guess simply not having the proper fallback fonts installed is the issue here, since installing Fira Sans resolves it, I guess it's not a big deal in the end, although it is a bit strange that so far rust-lang.org is the only site where I observe this problem (and of course in rustdoc by extension).

adrientetar commented 10 years ago

@MatejLach sans-serif at the end of the font stack means that the browser should use the default sans-serif font. This will work on any browser so clearly there is an issue with arch. Talking about Firefox, it should stop trying to use the webfont and switch to fallback if it does not load within 3 seconds after the concurrent rendering steps are done. Clearly there is an issue going on here that is specific to Arch.

MatejLach commented 10 years ago

@adrientetar Most likely, this is indeed specific to Arch, because I have dozen sans-serif fonts from the Google Web Fonts directory installed, I just can't think of as to why the problem would actually occur with Arch. May need to ask around.

arslan commented 9 years ago

I had a similar problem (July 2014) and solved it. (rust-lang/rust-www/issues/51). I will quote the solution here: "The problem was caused by the font that was already installed on my system as part of google fonts stack, which happens to bear the same name as the font that was supposed to be downloaded from the website. After deleting it from my system all browsers started sending request for the font from the website, which solved the problem."

rnd42 commented 9 years ago

Thank you rcx, that's exactly the problem I had. I did the following to fix it:

$ mkdir ~/temp

remove the Fira fonts installed from the ttf-google-fonts-git package:

$ sudo mv /usr/share/fonts/TTF/Fira* ~/temp/

If you installed the Fira font packages via yaourt to fix this you can now uninstall them:

$ yaourt -R otf-fira-mono otf-fira-sans

and now I can view the site fine.

adrientetar commented 9 years ago

We call local fonts first in the CSS. Would removing that call a good thing? Assuming other people affected also run Arch?

adrientetar commented 9 years ago

(I still believe that there is a bug which should be reported to Arch maintainers.)

MatejLach commented 9 years ago

@adrientetar I would report it, expect that I am not sure which part of the font stack this bug touches. Also, stuff like the Google Web Fonts isn't maintained in the official repos, but in AUR, which is user-maintained

rnd42 commented 9 years ago

I added a comment to a preexisting issue at https://code.google.com/p/googlefontdirectory/issues/detail?id=368 . Thanks for your help.