[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ft-devel] [Patch] Autofit and stem snapping
From: |
Frederic Crozat |
Subject: |
RE: [ft-devel] [Patch] Autofit and stem snapping |
Date: |
Tue, 27 Sep 2005 16:08:56 +0200 |
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
- Re: [ft-devel] [Patch] Autofit and stem snapping, (continued)
- RE: [ft-devel] [Patch] Autofit and stem snapping, Turner, David, 2005/09/27
- RE: [ft-devel] [Patch] Autofit and stem snapping,
Frederic Crozat <=
- RE: [ft-devel] [Patch] Autofit and stem snapping, Turner, David, 2005/09/27
- RE: [ft-devel] [Patch] Autofit and stem snapping, Turner, David, 2005/09/27