Spinning off from bug 367848. The decimal of the device pixels of letter-spacing and word-spacing is dropped on WinIE7 and Opera9(Win). Gecko inserts the space if the accumulation spaces are over a device pixel. This is not a big compatibility issue. But I think that the different width spaces are not good for the looks.

I'm still somewhat against this (although not strongly), as I said in bug 367848 comment 3. At some point font rendering will probably support sub-pixel positioning. There are good reasons to round borders and text-decorations that don't apply here.

And in fact, Mac does currently appear to do sub-pixel text rendering.

I tested on linux. If the font is rendered with bitmap glyphs, the sub-pixel rendering is disabled. (I think that such is good thing for bitmap glyphs.) If we only support the vector fonts, sub-pixel rendering is good way. But we must support the bitmap glyphs, we still have the issue in cairo rendering... (Note that the some CJK fonts have bitmap glyphs for small sizes. e.g., between 9pt and 12pt.)

I tested on Mac. Mac may always use the vector glyphs even if the font has bitmap glyphs. I think that on the Mac, we may not need to round. But on linux, I don't think so. (of course, on Win, we should round it.) We have two ways: 1. only on Win/Linux, we round the values. 2. on all platforms, we round it.

Note that Safari rounds the values to the lower device pixels.

3. leave our current behavior

(In reply to comment #3) > And in fact, Mac does currently appear to do sub-pixel text rendering. > dbaron: What document tell you the information? I'm working on text-decoration offset issues, in the testing, I found the fact that Mac doesn't support the sub-pixel rendering for vertical positioning. I.g., in the following fragment, <span>XXX</span><span style="position: relative; top: 0.4px;">XXXX</span> The all characters rendered in same Y position.

I have a question. Would the sub-pixel rendering be supported on Linux? See the screenshot. This is a screenshot of the following testcase: <p style="letter-spacing: 0.12em;"> <span>EEEE</span><br/> <span style="position: relative; left: 0.4px;">EEEE</span><br/> <span style="position: relative; left: 0.5px;">EEEE</span><br/> <span style="position: relative; left: 1px;">EEEE</span> </p> It looks like the first two lines are rendered in same X position. And last two lines are too.

(In reply to comment #8) > What document tell you the information? I observed it, looking at *horizontal* positioning. See bug 359903 comment 8.

I'm resetting bugs which are assigned to me but I'm not working on them and I don't have plan for fixing them in near future.

We could do this for platforms that don't support horizontal subpixel positioning. But of our major platforms, that's only Windows.

roc: see comment 9. Does gecko of Linux support the subpixel positioning now?

I'm not sure.

It may depend on the kind of screen you have.

I retested on Ubuntu9.04 on VMware6.5 of Windows, but the subpixel positioning is not supported on latest trunk build. The display is "Unknown" for Ubuntu.

Google Chrome rounds, Fx shows a moiré. I strongly suggest to do it like chrome.

We support subpixel positioning on Windows now with D2D. Subpixel positioning is definitely the future. I stand by comment #12: if we're going to do anything here at all, we should detect whether the platform does subpixel positioning and if it does not, then round letter-spacing/word-spacing. I'd take a patch for that, although I wouldn't ask anyone to work on it.

Bug 939132 suggests an alternative (better, IMO) solution to the problem here.

In these days, IE 11 and Chrome uses subpixle text positioning. So, they render the testcase similar to Gecko. So, there is no reason to change our behavior now.