Nikolaus Waxweiler wrote:
>> All I can say is that I didn't turn it off and that the font smoothing gamma
>> value matters.
>
> Be more specific.
You asked if gamma correction is enabled in my Qt builds, the only way I can
answer that without additional information is the way I did. A priori i
>> 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. T
Nikolaus Waxweiler wrote:
>> Right, and where did *that* come from in discussion that's about font
>> engine choice by the user?
>
> We are talking about giving devs the ability to ship Qt apps with
> switched font engines, no?
Here's what I currently have locally (disregard the hacks for buildi
Konstantin Tokarev wrote:
> Note that Mac OS X at least up to 10.5 allowed setting strong hinting in the
> system settings
It indeed used to have a combobox with different levels of font smoothing. That
went the way of the dodo together with CRTs; nowadays all that's left is "Use
LCD font smoo
31.12.2017, 03:11, "Nikolaus Waxweiler" :
>>> We want to get to "Gamma 1.8, darkenend":
>>> https://www.freetype.org/image/BlendingExamples.png
>>
>> On Mac (FT and/or FT+FC *without* Infinality+Ultimate patches) I
>> find 1.5 comes closer to the native CoreText font colour. 1.8 is too
>> th
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 correc
Nikolaus Waxweiler wrote:
> changes. Nobody could stand to use Macs if bitmap fonts were the
> pinnacle of on-screen legibility.
? Where does that come from and what does it even mean?
>> tweaking fontconfig files do so in part to reduce such differences.
>
> You can't fix fonts having differen
Nikolaus Waxweiler wrote:
> We want to get to "Gamma 1.8, darkenend":
> https://www.freetype.org/image/BlendingExamples.png
On Mac (FT and/or FT+FC *without* Infinality+Ultimate patches) I find 1.5 comes
closer to the native CoreText font colour. 1.8 is too thin.
And for giggles, which one look
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.
Which confirms my claim that most users will give higher priority to
on-screen legibility than to design veracity. Very un
Nikolaus Waxweiler wrote:
> > DirectWrite rendering looks better than GDI rendering (in the sense that
> it is truer to the designed outlines and the spacing with fewer
That's not what I call looking better, but more veridical. The two can overlap
but just as (actually, more) often they don't.
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 gl
On Saturday December 30 2017 14:01:33 Jean-Michaël Celerier wrote:
[apologies, hit the wrong key]
> isn't this a common complaint actually :
> https://www.google.com/search?q=qt+quick+blurry+text ?
Let's put it this way: not common enough for neither the Qt nor the KWin
developers to heed? ;)
On Saturday December 30 2017 14:01:33 Jean-Michaël Celerier wrote:
> isn't this a common complaint actually :
> https://www.google.com/search?q=qt+quick+blurry+text ?
Let's put it this way: not common enough for neither the Qt nor the KWin
developers to heed? ;)
> In my case I am for instance s
> And even then ... how many users complained about window titles looking
blurry when KWin started using QtQuick for rendering titlebars?
isn't this a common complaint actually :
https://www.google.com/search?q=qt+quick+blurry+text ?
But I think that the overall problem is that there are two cate
Nikolaus Waxweiler wrote:
> 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.
Remember that there's also the issue of getting the
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 ev
Nikolaus Waxweiler wrote:
> I don't get it. How will this improve the look of Qt-Mac applications?
This is in the eye of the beholder, to some extent. Ideally you will hardly
notice a difference as a casual user.
> Apps using CoreText will look different than Qt apps linking to a
> patched Fre
On Friday December 29 2017 21:44:27 René J.V. Bertin wrote:
> It might be trivial to replace QCoreTextFontDatabase with QFontconfigDatabase
> in QCocoaIntegration but that would be a build-time choice.
In fact it is ... and with a bit of static_cast'ing one can probably make it a
runtime (start
On Thursday December 28 2017 20:08:38 Sérgio Martins wrote:
Hi,
> What I meant is that you don't need to touch FT code when adding
> fontconfig support to macOS. The code already exists and is
> cross-platform (even worked on QNX). It's just that it's not being
> used by cocoa QPA.
So... Current
Besides, fontconfig with infinality patches honestly gives a
beautiful rendering, crispier and yet fuller than everything you
can see on othe OSes in my taste.
I agree completely, except - I'm not (yet) convinced that the
Infinality patches to FreeType are of any effect on Mac. Fonts
rendered wi
On Friday December 29 2017 10:38:04 Jean-Michaël Celerier wrote:
> Besides, fontconfig with infinality patches
>honestly gives a beautiful rendering, crispier and yet fuller than
>everything you can see on othe OSes in my taste.
I agree completely, except
- I'm not (yet) convinced that the Infina
:+1: for being able to use fontconfig everywhere. It's painful to have to
make pixel adjustments on each platform because they don't render fonts
exactly the same everywhere. Besides, fontconfig with infinality patches
honestly gives a beautiful rendering, crispier and yet fuller than
everything yo
Sérgio Martins wrote:
> What I meant is that you don't need to touch FT code when adding
> fontconfig support to macOS. The code already exists and is
> cross-platform (even worked on QNX). It's just that it's not being
> used by cocoa QPA.
Hmmm, I guess I'll need to have another look then. It ha
On Thu, Dec 28, 2017 at 7:53 PM, René J.V. Bertin wrote:
> On Thursday December 28 2017 19:46:28 Sérgio Martins wrote:
>> But adding fontconfig support should be quite trivial and wouldn't
>> touch FT code.
>
> It used to be trivial to build Qt on Mac with fontconfig enabled (but not
> actually u
On Thursday December 28 2017 19:46:28 Sérgio Martins wrote:
> Check the last two comments of
> https://bugreports.qt.io/browse/QTBUG-42839, there are no plans.
Oops, sorry, I forgot about that.
> I also wouldn't call it "evolving FreeType", as FreeType is
> independent from the font database.
B
On Thu, Dec 28, 2017 at 6:32 PM, René J. V. Bertin wrote:
> Hi,
>
> Are there any plans to evolve the FreeType support on Mac any further,
> possibly
> adding FontConfig support so fonts can really be rendered in identical fashion
> on at least the major Unix platforms?
Hi René,
Check the las
Hi,
Are there any plans to evolve the FreeType support on Mac any further, possibly
adding FontConfig support so fonts can really be rendered in identical fashion
on at least the major Unix platforms?
If so, would you consider making it easier to select the FreeType engine?
I've been experimen
27 matches
Mail list logo
