I am trying to mimic the text in the articles on the website desiringgod.org. They use the Merriweather font with a dark grey color for the body text on a white background.
When I put the same settings on my website the text looks different, not quite as smooth and darker. I checked all the CSS and even went through some of the javascript to make sure everything was the same and to see if anything special was happening. I can't see anything that would account for the difference. (mine has different line height but that shouldn't make a difference). I even tried downloading their WOFF2 font just to see if that made a difference (as opposed to using the one from Google) and that didn't change anything either.
I then took a screen shot of a portion of text on each page (theirs and mine). Bringing it into photoshop I noticed that for the one coming from the desiring god website photoshop determined the image on the clipboard was greyscale but for mine it determined it was RGB. Then looking closer I noticed that it seems my page is being affected by ClearType on windows and the desiring god one is not. If you zoom in on the samples below you will see the colored antialiasing typical of cleartype on mine and the grey antialiasing on theirs.
Is there any way that could be possible? Is there any way to stop that from happening? The text on desiring god is more pleasing to read and I would like the same effect.
After spending way too many hours on something that really doesn't look that much different, I finally figured it out. Whew...
They put this class on one of the containers holding their text:
.gpu {
backface-visibility: hidden;
perspective: 1000}
Once I did that for my container all the anti aliasing was grayscale.
As you can see they have a slight different version from Google's Merriweather.
/* latin */
#font-face {
font-family: 'Merriweather Google';
src: url(https://fonts.gstatic.com/s/merriweather/v19/u-440qyriQwlOrhSvowK_l5-fCZM.woff2) format('woff2');
}
#font-face {
font-family: 'Merriweather Desiring';
src: url(https://jsbin-user-assets.s3.amazonaws.com/rafaelcastrocouto/merriweather-v11-latin-300.64e603fa.woff2) format('woff2');
}
p.google {
font-family: "Merriweather Google";
}
p.desiring {
font-family: "Merriweather Desiring";
}
p {
font-size: 18px;
font-weight: 300;
line-height: 180%;
letter-spacing: normal;
max-width: 700px;
border-bottom-color: rgb(51, 51, 51);
border-bottom-style:none;
border-bottom-width: 0px;
color: rgb(51, 51, 51);
vertical-align:baseline;
width:700px;
-moz-osx-font-smoothing: grayscale;
-webkit-font-smoothing: antialiased;
-webkit-tap-highlight-color:rgba(0, 0, 0, 0);
}
<link href="https://fonts.googleapis.com/css?family=Merriweather" rel="stylesheet">
<p class="google">That’s not right. </p>
<p class="desiring">That’s not right. </p>
Related
I am trying to rebuild this website in Polymer: http://qprogrammers-mockup.webflow.io/. So I can extend it easily in the future. I have everything down and I am using the same font, font-weight, font-size and I checked this with a chrome extension whatfont?.
But the fonts seems different. The example website is still much sharper. I read the css, but I cannot find out why. I also added:
body {
background-color: e8e8e8;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing:grayscale;
font-family: 'Open Sans', sans-serif;
font-weight: 300;
}
Given your example, I cannot tell how much more CSS you have. But this may just be a case of you not invoking the webfont Open Sans and your browser is reverting to whichever sans-serif it is using. You could add the following line to the top of your CSS and see if it makes a difference:
#import url(https://fonts.googleapis.com/css?family=Open+Sans:400,300,300italic,400italic,600,600italic,700,700italic,800,800italic);
Finally, you are missing a '#' on your background color property:
background-color: #e8e8e8;
From the images below, you can see that the font rendering used by safari adds some white lines to some characters. This occurs in Safari for both iOS and Mac. While in the example below it is not as noticeable, in practice it can be quite distracting.
I noticed this happened after I added font-weight: 400; to my text. The reason I added it was to fix another issue by Safari which rendered by font with large kerning between letters see this Stack Overlow question.
This is the entire CSS for the text:
h2 {
font-family: 'My-Font', sans-serif;
font-size: 3.5em;
line-height: 1.2em;
margin-bottom: 0.5em;
text-align: center;
}
Is this another bug in Safari and is there a workaround if so? Thanks.
Some folks recommend
text-rendering: optimizeLegibility;
Other
transform: perspective(1px);
Hope it helps.
I ask this because when I try to create a CSS font stack for multi-language content, such as English and Chinese, the final rendering is affected by the first font in the stack (usually Latin ones, since most Chinese font comes with Latin support).
See this Codepen, for example.
div.a p {
overflow: hidden;
}
p {
background-color: red;
border: 1px solid black;
display: inline-block;
}
.chinese-only {
font-family: "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.english-chinese {
font-family: "Avenir Next", "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.chinese-english {
font-family: "Hiragino Sans GB", "Avenir Next", sans-serif;
font-size: 24px;
line-height: 48px;
}
What I am seeing:
Since Chinese glyphs only appear in the Hiragino Sans GB, I expect all Chinese blocks to use the same line height. But they are apparently affected by adding the Avenir Next font at the top of the stack.
Since both Firefox and Chrome on OSX renders my example the same, I wonder if the CSS specification mentions anything about this. CSS 2.1 fonts spec doesn't appear to state what to do with line height when you fallback on missing glyphs.
Updated: Safari does render differently, but unfortunately the difference is due to overflow: hidden, not glyph fallback. My updated example may show this a bit clearer.
On Chrome and Firefox
On Safari
And if you are really into font-related headaches, try this example showing different font stacks, and see how they differ on each browser.
This is pretty much going to come down to the user agents. Any time the CSS specification says, “not defined by this specification”, that’s code for “we’ll let browsers do whatever they think is best and then try to get them all to behave consistently after a few years of doing it differently”.
Furthermore, the latest CSS Inline Layout Module states right at the top of Section 1 (Line Heights and Baseline Alignment):
This section is being rewritten. Refer to section 10.8 of [CSS21] for the normative CSS definition or the 2002 Working Draft if you want pretty pictures. (But ignore the old text, half of it’s wrong. We’re not specifying which half, that’s to be determined.)
That’s from last month. So, you know, good luck and Godspeed, basically.
Interestingly, I see a different result in Safari 6.2.2 than you posted:
If there’s a difference between that and the latest Safari, you might be able to track down a bugfix between the two versions that explains why it changed.
I have a simple svg (drawn by me in illustrator), which I am trying to convert to a webfont (together with other svg's). When I open an svg in an editor I see it correctly (black pawn shakes a hand with a white pawn). The same way if I am converting it to png.
But after I converted it to a webfont with grunt webfont
webfont: {
icons: {
src : 'path/svg/*.svg',
dest : 'path/fonts',
destCss : 'path/css',
options : {
autoHint: false,
font : 'icons',
hashes : false
}
}
}
But in the webfont it looks really strange (everything is transparent except of the outline)
Here is an example of my webfont and css generated for it:
#font-face {
font-family: 'icons';
url('font/icons.woff') format('woff'),
font-weight: normal;
font-style: normal;
}
.icon {
font-family: 'icons';
display: inline-block;
vertical-align: middle;
line-height: 1;
font-weight: normal;
font-style: normal;
speak: none;
text-decoration: inherit;
text-transform: none;
text-rendering: optimizeLegibility;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
.icon_draw:before {
content: '\f103';
}
I have high belief that the problem is with my svg (all other fonts look nice: some of them are mine and some taken from other sources). But I have no idea what is wrong.
P.S. I tried to include all relevant and not relevant details, but if you need something else (or I forgot something else) please let me know.
I am not familiar with grunt-webfont, so the following is just an educated guess.
SVG defines that the fill property defaults to black. Your black pawn has no defined fill, so it is defaulting to black when rendered in a proper SVG renderer.
However my guess is that the SVG to webfont converter utility does not appreciate that rule and is only looking at the properties defined on the shape itself. If I am right, explicitly setting the fill to black on the black pawn body shape may fix your problem.
Also I noticed that the way you have done the arm of the black pawn is a little strange. You have made a piecemeal shape and filled it by drawing a whole lot (25 by my count) of thick short strokes. Font renderers expect glyphs to be defined using closed filled shapes. Not doing it that way may cause problems. Ideally the arm should be a single filled shape. On the other hand, it may work perfectly fine.
I use custom font in my CSS with this method:
#font-face {
font-family: 'Gabriola';
src: url('Gabriola.eot');
src: url('Gabriola.eot?#iefix') format('embedded-opentype'),
url('Gabriola.woff') format('woff'),
url('Gabriola.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
.gabriola {
font-size: 20px;
line-height: 20px;
height: 20px;
background: red;
}
<div class="gabriola">Some texty text here</div>
Each browser renders this fonts by it's own way with vertical offset top and bottom like this
What am I doing wrong? Thanks
I know it's been 5 years since the OP asked the question, but I found this great technique on getting text baseline-aligned correctly.
Basically, the text container must be an inline-block with line-height: 0;
Then, you create an inline-block pseudo-element and set its height according to the line-height you wanted:
span {
font-size: 2em;
background: red;
}
span.baseline-align {
vertical-align: baseline;
}
span.true-baseline-align {
display: inline-block;
line-height: 0;
}
span.true-baseline-align::after {
content: '';
display: inline-block;
height: 1em; // this is where you control line-height
}
<span>Normal text</span>
<br><br>
<span class="baseline-align">With vertical-align: baseline</span>
<br><br>
<span class="true-baseline-align">with trick to really baseline-align</span>
http://blogs.adobe.com/webplatform/2014/08/13/one-weird-trick-to-baseline-align-text/
It's possible there is not anything you are doing wrong. Here are some points that may apply, some controllable by you, some not.
Just to be sure, explicitly set vertical-align: baseline.
The different files (.eof, .woff, .ttf) themselves may not be defined the same, and thus different browsers are using different files and displaying differences.
Not sure if having two src calls is messing things up, but you can try eliminating the second one:
#font-face {
font-family: 'Gabriola';
src: url('Gabriola.eot'),
url('Gabriola.eot?#iefix') format('embedded-opentype'),
url('Gabriola.woff') format('woff'),
url('Gabriola.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
These are all mere guesses. You will have to test #1, 3. If the issue is #2, I'm not sure there is an elegant solution.
There is, of course, the caveat on this site:
Keep in mind that font rendering can vary widely across browsers and
operating systems. Many developers have experienced such poor results
from Windows and Internet Explorer that they avoid using custom fonts
altogether. Always be sure to examine your results closely on all the
browsers that you can to decide if the quality is acceptable.
Update
This post gives some tips about possibly resolving rendering issues. This is for Font Squirrel, and he specifically notes:
If you downloaded the kit, you might try regenerating the font with
the generator. We make periodic adjustments to the generator that
might improve the hinting or rendering of the font.
But he also confirms,
Not to pass the buck, but the most common cause is a bad original
font.
Which goes with my point #2.
I had the same problem and the solution was to reconstruct the font with the properties of the original without changing anything in a new file with Hight logic font creator, the font is unchanged and equal to the original problem is corrected and aligned to the perfection in all browsers including ie6, was the work of a few hours but this is the result in case you need some user.
http://www.filefactory.com/file/1miw29cddg21/n/crossbrowser_gabriola_font.zip
This is the solution if anyone has the issue and do not want or cannot reconstruct the font:
https://developer.mozilla.org/en-US/docs/Web/CSS/#font-face/ascent-override
This prop will adjust the vertical ascend property when the font is imported.