Since Cairo was switched on on Mac OS X, there have been a number of inconsistencies with both the width and line spacing of displayed text, as well as irregular placement within the div or xul box. These have changed over time, but are still not completely right. Since I can't find a current bug, I'll use this one to outline what I can see. Please open the first attachment, which a simple block of text in a div, containing a number of rows of 'f's and 'j's, broken up into words. From Firefox 0.9 (or earlier) all the way up to the 20061121 build (just before Cocoa), the div was displayed in a very consistent manner. Since then, the drawing has deviated in four different ways: 1. In all Cocoa builds, the text overflows the bottom of the div by 1 px. i.e. the very bottom of the 'j's in the bottom row are drawn just below the div (coloured area). Either that, or the div colour is calculated and drawn out of alignment. Up until Cocoa, the very bottom of the j was always drawn on the very last pixel row of the div. 2. In all Cocoa builds, the widths of the "words" now vary within a row, even though they are exactly the same words ("width" measured from the left of first 'f' to right of final 'j'). Up until Cocoa, they were always consistently 26px. The widths for the words in each row now follow the pattern: 26, 27, 26, 26, 26, 27, 26, 26px. So there are two words in there that are 1 px too wide, and they're always the 2nd and 6th words. The spacing between words has remained a constant 5px, however. 3. In Cocoa builds up to and including 20061213, the space at the top of the div was 2px, as it was before Cocoa. Since 20061214, there is 3px instead. Perhaps because of the checkin for bug 362428?? Not sure. 4. The pattern of spacing between rows has changed 4 times since Cocoa was switched on. Before Cocoa, spacing was a consistent 2px between rows. From 20061122-20061213 it followed the pattern 2-2-1-2-2-1-2-2 (numbers are px). From 20061214-20070122 it followed the pattern 2-2-3-2-2-2-3-2. From 20070123-20070206 it followed the pattern 2-3-2-2-3-2-2-2 (from checkin for bug 333659 perhaps?). From 20070207 onwards it followed the pattern 2-3-2-2-2-3-2-2 (from checkin for bug 177805).

roc, I was wondering if you have any insight into this? I was hoping that the font metrics fixes in bug 96041 might reduce the inconsistencies with font rendering on Mac (refer to comment 0 for background), but the current situation with the testcase attachment 254646 [details] is (with reference to the points in comment 0): 1. 1 px gap between the bottom of the text and the bottom of the div. Pre-Cocoa there was no gap. For a lot of the time Cocoa has been around the text actually overflowed the bottom 2. in each row, the widths of the "words" (and the spaces between the words) now vary as follows: 27 (4) 27 (5) 26 (5) 26 (5) 26 (5) 27 (5) 26 (5) 26, all numbers are px and the numbers in brackets are the widths of the spaces. Pre-Cocoa, the "words" were consistently 26 px, and the spacing 5 px 3. A gap of 3 px at the top of the div since Dec (2 px before that, including pre-Cocoa) 4. Spacing between rows now varies as follows: 4-4-3-4-3-4-4-3 px. Pre-Cocoa it was consistently 2 px between rows, but since Cocoa the values have changed frequently (see point 4 in comment 0)

> 1. 1 px gap between the bottom of the text and the bottom of the div. Pre-Cocoa > there was no gap. Why do you think this should be considered a bug? > 2. in each row, the widths of the "words" (and the spaces between the words) > now vary as follows: 27 (4) 27 (5) 26 (5) 26 (5) 26 (5) 27 (5) 26 (5) 26 How are you getting these measurements? And what are you system font smoothing settings? Because we're doing subpixel positioning now, when it's enabled in the system, you will see the words vary slightly from one column to the next, and the number of blank pixels between each word may differ by one. But because of subpixel antialiasing this should not be very perceptible to users. > 3. A gap of 3 px at the top of the div since Dec (2 px before that, including > pre-Cocoa) Why do you think this should be considered a bug? > 4. Spacing between rows now varies as follows: 4-4-3-4-3-4-4-3 px. I see this. It's probably because we lay out with subpixel precision vertically but then round the Y coordinate to the nearest pixel when we render. I don't think it's that serious although we could probably fix it by rounding something during layout. File a separate bug for that if you want. Include a testcase with the font and size style set inside it, please.

Thanks for responding, roc. Firstly, my font smoothing is set to Automatic (min. size for smoothing set to 8 pt). Varying it from Light to Strong had no appreciable effect on the attachment. And the tool I was using to count pixels is Pixie in the Apple Developer Toolkit. To answer, I wasn't certain that any of the things I mentioned was a "bug". What caught my attention in the first place was the issue with text overflowing the bottom of the div, which quite obviously *was* a bug, and began at the same time as the other text effects I mentioned. That particular problem is now gone, but I noticed that the other "discrepancies" in text positioning remained, though they occasionally changed values with new check-ins. Given that the old values had been consistent forever before Cocoa, and are identical to what I still observe in Safari (would Safari do subpixel positioning as well?), I thought it was worth bringing to someone's attention. If it's intentionally different, I can resolve this bug. I can file a new bug if you think the line spacing, at least, is worth fixing. Cheers.

I don't think Safari does subpixel positioning, although I'm not sure. It's probably worth filing a bug on the varying line spacing, and closing this one. Thanks!

This test case shows different behaviour between Opera, Safari/Chrome and Firefox. It would be good to understand why.