Freetype changes

[Matthew Garrett]

Ok, Tobias has produced a very helpful image at 
ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot1.png - from left to 
right, they're gutsy before I reverted the changes, gutsy with altered 
hinting settings and gutsy post-revert.

I find the left-hand column the most attractive, but the right-hand 
column the most readable. The difference is clearest under 
magnification. Vertical strokes tend to be fully pixel aligned in the 
right-hand column, but blur out into adjacent subpixels in the left-hand 
column. The advantage of allowing this blurring is that it permits more 
accurate positioning of the characters, allowing for more even spacing 
and correct rendering of the shapes. The disadvantage is that what used 
to be a solid black line rendered on a pixel boundary is now a grey line 
with a slight colour fringe. More importantly to me, it also gives me a 
headache (something of an irritation given that my work requires me to 
be using terminals for most of the day)

The issue becomes more obvious as DPI[1] reduces. On a 14" 
screen at 1024x768 (still not uncommon, sadly), the colour fringing is 
very noticable[2]. This is less of a problem if we reduce the 
agressiveness of the hinting, as seen in the middle column of the image 
- the downside is that you get reduced contrast as a result, which also 
has an unfortunate impact for people using the terminal.

I suspect that there isn't actually a "one size fits all" solution here. 
Contrast is the most important factor in some applications, while in 
others correctness is much more important. It may be possible to achieve 
this at the fontconfig level by choosing different defaults for 
monospace compared to other fonts, but right now with the new filtering 
there's no way to obtain the old behaviour.

It may be obvious that I'm concentrating on the terminal use case here, 
to the arguable exclusion of the (more common) graphical user interface 
case. The main reason I'm doing that is that I perceive the benefit to 
the general desktop case to be aesthetic rather than functional, and the 
degredation to the terminal case to be functional rather than aesthetic. 
Most of our developer base still use terminals for a lot of work, and 
making changes that impact their ability to do that has the potential to 
reduce our ability to develop the distribution.

Anyway. I agree with Scott that this change does provide benefits for 
many use cases, and I think we should look into it further. However, I'd 
rather do that at the beginning of a development cycle where we have 
enough time to fine-tune it properly - doing it at beta time is only 
really going to give us the options of shipping it as-is or reverting it 
entirely, and the general userbase is going to be unhappy if we revert 
it between beta and release. I'd prefer to defer it until we have the 
confidence that we can get it into a more workable state.

[1] Actual screen DPI, rather than the logical DPI that X uses
[2] Cleartype also behaves pathologically in that case - I find XP 
almost unusable on that sort of hardware
-- 
Matthew Garrett | mjg59 at srcf.ucam.org