[argyllcms] Re: A question and some suggestions regarding calibration (dispcal)

  • From: Ver Greeneyes <vergreeneyes1@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 15 Feb 2016 16:48:05 +0100

As an update, it turns out all that clipping was caused by using the wrong
setting in collink :\ I was using "-et" - using "-eT" instead fixes the
problem. Classic PEBKAC! On the plus side, I'm pretty sure the accuracy of
my calibrations is much improved now thanks to all my experimenting ;)

Regards,

Emanuel Hoogeveen

On Wed, Jan 20, 2016 at 9:51 AM, Florian Höch <lists+argyllcms@xxxxxxxxx>
wrote:

Am 20.01.2016 um 00:51 schrieb Graeme Gill:
Another horrible hack to work around a problem
that shouldn't exist.

Well, I actually applaud MS that the advent of 4K/"Retina"/HiDPI
displays has led them to realize that a text scaling setting that only
affects text really makes no sense (a realization that browser vendors
arrived at much earlier, thankfully) - the latter would create normal
size text next to tiny graphical elements on such displays. With the new
approach, everything is scaled in proportion, and thus atleast looks
reasonable in size, albeit a little fuzzy unless application authors
take care of the necessary work. I envy you a little, I think you'll get
away with just calling SetProcessDpiAwareness() and be done with it,
there's more work to be done for graphical UI applications because after
setting an appropriate DPI awareness level, you then need to take care
of appropriate scaling graphical elements (icons, spacing...) yourself.
The main issue with SetProcessDpiAwareness seems to be that application
authors were probably not understanding it correctly initially (or
confusing it with the older SetProcessDpiAware) - apparently some just
set the awareness level for their graphical application "so it doesn't
look fuzzy on Windows 8.1" without then implementing the necessary
scaling, which leads to some applications really look silly (the
aforementioned normal-size text next to tiny icons and other elements)
in a hidpi scenario.

If you look at the godawful mess of how screen DPI can be set in
sometimes conflicting/interacting in "interesting" ways on the Linux
desktop side (I wish the Gnome/KDE UI guys would realize that text and
UI scaling are not separate things), MS now at least has a relatively
straightforward implementation (sans the
SetProcessDpiAware/SetProcessDpiAwareness API confusion).

Rather like the horrible and badly working hacks
being applied to web pages to make them "mobile friendly".

Hmm. You're not using an ancient browser on relatively modern websites
are you :-)

Cheers,

Florian.


Other related posts: