On Saturday 19 November 2016, Nikolaus Waxweiler wrote: > >> Correct font rendering with linear alpha blending and gamma correction > >> can make text look pale like reported in > >> https://bugreports.qt.io/browse/QTBUG-41590 due to the way the math > >> behind it works out. Stem darkening compensates for the paleness. > > > > Any idea why exactly? > > I'm not sure what you're asking. Do you mean why LAB+GC results in > pale(r) text? The paleness is an expected side-effect of gamma > correction on low-DPI screens. > No I understand the math. I am just curious from a philosophical point of view how come stem darkening is even needed. Gamma-corrected blending might end up paler, but it should be a more correct result, so it just odd that it looks wrong and that a compensation is needed. Somewhere we must have done something that relied on naive blending. Maybe in the design of the fonts?
Also I notice in your example you also use a too low gamma value. The standard in screens in between 2.2 and 2.4, and when using that I generally see an inversion in the contrast balance. Look at the attached example. Ideally with correct blending text should look equally "bold" regardless of background and foreground color. It is obvious white on black with naive blending is too weak, but the color on white text with GC blending is just as weak, while white on black is now as bold as color on white used to be. If I used a gamma of 1.6 it would look more balanced, but my screen has a gamma of either 2.4 or sRGB , so why does using the right value give the an unbalanced result? Anyway, on the API front. Forcing to autohinter is probably not acceptable. So we could enable stem darkening where native available, but then we need to know if what engine a face is using, or better yet specifically if the engine used right now on this face did stem darkening. Best regards `Allan
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
