CSS #font-face - what does "src: local('☺')" mean? - css

I'm using #font-face for the first time and downloaded a font-kit from fontsquirrel
The code they recommend inserting into my CSS is:
#font-face {
font-family: 'junctionregularRegular';
src: url('Junction-webfont.eot');
src: local('☺'),
url('Junction-webfont.woff') format('woff'),
url('Junction-webfont.ttf') format('truetype'),
url('Junction-webfont.svg#webfontoNEpZXy2') format('svg');
}
Now, the smiley face thing has me stumped. But so too does the number of urls in the src - why do they recommend so many files and will they all be sent to the browser when a page is rendered? Is there any harm in removing all but the .ttf?

if you read the notes in font-squirrel's font-face generator, you'll see that it was a gotcha by paul irish.
Here is the excerpt from his blog post:
And.. regarding #font-face syntax
I now recommend the bulletproof smiley variation over the original bulletproof syntax.
#font-face {
font-family: 'Graublau Web';
src: url('GraublauWeb.eot');
src: local('☺'),
url('GraublauWeb.woff') format('woff'), url('GraublauWeb.ttf') format('truetype');
}
From the bulletproof post:
Yes, it's a smiley face. The OpenType spec indicates any two-byte unicode characters won't work in a font name on Mac at all, so that lessens the likelihood that someone actually released a font with such a name.
There are a few reasons why smiley is a better solution:
Webkit+Font Management software can
mess up local references, like
turning glyphs into A blocks.
On OS X, Font Management software may
alter system settings to show a
dialog when trying to access a
local() font that's accessible
outside of Library/Fonts. More detail
on my bulletproof post.
Font Explorer X is
also known to mess up other stuff in
Firefox.
Although it's unlikely, you could
reference a local() font which is
completely different than what you
think it is. (Typophile post on
different fonts, same name) At the
very least its a risk, and you're
ceding control of the type to both
the browser and host machine. This
risk may not be worth the benefit of
avoiding the font download.
These are all pretty edge case issues, but it's worth considering.

The local(☺︎) is a css hack to divert IE6-8 from downloading fonts it can't use (it can only use fonts in EOT format).
Explained: The last src property takes precedence in the CSS cascade, meaning that the CSS will be parsed from bottom to top. The local(☺︎) will make IE skip the src at the bottom, without wasting bandwidth downloading fonts it can't use, and rather go straight to the font in .eot format (defined on the line above in your question) that it will use. The smiley is just to ensure there won't be a local font with that name (character combination).
Read more here: http://nicewebtype.com/notes/2009/10/30/how-to-use-css-font-face/

Related

Chrome uses a different baseline for my webfonts [duplicate]

I'm using a custom font in a page I'm developing, Droid Sans, and at certain font sizes, the bottom is cut off, but only in Opera and webkit browsers.
It's easy to reproduce on Google's own webfonts page looking for Droid Sans and showing the whole alphabet at 18px: http://www.google.com/webfonts
It's especially clear for the lower case g.
Is there some css trick / hack I can use to increase the line height / show the whole character or am I really limited to only certain sizes of the font?
line-height and padding for example don't change anything and 20px font-size works fine and at the moment I am using Windows 7.
Edit: By the way, I am aware of a similar question here but as the accepted answer is changing the font size and the rest of the answers do not apply, it is of not much use to me.
Edit 2: An example that at least for now shows the problem (left hand column, under the slideshow, Il Cerca Viaggi).
Edit 3: The problem seems to be limited to Windows although I'm not sure which versions.
Edit 4: I have added a screenshot from Google Webfonts to show that the problem is not specific to the site I'm developing.
Although it is not the solution I am looking for, I have found a possible solution that might work for others:
In my original style-sheet I have specified the font as follows:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype'),
url('droid-sans/DroidSans-webfont.svg#DroidSans') format('svg');
font-weight: normal;
font-style: normal;
}
This is causing webkit browsers to use the woff file / format.
Changing the order of the font specifications and removing the hash-tag after the svg specification (why is that there anyway?), causes webkit browsers to use the svg file / format:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.svg') format('svg'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
This solves the problem, all characters are displayed correctly.
However, at least in Windows 7 64bit, the svg font is not as sharp as the woff font, it's kind of blurry so I will not be using this solution and am hoping for a better one.
To a similar question, one answer suggested that, while this appears to be a Windows font rendering issue specifically, hosting svg, eot and otf versions of a TrueType font (TTF) containing the font, which was not optimized for the web, had fixed the problem for its provider. If possible, get a clean, un-optimized version of the DroidSans font and export the web fonts yourself.
EDIT: Sorry all, I was out for the holiday and didn't have access to SO. Since I've been back, I've done a little research into exactly what's causing this problem on Windows machines...
It appears that the issue lies with the way the OpenType format is rendered on Windows machines. The issue with truncated descenders seems to transcend software type to affect multiple Windows programs attempting to render OpenType. Currently, you have the Embedded OpenType format (EOT) version of the font listed first in your CSS document under #font-face. Since Chrome and Opera both recognize this format, they'll disregard the subsequent source declarations and use EOT to display the font. Unfortunately, there doesn't seem to be a quick fix that you could apply to an OpenType font itself to force the software rendering it to allow adequate line-spacing for the lowest of its descenders on Windows machines...
However, you can be choosy about which fonts you feed to your viewers' browsers. Personally, I would recommend placing the SVG version first in your CSS, and for browsers that don't recognize this format, suggest TrueType (TTF) second, then WOFF, then EOT for browsers that don't support any of the aforementioned (some older versions of IE appear to support OpenType exculsively). If the SVG rendering isn't much to your liking, try TrueType first instead.
Alternatively, although I'm no longer really that confident that it will help, you can download a TTF of DroidSans at FontSquirrel and use a software package like Typograf to export web fonts (EOT, WOFF, SVG). Try rearranging the sources in your CSS as outlined above first, though.
ANOTHER EDIT: My erroneous use of TIFF instead of TTF has been redacted to avoid confusion in the future. Apologies for the mix-up, guys...
I am not sure but try to add this for padding to work
display:block;
padding-bottom:20px;
margin-bottom:10px;
line-height:normal !important;
line-height:55%;
Set the line height to normal, it is a firefox bug and use the line height in %
I think this might do the trick
It all boils down to the font itself.
Look here
http://jsfiddle.net/DdMej/2/
The first row uses Drod Sans by Google fonts.
The second row uses the font you have on your site.
edit 1
Screenshot
http://imageshack.us/photo/my-images/811/screeniy.png/
I too was seeing my Google Font 'Lato' cut off at the bottom portion of the rendered text. In my case, I needed to serve the font files locally instead of using Google Fonts. To do this I:
Converted the font from .ttf to webfont files with Font2Web
Served the font files locally as static file assets from the localhost
Included fonts in my css with the bulletproof #font-face implementation
This eliminated my cut off rendered text issue.

Why do Font Squirrel's #font-face definitions contain two src declarations?

In doing some research on the "correct" syntax for using #font-face in a cross-browser friendly way, I came across the following site, which makes a lot of sense:
http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax
However, if you look at any of the #font-face demo code provided by Font Squirrel, the #font-face definitions are as follows:
#font-face {
font-family: 'OswaldLight';
src: url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.eot');
src: url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.eot?#iefix') format('embedded-opentype'),
url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.woff') format('woff'),
url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.ttf') format('truetype'),
url('/utils/load_demo_font.php?font=1145/Oswald-Light-webfont.svg#OswaldLight') format('svg');
font-weight: normal;
font-style: normal;
}
Why do the Font Squirrel demo scripts all contain two src declarations? I can't understand this.
It's an IE9 compatibility mode issue.
For a full explanation, first see: http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax
How it works
Internet Explorer <9 has a bug in the parser for the src attribute. If you include more than one font format in the src, IE fails to load it and reports a 404 error. The reason is that IE attempts to load as a file everything between the opening parenthesis all the way to the very last closing parenthesis. To deal with that wrong behavior, you merely declare the EOT first and append a single question mark. The question mark fools IE into thinking the rest of the string is a query string and loads just the EOT file.
Then see the follow up article: http://www.fontspring.com/blog/further-hardening-of-the-bulletproof-syntax
A potential looming problem with the new syntax we introduced earlier this month was raised by Microsoft. The soon-to-be-released IE9 comes with a feature that allows it to render in both IE7 and IE8 Modes. In these two modes, Microsoft 'fixed' the parser bug that affected the actual IE7 and IE8. This fix breaks the #font-face syntax for those compatibility modes.
...
This syntax is exactly the same as our previous iteration with the addition of a second 'src:' attribute that specifies the EOT again. We'll leave it up to you to decide if this is necessary.
If you don't care about compatibility view you can clear that first src right out.
The second one overrides the first if the browser understands the second one, but not the first one. This way you can add compatibility for multiple browser. Browser A uses the first SRC and Browser B, C and D use the second SRC statement.

Working with web (#font-face) fonts

I have a basic question that probably refers more to design field, but still it is a web programming.
Let say I need to use Palatino-Linotype font in my web application. How do I better embed it in to my web page application?
My known way:
1) Go to font.com and buy all kinds of palatino-linotype: normal, bold, italic, italic-bold. 4 different files.
2) Then I load fonts via fontface style
#font-face {
font-family: "Palatino-Linotype-normal";
src: "..."
}
#font-face {
font-family: "Palatino-Linotype-italic";
src: "..."
}
3) A I have 4 different fonts, in HTML markup I need explicitly set font of the element to make it bold, or italic, or italic-bold (that what I don't like the most).
Question:
1) is that workflow of using custom web fonts?
2) Maybe there is a way to treat this fonts as usual fonts in term of setting only one font on parent element, and for inner set only style="font-style: italic;" if I want them to be italic.
3) question about performance, does web font rendering speed differs from rendering of usual fonts?
The logical way, generally supported by browsers, is to declare each typeface in a separate rule, as in
#font-face {
font-family: foobar;
src: url("foobar-regular.woff");
}
#font-face {
font-family: foobar;
font-style: italic;
src: url("foobar-italic.woff");
}
and then just declare font-family: foobar and use font-style: italic directly or indirectely via <i>, <em>, and other markup that causes default rendering in italic.
I have simplified the code in an obvious way; naturally you should normally make the font available in different formats, as recognized by browsers.
Services like FontSquirrel generate different code, but it is fairly straightforward to fix the code they produce, or write the code from scratch.
I have intentionally used “foobar” and not “Palatino Linotype”, since the latter is not legally available for use as a downloadable font; at least this is what presume until proven otherwise. (There are many sites on the web that distribute or sell fonts illegally.)
Check out Fontsquirrel http://www.fontsquirrel.com/ it helped me to generate fonts and css:s compatible for multiple browsers.
If you only use Palatino Linotype Normal, and then change it to bold in CSS you won't get the same results as Palatino Linotype Bold. The thing here is that the browser rendering will be used to achieve that and it will suck a lot. I mean, for me and probably for you it will look the same - but not for designers :)
Also there are a lot more to one font than normal, bold and italic. There are light, semi light, black and so on. And designers tend to use those a lot.
So in general, for the first and second question: use different font faces for different styles and no way to use different faces for different styles, another font family indication is needed.
As for the 3rd one: performance is an issue with embedded fonts. But mostly not because of rendering, but because the font files are heavy to download. So be sure to cache them and use only those needed. For example http://www.fontsquirrel.com/ in the previous answer actually by default adds too many files that are all downloaded, so make a little research to know about different formats and what you need to embed.
You use Palatino-Linotype font in your web application use web font from google.
https://developers.google.com/webfonts/docs/webfont_loader
The Web Font Loader is a JavaScript library that gives you more control over font loading than the Google Web Fonts API provides. The Web Font Loader also lets you use multiple web-font providers. It was co-developed by Google and Type kit.
More inforamtion follow this link to my blog:
http://webtemplatesmonster.blogspot.in/2013/02/how-to-use-font-face.html
#font-face { font-family: 'Awesome Font'; src:
url('awesome-font.eot'); /* IE9 Compat Modes */ src:
url('awesome-font.eot?#iefix') format('embedded-opentype'), /*
IE6-IE8 */
url('awesome-font.woff') format('woff'), /* Modern Browsers */
url('awesome-font.ttf') format('truetype'), /* Safari, Android, iOS */
url('awesome-font.svg#svgFontName') format('svg'); /* Legacy iOS */ }

Is using the smiley (☺) in #font-face still relevant?

This might be a bit of hasty conclusion, but my question arose when I find that FontSquirrel.com does not generate the smiley (☺) with their #font-face generator.
Instead of the usual bulletproof standard (as laid out by Paul Irish regarding the smiley), the FontSquirrel's #font-face generator generates only this:
#font-face {
font-family: 'sansationregular';
src: url('sansation_regular-webfont.eot');
src: url('sansation_regular-webfont.eot?#iefix') format('embedded-opentype'),
url('sansation_regular-webfont.woff') format('woff'),
url('sansation_regular-webfont.ttf') format('truetype'),
url('sansation_regular-webfont.svg#sansationregular') format('svg');
font-weight: normal;
font-style: normal;
}
I realize it might be too hasty to conclude that by FontSquirrel abandoning the smiley means the smiley is no longer relevant, but considering FontSquirrel's #font-face generator seem to be the most popular and the most used generator out there, it makes me wonder why they don't include the smiley anymore. Especially because they seem to have included it before...
Just in case anyone's not familiar with the smiley, there is a good explanation here.
EDIT - Ran into some more info that may interest: https://stackoverflow.com/a/4520467/1455709
Android 2.2 devices will suffer from local() usage, your #font-face wont work at all.
I can confirm that on Android 2.3.6 (default browser) local() will break your #font-face declaration.
Android 4.0 (default browser) works fine with local().
Unsure of everything in between. So again, I think it's down to your user base, or the effort you want to go to with multiple stylesheets to ensure your font works everywhere.
Well, they are only generating the code needed to display your font on all browsers. It's your decision as to whether you want to take the "risk" as to whether the user has a font by that name installed locally.
Depends on your audience I would say.
Does anyone really install fonts onto their local machine anymore? A lot of people on this site might, designers defiantly will, but the general public? Probably not.
What's the chance that the font your using has the same name as another different font? Small.
What's the chance the user has that particular other font installed? Very small.
If you want to ensure that the user downloads and uses your particular font, use it.
If you want to use Windows fonts (you're probably not allowed) and want them visible on Macs, then you wouldn't want to use the smiley face, so as to save every Windows user from downloading a font they already have (that actually is the same).
If you want to use a custom font called 'Verdana' you will defiantly want to use a smiley face. That, or make the font-family unique... I guess with a smiley face... But that would look messy, so use the local attribute.
The newest "bullet proof" method can always be found by using fontsquirrel's WEBFONT GENERATOR.
So since writing your question, .woff2support has been added.
Anyone wishing to clarify what the up-to-date method is the you should do the following.
Upload a tiny font file and this will generate a zip file with your font converted into all formats but more importantly it also contains a CSS file with the "bullet proof" method.
Which currently looks like this.
#font-face {
font-family: 'font-name';
src: url('fontawesome-webfont-webfont.eot');
src: url('fontawesome-webfont-webfont.eot?#iefix') format('embedded-opentype'),
url('fontawesome-webfont-webfont.woff2') format('woff2'),
url('fontawesome-webfont-webfont.woff') format('woff'),
url('fontawesome-webfont-webfont.ttf') format('truetype'),
url('fontawesome-webfont-webfont.svg#font-name') format('svg');
font-weight: normal;
font-style: normal;
}

Bottom of custom font cut off in Opera and webkit

I'm using a custom font in a page I'm developing, Droid Sans, and at certain font sizes, the bottom is cut off, but only in Opera and webkit browsers.
It's easy to reproduce on Google's own webfonts page looking for Droid Sans and showing the whole alphabet at 18px: http://www.google.com/webfonts
It's especially clear for the lower case g.
Is there some css trick / hack I can use to increase the line height / show the whole character or am I really limited to only certain sizes of the font?
line-height and padding for example don't change anything and 20px font-size works fine and at the moment I am using Windows 7.
Edit: By the way, I am aware of a similar question here but as the accepted answer is changing the font size and the rest of the answers do not apply, it is of not much use to me.
Edit 2: An example that at least for now shows the problem (left hand column, under the slideshow, Il Cerca Viaggi).
Edit 3: The problem seems to be limited to Windows although I'm not sure which versions.
Edit 4: I have added a screenshot from Google Webfonts to show that the problem is not specific to the site I'm developing.
Although it is not the solution I am looking for, I have found a possible solution that might work for others:
In my original style-sheet I have specified the font as follows:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype'),
url('droid-sans/DroidSans-webfont.svg#DroidSans') format('svg');
font-weight: normal;
font-style: normal;
}
This is causing webkit browsers to use the woff file / format.
Changing the order of the font specifications and removing the hash-tag after the svg specification (why is that there anyway?), causes webkit browsers to use the svg file / format:
#font-face {
font-family: 'DroidSans';
src: url('droid-sans/DroidSans-webfont.eot');
src: local('☺'),
url('droid-sans/DroidSans-webfont.eot?#iefix') format('embedded-opentype'),
url('droid-sans/DroidSans-webfont.svg') format('svg'),
url('droid-sans/DroidSans-webfont.woff') format('woff'),
url('droid-sans/DroidSans-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
This solves the problem, all characters are displayed correctly.
However, at least in Windows 7 64bit, the svg font is not as sharp as the woff font, it's kind of blurry so I will not be using this solution and am hoping for a better one.
To a similar question, one answer suggested that, while this appears to be a Windows font rendering issue specifically, hosting svg, eot and otf versions of a TrueType font (TTF) containing the font, which was not optimized for the web, had fixed the problem for its provider. If possible, get a clean, un-optimized version of the DroidSans font and export the web fonts yourself.
EDIT: Sorry all, I was out for the holiday and didn't have access to SO. Since I've been back, I've done a little research into exactly what's causing this problem on Windows machines...
It appears that the issue lies with the way the OpenType format is rendered on Windows machines. The issue with truncated descenders seems to transcend software type to affect multiple Windows programs attempting to render OpenType. Currently, you have the Embedded OpenType format (EOT) version of the font listed first in your CSS document under #font-face. Since Chrome and Opera both recognize this format, they'll disregard the subsequent source declarations and use EOT to display the font. Unfortunately, there doesn't seem to be a quick fix that you could apply to an OpenType font itself to force the software rendering it to allow adequate line-spacing for the lowest of its descenders on Windows machines...
However, you can be choosy about which fonts you feed to your viewers' browsers. Personally, I would recommend placing the SVG version first in your CSS, and for browsers that don't recognize this format, suggest TrueType (TTF) second, then WOFF, then EOT for browsers that don't support any of the aforementioned (some older versions of IE appear to support OpenType exculsively). If the SVG rendering isn't much to your liking, try TrueType first instead.
Alternatively, although I'm no longer really that confident that it will help, you can download a TTF of DroidSans at FontSquirrel and use a software package like Typograf to export web fonts (EOT, WOFF, SVG). Try rearranging the sources in your CSS as outlined above first, though.
ANOTHER EDIT: My erroneous use of TIFF instead of TTF has been redacted to avoid confusion in the future. Apologies for the mix-up, guys...
I am not sure but try to add this for padding to work
display:block;
padding-bottom:20px;
margin-bottom:10px;
line-height:normal !important;
line-height:55%;
Set the line height to normal, it is a firefox bug and use the line height in %
I think this might do the trick
It all boils down to the font itself.
Look here
http://jsfiddle.net/DdMej/2/
The first row uses Drod Sans by Google fonts.
The second row uses the font you have on your site.
edit 1
Screenshot
http://imageshack.us/photo/my-images/811/screeniy.png/
I too was seeing my Google Font 'Lato' cut off at the bottom portion of the rendered text. In my case, I needed to serve the font files locally instead of using Google Fonts. To do this I:
Converted the font from .ttf to webfont files with Font2Web
Served the font files locally as static file assets from the localhost
Included fonts in my css with the bulletproof #font-face implementation
This eliminated my cut off rendered text issue.

Resources