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.
Related
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.
I have ttf fonts from the web that are listed in ftp client* directory listing as windows ttf fonts. I am working with embedded fonts on Firefox on Mac OSX platform and I am getting the following web console error:
[17:59:49.201] downloadable font: rejected by sanitizer (font-family: "Cryv2" style:normal weight:normal stretch:normal src index:0) source: http://localhost/html5/css/fonts/new-fonts-ttf/CryUncial/Cryv2.ttf # http://localhos/html5/css/embeddedFontDeclarations.css
Is this because windows ttf is different? Or is the file corrupted?
If so, is there a way of screening font files from the web for usability, or converting windows ttf to more universal file?
I do and have converted ttf file to eot files for the sake of Internet Explorer, but I primarily work on DOM based
browsers, and Firefox for dev, authoring and testing on Mac OSX environment using pre-installed Apache server locally.
*ftp client is Fetch and text editor is BBedit. Firefox 12.0
http://caniuse.com/#feat=ttf
You can use ttf, but it needs to be a completely error free one, and encoded in Unicode, so Wingdings is an example of a problem in Firefox.
Please see this for reference: Wingdings font family does not seem to work on Firefox and Opera
Also, load it like http://www.example.com/xxx with the ws to ensure there isn't any problems. Sometimes servers act weird when you are testing on the site.
Here's a way of converting ttf to a whole set of universal fonts: http://www.fontsquirrel.com/tools/webfont-generator. Font Squirrel is a good choice. ;)
I downloaded the font from http://www.dafont.com/de/cry-uncial.font
and checked it with http://www.fontsquirrel.com/tools/webfont-generator
The only file working is "Cry Uncial Italic - crvy2i.ttf".
The other two font files are corrupt.
I guess, you need to rebuild the font (with a ttf editor) or switch.
What might work, too, is to work with converted fonts from that ttf.
You wrote, that you converted the font to "eot" already.
Try to convert to "woff" and "svg", too.
Then add the urls in this order "eot, woff, svg".
The browser would use the first good one (https://stackoverflow.com/a/21155626/1163786).
Just leave the corrupt ttf out.
Check this out.
Relevant text:
You get this error if you run out of memory when loading the fontfile
or if there is something wrong with the layout (contents) of the
fontfile. This is a protection against bad or malicious font files. It
is probably possible to disable the sanitizer by setting the pref
gfx.downloadable_fonts.sanitize to false in about:config but then you
are no longer protected. Use at your own risk. Do not blame Mozilla if
you are infected with malware.
Firefox does not support .ttf fonts but will accept .woff fonts. The case is same with Internet Explorer which accepts only .eot fonts. Try converting your .ttf to .woff or find .woff version for your font.
To Convert - > http://everythingfonts.com/ttf-to-woff
I am using #font-face to refer new fonts and it works fine.
My question is: are the font files downloaded to the computer from where my website is being visited or just stored temporarily? They do not get stored in Control Panel -> Fonts.
So is it just browser cache or the computer can get to have to font used in other software like Word etc?
Thanks for your help.
The short answer is no. When they're used in a webpage the browser just stores them temporarily. You would have to install the font separately for the other uses you mentioned.
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 recently finished a Genesis (v1.5) child theme for WordPress (v3.1), uploaded it to my site and the fonts aren't appearing as they should. I used Font Squirrel to make the appropriate files and CSS for the font. I have permission from the font designer to use it for web embedding. This same code works great on my test site.
I used Firebug (v1.6.2) in Firefox (on OS X, v3.6.15) and found that the font files were getting 404 errors. I've triple checked the files and they are where they should be. I've uploaded them again and again and still get 404 errors on the font files. The fonts do not work in Chrome (on OS X, v10.0.648.133), Internet Explorer (on Win XP SP3, v8.0.6001.18702), or Firefox (on Win XP SP3, v3.6.15).
I tried turning off plugin one-by-one, but that didn't make any difference, so I know it's not a plugin conflict. I'm looking at the font files on the server, so I know they are there. Any ideas what to try next?
NOTE: I changed the CSS for the title font size on the production site since it jacked up the layout without the correct font. Otherwise, the code is identical to the test site. Note the "Remove these once font-face works" section at the top of the CSS file.
I too was getting 404 errors with my face-face files in WordPress. The files were there but I was getting a 404 inside WordPress.
I moved my font directory out of WordPress and put it into the root of the domain and changed my CSS accordingly.
All OK now.
In production site you have your fonts in fonts/ directory, while in the test case only "GuildofProfessionalActorsRegu" links to fonts/ and if you change the font family on #title a with firebug you'll see a your custom font. Try fixing the first rule.
Using any proxy?
At my work I can't see mines in a web I did some time ago...