I have a social network that allows users to choose fonts for their profiles. It works great on Chrome, Safari and Firefox but IE7-9 does not play well.
What should I change in my font php file to echo some nice css? Here is the code:
$fontovi_style='';
foreach(explode(",", str_replace("\n",'',file_get_contents(ROOT.'media/font-list.txt'))) as $k=>$v){
$ime=str_ireplace('.ttf','',$v);
$fontovi_style.='#font-face {font-family:"'.$ime.'";src: url("/media/fonts/'.$v.'")
format("truetype");}'."\n";
}
echo $fontovi_style;
Internet Explorer does not support TTF, it only supports EOT.
Check this link for further explanation.
This is to some extent a duplicate of this question
I'd just like to make an observations though: Generating this list on the fly for every single page slows down page load plus it puts some extra load on your server (ie it's not cacheable, it makes your pages larger, I/O reading the font list every time, etc)
go to this link http://www.fontsquirrel.com/fontface/generator
upload your font
then download all files have different font formats which is supported for different browsers and use in your project. now it will work accurately in all browsers
Related
I've been referencing the findings in this thread and in this question when trying to get a custom font that uses embedded bitmaps to render them via #font-face, and in my experimentation with fonts that I know are configured correctly, I found the following results displaying 日本語 using Windows 10 and Vivaldi (Chrome, etc), with ClearType on and configured (unsure if this matters):
span {
font-family: "SimSun"; // or just omitted, since this is a fallback font
}
#font-face { font-family: "font"; font-weight: normal; src: url('simsun_0.ttc'); }
span {
font-family: "font";
}
simsum_0.ttc is the font that I pulled from C:/Windows/Fonts/ and placed in the folder where the css lives. I've also verified that this file does indeed have embedded bitmaps and is configured correctly.
I've since just installed the font I'm working on and referenced it via its system name, which then loads the bitmaps correctly. Is there any way to get browsers to load the bitmaps from fonts loaded via #font-face? Is there any documentation or spec on this limitation, or possible work-arounds?
More examples
This works the same for custom-built fonts as well - here's an example with an .otf font in Chrome. The font loaded via it's name when installed on the system:
and the same font loaded via #font-face's url:
Chrome and Firefox (and likely others) run OTS on the fonts not available in the system, which removes the EBDT & EBLC tables (where the bitmaps are stored) from the font.
From the OTS readme:
The OpenType Sanitizer (OTS) parses and serializes OpenType files (OTF, TTF) and WOFF and WOFF2 font files, validating them and sanitizing them as it goes.
The C library is integrated into Chromium and Firefox, and also simple command line tools to check files offline in a Terminal.
The CSS font-face property is great for web typography. Having to use images in order to get the correct typeface is a great sadness; one should be able to use vectors.
However, on many platforms the system-level TrueType font renderers have never been part of the attack surface before, and putting them on the front line is a scary proposition... Especially on platforms like Windows, where it's a closed-source blob running with high privilege.
In 2014, there was interest in adding color bitmap tables to Chromium, and support was added to pass-through the color bitmap (CBDT & CBLC) tables to OTS, so it seems possible that support could be added for these as well, if the browser requests it.
The steps I see to make this possible are:
Add the ability to pass-through the EBDT & EBLC tables to OTS. This is the current location of the code that passes the color tables through.
Request that each project (Chromium, Firefox, etc) allow the pass-through.
Wait for all the updated code to be pushed down-stream.
There might be more complicated implementations of this sort of support (options in #font-face, etc), but this seems like the easiest, since the color tables are already supported (somewhat) in the same way.
A reliable and easy option is to use a service like FontSquirrel.
https://www.fontsquirrel.com/tools/webfont-generator
Upload the fonts and it will generate everything you need so you can download, copy and paste into your project.
Good luck!
The problem is #font-face doesn't support TrueType Collections (.ttc) files, so it will fail loading it. Does the console give you errors indicating something like this?
You could use a tool to extracy the needed .ttf from the .ttc file, if the license allows this. Or you could ask the foundry you got the font from to supply you with a .ttf (or .woff2, whatevr you need).
I'm using Open Sans on my site, and I'm noticing from the handy colored dial on Google Web Fonts, that if I want the light, italic, semi bold, bold, and other styles, that it becomes quite a heavy download for the end user.
Is this really a problem with a font as popular as Open Sans? Do browsers download Open Sans all over again every time a website has their own file listed in an #font-face declaration?
Am I incurring expensive HTTP requests, or am I just adding what is missing? So that if a browser already has Open Sans Regular, Italic, and Bold (and bold italic), they're only grabbing Light and Semi Bold from me?
Preemptive Update I've used the local() expression in my #font-face declaration, and it's given me real bad problems with italic styling, it basically ignores it.
Unless you use local(), which you say you have problems with and which is prone to users having different font files than the one you assume they have, font files are just like any other resource (scripts, images, style-sheets).
They will get cached by browsers, depending on user preferences - this meaning they only get downloaded once and used from cache from that point on, until the cache expires or gets cleaned.
If you define a #font-face and specify font files for it, the first format the browser understands from the list of font file formats you list will be downloaded and used. That's why you normally list the lightest formats first and the heaviest last: (woff2 > woff > ttf > svg).
Please note that if you serve the font files from your server browsers will never use the font-files from, let's say Google, even if they are exactly the same. This gives you the option to serve modified font-files. But if you use font-files from Google, users might already have them cached, and they will be used if they had the exact same download link (same weights, same variants).
I added a bit of css (#font-face)script in my Luna theme on Bigcartel. the font works but not in safari and mozilla where do I have to look to get this working in those browsers ?
here is the answer I followed and used the script from:
Can I upload a custom font to big cartel
You need to configure your webserver to allow font files to be loaded from a separate domain - if you check the Network tab in your browser's web inspector you'll likely see an error about it.
There's lots of good info on how to do that here: How to add an Access-Control-Allow-Origin header
In CSS why is a backup font recommended if I am uploading a custom font for use with the webpage?
I thought the backup fonts were only needed in case the client doesn't have the 1st/2nd/3rd..etc choice installed.
For example if you have this code:
#font-face {
font-family: MyCustomFont;
src: url('../fonts/MyCustomFont.ttf');
}
Why is this necessary?
body {
font-family: MyCustomFont, Arial, Helvetica, sans-serif;
}
It's not necessary to specify a font stack, but it helps to degrade gracefully in obscure cases when a browser is unable to use the font somehow, e.g. if the HTTP request for the font file times out, the font file itself becomes corrupted or otherwise unusable, the browser doesn't support any of the given font formats, among others.
You should do your best to ensure the custom font gets downloaded and used properly, of course. But things can and do happen that are out of your control sometimes, so it doesn't hurt to still have something nice to fall back to. That's why they're called backup or fallback fonts :)
DaveRandom, these would be the only nested while loops involved in the business of computing.
I figured out a way to integrate Google Fonts without any of the problems usually found when 3rd party fonts are used.
First off, we know our Google Fonts files are in the .woff format and may not work in all browsers.
Second, if a Google Cloud or some other molest prevents the download of the font file from our server due to cache restrictions or other network limits we know this pseudo-state of connectivity will likely support the .woff fonts from Google Fonts.
To the credit of Google we may be able to load our images in some other way so why not try a Google Fonts version of our end product.. so here is why not:
In order to insure the font remains the same when adding Google Fonts I recommend not removing the self-hosted fonts unless a verified plaintiff requests you do so for rights ownership reasons.
Instead of removing self-hosted fonts which are the true key to real cross-browser compatibility, create a same-font entry in CSS that specifies it's font title as 3rd party such as: 'ArialVanityGoogleFonts'.
Use the browser's built-in font fallback .csv and include the fonts as follows: ArialVanity, ArialVanityGoogleFonts, Arial
I have no idea why this is happening. I am following the standard tried and tested method of using google web fonts
<link href='http://fonts.googleapis.com/css?family=Sunshiney' rel='stylesheet' type='text/css'>
<style>
h1{ font-family: 'Sunshiney', cursive; }
</style>
<h1>Hi there</h1>
This works in Safari, Chrome and IE but not FF7.
Has anyone come across this. I've also tried using the JS integration and the #import syntax and it is the same. I'm really stuck.
This is a known issue with Google Web Fonts. An internal configuration change broke serving of one of the headers needed for reliable operation in Firefox and IE9+. The fix is propagating now and it should be working soon.
Thanks for reporting the issue!
(I'm an engineer on the Google Web Fonts team, found this in a twitter search trying to investigate how deep the breakage went)
I think its problem with google
On my browser FF 7.01 is show Comics Sans
http://fonts.googleapis.com/css?family=Sunshiney => redirect to
themes.googleusercontent.com/static/fonts/sunshiney/[...]3HZu7kw.woff
And response with no font data
but when type this adress in url bar i can save this font
so.
Just download this font and simple embennded to webpage
Will be faster
eq
====> 0,20second to download family=Sunshiney
=====> 0,30 to download woff font
There is currently an issue on Google's end with the Webfonts. It's odd because they were working just a few days ago, and I've seen them load up once or twice, but otherwise it's reverting to the fallback font.
Your best option is to download the file and manually embed it into your webpage using #font-face. There's a good article on that at Six Revisions.
I hope Google gets it sorted soon.
Just in case it helps someone, I just had a problem with Google Web Fonts not rendering on a colleague's Mac, but working on other (similarly configured) Macs. It was obviously something client side, and turned out to be the browser.display.use_document_fonts setting (see here).
To stop it happening, it's a case of going to Preferences .. Content .. Fonts & Colors .. Advanced and making sure "Allow pages to chose their own fonts, instead of my selections above" is checked.