Fri 01 May 2009 09:18:28 AM UTC, comment #5:
Tom,
I did some experimentation, and looked at the standards.
A PDF file clarifying overshoot issues is available: "Adobe Type 1 Font Format", especially ch. 5 and sect. 3.2
I then reviewed the PS Private entries for all the faces in FreeFont, and made some adjustments: especially the BlueValues and Stem widths were off; now BlueFuzz is disabled.
However, I don't see that these PS Private values make any difference in rendering on my sytems. Still in Sans sizes from about 14pt to 20pt, the overshoot appears excessive (in Gnome/Pango, 96DPI, anti-aliasing RGB, full). In FreeSerifBold, the effect is worse and is noticeable in a larger range of sizes.
It may be that these settings are considered outdated.
The "jump" in the overshoot that is apparent in your screen shot may be due to a setting. On my Ubuntu system, System Settings -> General -> Appearance -> Fonts has a button Use anti-aliasing -> Configure... ; the "Exclude Range" setting has an effect.
While the Type 1 BlueValues are clearly related to this issue, I doubt how effective they would be here, even if they were properly implemented. They are explicitly designed to avoid rendering overshoots in small font sizes, where the excess caused by turning on a single pixel would be distracting. Here, we have an obvious overshoot at much larger font sizes. And we are looking at LCD screens with anti-aliasing capabilities.
I'm not sure of the use of BlueScale values. Maybe that can have some effect.
It seems that the Sans face (again, originally from the Nimbus fonts) simply has a very large overshoot. It is twice that of the DejaVu Sans face, for example. It looks OK in very large sizes, but poor in medium ones.
In GTK systems, you can experiment with this command:
pango-view --font="freesans" --waterfall -q -o out.png in.txt
(See example output attached.
Also, I attached an HTML file that can be used for experimenting (use CSS to adjust styles.)
(file #18065, file #18066)
|