Comment by sid0 | Hacker News Reader

Comment by sid0 | Hacker News Reader

Parent Full thread

The trouble is, the current standardisation processes are far too slow to be practically useful, while the breakneck pace of experimental feature development is too fast to keep up, so there is no useful definition of "a little" in your suggestion that we can use for planning new web projects and making decisions about which technologies we will rely on.

If you're starting a new web project today, you look at what technologies the browsers you're targeting already support with unmodified syntax. (I'd argue that that development model's a poor fit for the web, but that's a different question.)

On Windows systems, the kerning is very odd in a lot of fonts since they moved to the new rendering engine a while back. The spacing following a capital T is usually way too tight, and in some fonts there are a few other examples as well. This can render pages completely illegible at typical body text sizes.

That is an artifact of ClearType subpixel positioning. Firefox 7 or 8 onwards (I don't remember which) turn subpixel positioning off for several commonly-used fonts, listed in gfx.font_rendering.cleartype_params.force_gdi_classic_for_families.

Also, take a Windows 7 computer with a few Adobe professional OpenType fonts installed locally -- probably some that come with Creative Suite would do -- and just try selecting those fonts using CSS in recent versions of Firefox.

I have a feeling you're choosing the font incorrectly. Note that with DirectWrite, any weight modifiers ("semibold", "black", "light") aren't part of the font name any more. Instead you need to specify weight using the font-weight property. So instead of saying Arial Black as you would normally, you need to say Arial with weight 900: http://www.neowin.net/forum/topic/971376-firefox-displays-my...

This is not a bug, though -- this is correct behaviour.

Most currently available web fonts also seem to look terrible (poorly hinted, terrible aliasing) on Windows XP in Firefox, but since they don't look great in other browsers either and they look better in Firefox on Windows 7, I'm inclined to point the finger more at Windows XP than Firefox in that case.

That's because most downloadable fonts aren't hinted for ClearType. DirectWrite with its subpixel positioning can cope much better with unhinted fonts.

> If you're starting a new web project today, you look at what technologies the browsers you're targeting already support with unmodified syntax. (I'd argue that that development model's a poor fit for the web, but that's a different question.)

If we really did that, we'd be back in the land of HTML4 and CSS2.1 and, ironically, Flash and Java applets.

I think the reality for most projects today is that we make a decision about how much portability pain we're willing to accept in return for using newer technologies to alleviate other pain such as making yet another set of rounded corner graphics, and we make a decision about how much degradation in the user experience is acceptable for older browsers that don't support whatever non-portable technologies we choose to adopt.

This is a far cry from what web standards should be, of course.

> That is an artifact of ClearType subpixel positioning.

That may be so, but the fact is that for several months lots of people using Firefox will have had difficulty reading lots of sites that worked perfectly well in older versions of Firefox and still work perfectly well today in other browsers (which makes me very suspicious of pinning the blame entirely on ClearType, BTW; no other software on these PCs has any trouble displaying those fonts).

If you're going to cause that kind of regression, then IMHO a policy of trying to force all of your users to update continually and ignoring the needs of those who can't or won't is inappropriate. Particularly in a security-sensitive application like a web browser, I think forcing users to choose between recent versions with vulnerabilities patched or old versions that actually did their job properly is irresponsible. After all, isn't this one of the reasons plug-ins are supposed to be Very Bad Things?

> I have a feeling you're choosing the font incorrectly.

Given that there is no standard specification of how to choose fonts like this, I think that's perhaps a rather bold claim to make (no pun intended). (Go ahead, check any W3C recommendations you like, you won't find it. In fact, the CSS2.1 Recommendation specifically acknowledges the variations in things like font weights between different families. It also provides no specific advice on naming conventions for font families at all, because what would you say that makes sense anyway?)

Again, it doesn't really matter though, because the point is that it worked on every other browser. Whether they are tolerant and Firefox is correct or they are correct and Firefox is broken doesn't change the end result.

> That's because most downloadable fonts aren't hinted for ClearType. DirectWrite with its subpixel positioning can cope much better with unhinted fonts.

Sure, but hundreds of millions of people are still browsing with ClearType, so I think trying to get professional sites to use web fonts that look rubbish in comparison to tried-and-tested screen-optimised fonts like Georgia and Verdana is one of those "Oooooh, shiny" policies that is more driven by hype than substance.

And for the record, a lot of the fonts available on the commercial font rental services render poorly even on high-resolution screens using the latest browser versions on Windows 7. I suspect the font services and foundries are banking on higher-res screens of the kind we're seeing on the latest smartphones making the need for traditional screen-font hinting obsolete. But this is drifting off-topic so I won't follow that avenue any further.

That may be so, but the fact is that for several months lots of people using Firefox will have had difficulty reading lots of sites that worked perfectly well in older versions of Firefox and still work perfectly well today in other browsers (which makes me very suspicious of pinning the blame entirely on ClearType, BTW; no other software on these PCs has any trouble displaying those fonts).

Read my words carefully. I did not say it is an artifact of ClearType. I said it is an artifact of ClearType subpixel positioning. Subpixel positioning is only available with WPF and DirectWrite, and very few Windows apps use those APIs. IE9 has exactly the same "problems" as Firefox does.

Given that there is no standard specification of how to choose fonts like this, I think that's perhaps a rather bold claim to make (no pun intended)

By "incorrectly" I meant "in a way that Firefox doesn't recognize". You don't blame Firefox when you misspell a variable name in a JS script, do you? Similarly, if you specify a font that Firefox doesn't recognize and it doesn't work it's not a bug in Firefox.

Again, it doesn't really matter though, because the point is that it worked on every other browser.

It worked in Firefox too -- the next font in the list got selected and the text still got displayed. The web platform provides no guarantees as to pixel-perfect rendering. If you want that you should publish a PDF instead.

Whether they are tolerant and Firefox is correct or they are correct and Firefox is broken doesn't change the end result.

It still works in other browsers, and it still works in Firefox. It has nothing to do with tolerance and everything to do with Firefox simply using a different API to enumerate fonts.

I'm afraid we're talking at cross-purposes about the first issue. What I'm talking about is entirely Firefox-specific (IE9 renders the same sites just fine) and it applies on Windows XP as well as Windows 7.

As for the remainder of our discussion, my point is simply that you can't do a lot of basic stuff like font selection in a standardised way today, and the constantly moving goalposts are not helping. Falling back to the next font in a list if a font isn't installed is a potentially useful behaviour. Falling back to the next font in a list in some browsers when the font is installed and other browser do find it means we haven't defined the standard for identifying fonts clearly enough.

What I'm talking about is entirely Firefox-specific (IE9 renders the same sites just fine) and it applies on Windows XP as well as Windows 7.

Do you have a test page? If it happens on Windows XP too then it's probably a bug. Did you file one?

The entire Web is a test page for this one, and I have come across numerous stories similar to my own. If you have the problem on your machine, you can't miss it: basically any time you see a capital T there will be an obvious kerning problem.

I have no idea whether a specific bug has been filed. I'm afraid I have given up trying to help Mozilla, since they seem to do just about everything possible to make it difficult to do so (insanely overcomplicated bug tracker, can't even download the past few releases any more, etc.). At current rates, I expect them to last about as long as RIM, so I devote my limited spare time to helping other projects instead.

The entire Web is a test page for this one, and I have come across numerous stories similar to my own. If you have the problem on your machine, you can't miss it: basically any time you see a capital T there will be an obvious kerning problem.

I haven't seen anything close to this, especially on Windows XP. Do you have a test page, a screenshot, anything?

can't even download the past few releases any more

OK, I can't assume good faith any more. You're outright lying now. https://ftp.mozilla.org/pub/mozilla.org/firefox/releases

At current rates, I expect them to last about as long as RIM, so I devote my limited spare time to helping other projects instead.

Troll.

> I haven't seen anything close to this, especially on Windows XP. Do you have a test page, a screenshot, anything?

Well, the top result if you Google for "Firefox kerning capital T" is this report from a few days ago, complete with screenshot:

http://forums.mozillazine.org/viewtopic.php?f=9&t=230274...

For the record, I'd already hacked one about:config entry about HarfBuzz (obviously something most users won't know how to do) to fix an earlier related problem, and it sounds like I now need to hack another one to fix the same problem in more recent Firefox builds.

> You're outright lying now. https://ftp.mozilla.org/pub/mozilla.org/firefox/releases

Well, thank you for the link. I can honestly say that despite using Mozilla browsers for many years and trying to file a bug on numerous occasions, I have never come across that FTP site. It sure as heck wasn't mentioned anywhere usefully prominent on either the main web site to download Firefox or the pages relating to filing a bug last time I tried, and I did spend several minutes looking.

I will just reiterate here that it wouldn't matter to me anyway now, though, because the one previous build I did find and install when trying to report a bug a few weeks ago (the latest 3.6 series one) basically screwed up my entire add-ons configuration in my current (then v5) Firefox build, something it had no reason to go anywhere near when I was just trying to do a clean parallel install to check for regressions in a particular area. If I'm going to volunteer my time to help out, it simply isn't worth risking the hassle of reconfiguring my up-to-date Firefox installation (which I use for actual paying work) any time I want to check for regressions since an older version.

> Troll.

No, honest opinion. I think the Firefox team's repeatedly demonstrated attitude to fast releases, new features vs. quality control/regression testing, and generally providing a sustainable, reliable platform useful for business applications, is fundamentally flawed on a management level. Their reliance on Google for almost their entire income stream is also fundamentally flawed on a commercial level, given that it is ultimately in Google's commercial interests to move more people onto Chrome and lock them in by using Chrome-specific features in Google's web offerings. If your management/PR and your commercial set-up are undermined, it doesn't really matter how good you are technically.

Anecdotally, I have been in two meetings already this week where director-level people (that's CxO level people for those of you across the pond) in medium-sized companies have made policy decisions that Firefox support is no longer to be considered a priority for their web development work (which is a significant part of their business in each case). The reasoning was much the same in both cases, and the same as other meetings I've been to recently: the amount of time that developers have been spending working around regressions and incompatibilities in recent months can't be justified when you don't know what will break again or be fixed anyway in the next release less than three months away, and when any claim of support that can't be relied upon for business-level timescales isn't worth anything in the market anyway.

More objectively, look at any reputable measure of market share in the browser space. Firefox hasn't been going anywhere for quite a while; if anything, it's dropped slightly according to some sources. Meanwhile, IE has been losing share as fast as ever, Chrome has been racing up faster than any browser in history, and several of the "minor" browsers are grabbing enough of the pie to register. That is not a healthy picture for Firefox.

Reply on news.ycombinator.com