345392 - Never anti-alias certain monospace fonts (Monaco, Courier, others?) 10px and smaller

Status: NEW

(Core :: Graphics: Text, enhancement)

Description

[Trevor Johns]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2

Right now, Camino decides whether a font should be anti-aliased or not based on the "Turn of text smoothing font sizes # and smaller" option in System Preferences/Appearance. This applies to all fonts, regardless of whether they are fixed width or not.

However, other applications seem to treat fixed width fonts differently, instead choosing to disable anti-aliasing at 10pt. and smaller, regardless of preference.


Reproducible: Always

Steps to Reproduce:
1. Go to System Preferences/Appearance, turn off font smoothing for font sizes 8 and smaller.
2. Launch Camino, go to Preferences/Appearance, set monospace font to 10pt Monaco. Browse to a page that has monospace text (like this bug).
3. Launch TextEdit, select Format/Make Plain Text, make sure the font is set to 10pt Monaco and type some text.
4. Compare rendering between Camino and TextEdit.

Actual Results:  
TextEdit ignores the preference in System Preferences and does not anti-alias the text, whereas Camino follows the preference and anti-aliases the text.


Expected Results:  
Like TextEdit, Camino should chooose not to anti-alias the text.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

There's an old bug around here somewhere where this subject was argued and changed to the current behavior.

I think setting browser.quartz.enable_all_font_sizes to false will make this work as you intend (but I'm not sure).

Comment 2

[Trevor Johns]

Attachment: Font handling comparison

(In reply to comment #1)
> There's an old bug around here somewhere where this subject was argued and
> changed to the current behavior.

I think that would be bug 180535. At least that's where browser.quartz.enable_all_font_sizes was created.

That bug is about bitmap fonts, whereas this is about monospaced fonts. Clearning browser.quartz.enable_all_font_sizes certainly gives me the behavior I'm looking for, but it also affects Geneva (for example). I think there should be a distinction between the two.

I've attached an image demonstrating the difference between how Safari and Camino (both with and without enable_all_font_sizes) handle this. I think in this case Safari is doing the right thing.

Comment 3

[Chris Lawson (gone)]

Per comment 2, this is important for Safari parity. If there's a way we can fix this, we probably should.

Comment 4

[Chris Lawson (gone)]

Confirming, because no one has given a good reason why we shouldn't do this in the last four months. :-p

Comment 5

[Chris Lawson (gone)]

It seems likely that this is a Core bug rather than something Camino-specific.

Firefox 2 seems to respect the anti-aliasing preferences in System Prefs.

Minefield 2008042704 (Firefox 3 nightly) does not; it seems to render things the same way my debug Camino 2008060519 does, and both appear to ignore the browser.quartz.enable_all_font_sizes preference now (I'm betting the latter is a side effect of Cairo).

Smokey, where should we kick this?

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Since the (old) summary and comment 0 are round-about, what this bug asks is that we never anti-alias monospaced fonts 10px and below.  

That is, if you set System Prefs's "Disable text smoothing for fonts size [8] and smaller", that means you want all fonts 9 and above to use AA--except if they're monospaced, in which case 9 and 10 should not be AAed.  Monospaced fonts 10px and smaller should never be AAed.

John, is this something you could make happen in cases where gfx.use_text_smoothing_setting is enabled, since that pref is currently controlling whether Gecko honors platform conventions?

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: testcase

Here's testcase with two different monospace fonts and a serif and sans-serif pair.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Screenshot

Here's a screenshot of the testcase in the previous comment in TextEdit and Safari on 10.5, showing AA disabled on 9 and 10 when the OS is set to disable only on 8 and smaller.

Comment 9

[John Daggett (:jtd)]

(In reply to comment #6)
> John, is this something you could make happen in cases where
> gfx.use_text_smoothing_setting is enabled, since that pref is currently
> controlling whether Gecko honors platform conventions?

Yes, enabling gfx.use_text_smoothing_setting will use the system prefs setting.  It will disable anti-aliasing based on the system setting but it won't enable the placement of glyphs on pixel boundaries, that's why the text is basically unreadable below 8pt.

1. Open about:config
2. Enter gfx. in the filter field
3. Enable gfx.use_text_smoothing_setting
4. On restart, text will be rendered based on Appearance panel setting

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Safari vs Camino comparison (gfx.use_text_smoothing_setting on)

Sorry, maybe I wasn't clear enough.  Here's a better illustration:

With the system setting to disable AA at 8 and below (and, in Camino, gfx.use_text_smoothing_setting set to true before launch):

1) Times and Helvetica are AAed at 9 and up, and not AAed at 8 and below
2) In Safari (and other Mac apps, e.g. TextEdit in the previous screenshot in comment 8), *mono* fonts like Monaco and Courier are not AAed at size 9 and 10, despite those values being higher than 8.
3) In Gecko with gfx.use... on, all fonts 9 and up are AAed.

This bug is asking for us to also support this special behavior, i.e., don't AA any mono fonts 10 and smaller.

Since we only honor OS font behaviors when gfx.use_text_smoothing_setting is on, I asked/suggested in comment 6 that perhaps it would make most sense if this additional behavior (no AA of mono fonts 10 or smaller) was incorporated into the existing behaviors that gfx.use_text_smoothing_setting enables.

John, do you follow that?

Comment 11

[John Daggett (:jtd)]

Attachment: TextEdit rendering for various fonts

OK, got it.  The behavior seems to be that Monaco and Courier render without anti-aliasing for all sizes up to and including 10pt, *independent* of the Appearance panel setting.  Other monospaced fonts, Osaka Mono, DejaVu Sans Mono, etc. render as expected.

I searched through the Webkit code and didn't find any special casing so I'm guessing this is something buried deep down within Cocoa/Quartz.  Wouldn't be the first time...

Are there fonts other than Monaco/Courier for which this behavior occurs?

Comment 12

[John Daggett (:jtd)]

Attachment: TextEdit RTF test file

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #11)
> Created an attachment (id=324239) [details]
> TextEdit rendering for various fonts
> 
> OK, got it.  The behavior seems to be that Monaco and Courier render without
> anti-aliasing for all sizes up to and including 10pt, *independent* of the
> Appearance panel setting.  Other monospaced fonts, Osaka Mono, DejaVu Sans
> Mono, etc. render as expected.

Yeah, that's a much better description. :) 

After I added Courier to the list, I didn't think to test any other monospaced fonts; I wonder if this is a perhaps a quirk embedded in the fonts themselves?

I went through other monospaced candidates on my 10.5 system, and Courier New also seems to have this behavior, though; maybe it's matching against partial font names?  I wonder what happens if you internally rename, say, "DejaVu Sans Mono" to something like "Monaco DeLuxe"?

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Apparently the value can also be controlled by the NSGlobalDomain AppleSmoothFixedFontsSizeThreshold default (Google reveals a bunch of places and people setting it, but it doesn't exist by default, so the default value of 10 must also be hard-coded somewhere else).

(In reply to comment #13)
> I went through other monospaced candidates on my 10.5 system, and Courier New
> also seems to have this behavior, though; maybe it's matching against partial
> font names?  I wonder what happens if you internally rename, say, "DejaVu Sans
> Mono" to something like "Monaco DeLuxe"?

I also wonder whether Menlo gets this behavior on 10.6?