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

[Turner, David]

Hi again,

I just tested 2.1.7, and it exhibits the same problem than other
releases with the 'ö', at least in 'ftview'.

It seems the regression is more complex than originally thought.
Could you tell us:

  - which version of Pango and libXft was being used in Mdk10
  - which exact version of Vera Sans was used ?
  - if you applied some patches to the 217 used in Mdk10 ?

Regards,

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


> -----Message d'origine-----
> De : Frederic Crozat [mailto:address@hidden
> Envoyé : mardi 27 septembre 2005 16:09
> À : Turner, David
> Cc : address@hidden
> Objet : RE: [ft-devel] [Patch] Autofit and stem snapping
> 
> 
> Le mardi 27 septembre 2005 à 11:15 +0200, Turner, David a écrit :
> > Hi Frederic,
> > 
> > All I can say now is that there is no difference regarding
> > hinting of 'ö' in DejaVuSans between the current CVS and
> > previous releases of FreeType.
> > 
> > I've tested both 2.1.8 and 2.1.9 and they both exhibit the
> > problem when LCD-decimated rendering is used in "ftview"
> 
> Unfortunately, it is not possible to test directly with 
> ftview and older
> freetype (ftview was not available for 2.1.8 or 2.1.9 and current
> version of ftview is using symbols not available in freetype 
> older than
> 2.1.10). So, I must rely on old build of GTK applications, which might
> add other layers of complexity and changes in font management
> (fontconfig, pango, xft, whatever :(
> 
> > What it means is that it's not something that we're going
> > to fix real soon now, mainly because it _probably_ means a
> > lot of tinkering with the hinting algorithm
> > 
> > Any idea why you thinked it was a regression ?
> 
> Because I'm an idiot ? :)
> 
> More seriously, I've got mixed reports from our testers and 
> the initial
> bug you fixed (other_flags not being zeroed everytime) was probably
> causing my initial test to be inaccurate (because if you started with
> monochrome or LCD and switch to full hinting, ö was not being rendered
> correctly, unlike starting directly with full hinting.
> 
> I've done more tests : 
> -Mdk 10.0 (shipped with 2.1.7) and using similar testcase (gtk2 app
> using Bitstream Vera Sans 10, dpi 96) : ö was always rendered 
> correctly,
> either with monochrome, light, full or LCD (all 4 possible LCD mode
> tested). In some settings (dpi 84, horizontal LCD RGB), one 
> dot of ö is
> rendered as very light blue but is still visible. On this same
> environment, I've changed freetype to 2.1.9 (shipped with Mdk 
> 10.1, 2005
> LE) and 2.1.10 (shipped with Mdk 2006) and current CVS and I got the
> same rendering.
> 
> -Mdk 2005 LE (aka 10.2) : shipped with freetype 2.1.9. I get the same
> problematic rendering as CVS HEAD with monochrome or horizontal LCD.
> 
> -with Mdk 2006, with freetype 2.1.10 without your two fixes, ö is
> rendered ok (but of course, everything else is ugly :). When I put the
> two fixes, I get back the misrendering for ö.
> 
> So, I can confirm 2.1.10 + your two fixes (or CVS HEAD) are doing same
> rendering as 2.1.9.
> 
> I misuse "regression" term, in the sense that 2.1.10 was doing a
> "correct" rendering of the second dot of 'ö' (if we forget other
> rendering problems), compared to 2.1.9 or 2.1.10+cvs fixes. That is
> probably why our german test users complained when I put the vertical
> dimension fix => they notice this changes in rendering (which was
> already there in Mdk 2005 but they probably had forgot about it), so
> everybody thought the cvs fixes introduced a regression, which in fact
> was not one.
> 
> I hope I was clear enough this time :)
> 
> -- 
> Frederic Crozat <address@hidden>
> Mandriva
> 
>