RE: [ft-devel] [Patch] Autofit and stem snapping

[Turner, David]

Hi everyone,

I've got it !

- the demo code didn't really select the hinting algorithm
  correctly, I've corrected it in the CVS to match libXft's
  behaviour

- there was a bug in the auto-fitter, which never resetted
  hint mode bitflags within af_latin_hints_init. The fix is
  a one-liner below !!. Shame on me :o)

  The problem was probably introduced in 2.1.9, which used
  the auto-fitter, instead of the auto-hinter, by default.
  The patch applies to 2.1.9 as well. Fixed in CVS this
  morning before going to work.

I'd like to thank Frederic for its analysis, which has been
helpful to locate the problem quickly. However, I'd like to
add that:

- there is still a bug in "ftview", where cycling rendering
  modes creates some weird rendering the second time you
  activate RGB decimated mode.

  I currently believe it is a bug in the blitter of the
  'minigraph' library, used by the demo programs. Which
  would imply, if I'm correct, that this doesn't impact
  FreeType or the cache

- I'm still unsure wether the current auto-fitter sources
  duplicate 100% the old auto-hinter with regards to
  hinting algorithm. I'll have to check this.

  Maybe Owen's patch wasn't so bad after all, though in
  surprising ways ;-)


More on all of this later,

Regards,
  
- David Turner
- The FreeType Project  (www.freetype.org)


--------------------- cut here ----------------------------------
Index: src/autofit/aflatin.c
===================================================================
RCS file: /cvsroot/freetype/freetype2/src/autofit/aflatin.c,v
retrieving revision 1.21
diff -u -r1.21 aflatin.c
--- src/autofit/aflatin.c       24 Aug 2005 08:04:56 -0000      1.21
+++ src/autofit/aflatin.c       22 Sep 2005 20:40:10 -0000
@@ -1311,6 +1311,8 @@
 
     mode = metrics->root.scaler.render_mode;
 
+    hints->other_flags = 0;
+
     /*
      *  We snap the width of vertical stems for the monochrome and
      *  horizontal LCD rendering targets only.
-----------------------cut here----------------------------------


> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden 
> la part de
> Frederic Crozat
> Envoyé : mercredi 21 septembre 2005 10:22
> À : Werner LEMBERG
> Cc : Turner, David; address@hidden
> Objet : Re: [ft-devel] [Patch] Autofit and stem snapping
> 
> 
> Le mercredi 21 septembre 2005 à 00:20 +0200, Werner LEMBERG a écrit :
> > > Ok, while investigating how to fix this bug in cairo, I found some
> > > problems between rendering of freetype 2.1.9 and 2.1.10 [...]
> > 
> > These problems seem to be related to subpixel positioning.  
> Which font
> > are you using?  Have you tried those settings with ftview 
> or ftstring?
> > Note that I don't use GTK, so I can't really help.
> 
> Only the first problem is related to subpixel positioning, the second
> one is affecting also standard antialiasing.
> 
> For my test, I'm using DejaVu (which is Bitstream Vera with additional
> non-latin1 glyphs) Sans 10 (dpi 96). I've attached the font 
> to this mail
> to ease debugging.
> 
> I've just tried to use a little ftview (I'm not an expert 
> with it) and I
> discovered interesting things (this is with freetype2 CVS HEAD) :
> 
> for the first bug I reported :
> -run ftview -r 96 10 DejaVuSans.ttf 
> -switching rendering mode between normal, light (notice there is no
> rendering change between light and normal), horizontal LCD RGB (with
> ugly yellow halo), horizontal LCD BGR (ugly blue hallow), vertical LCD
> RGB and vertical LCD BGR. Now, do this cycle another time and 
> notice how
> the yellow and blue halos have disappeared in horizontal LCB 
> rendering,
> as well as the rendering is now different between normal and light
> rendering.
> -btw, if I try to enable normal cache instead of sbits cache, 
> I'm unable
> to get any subpixel rendering (but it might be normal, again, I'm a
> newbie concerning Freetype2 and ftview :)
> 
> for the second bug I reported :
> -run ftview -r 96 10 DejaVuSans.ttf 
> -switch between no antialiasing and antialising => when AA is enabled
> back, glyphs are the same as when you started ftview
> -switch between normal and sbits cache => no visible difference
> -switch to normal cache and then disable and enable back AA 
> => now, you
> don't get the same rendering as before. You can now switch between
> normal and sbits cache to see differences in rendering. 
> 
> -- 
> Frederic Crozat <address@hidden>
> Mandriva
>