[Development] about the Cocoa/Freetype fontengine
Nikolaus Waxweiler
madigens at gmail.com
Sat Dec 30 18:03:31 CET 2017
>> People notice different font rendering.
>
> Yes - but they're not likely to complain if the different look also
> looks better.
DirectWrite rendering looks better than GDI rendering (in the sense that
it is truer to the designed outlines and the spacing with fewer
compromises for black and white glyphs), yet so many people complained
about blurry fonts that Microsoft lowered the gamma correction in IE to
make the fonts look blacker.
>> The performance hit is measurable in the rendering benchmark tool
>
> Measurable in a benchmark tool doesn't mean there are performance
> issues. I've been using Infinality on a very slow system, without
> any ill effects.
They still exist and would better not be there. Actually, since the core
Infinality patch set is mainlined, they already are part of the code base...
>> consistency. Sit a Core Web font next to some random Google Font
>> font on the internet and they'll look jarringly different, like
>> each used a
>
> If you mean fonts rendered by FreeType with and without Infinality
> looks jarringly different, then yes, that can be the case at regular
> point sizes on regular density displays. Which is the whole point:
> with the result looks jarringly better.
I mean fonts rendered through Infinality that match the specifics
required for good looks and others that don't. That is the core problem.
And then you have fonts next to each other where one was originally
hinted for Win95-style bitmap display (e.g. Arial) and the other is
trying to take advantage of ClearType. Looks jarring in a bad way even
on Windows.
> Erm, I'm talking about KDE desktops using Qt4 or better, which have
> the option to activate sub-pixel rendering and hinting (which will
> be on by default IIRC). Basic X11 font rendering doesn't, indeed.
I'm talking about linear alpha blending and gamma correction. Qt4 and 5
(and Skia) are capable of it, it's just disabled by default (except for
5.9 with CFF fonts iirc). That is the problem. Subpixel rendering and
positioning are icing on the cake.
> Instead it relied on pre-rendered bitmap fonts like for a
> high-resolution matrix printer. And curiously those fonts could be
> displayed 100% correct - with moiré effects and blurring between the
> display phosphor and our retina taking care of making the letters
> look smooth enough to be pleasant.
Black and white fonts need no linear alpha blending and gamma correction
because they contain no grays, so the X11 way of rendering is indeed
correct ;) And I'm well aware of the smoothing effect of analog displays.
Background: FreeType's renderings of glyphs are coverage maps in linear
space (50% coverage of a pixel by an outline == pixel gray level of 128
in 8 bit). All our displays have a non-linear gamma curve though. 0%
coverage == white and 100% coverage == black are the same in linear and
sRGB gamma space, just everything in between isn't, which means you have
to convert the values before you put them on arbitrary surfaces for
display on a sRGB screen -> linear alpha blending and gamma correction.
That is why I'm talking about correctness with such certainty :)
We want to get to "Gamma 1.8, darkenend":
https://www.freetype.org/image/BlendingExamples.png
> Either way, a long as we're talking about vector fonts rendered on a
> raster display the term correct has a very relative meaning.
As long as you convert vectors (any vectors, really) to bitmaps and put
them on arbitrary surfaces, you have to do linear alpha blending and
gamma correction to comply with baseline rendering correctness. Only
afterwards can you be relative in your meaning.
> I have no idea if those are CFF fonts and can't find a reference to
> the family in the .conf files either.
Should be easy to find out. Filename ends with ".otf", you're most
likely looking at a CFF font (see e.g. Cantarell). Cubic beziers inside
the font are a dead giveaway.
> It is, inevitably. It's aimed at fooling human perception and as
> such cannot be an exact science (unless you're a biologist or
> "assimilated" neuroscientist :)).
Wait, what I was trying to say is that just because someone instructed
some glyph in some way, doesn't mean it's been instructed well.
> The issue at hand here is whether or not Qt should/could allow users
> to use font rendering based on FreeType+FontConfig across the main
> platforms, with as the main argument the fact that this will allow
> (near) perfect cross-platform homogeneity in text rendering.
And I think it is asking for users to complain about different looking
fonts on their platform. It's annoying enough that all major toolkits on
X11 interpret fontconfig in slightly different ways when messing with
hinting etc.
>> export FREETYPE_PROPERTIES=cff:no-stem-darkening=1
>
> I see absolutely no difference between the two. Maybe simply because
> I'm not using any CFF fonts.
Err. Does 0 make a difference? If not, you're probably not looking at a
CFF font or something else is going on. CFF darkening is noticeable.
> One could probably say that the FT+FC rendering shown in those
> images is not correct for certain glyphs.
If linear alpha blending and gamma correction are involved, they are
correctly rendered in the technical sense.
---
> But the main app I work on is a music software for artists ; these
> generally have a *very strong* visual identity.
> in this case it's a good thing to pop out from other software on your
> desktop
From the screenshots, the apps appear to use a native font renderer.
Nothing wrong with a strong identity, but please user-test font renderer
changes before you unleash them on your users...
More information about the Development
mailing list