freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft] changing the depth of gray for anti-aliasing


From: Peter Grandi
Subject: Re: [ft] changing the depth of gray for anti-aliasing
Date: Sun, 12 Feb 2012 16:13:38 +0000

>> [ ... ]and in particular by this side-by-side comparison image:
>>  http://www.sabi.co.uk/Misc/snapFontAliasingDarkLight.png

>> that anti-aliased text looks very different on dark
>> backgrounds (thinner, not so fuzzy) than on light ones
>> (thicker, fuzzier).  [ ... ] Therefore it would be nice to be
>> able to control how dark is the anti-aliased "fuzz", [ ... ]
>> Is there a runtime tweakable already?

> No.  However, you might experiment with changing the gamma
> value (this is the job of your GUI). [ ... ]

Ahhh interesting indeed. It turns out that gamma has indeed a
profound effect. I tried by setting X gamma to 1.0 (that is,
default) and changing the monitor gamma.

At monitor gamma 2.2 which the default for most non-Mac monitors
there is indeed a very large difference between monochrome and
antialiased text, which seems to disapper around gamma 1.6-1.7
(my monitor reaches down to 1.8 so I had to use X gamma to go
down a further bit).

That is not so good because on PCs just about everything looks
rather washed out at gamma 1.8 (the Mac gamma), and even worse
at gamma 1.6-1.7.

  Note: I have a moderately high end recent h-IPS monitor with
  full 24-bit colors with really smooth and wide tone gradients.

However admittedly the light/medium/dark gamma tests in the KDE
settings do look best on gamma 1.6-1.7, as in I can distinguish
rather more dark grays than at gamma 2.2.

Which is unfortunate, because it looks like Freetype2 is set for
the "right" gamma which nobody uses...

> Another possibility is to tweak FontConfig so that it uses a
> different rendering mode. Again, to bypass your desktop, try
> the `ftview' demo program and cycle through the different
> rendering modes with the `L' key.

I have been experimenting with 'ftview' and with great dismay,
as the results are often amazingly surprising, and it is not
easy for me to map these Freetype2 settings onto Fontconfig
settings that is what I must eventually configure in some
'/etc/fonts/' file. First two things that seem bugs:

  * "'h' or "glyph hinting" seems to force antialiasing on
    when "sbits cache" is active, but not with "normal cache".
    I have thus done all tests with "normal cache".

  * Sometimes the "glyph waterfall" (which I have used for all
    testing) shows some sizes as essentially identical (e.g. for
    Deja Vu Sans Mono 13pt and 14pt, 15pt and 16pt, and 20pt and
    21pt are only slightly different, but same widths). This
    happens only when (not necessarily an exhaustive list):
      - "anti-aliasing" off, "forced auto-hinting" off.
      - "anti-aliasing" on, some combinations of "forced
        auto-hinting" and "light anti-aliased" have seemingly
        identical different point sizes.

and then some about rendering options:

  * "light anti-aliased" seems to give seemingly much thicker
    features than "normal anti-aliased", yet the glyphs seem
    narrower, and more evenly spaced (the metrics seem identical
    though, some glyphs just seems to shift position a bit).
    This seems to happen only if "glyph hinting" is active.

  * I was amazed by how enormously different glyphs can be
    between "forced autohinting" on and off. I have tried DejaVu Sans
    mono for Truetype (which contains also some bytecode hints)
    and Adobe Courier for PostScript:
    - with "forced autohinting" on, glyphs are much taller than
      with it being off.
    - With "forced autohinting" on, glyphs in antialiased mode
      look rather thicker.

However I got overall the impression that results seemed
inconsistent, with the same combinations of states giving
different results at different times depending which
combinations had previously been used.

I have also slightly modified 'ftview.c' from 'ft2demos-2.4.8'
to cycle backwards and forwards through rendering modes and LCD
modes, as in particular it is useful to see differences between
the two "adjacent" modes in the latter.

-- ft2demos-2.4.8/src/ftview.c 2011-08-14 07:06:13.000000000 +0100
+++ ft2demos/src/ftview.c       2012-02-12 14:59:01.624114195 +0000
@@ -656,8 +656,10 @@
     grWriteln( "  h           toggle outline hinting" );
     grWriteln( "  l           toggle low precision rendering" );
     grLn();
-    grWriteln( "  L           cycle through LCD modes" );
-    grWriteln( "  space       cycle through rendering modes" );
+    grWriteln( "  K           cycle backwards through LCD modes" );
+    grWriteln( "  L           cycle forward through LCD modes" );
+    grWriteln( "  backspace   cycle backwards through rendering modes" );
+    grWriteln( "  space       cycle forward through rendering modes" );
     grWriteln( "  1-6         select rendering mode" );
     grLn();
     grWriteln( "  e, E        adjust emboldening" );
@@ -975,7 +977,10 @@
       break;
 
     case grKEY( 'L' ):
-      handle->lcd_mode = ( handle->lcd_mode + 1 ) % N_LCD_MODES;
+    case grKEY( 'K' ):
+      handle->lcd_mode = (event->key == grKEY('L'))
+        ? ((handle->lcd_mode == (N_LCD_MODES-1)) ? 0 : handle->lcd_mode+1)
+        : ((handle->lcd_mode == 0) ? (N_LCD_MODES-1) : handle->lcd_mode-1);
 
       switch ( handle->lcd_mode )
       {
@@ -1002,10 +1007,14 @@
       FTDemo_Update_Current_Flags( handle );
       break;
 
-    case grKEY( ' ' ):
+    case grKeySpace:
       event_render_mode_change( 1 );
       break;
 
+    case grKeyBackSpace:
+      event_render_mode_change( -1 );
+      break;
+
     case grKEY( 'G' ):
       event_gamma_grid();
       break;



reply via email to

[Prev in Thread] Current Thread [Next in Thread]