6 years ago When viewing pages in FFOX, the fonts appear heavier than specified. This is especially troublesome with icon fonts.

Even when specifically set to normal/400 weight (or even any weight lighter), they appear to be bolded. In jdaggett's demo: You can see that with no font smoothing (webkit), Safari comes in somewhere between Chrome (the lightest) and FFOX (the heaviest). With font smoothing enabled, Chrome and Safari are identical, but FFOX is very heavy (of course, since it's not changed by webkit font smoothing): Here's JD's image (blown very large) of his font vs my machine's font: I have found, that on my Mac, if I go to Settings General and set 'Use LCD font smoothing when available' to OFF (it's on by default) and restart the browsers, FFOX looks like the other browsers. I know I'm not unique, because one of the guys at work pointed out the bolded icon font to me before I'd seen it. My personal machine is: Mac OS X (10.7.5) Processor: 2.66 GHz Intel Core i7 Memory: 8GB 1067 MHz DDR3 Graphics: NVIDIA GeForce GT 330M 512 MB If you need another test case, you can view the icon font in the footer at: Those are the fonts I originally noticed with the bold appearance in FFOX.

(I was supposed to cc:brendan and:dbaron. But don't see how to do that in the interface.). 6 years ago Created screenshots showing the contatta font as rendered in TextEdit.app This shows how the contatta icon font renders in TextEdit.app, as black on white and as white on black, comparing grayscale-only (left) vs LCD (right) font smoothing.

The 'problem' in Firefox is simply how OS X renders the font when 'LCD font smoothing' is enabled (which I think is the default). AIUI, it's widely known among the font-design community that OS X tends to fatten glyphs somewhat compared to other rasterizers. For the usual case of black-on-white text, this works OK (though some people like it more than others); however, for white-on-black, the effect can be much too heavy-handed. It's not clear to me, though, that we'd want to disable LCD smoothing altogether, if it's enabled in the system preferences.

As a general rule, we should be honoring the user's settings, and if we -don't- use LCD smoothing when it's enabled system-wide we're likely to get complaints that Firefox's font rendering looks different ('weak'?) compared to other applications running on the same system. One option might be to disable LCD smoothing for downloaded (@font-face) fonts, on the grounds that it might provide a better match to how other browsers render the same pages. I'm not keen, though, as that puts us in a position where the exact same font will render quite differently when used via @font-face to how it renders when installed locally. I don't think that's helpful to designers, overall. Maybe we could detect when we're drawing light-on-dark text, and switch to grayscale-only AA in that situation. Difficult to do in a fully general way, though: what would we do when drawing text with a gradient, or on top of an image or other variable background? Or another option would be some kind of CSS property that authors can use to select which kind of antialiasing should be applied.

That only works for authors who are actually aware of the issue, though, and figure out what works best for their particular font. And it enables authors to ride roughshod over the user's preference for how fonts render on their system, which is something I think should normally be under the -user's- control. In short: while I sympathize with the reporter's complaint, and agree that example looks bad, it's not at all clear to me what would be the most appropriate solution in Firefox.

6 years ago FWIW, viewing the contatta.com site in Opera (v12.14) on OS X shows rendering that looks very much like Firefox's. With Opera switching from Presto to Webkit, I suppose that's likely to change, but it serves to demonstrate that this isn't really a Firefox issue, it's an OS X font-rasterizer issue. I realize this may seem like trying to duck the issue, but my recommendation to authors would be -not- to use 'icon fonts' for things like this. They do seem to be a hot topic in the web-authoring world at the moment, but font and text-rendering APIs and technologies have been optimized for -text- rendering, and things like the Twitter or Facebook or Youtube logos are -graphics-, not text. As such, the appropriate web technology to deliver them would be SVG or PNG graphics, not @font-face. And that will give you much better control over exactly how they appear (as well as ensuring the intended logos appear even for people who have turned off the option to 'allow sites to use their own fonts'). 6 years ago While I agree that users should have control of their experience, I'm not sure the answer to this issue is just 'don't use icon fonts'.

The ease of use/upkeep/advances in @font-face/etc mean they're likely here to stay. It seems to me that giving a developer the ability to fine tune the experience on their site is important. Please don't say that because there are some ignorant devs out there, we can't have nice things. (If that were the case, we could throw out lots of the advancements of HTML5 and CSS3 — because people are building things that are really no different than Flash.;) Having something like I have in webkit, with font smoothing/antialiasing/etc would be my optimum solution — as a dev who keeps the user's best interest in mind.

The problem is large enough, that if you Google the issue, you'll find lots of folks floundering around with font issues — and no solution. Help us to make FFOX look awesome? 6 years ago Created screenshot, closeup of testcase on various browsers Magnification of the reddit icon from the testcase.

The top row shows Firefox/Safari/Chrome on Stephanie's machine, the bottom row shows it on my Retina Mac Book Pro. Notice that Chrome uses subpixel antialiasing on my machine but grayscale antialiasing on Stephanie's machine. Safari on Stephanie's uses subpixel antialiasing, so this isn't a system setting issue (i.e.

Disabling the LCD font smoothing setting in Prefs or any of the other low-level means of doing this). On my machine there are slight variations in the pixel values across the three browsers (Safari and Chrome don't match). 6 years ago (In reply to Stephanie Sullivan Rewis from ) I know I'm not unique, because one of the guys at work pointed out the bolded icon font to me before I'd seen it. Could you ask them to view the testcase I made on their machines? Do they see the same results as you?

Walking around the office yesterday at Mozilla Japan I couldn't find anyone who showed results similar to the one you're seeing, nor could I reproduce it on an iMac running 10.6. In all cases, results across browsers Firefox/Safari/Chrome used subpixel antialiasing. My personal machine is: Mac OS X (10.7.5) Processor: 2.66 GHz Intel Core i7 Memory: 8GB 1067 MHz DDR3 Graphics: NVIDIA GeForce GT 330M 512 MB What flavor of Mac is this? IMac/MacBook Pro/mini? Are you using an external monitor? If so, what model/make?

Thanks for your help with this! 6 years ago (In reply to Jonathan Kew (:jfkthame) from ) I realize this may seem like trying to duck the issue, but my recommendation to authors would be -not- to use 'icon fonts' for things like this.

They do seem to be a hot topic in the web-authoring world at the moment, but font and text-rendering APIs and technologies have been optimized for -text- rendering, and things like the Twitter or Facebook or Youtube logos are -graphics-not text. As such, the appropriate web technology to deliver them would be SVG or PNG graphics, not @font-face. And that will give you much better control over exactly how they appear (as well as ensuring the intended logos appear even for people who have turned off the option to 'allow sites to use their own fonts'). I definitely agree with you to some degree here, the naive insertion of graphics into fonts can lead to poor results in some cases, for example the eyes of the Android icon in my testcase at small sizes. But I think there's definitely a utility in being able to package a set of graphics into a font and that's why these sorts of fonts are gaining popularity.

I think it would be worthwhile to define and support some form of the 'font-smoothing' property so that authors can get rendering similar to what they get in Webkit browsers with -webkit-font-smoothing. How about: font-smoothing: auto antialiased where 'auto' is what happens today, user agents try to optimize the rasterization of text based on display parameters and 'antialiased' explicitly forces grayscale antialiasing. The original 2003 flavor of font-smoothing had 'none' and 'subpixel-antialiasing' but I don't think those make sense in practice. 6 years ago Hi John.

My machine is a 17' MacBook Pro. I do have an external monitor (I use them as duals), but I don't see any difference in weight from one to the other. It's a Samsung. The guy at work that showed me the bold fonts previously (but is no longer here) had a MacBook Air (I THINK). I do remember it was small. = The rest of our office (being a startup) are all on newer MacBook Pros—most under a year old.

They do not see a difference in the top row of your example, but of course DO see better rendering in Safari and Chrome in the anti-aliased group below. That said, they all see the overly bold Contatta icons in FFOX — especially evident with YouTube and Google+ - (And yes, I do have webkit font smoothing on in Contatta since it's needed.) I would be thrilled with the ability to set the font-smoothing in FFOX as well. Tickled pink! (We have a huge assortments of icons in our platform — having the ability to change their color and add text-shadow, etc, just as we do for a font is a big time/maintenance saver. Getting rid of huge sprite sheets also makes our lives much simpler.) Thanks, John. 6 years ago Firefox needs to implement the equivalent of -webkit-font-smoothing: antialiased; if you want people to be able to use icon fonts.

See this screenshot: The browser on the top is Safari, with font smoothing set to antialiased, rendering the IcoMoon icon properly. The same behaviour is observed in Chrome on Mac. (I haven’t tested on any other platforms at the moment.) The browser on the bottom is Firefox. The icon font is unusable and there is not way to get it to render properly.

(The same problem occurs in Opera on Mac.) This basically means that I cannot use icon fonts on my site until the font-smoothing is implemented in Firefox (as I don’t want to give Firefox users such a subpar visual experience). 6 years ago If we're going to do something like this, let's at least give it a sensible name. AFAICT, -webkit-font-smoothing: antialiased actually means 'use grayscale antialiasing, but do not use subpixel (ClearType, LCD-style) antialiasing'. A more logical set of property values might be something like: (-moz-)font-smoothing: none grayscale subpixel auto where 'auto' would be the default, and would mean 'use the system-wide default setting'. I think we should push back against using the term 'antialiased' to mean.one specific kind. of antialiasing, to the exclusion of others.

Both grayscale AA and subpixel AA are valid implementations of antialiasing, so a setting of 'font-smoothing:antialiased' has no reasonable grounds to choose between them. 6 years ago (In reply to Stephanie Sullivan Rewis from ) Hi John. My machine is a 17' MacBook Pro.

I do have an external monitor (I use them as duals), but I don't see any difference in weight from one to the other. It's a Samsung. Were all the screenshots taken on the external monitor or on the built-in screen? It would be interesting to compare the browser combinations together on each screen rather than comparing on different screens. If the OS doesn't 'know' the monitor it will often default to grayscale anti-aliasing for that monitor.

Apple's support sites lists lots of people reporting issues with 10.6 and 10.7 about the OS not knowing their display and how to manually force on subpixel antialiasing via a defaults tweak. The rest of our office (being a startup) are all on newer MacBook Pros—most under a year old. They do not see a difference in the top row of your example, but of course DO see better rendering in Safari and Chrome in the anti-aliased group below.

Right, this makes sense. That said, they all see the overly bold Contatta icons in FFOX — especially evident with YouTube and Google+ - (And yes, I do have webkit font smoothing on in Contatta since it's needed.) Right, Firefox ignores the '-webkit-font-smoothing' property which is why it renders differently. 6 years ago (In reply to Jonathan Kew (:jfkthame) from ) If we're going to do something like this, let's at least give it a sensible name. I think we should push back against using the term 'antialiased' to mean.one specific kind. of antialiasing, to the exclusion of others.

Both grayscale AA and subpixel AA are valid implementations of antialiasing, so a setting of 'font-smoothing:antialiased' has no reasonable grounds to choose between them. Yeah, I would agree with you that the terminology is problematic, in particular the 'antialiasing' term. But I think the underlying question here is whether this is a solution for a short-term problem for which a prefixed property would suffice (e.g.moz-font-smoothing) or a more general problem that needs to be defined formally in a spec.

I tend to think it's a short-term problem, there's no subpixel rendering on iOS or in the Metro UI and the problem here is a non-issue on Retina resolution displays. AFAICT, -webkit-font-smoothing: antialiased actually means 'use grayscale antialiasing, but do not use subpixel (ClearType, LCD-style) antialiasing'. A more logical set of property values might be something like: (-moz-)font-smoothing: none grayscale subpixel auto where 'auto' would be the default, and would mean 'use the system-wide default setting'. So the problem with the complete set of options here is that 'auto' and 'subpixel' are basically duplicates, since you can't force on subpixel anti-aliasing in all situations. If a user has explicitly disabled it, then the author shouldn't be able to force it on via 'subpixel'. Nor is subpixel anti-aliasing needed or desired on Retina resolution displays.

Css Font Smoothing Coming To Firefox For Mac Download

Chrome already disables subpixel rendering on Retina displays (curiously, Safari does not). I also don't see a strong need for 'none' either, I doubt there are many actual use cases for an author-level control like this. Which really leaves the 'antialiasing' value as the only one with a real use case. In this one particular case, I think it might make sense to simply implement support for the '-webkit-' prefixed property and only support auto/antialiased. This is really an OSX-specific property masquerading as a general property and I don't see great value in implementing it on other platforms. As screen resolutions increase it will die a well-deserved death. I'd be curious to hear if dbaron or tantek have an opinion here.

Finally got over here to check it out, Zoltan. I’ll post about it and spread the word after I get back from Ireland. IE is a strange bird, really. I got started in web development in an Intranet environment with IE as the only approved browser so I know it intimately. It’s a pain in the ass to be sure, but very, very hackable. (High hopes for IE9.) Over the years I’ve found that if you look at IE’s features long and hard enough and then test enough, you can almost always get IE to “heal itself”.

Css Font Smoothing Coming To Firefox For Mac

Judo style, you can use IE’s own peculiarities to overcome it’s peculiarities. Quite amazing. @Jennifer: Using the DropShadow filter on this container will do this trick, as long as you set a background color to the object, otherwise IE6-8 will put a drop shadow on the text as well. In order to handle transparent backgrounds in IE6-8, one must use the Chroma filter alomg with the DropShadow filter in order to make this work.

Here is an example of this in action: View the source to see the full CSS with a brief explanation. I will probably end up writing an additional blog post about this method so I can explain in detail. I can’t get this to work when using -sand-transform:rotate on the same element – although if I copy the -sand-transform generated rotation rule, append this within the same filter: parameter and add it to the stylesheet manually it does work.

Is there a way to pass this through -sand-transform to get the required effect? Background-color: white; filter: progid:DXImageTransform.Microsoft.Matrix(M11=0.998630, M12=0.052336, M21=-0.052336, M22=0.998630, sizingMethod=’auto expand’) progid:DXImageTransform.Microsoft.Chroma(color=’#ffffff’); Many thanks.