No problem her with that page in Firefox 4 on Linux.

Which monospace fonts did you try?

All fonts (Courier New, DejaVu Sans Mono, Liberation Mono) that I tried worked in Firefox 4.

• http://en.wikipedia.org/wiki/DejaVu_fonts

Thanks, this is interesting. I just edited the original post to include a link that displays the problem. Can you see if it passes in your configuration?

(oops) I think you might have meant that you browsed to the test page and it passed. (I didn't expect to get a response so quickly!) If your view of the page passed, there may be an OS-specific font problem. Maybe I can enlist a local Mac user to see if the page mis-renders in FF4/Mac. I'm on Windows 7.

Yes, I meant the test page that you have added to your post. Your original post was from 1 month ago and probably got lost along the many posts during the Firefox 4 release.

Do you still have that problem with Firefox 4.0.1?

Monospace fonts should always work and spaces should have the same length as all other character.

Does it work if you specify a specific font-family via CSS?

pre { font-family: "Courier New"; }

Can you attach a screenshot?

Use a compressed image type like PNG or JPG to save the screenshot and make sure that you do not exceed the maximum file size (1 MB).

Let me know if this didn't work out. I attached two PNG files, one with a FF4 capture, and the other with a Chrome11 capture.

The text looks perfectly aligned (| under the size 'e'). It is only the part further down that has the trialing spaces a slight bit smaller.

When the monospace alignment problem (space glyph size

The quick red fox jumped over the lazy brown dog     |

Does it help if you disable hardware acceleration?

• Tools > Options > Advanced > General > Browsing: "Use hardware acceleration when available"

If disabling hardware acceleration works then check if there is an update available for your graphics display driver.

Thanks for the suggestions. Disabling hardware acceleration does not resolve the problem. I have attached two screenshots that show how dramatically different the rendering can be. In FF4 the lines from the enzymes point to the wrong location in the sequence. This is very bad! It's a shame because I used to recommend Firefox to visitors to the site.

Apparently this is a Windows-specific issue, as Firefox 4 on Mac passed the page test (according to someone who tested for me.) Version 4.0.1/Win shows the same behavior as 4.0.0.

I have the same issue with the monospace fonts on Windows 7 + FF4. I've turned off hardware acceleration. Enabling/disabling clear type seems to make no difference. My workaround for the moment has been to replaces spaces in my test data with one of the Unicode space characters of varying widths. In my case, "em space" when using the Consolas font fits the bill:

data:text/html;charset=utf-8,%3Chtml%3E%3Chead%3E%3C%2Fhead%3E%3Cbody%3E%3Cpre%20style%3D"font-family%3AConsolas"%3EConsolas%2Bunicode%20char%20%238195%20workaround...%0D%0ASpace%3A%0D%0A%20%20%20%20%20%20|%0D%0Aabcdef|%0D%0AUnicode%26%23x2003%3Bchar%26%23x2003%3B%238195%26%23x2003%3B(0x2003)%0D%0A%26%23x2003%3B%26%23x2003%3B%26%23x2003%3B%26%23x2003%3B%26%23x2003%3B%26%23x2003%3B|%0D%0Aabcdef|%0D%0A%3C%2Fpre%3E%3C%2Fbody%3E%3C%2Fhtml%3E

Thanks, Gurok! The Consolas - em space workaround narrows the gap, no question. I have put up a page that shows the workaround benefit here. But it's clearly only an approximation. In my application the spaces have to line up exactly or the DNA sequence will be misread.

This is actually what I meant. Try going to this page:

http://users.tpg.com.au/penneyb/test.html

View source and you'll see where the em spaces should be. By any chance, are you using nVidia hardware, brianseed?

That works nicely! And yes, I have an NVIDIA Quadro FX 880M.

I won't be implementing this workaround in the near term, though. The code base is too large and the number of interdependencies is too great for a rewrite to make sense at this time.

Hrm... I'm using nVidia hardware (8800GTX) too. When I test on Windows 7 at work, with roughly the same configuration (but a generic graphics solution), the problem isn't apparent. I don't know enough about FF4 to know whether video hardware matters when it comes to font rendering, but it's all I can think of for now.

That workaround is probably best implemented with a bit of JS to detect whether it's applicable. You can't really rely on "Firefox 4" and "Windows 7" in the user agent of requests to detect whether or not to replace spaces like that. I've tested on two machines, and the problem's present on one but not the other. You could write some JS to compare the width of a regular space, an em space and a random character (e.g. 'x'), and only replace spaces with em spaces if the regular space wasn't as wide as the random character and the em space was.

But you're right, it's best not to implement a workaround at all. I'd love to know what the cause of this issue is.

That is very interesting. Also ominous, because once the hardware layer starts interacting with (high level) code the odds are pretty good you're in trouble.

The principal app affected by this has >3000 lines and emits embedded javascript that also relies on the <pre> directive for display of the relationships between enzyme cleavage sites and the sequences of the fragments the enzyme liberates. I really can't afford to tinker with the space char. It's too bad.

Guys, don't blame the hardware as long as every goddamn notepad app out there does get it right.

The html below shows the same issue for other fixed width fonts on my system (NVS3100M); see attached image for ff 4.0.1 rendering.

I agree that the whitespace issue is a potential FF4 deal breaker (source code listings and other ASCII Art depend on this, ...).

So stop whining and get it fixed.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><body>
<pre style="font-family: Courier New">
Courier New<br />

+-------+-------+-------+-------+-------+------+<br />

|       |       |       |       |       |      |<br />

+-------+-------+-------+-------+-------+------+<br />

</pre><pre style="font-family: Lucida Sans Typewriter">

Lucida Sans Typewriter<br />

+-------+-------+-------+-------+-------+------+<br />

|       |       |       |       |       |      |<br />

+-------+-------+-------+-------+-------+------+<br />

</pre><pre style="font-family: Consolas">

Consolas<br />

+-------+-------+-------+-------+-------+------+<br />

|       |       |       |       |       |      |<br />

+-------+-------+-------+-------+-------+------+<br />

</pre>

</body></html>

Does it work in Save mode or with D2D disabled?

Works fine here on Linux with the above posted code.

The test page renders correctly when the browser is started in safe mode. In addition, more demanding rendering tests of DNA analysis code pass when the browser is started in safe mode. This is a major step forward! However I have not been able to localize the safe mode change that is relevant. Individual or collective disabling of the various components enumerated by checkboxes in the safe mode modal dialog window does not correct the space glyph mis-rendering. Only selection of the "continue in safe mode" option produces the desired behavior.

In Firefox 4 Safe mode disables extensions and disables hardware acceleration.

• Tools > Options > Advanced > General > Browsing: "Use hardware acceleration when available"

If disabling hardware acceleration works then check if there is an update available for your graphics display driver.

You can also try to toggle some of the Boolean gfx prefs on the about:config page to enable or disable some features. Filter: gfx

To open the about:config page, type about:config in the location (address) bar and press the "Enter" key, just like you type the url of a website to open a website.
If you see a warning then you can confirm that you want to access that page.
You can use the Filter bar at to top of the about:config page to locate a pref more easily.

• http://kb.mozillazine.org/about:config

Disabling hardware acceleration wasn't effective. (You had suggested this before.) I explored each of the gfx prefs using a page reload to evaluate the consequences of a change, but am not sure whether these require a browser restart to take effect. If they do, my test was ineffectual. In any case, starting from default mode (user preferences reset to default), I was not able to realize the desired page performance following toggling any of the gfx prefs (or changing their numeric values) and conversely, upon start in safe mode, I was not able to defeat the desired behavior by toggling any of the gfx prefs (or changing values). I looked into ways that I might be able to list and compare the preferences in safe mode with those in default mode but didn't make much headway. Thanks for your suggestions.

It seems I can toggle the bad behaviour using:

gfx.font_rendering.directwrite.enabled

A browser restart was required.