[Development] about the Cocoa/Freetype fontengine

René J. V. Bertin rjvbertin at gmail.com
Sun Dec 31 11:11:04 CET 2017


Nikolaus Waxweiler wrote:

> Fair enough, depends on your screen and how much you darken. Ideally,
> you match the sRGB gamma curve of roughly 2.2 that in an ideal world,
> your screen matches, too. Ha!

I recall a difference in opinion between Apple and the rest of the world about 
what the correct gamma should be. To me 2.2 always looked too bleak.

I calibrate my Mac screens btw, not using hardware but with the SuperCal 
utility.

> Both look off (right: hinting, left: autohinting), specifically the
> gamma correction. Looks more like a gamma of 1.0 plus maybe some

Nope, 1.5 .

> thickening/smearing via the LCD filter. Is gamma correction enabled in
> your Qt build? 

All I can say is that I didn't turn it off and that the font smoothing gamma 
value matters.

> No strong hinting preference here, still prefer left for
> the slightly cleaner look should you wonder.

Hah. Both are Konsole under X11 with Novarese BQ Medium for menus and Ubuntu 
Mono for the terminal font. Left is with Infinality+Ultimate (preset #3), right 
is stock FT+FC.
Those are the point sizes and colours I work with; needless to say left is much 
easier on the eyes in the long run. Seeing them side-by-side I do think it could 
be a tad darker though.

> Reworded: if most users have higher priority on on-screen legibility in
> the strongly hinted sense, nobody would have used Macs before Retina
> screens.

You forget there are other reasons, and I didn't claim that legibility had to 
include hinting (most users won't care what tech is used, evidently). You can 
get very readable text with bitmapped fonts if they're well done - remember my 
earlier remarks about Monaco. In fact I realised that my Terminal.app is still 
set not to anti-alias text because it simply looks sharper. Because it is (but 
then hinting and smoothing are not necessarily coupled, are they.)
Looks something like the attached screenshot (of the old X11 pre-rasterised 
version). I've spent countless hours coding in vi with exactly that font; that 
only changed after I installed a KDE4 desktop and discovered the Infinality 
patches. Still, that same font looked a bit better with the more modern tech in 
OS X (provided it was black on white, granted). Not that I had much choice 
outside of Terminal.app ...

> Text on pre-Retina Macs is however quite readable if you get
> used to the look.

Then there's that: going back to such a Mac might be hard if you've never gotten 
used to them, but once they were the reference (and I have never cared to shell 
out the extra cash for one).

> Reworded: you can't reduce the difference between different hinting
> strategies without rewriting the hinting

And what if you can switch the autohinter on or off per font (or per glyph if 
FontConfig allows that kind of control)? I see it's a FreeType property so 
technically this should be possible.

> We are talking about giving devs the ability to ship Qt apps with
> switched font engines, no?

A priori in a way that can be overridden as far as I'm concerned because handled 
via existing mechanisms (env. variables, command line options, qt.conf 
settings). I did write a PoC implementation to switch via a platform theme 
plugin, based on what's in a settings file so yeah, that approach could make it 
possible to force a font engine. There's no law against given devs noose-making 
API, is there? ;)

BTW, is there a technical reason to expect one cannot change a 
fontengine/fontdatabase anymore after the first fonts have been rendered?

R.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: monaco-bitmapped.png
Type: image/png
Size: 5973 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20171231/76118086/attachment.png>


More information about the Development mailing list