This is in the eye of the beholder, to some extent. Ideally you will
hardly notice a difference as a casual user.
[...]
Well, that's up to the application developer to decide, no? Qt
evolves in a universe where it's considered normal to ship copies of
the required libraries with(in) each and every application. That
includes the FreeType library if that font engine is to be
supported, and the FontConfig library could be included just as
easily. With or without patches.
I think you have to carefully match the rendering of CoreText (and its'
darkening algorithm) for users not to notice. At that point, you might
as well use CoreText, unless you have something very specific in mind.
People notice different font rendering. Just recall the fuzz over
browsers switching to DirectWrite for text rendering.
The Infinality patches aren't mainlined (what's left of them) for 2
reasons that I'm aware of. The FT developers are overly cautious
about possible licensing issues and claim there are performance
implications. I can only comment from personal experience and
expertise on the latter: humbug.
The performance hit is measurable in the rendering benchmark tool, not
sure how much it carries over when you use caches, but it's still iffy.
Rendering glyphs multiple times for subpixel positioning might make that
even worse.
Can't remember something being about licenses.
The part of the left-over patchset I sifted through contained
post-processing hacks that in their form were not acceptable for mainlining.
Is that longer than about 6 years ago? I've been using the patch set
for that long, with the accompanying FC and Cairo patches of course,
and the only specific circumstance where I had jagged (pun intended)
fonts was when an application shipped its own FreeType (wine!) or I
tried a new distro. Plus possibly a very rare occasion where the
patch maintainer slipped up.
Can't remember, but followed the patchset for at least as long as
Infinality was active. It's not about being jagged, it's rendering
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
different rendering framework. The same happens on Windows, by the way.
OTOH I get frequent requests to upgrade my Trusty PPA with the
patched FT, FC and Cairo libraries, and if you look at the number of
forks around and the activity around the various packaging
implementation you'll realise that there are a lot of people who
care and consider the gain in quality is significant enough to mess
around with system libraries. That's certainly not for nothing.
Understandable, because the starting point is crappy.
The entire patch is tailored to a platform that never rendered
fonts correctly.
Shall we say optimally and make it dependent on point size?
No, incorrectly hits the mark. As soon as your rendered glyph image
contains shades of gray, you MUST use linear alpha blending and gamma
correction. Everything else is incorrect. The Windows and Mac platform
have been doing that for decades, X11 libs never did to my knowledge.
Or, Qt4 or 5 once did and was immediately called back by users
complaining about thinner looking text. That is why you need some form
of darkening on top, at least on LoDPI screens.
The fuzziness FT > CoreText > FT X11 is because on X11, some form
of hinting is usually turned on and there is no linear alpha
blending plus gamma correction, leading to harsher rendering that
only appears less fuzzy.
That's the whole trick, isn't it? Exploiting specifics of human
vision so things look sharp while in reality they aren't and even if
they were we wouldn't perceive them as such (read up on how fresco
painters from the Renaissance worked around that, for fun :))
The "sharpness" is bought with overall harsh- and blotchyness and weaker
rendering of lighter text on darker backgrounds. It's a bad trade and
makes people flock to band-aid solutions like the Infinality patchset :)
CoreText ignores hints but darkens stems (overly so by default) to
counter the effects of gamma correction, FT will only do that when
told so.
Which only means that both platforms have there own suboptimal way
of doing things. Font developers provide hinting for a reason and
spend inordinate amounts of time getting it right. Ignoring it is
just stupid, at least on devices with traditional and affordable
display densities.
Apple could do with a lighter darkening algorithm, yes, but it's okay, I
usually turn it down one notch. The CFF darkener delivers the best
looking results so far, as it only counters the thinning such that the
font looks as meaty as before gamma correction.
There is not always a good reason behind a certain hinting decision
(just look at all the fixing Infinality has to do; hinting can be a very
seat-of-the-pants business) and it is perfectly acceptable to ignore it
all and do something else (autohinter) or nothing at all (CoreText).
Remember that it's the design of a font, not the hinting that is canonical.
One of my pet peeves with TrueType hinting is that the designer decides
the final look, which can clash with the decision of the designer of the
font right next to it. Compare the hinted look of Source Sans Pro,
Ubuntu or https://acumin.typekit.com/ to what's on Google Fonts which
its' many ttfautohint'ed fonts. Or compare it to CFF fonts.
Background: (hintslight) autohinter and CFF engine only snap horizontal
stems to pixel boundaries but do not change their width. TrueType fonts
like those mentioned snap the entire width to pixels and may change
vertical stems and bearings. Sounds like a small difference, can make a
font look very different however.
You probably shouldn't enable stem darkening when using the
Infinality set or turn off hacks for CFF fonts until there are no
more issues.
I probably would if I knew how.
export FREETYPE_PROPERTIES=cff:no-stem-darkening=1
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
