From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 20 Jun 2012 18:52:28 +0100
From: Ethan Grammatikidis <eekee57@fastmail.fm>
To: 9fans@9fans.net
Message-ID: <20120620185228.0807a5d6@vardo.ethans.dre.am>
In-Reply-To: <779a7f23d339cbcae24f7627f9950131@sp.inri.net>
References: <727e89f148b2a84c82d495a031ada082@brasstown.quanstro.net>
	<779a7f23d339cbcae24f7627f9950131@sp.inri.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] dejavu sans
Topicbox-Message-UUID: 9f2919a2-ead7-11e9-9d60-3106f5b1d025

On Mon, 11 Jun 2012 23:55:06 +0000
sl@9front.org wrote:

> >> In native, I no longer benefit from X11's rendering. Here, blurry
> >> fonts look blurry.
> >
> > i'm not having that problem.  but that might be because of the details of
> > the conversion to font, or due to personal sensitivity to subpixeling.
>
> In my case it's the same several machines used with the same screens. The
> only change was the local operating system. From drawterm on OpenBSD
> I thought vera was very nice (and used it for around a year); in Plan 9 native
> on the same machine vera looks blurry. I realize this is subjective to a certain
> extent, but that's precisely the problem: I sees what I sees.
>
> Note: I don't really understand the way graphics are put on screen in either
> operating system.

I believe I do, and I'm pretty sure the difference lies in gamma or
color correction which is provided by most graphics chipsets but is
inaccessible with VESA. It is also likely to be inaccessible with
native drivers if they are open source, it was a fluff feature when
CRTs were common and seems to still be treated that way.

You may have noticed that images appear paler on those displays where
Vera looks blurry. This is because of the lack of gamma correction.
Black may still be black and white white, but without gamma correction
a 50% grey may appear far brighter than it should be, especially on a
LCD. (On a CRT it's more likely to be darker, in my experience.) Vera
then looks blurry because the pixels that are supposed to be mid-grey
become far brighter, far more visible than they are meant to be.

The particularly interesting thing about this is it suggests a
workaround. The font is implemented as a 4-bit greyscale image. Instead
of treating the font as a true greyscale it could instead be treated as
a palettized image and the palette adjusted to suit the screen,
darkening the greys on the displays for which it is necessary.

I'm not sure when the palette adjustment should take place. It could be
adjusted on font load, but perhaps it would be better to statically
adjust fonts for each display and put something like this in
$home/lib/profile:

for(fdir in \
	/mnt/term/lib/font/bit \
	/mnt/term/usr/local/plan9/font \
	/mnt/term/usr/local/inferno/fonts \
) {
	if(test -d $fdir) {bind -b $fdir /lib/font/bit}
}

A small program could be made to display a font ignoring any previous
palette, allow the user to adjust it (a single slider control may
suffice), and then batch convert any 4-bit subfont files in a chosen
subtree.

--
This is obviously some strange usage of the
word "simple" that I was previously unaware of.