When I make an edit to the stylesheet of my site, the change appears in Chrome (I load the CSS file in the browser, so I can see the edit is there). When I open the CSS file in Firefox, the edit is not there. I understand browsers will render code differently, but how is it possible that two browsers can open the same CSS file and display two different sets of code?
I tried:
deleting Firefox's cache and restarting the program
deleting the old stylesheet via FTP and uploading an edited one
I checked if the site had a CDN that was perhaps serving the old
file, but the site has no CDN.
I am developing a website that uses the Google font Open Sans like so:
<link href='https://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,600,600italic,700italic,800italic,800,700' rel='stylesheet' type='text/css'>
Normally, I use Chrome when working with my website, but today I decided to see how it looks in IE 11 (11.0.10240.16431) on Windows 10. Unfortunately, Open Sans isn't being loaded and rendered properly. I see lots of these errors in the Developer Tools console:
CSS3111: #font-face encountered unknown error.
PRmiXeptR36kaC0GEAetxjqR_3kx9_hJXbbyU8S6IN0.woff
Thinking that was strange--I had previously developed a site that loaded Google Fonts just fine in IE 10--I headed on over to https://www.google.com/fonts. More CSS3111 errors, with every custom font being displayed in serif instead:
Is Google Fonts simply broken for IE 11? The fonts do load correctly in Edge, Chrome, Firefox, etc. I am at a loss for how to proceed to get these fonts to work in IE.
UPDATE 1
Setting the emulated document mode to 8 in IE 11 causes the fonts to render correctly. IE 9+ still exhibited the same issues, however. Is this some kind of incorrect user agent string processing by Google, perhaps?
UPDATE 2
I went to FontSquirrel and downloaded Open Sans in all its formats. I also imported the CSS provided in the ZIP. Unfortunately, IE and now Firefox continue to report that the font can't be used. Firefox says downloadable font: not usable by platform.
UPDATE 3
I've confirmed that IE's Font download setting is set to Enabled for all security zones.
For me, this issue was caused by a Windows 10 feature called Untrusted Font Blocking. My office network had this turned on in our group policy settings.
Using this feature, you can turn on a global setting that stops users from loading untrusted fonts that are processed by the Graphics Device Interface (GDI). Untrusted fonts are any fonts that are installed outside the %windir%/Fonts directory. https://support.microsoft.com/en-us/kb/3053676
To disable Untrusted Font Blocking using Group Policy:
Open Group Policy Management Editor
Under Local Computer Policy, expand Computer Configuration, expand Administrative Templates, expand System, and then click Mitigation Options.
In the Untrusted Font Blocking setting select Do not block untrusted fonts
To disable Untrusted Font Blocking using Registry Editor:
Open Registry Editor (regedit.exe) and go to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\
If the MitigationOptions key is not there, right-click and add a new QWORD (64-bit) Value, naming it as MitigationOptions.
To turn this feature off. Type 2000000000000.
IMPORTANT: A computer restart is required for the changes to take effect
As weird as it sounds, the solution is to turn on the Windows firewall. With the firewall switched off, you cannot even add TTF fonts to the system, and this is the same problem as with #font-face. I've found that solution here: https://superuser.com/questions/957907/unable-to-install-fonts-on-windows-10
Don't worry about font blocking. Turn your fonts into base64 and include through CSS. This way you push the fonts through the browser code and the font files are not downloaded in the usual fashion. This is also a DISA STIG issue to disable downloadable fonts. The solution can be seen at this post and also copied here:
You just need to Base64 the font and include it in a CSS file. Make sure to remove your call to the downloadable WOFF file once you include the call to the new FontAwesomeB64.css
Use https://www.base64encode.org/ to encode the WOFF Font-Awesome font file.
Edit the the resulting file and add these lines. When you get to the src:url line, make sure to run that right into the base64 information you received (don't use the greater than and less than signs I show here.) At the end of that base64 information add the single quote, parentheses, a semi-colon, and curly brace to finish:
#font-face {
font-weight: 400;
font-style: normal;
font-family: 'FontAwesome';
src:url(data:application/x-font-woff;base64,<insert base64 code here>);}
You now have a base64 CSS file of the Font-Awesome font that bypasses all font download denial settings in browsers.
I've found that this works with all fonts, a little heavier on the download but worth the guarantee of functionality.
I have this exact problem on many Windows 10 / IE 11 machines (ie web fonts do not work and give CSS3111 errors in the debug console). In all cases the firewall was already on (and managed by group policy).
I found that disabling the firewall in the registry
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\EnableFirewall = 0
followed by a reboot, then setting it back to 1 and rebooting again fixes the problem.
The other thing that always fixes the problem is to unselect "Internet Explorer" in the Windows Features, reboot, then reselect "Internet Explorer" and reboot again.
My guess is that this is some type of internal windows firewall bug and both of the above actions trigger the firewall service to clean up some type of internal corruption.
In Windows 10 there are three levels for font blocking:
IE security settings for downloading fonts (user part)
Option "untrusted font blocking" (Computer level)
Option" Enable front providers" (Computer level)
You have to enable all, to get it working.
When you have a font installed on your system, but the website you're visiting is using google fonts (in this case Muli), does IE9 load up your installed font file, or the one from Google?
In other words, how does IE9 prioritize which font file to load if there are two available with the same name?
EDIT:
I think the answer is that it uses the downloaded version of the font. I installed Muli and then used fiddler to watch the site and it downloaded the .eot
I'm not 100% sure that's right but it seems like it is. Doesn't explain why my client's fonts look ~ever~ so slightly different than mine, but she has some other issues I can't replicate so it might be a larger issue than just fonts.
Start IE, load the page (either locally or by internet), press the F12 key, click the Network tab, click the Start Capturing button, refresh the page. Does your font file appear within the list? If not then it is probably loaded from the OS and not from Google.
I have a django site running locally. Everything seems ok except the CSS files that can not be loaded by Chrome. I can see a Failed to load resource error in the console.
The site is ok in firefox
The site is ok if I get the css not from the local server but from the production server
The css source can be viewed correctly
I have no special blocker plugin install
The css is rather big but I still have the issue if I use a very short file
I have similar issues with some js files (ckeditor)
It works of with some other css and js (admin css for example)
The django app has been developped with 1.0 and I am in the process of moving it to 1.4. The css and js files are served as media
Any idea?
Didn't find the real cause but the problem is solved. Maybe because it was served as media and now it is served as a static.
I have an HTML page that is converted to PDF via wkhtmltopdf. Everything works nice and dandy on my local machine, Arabic fonts, PDF conversion to them, new custom fonts. I used #font-face, locally stored fonts, and utf-8 encoding. No problems.
But up on the server, not only do (1) Arabic characters turn into black boxes,
but (2) even not-that-extraordinary English fonts (like Georgia and Impact) stop working. The PDF is rendered in plain sans-serif. That is, if it renders at all. At times it doesn't even produce output. I've added #font-face rules on my CSS for the server but wkhtmltopdf doesn't seem to pick them up. I know these fonts and paths are fine on the server because the HTML page uses the same CSS style sheet and it renders perfectly.
If I do simple plain text without any odd fonts, wkhtmltopdf works fine.
Any ideas? Does this have to do with being on the server? My local machine has Windows 7, the server's running Linux.
Problem solved. I did indeed need to upgrade my hosting plan so I could run the wkhtmltopdf static binary with X11. Although the Linux machine only has some Nimbus fonts on it, Arabic and other fonts are working fine for me by adding the font files and using #font-face css rules.
Additional note: to get Arabic text rendering properly using custom Arabic font files, I generated the required font files and css rules using FontSquirrel, with "No subsetting" under "Expert" rendering options.