Please check this screenshot!
alt text http://img267.imageshack.us/img267/1391/difference.png
This is the same page in Linux FF (on the left) and Windows FF (on the right, also it's displayed in the same way in IEs). I love how it looks in Linux FF and want to have the same look in Windows. However after playing with all CSS properties I know of, I didn't manage to change its look in Windows. Do you by chance know any solution for this issue?
Just in case: as a webdesigner you can't control pixel per pixel how your site will display on your user's browsers. Print and PDF are great for that purpose, not the web :)
Is Cleartype activated on Windows? This changes the display a lot and it's the user decision to activate or not this feature: if he doesn't like antialiasing you'd piss him off by forcing the rendering we can see on the left!
You can also change your stack of fonts in font-family and add other fonts than Arial.
You don't get to decide how the user's fonts look. The exact choice of font and whether it is anti-aliased is a client-side setting. Some (terrible luddites, IMO) prefer the pixellated look. In any case, Linux is likely to be using a lookalike fallback font (eg. ‘Sans’) rather than Arial itself, so it's never going to look exactly the same.
To turn anti-aliasing on in Windows for most fonts (in all applications, not just web browsers), you need to enable ClearType. Without ClearType, Windows's anti-aliasing is the old broken ‘font smoothing’ option, which for most fonts is so poor that Windows prefers not to use it. ClearType rendering isn't quite the same as the anti-aliasing Linux will be using; usually it only anti-aliases in the horizontal direction. So again it won't quite look the same, but it's generally considered pretty good at least for the Latin alphabet.
If you're really desperate to push it from the server side, you could use a #font-face rule to embed a font that has the GASP table hacked to always use anti-aliasing (using a ttfgasp.exe or a font editor). However doing this to Arial (or indeed most fonts without an open licence) would not be technically legal.
You can easily get the same look (or at least similar) by activating font smoothing in Windows. You can not, however, activate it using CSS.
Font smoothing is on by default in newer versions of Windows, so a lot of visitors will see it as you see it on your Linux system.
This is a user setting, and that is as it should be. Each user should be able to choose the smoothing setting that works best for him/her on his/her monitor.
If you absolutely want the text to look like on your Linux system for every user, your only option is to make it an image.
Different versions of Windows and Linux, and even different settings of their font rendering systems, yield different results in font rendering; in the first case antialiasing with subpixel optimizations for LCDs is clearly activated, while in the second case not even antialiasing is enabled.
To get nicer looking font rendering on Windows you should enable ClearType. In any case, it's all a client-side settings, and AFAIK you can't do anything for them from HTML - and you mustn't, if the user don't like antialiasing you shouldn't mess with his settings.
Related
For my current workflow I use iconic web fonts generated with the Icomoon. It’s a very easy and fun technique with an obvious advantages:
Icon behaves just like any other glyph, so any text CSS transformations can be applied to it in a natural way, like text-shadow, text-decoration, color etc.
Easy reuse, just add necessary font-family to element.
But it has major flaws do not let me sleep.
Font icons are blurry no matter how perfectly its curves are aligned to a pixel grid. Not to mention awful Windows rendering.
It’s hard to add new icons to the font, especially when vector source font is made from is not available and even lost.
It requires bunch of different font versions (woff, eot, ttf) for acceptable cross-browser support.
In the end fonts are not really for graphics at all (especially not monochrome), it seems to not the right way to use dummy empty and non-semantic <span class="icon"></span> for this purpose.
Well, the obvious alternative is SVG, which has no mentioned disadvantages. But has it’s own flaws, which do not let me use it’s easily.
A lot of small files are quite simply not acceptable in our HTTP/1.1 era.
Creating of icon modification is not an easy task and requires manual editing, which is also rather strange for our just-type-npm-install era.
I've googled for some npm packages which hasn’t satisfied me for some reasons.
So, I’m asking your advice how to manage this trivial and routine task. Is there productive and reliable way to generate SVG sprites with modified variations of original icon and bitmap fallback for old browser?
It doesn't make sense to talk about "supporting old browsers" without:
knowing what the majority of your users will be on (which'll be multiple browsers of course), and,
what support for the feature you want to use is for those browsers, for which we can use the handy http://caniuse.com
With that said, this is not going to be an answer so much as an explanation of how all those points you present "against" fonts are unfounded. Answers are great, but in this case we need to set the record straight so you can make real decisions based on facts, instead of (either "never", or "no longer" valid) preconceptions. I spent way too many years of my life working with fonts from an engineering perspective to let you maintain these claims =)
"Font icons are blurry no matter how perfectly its curves are aligned to a pixel grid. Not to mention awful Windows rendering."
This is plain old not true. As vector graphics, if they render poorly, SVG will also render poorly at the same size, although SVG will typically render worse: fonts actually allow for micro-outline-optimizations for dealing with small point sizes (.otf is better at this than .ttf, but the font maker needs to have spent the time to put them in. Pretty much all professional fonts come with that work done), and SVG doesn't, because it has no instructions in its vector graphics language to do so. As such, fonts render either on par with (if they have no optimization instructions), or better than (if they do) SVG.
For example, Font-Awesome comes with outline optimization that allows it to render pixel-perfect all the way down to a font size of 14px, which is already smaller than what browsers use as default size for text on a page (virtually all browsers agree to use a default of 16px serif). If you took its icon set and converted it to SVG, then tried to use those scaled down to match a 14px size, they would look an absolute blurry mess.
Or you can use an icon set that goes further, such as Symbol Set which has explicitly been designed for grid alignment, which means that even at sizes lower than intended, it still renders remarkably crisply.
SVG loses here.
As for Windows rendering, it might look bad, but that's not Windows's fault. Both Uniscribe and DirectWrite are really good at rendering fonts. Like, really good (which may not be a surprise, since Desktop Publishing has traditionally been Microsoft's core business since pretty much its beginnings, although that's shifting). Browsers that hook into them render fonts really well: IE has even supported web fonts since IE4... That's 1997. That's before HTML4 was even a thing, we were still on HTML3.2 at the time.
The problem isn't so much "Windows", as it's "older browser that are not IE, on Windows". Browsers didn't really care about web fonts for a very long time. It's only the last few years that major effort has suddenly gone into making sure they come with good Font shaping engines (like Harfbuzz, which is now used by Firefox and Chrome), and you won't get nice results for Fonts unless you're using a modern version of "not-IE" on a Windows machine.
And then finally a problem specific for "font vs SVG" on Windows and IE: While IE has supported web fonts since pretty much forever, SVG support only landed in IE9, so if you need to support IE8, you can't even use SVG. In the case for this very specific target audience, "fonts vs. SVG" isn't even a question, you have to go with a font.
"It’s hard to add new icons to the font, especially when vector source font is made from is not available and even lost."
No it isn't, you're still using HTML with CSS, so do what we always do when we need "letters not in this font": use font-fallback: font-family: iconfont1, iconfont2, iconetc.
"It requires bunch of different font versions (woff, eot, ttf) for acceptable cross-browser support."
Not for a few years now. These days we do not need multiple sources: caniuse shows us that everything supports WOFF and has done so for a few versions.
Even IE, although if you need to support IE8 you'll have to also find yourself an .eot (which is literally just a ttf file with an extra bit of metadata so IE will accept it... just like WOFF!) and then live with the fact that if this requires a conversion from otf to eot, you're going to end up with a shitty font because it's a lossy conversion (like converting .png to jpg. Excellent conversion software can generate a decent result, normal software will generate a mediocre result).
And because everything supports WOFF, we (thankfully) don't need ridiculous all-encompassing sets of ttf+otf+eot+woff+svg anymore, with a "bulletproof" #font-face rule that tries to optimize load order so not too many files are needlessly loaded - just use WOFF. Done. And in a pickle, add .eot as first source (with format indicator) and everything except IE will skip over it.
It's also worth looking at SVG font support: virtually nothing supports it, and those that do are in the process of deprecating it. SVG fonts as a thing has been discontinued because the results of using SVG fonts turned out to be incredibly much worse than using real fonts, underlining the explanation on point 1.
"In the end fonts are not really for graphics at all (especially not
monochrome), it seems to not the right way to use dummy empty and
non-semantic <span class="icon"></span> for this purpose."
Both of these claims are incorrect.
Fonts are for encoding vector graphics that are to be used in typesetting context. That can mean letters, or icons, or emoji; it can even be musical notes or mahjong tiles. And the way they do this has until very recently been as "single color", which is literally what monochrome is. The only place where monochrome rendering for fonts might be a problem is on monochrome monitors in which case: where the hell are your webpages being accessed that they can render webfonts, but do so on ancient-even-for-CRT technology O_O
As for semantics: if you need an icon that has no meaning inside the document and is purely UI candy then you do want a non-semantic element, so that text readers and the like for people with visual or reading disabilities don't get your icon read out loud to them, and text indexers for search engines (private or public) can safely ignore them entirely. Your icon should definitely be a non-semantic empty element that can be skipped by everything.
With all that said, what about bitmaps?
Bitmaps absolutely win at low point sizes, but—and this may be a surprise—fonts can actually contain embedded bitmaps so that they can render actual bitmaps, not vector graphics, at small point sizes.
Of course, only high grade fonts come with those, but that's also a thing you check for: does the icon font you're looking at come with bitmaps? If so, we have a winner. If not, then you might want to take the icon font you want to use, generate your icons as a bitmap file, and then manually clean up the bitmap before using it on your site.
This process is inherently manual, no utiltiy will do this for you and not get it wrong enough times that you still need to manually fix things up, but if you do go down this route, and you make your own icons based on a well known font, at a point size that makes the icons look better than the font rendering: give back to the world and send those bitmaps back to the font creators so that they can use them to build out the font's EBLC, EBDT, and EBSC tables and everyone else gets to enjoy having the bitmaps live inside the font, so we don't need to do crazy CSS sprite rendering.
I've been wondering myself why on windows my font looks smaller, and much crappier than on OSX.
Screenshot Mac VS Windows : http://screencast.com/t/UUxqLRhM
Is that because i used "em" on some rules instead of "px" ?
Thanks.
(This is from a comment, but I'll post as an answer.)
This is nothing on your end, and the culprit is different font rendering engines. Mac OS X tries to render fonts exactly as they were designed, whereas Windows tries to alter them slightly to make them more readable. The problem is, with certain fonts and sizes, it actually makes them look worse. (This article is a good read on the subject.)
If you make the font bigger, it will probably make it look better on Windows. I would venture to say that if you removed the bold font-weight, it would also look cleaner. You could also try a different font.
Overall though, all you can do is just play with different settings and see what looks good and what doesn't; the actual rendering is out of your control.
Different browsers do have different standard font-sizes. Maybo other font-types and the different way to show fonts of the OS.
100% same look is... not possible
The way MAC and PC handle fonts is different, but that is not what is happening here. You have set a font that is not web-safe, "MyHelveticaBold", and the font windows is using is clearly not the same as the one on your Mac. If you don't want to use a web-safe font then you should use open source web fonts that you can serve to the user upon visiting.
There are some CSS properties that can adjust how a font is rendered such as -webkit-font-smoothing. Read more here: http://blog.typekit.com/2011/01/26/css-properties-that-affect-type-rendering/
I'm working on a project with a designer and he insisted on using some specific font for titles and various elements in the page. So we're using a font kit to embed with #font-face.
It's working perfectly on PC (Firefox, IE 7 and 8, Chrome, Safari) but on Mac OS (Safari and Firefox) the fonts are not vertically aligned the same way. After looking on the Web, I didn't find any solution for this except "there always been differences between browsers and platforms, live with it".
I know that fonts are never rendered exactly the same across platforms, but this time it's not something like the font looks more bold or something like that. The font looks as if it's baseline is completely different between Windows and Mac OS X. On Mac OS, the font, at a size of 16px is 3px higher than on PC.
So I'm looking for a backup solution : is there a way to create a CSS specifically for Mac OS users? I do not want to target only Safari because Safari PC is ok, and Firefox Mac is not ok.
Or if you have a solution to fix the baseline difference that does not require a specific CSS file, I'd be happy to hear it.
Thanks!
I'm afraid that browser/os sniffing is your only option. CSS itself has no knowledge of OS nor do i have ever heard of a css hack that targets osx specifically.
This is the easiest way for me to detect OSX and add the OSX class to the document body so you can override css styles for OSX specifically.
if(navigator.platform.match('Mac') !== null) {
document.body.setAttribute('class', 'OSX');
}
Same as #ChrisR answer this is the easiest way for me to detect MAC and add the MAC class to the document body so you can override css styles for MAC specifically.
Additionally this keeps the current Body Class and just ADDS Mac on to it
if(navigator.platform.match('Mac') !== null) {
document.body.setAttribute('class', document.body.className +' MAC');
}
If setting an explicit line-height doesn't fix the problem, you can serve different stylesheets to each browser using your backend and detecting the OS in your application (via the user agent). You can also do something in JS doing the same thing, but there will likely be a FOUC while JS loads the relevant styles.
There's an easier way. http://rafael.adm.br/css_browser_selector/
It detects the browser and os and allows you to specify classes specific to it.
If you want close-to-perfect and painless, you're going to have to use the common fonts or fonts from an online service such as Google's free font library or one of the for-pay font libraries. These fonts have been designed and tested to work on the web.
Experimenting and including fonts for the user's browser to download and try to display correctly is fine, but won't be perfect and won't be painless. Also, be very careful with licensing restrictions - make sure the fonts your designer wants to use are properly licensed for use on the client's website.
If you have to do browser sniffing and serve multiple stylesheets, at this point I'd say your design is broken and needs to be revised. Show https://fonts.google.com to your designer and see if he likes any of those - they work cross-platform in all modern browsers and some are very slick. EDIT: Oh, and they're free to use without worries of licensing.
I'm not sure if this has anything to do with the recent Safari update, but I'm beginning to notice this a lot. There is a drastic difference in the way each browser is rendering fonts.
for instance, I took screenshots of what I am seeing here on stackoverflow...
http://twitpic.com/q43eh
I have verified that this is a trend via my co-workers machines.
has anyone noticed this or have any thoughts on non-hack solutions?
Font rendering isn't specified anywhere in the standards and therefore may (and will) vary between browsers and platforms.
In particular, Safari on Windows renders fonts like OS X does which tends to look weird to Windows users as Windows has quite a different take on how to render fonts than OS X.
You can definitely notice this, especially if you use Expression Web SuperPreview. This is just a general problem of the web, just like folks can hit Ctrl-+ and make your text bigger. Try not to use many absolute coordinates in CSS and the layout engine will ensure it's still readable
I first noticed this in OSX in October 2010. It is especially noticeable with Helvetica Neue. I suspect that an OSX update broke font anti-aliasing in font sizes above 12 pixels. I've posted an Apple Support message here.
I've got a website that I've just uploaded onto the interwebs, and it's displaying differently using Firefox 3.0.1 on Ubuntu and WinXP.
Two things I've noticed on Ubuntu:
The favicon is missing
The background color isn't displaying (it's set in the stylesheet)
What have I done wrong? The CSS file is being fetched under Ubuntu, so why isn't it applying all of the stylesheet, just the bits it likes? And why isn't the favicon displaying? Are they the same problem?
The answer on the background color: invalid HTML. But I'd love for someone to explain why it works under Windows and not Ubuntu.
The answer on favicon: previously, there was no favicon. The browser cached the lack of favicon. Clear the Firefox cache, and all is well.
I would first suggesting getting you html and css code validated. If there are any errors in your markup, these can cause errors in the rendering.
CSS Validator
HTML Validator
I've also run into differences between FF3 on WinXP and FF3 on OS X (mostly with CSS positioning). The CSS and HTML both validated properly, but I was never able to figure out why there was this difference. I would think that the rendering engine would be the same, but apparently there are at least a few subtle differences.
I agree.. there are subtle differences between the two operating systems. Part of this is just font sizes and how line height and letter spacing is determined. So much of page flow is based on these whitespace elements interact with other page elements.
i believe this is a font issue and a browser / OS issue.
we know that different firefox versions are dependent on the OS - there are some firefox extensions available for Linux, some firefox extensions for windows are available.
it's the font I guess.
Try to download mtts core fonts (microsoft true type ) which includes all the windows fonts so that firefox can display the fonts you specified in the css.
also you could check that you use fonts which are available on both platforms. Otherwise, I suggest rechecking and revalidating your code.
The other issue could be the screen resolution. It might be okay in windows with your high resolution but not with the low resolution ubuntu version.
Almost too obvious to say, but are they both "Firefox 3.01"? One isn't, for instance, Firefox 3.01 revision 3 update 6 service pack 9 and the other, well, you get the picture.
Even if they were both the very latest Firefox for that platform, doesn't mean they're exactly the same thing.
To see what's different, enter about:config in the address bar in Firefox in both Linux and Windows, press Enter, and compare the output
Ubuntu (I believe) apply their own patches to Firefox, so maybe this cause. Having said that, I thought that the patches were only for minor, GUI-type changes.