I'm writing a tiny website for a book that's currently being printed, and want to match the slightly eccentric font called Cronos Pro which it uses for its headings. I'm currently doing this with the following CSS:
header, h1, h2, h3 {
font-family: cronos-pro, sans-serif;
}
Cronos Pro is supplied using our Adobe Creative Cloud subscription, and under the terms of their licence this must be loaded as follows:
<link rel="stylesheet" href="https://use.typekit.net/xxxxxxx.css"/>
This just produces a set of #font-face rules defining the font, and it all works fine. Nevertheless, I feel I ought to keep the fall-back of sans-serif in case the font is temporarily unavailable, or for an old browser that doesn't support it.
However, Cronos Pro is a very compact font. If I know the browser is using it, I want it rendering bigger, as if I'd added font-size: 125% to the CSS. But if the browser falls back to its default sans serif font, I want it at 100% size.
I thought I could do this as follows, but Firefox tells me it's an invalid property value:
font: cronos-pro 125%, sans-serif;
Is there a good way of achieving this, bearing in mind the #font-face rule is outside of my control?
You could use JavaScript to add a stylesheet with your font-size: 125% tag if and when Chronos Pro loads successfully:
<script>
{
let font = "cronos-pro";
let styleSheet = document.createElement('style');
document.head.appendChild(styleSheet);
document.fonts.ready.then(function () {
if( document.fonts.check(`1em ${font}`) ){
styleSheet.sheet.insertRule('header, h1, h2, h3 { font-size: 125%; }')
}
});
}
</script>
Not sure if this is a "good way" to do it, but it should work in a pinch. I'm still a bit new at web development.
Related
Today, I stumbled across a CSS hack that works in my current browser:
When an element uses a system font, like "Courier", then I was able to define a custom #font-face to replace the Courier font with a custom web font.
It's working for me; however, before using that kind of CSS on customer websites I'd like to understand if this is intended browser behavior, or a glitch that might disappear any time or is not even supported on some devices.
.demo {
padding: 10px;
background: #eee;
}
/*
My Font Hack: Replaces Courier with "Roboto" Google Fonts
*/
#font-face {
font-family: Courier;
src: url(https://fonts.gstatic.com/s/raleway/v28/1Ptug8zYS_SKggPNyC0IT4ttDfA.woff2) format('woff2');
}
<div class="demo" style="font-family: Courier!important">
This is Courier
</div>
It doesn't replace anything, it just changes alias for the Courier font string for the current page where CSS is loaded in.
The reason you shouldn't do this not because of browser incompatibility/glitch, but because it changes semantics of "font-family: Courier!important" and down the line will make debugging font-related problems harder.
Currently, in my standard stylesheet I have:
#font-face {
font-family: myFancyFont;
src: url('myFancyFont.otf');
}
And I use that in other css declarations like:
.someClass {
font-size: 18px;
font-family: myFancyFont;
}
That all works well and good until someone goes to print the page at which point anything using myFancyFont prints out in a rather ugly font.
On screen version
Printed version
Notice the font looks double lined and blurry. My print.css file does change the background color from blue to grey.
Is it possible for me to redefine myFancyFont in my print.css file to a standard web safe font (like Verdana) so printing looks more normal?
I'm assuming that there could still be a problem if I simply do:
#font-face {
font-family: myFancyFont;
src: url('verdana.otf'); /*or a real version of the verdana font file*/
}
Is it possible for me to redefine myFancyFont in my print.css file to a standard web safe font (like Verdana) so printing looks more normal?
Yes, in your print stylesheet you can redefine your custom font family to use the preinstalled Verdana like so:
#font-face {
font-family: myFancyFont;
src: local('Verdana');
}
All references to myFancyFont in your standard stylesheet, provided they haven't been restricted to #media screen, will automatically use Verdana in print.
You do need to make sure that your print stylesheet is linked after your standard stylesheet in your HTML so that this #font-face rule will override your standard one.
Note that "web safe" doesn't necessarily mean "legible in paged media", although generally most web safe fonts do print pretty legibly.
I would simply use an #media print media query with Verdana as the standard font, like this:
#media print {
* {
font-familiy: Verdana, sans-serif;
}
}
Plus, if you have other, more specific CSS rules where you define your FancyFont, you'd have to include these too in this media query (changed to Verdana), or use !important in the above rule.
I used Google web fonts for my H1 text and the text looks very pixelated on my screen.
<link href='http://fonts.googleapis.com/css?family=Forum&v2' rel='stylesheet' type='text/css'>
<style media="screen" type="text/css">
h1 {
color:#544E4F;
font-family: 'Forum', cursive;
text-align:center;
margin: auto;
font-size:210%;
}
</style>
Thanks in advance!
After suffering the same problem for a long time, and after doing a lot of research about it, I finally did the following:
I found http://www.fontsquirrel.com
I downloaded the (pixellated) font I was using (Exo family)
I uploaded it to my site
I referenced it locally to avoid using Google Fonts (you can achieve this by downloading a #font-face Kit that is available at fontsquirrel.com also).
It looks OK to me. However note that h1 receives the style:
font-weight: bold;
in most browsers' default style sheets. Since you only have a normal-weight variant of the font available, the browser has to synthesise the bold weight automatically from the normal. There are various different methods of auto-bolding of varying levels of quality, but it's never going to look as good as a real designed bold. Maybe you are getting a poorly-synthesised font variant.
If you want to use Forum for headings I suggest adding the rule:
font-weight: normal;
which will allow the browser to use the regular, unmolested font. Alternatively if you really do want that bold, best choose a different font that does actually have a bold weight.
Another possibility is that you've got anti-aliasing turned off at a system level, and it's being overridden for your normal browser font but not for web fonts. If that's the problem then you could try to override for everything else using eg:
font-smooth: always;
-webkit-font-smoothing: antialiased;
although it's questionable whether it's really a good idea to be ignoring the user's preferences, and also arguable whether it should be subpixel-antialiased instead for WebKit...
Well I'm just throwing these out there, but..
My best guess is to use em rather than % for your font size. Such as, font-size:4.5em.
Maybe try using a div instead of h1, though I doubt that would do much of anything.
Try adding this:
h1 {
text-shadow:0 0 1px transparent;
}
I'm using the Google webfonts API to embed Droid Sans on a page. All is fine, except for the descenders (i.e. the dangly bits on y, g, etc). The latest versions of Firefox, IE and Chrome on my Windows Vista box are all cutting the bottom off.
<!DOCTYPE html>
<html>
<head>
<title>Droid sans descender test</title>
<meta charset="utf-8">
<link href="http://fonts.googleapis.com/css?family=Droid+Sans:regular,bold" rel="stylesheet" type="text/css">
<style type="text/css">
body { font-size: 16px; font-family: "Droid Sans", sans-serif; }
h1, h2, h3 { margin: 1em 0; font-weight: normal; }
h1 { font-size: 2em; }
h2 { font-size: 1.5em; }
h3 { font-size: 1em; }
</style>
</head>
<body>
<h1>A bug ran under the carpet anyway</h1>
<h2>A bug ran under the carpet anyway</h2>
<h3>A bug ran under the carpet anyway</h3>
</body>
</html>
The above code looks like this:
(source: thinkdrastic.net)
I've tried line-height, font-size, padding etc to no avail. I had some success with font-size-adjust, but the last time I checked it was Gecko only. Does anybody know of a fix for this?
With some help from #adamliptrot, I discovered that Droid Sans' descenders are absolutely fine at a few precise pixel sizes: 18, 22 and 27px. I adjusted my em's accordingly:
h1 { font-size: 1.6875em; }
h2 { font-size: 1.375em; }
h3 { font-size: 1.125em; }
Not ideal, but it works:
(source: thinkdrastic.net)
Although your question is in relation to the Google Web Fonts API, the principle of my answer beneath is the same.
If the descendants are being cut-off when serving a TrueType Font, the most likely cause is that OS/2 metrics are incorrectly set (negatively) on the font.
The values that may need adjustment are WinAscent & WinDescent.
A quick and dirty fix would be to adjust these both to 0.
This can be done using Font Forge. Once the font is opened in FontForge, you can gain access to these parameters via the 'Font Info' dialogue.
I have checked the referenced ttf files, and even in windows font viewer the descenders are being cut. Seems more of an issue with the font being served rather than with your styles.
If you're using Font Squirrel, it seems the issue with the sans variant has been sorted, but the issue remains with Font Squirrel's serif variant.
For a fix for the serif variant, go to the Web Font Generator and load the font files you need (do not rely on the package they provide).
Click the 'Expert' radio button, leave all of the settings but under 'Advanced Options' change the 'Em Square Value' to '2162' and generate the font.
This renders the font properly at all sizes
we've been having the same problem...we tried using font squirrel. we tried using google web fonts. The font kept cutting off "hanging" letters like g. Also, the google hosted version did not appear as true and clear as the other ones. The font seemed a bit choppy.
Our solution:
We hosted the font ourselves without formatting it for the web. Then we converted the ttf file to an svg, .eot, and .otf, and uploaded those as our fixes for ie and mozilla etc.
If the tip at the top - changing font-size to....
h1 { font-size: 1.6875em; }
h2 { font-size: 1.375em; }
h3 { font-size: 1.125em; }
doesn't work for you, then add "line-height" to the element that is cutting off the descenders. ``
I'm just guessing here, but I've had the same problem occur when fonts get substituted. I just wonder if this occurs when say a font substitution replaces a 1024em font with a 1000em font or vice-versa. I had some major descender cut-off using a 2048em font. Might be worth investigating.
I had a similar dilemma and the line-height fix worked for me (i.e. I added this code to the Custom CSS section):
h2 { line-height: 140%; }
The idea in the following is the first #font-face is for Firefox, the second for IE, and Arial for anything else that can't make sense of the first two. Its all working except for I want to give a different size in the case of Arial, and haven't figured out the syntax to do that.
#font-face {
font-family: Tribeca;
src: url("Tribeca.ttf"); format("truetype");
}
#font-face {
font-family: TribecaIE;
src: url("Tribec0.eot");
}
BODY
{
FONT-FAMILY: Tribeca, TribecaIE, Arial; font-size: 195%;
}
I don't believe this is possible with css alone; we will probably need to use javascript.
All we want to do is specify a different font-size if Arial is the active font. Detecting the active font is not exactly straightforward, but here is one method that will work for our particular purpose. We can create a temporary element containing some Arial characters and measure its width, and then create a second element containing characters without specifying a font (so that it defaults to the "active" font) and compare widths. This won't tell us which font is currently active, but can indicate whether or not one of the embedded fonts was loaded with #font-face as they certainly won't have the same width as Arial. If the two elements' widths aren't equal we know that Arial could not have loaded, and so we will only adjust the font-size if the widths are equal.
Even if the browser is unable to load the Arial font, our test is still functional, because when we specify Arial during the test, the browser will default to the same font as it would for the second element. Both elements will still have equal width if the browser is unable to load the embedded fonts with #font-face.
If anyone would like me to further illustrate with code, I'll be happy to write the javascript.
This is not supported by normal CSS rules..
I believe your options are
the font-size-adjust property of css 3
javascript (jQuery), and check for current font to see which one of the three is effective and adjust the font-size accordingly.. http://www.w3.org/TR/css3-fonts/#font-size-adjust ( you should also have a look at the http://www.modernizr.com/ )
I believe it is this (close to what you have):
#font-face {
font-family: Tribeca;
src: url("Tribeca.ttf");
}
#font-face {
font-family: Tribeca;
src: url("Tribeca.eot");
}
body {
font-family: Tribeca, Arial;
}
IE won't know how to open the ttf, so it won't bother. Then it will open the eot. Then, you just specify the font by the given name in the body declaration.
Target your browsers by knowing which one reads which type of declaration.
Conditional Comment load different CSS calls.
Then you can specifically tell each one to do something different per rule.
Also there is typekit
#font-face {
font-family: 'Tribeca';
src: url(Tribeca.eot);
src: local('Tribeca'), url(Tribeca.ttf) format('truetype');
}
MSIE will ignore the last line cos it doesn't understand format rule. and yes as pointed by porneL above, format() should go in the src property.
local() will make supporting browsers use local font file if user has it instead of downloading from your server (and probably make IE ignore the line too).
as for the font-size adjustment, as pointed by Gaby: CSS 3 font-size-adjust. but it looks like it's not widely supported, yet.
To void code duplication with #font-face, you can do this via server side. If you use for example some urlrewrite, detect UA, if it's IE - return file with .eot extension, if it's normal browser - ttf.
As for me, it works great.
And for this case, you shouldn't change your css files, just should have 2 files: .ttf & .oet.
Although it's against normal good-practices when using CSS, you could use the !important declaration in your conditional CSS.
As an example, we create two stylesheets: the 'default' one, which will have a section for Firefox-specific styles and an Internet Explorer stylesheet.
Then, using the standard <link rel="" /> method of importing stylesheets:
<link rel="stylesheet" href="normal/css/file.css" type="text/css" media="screen, projection">
<!--[if IE]><link rel="stylesheet" href="http://mysite.com/path/to/ie6.css" type="text/css" media="screen, projection"><![endif]-->
Within the 'default' stylesheet, our Firefox styles are wrapped in the following:
#-moz-document url-prefix() {
#my-id { font-size: 100%; }
}
This works because the #-moz-document url-prefix() section is how Firefox addons style webpages. So, other browsers don't understand it and therefore just skip it.
BODY
{
FONT: 140% Arial;
FONT: 195% Tribeca,TribecaIE;
}