Re: [ft-devel] [freetype2] master 300da33 1/2: * src/truetype/ttgxvar.c (ft_var_get_item_delta): Optimized.

[Behdad Esfahbod]

You changed:

-        else if ( face->blend->normalizedcoords[j] < axis->startCoord ||
-                  face->blend->normalizedcoords[j] > axis->endCoord   )

into:

        else if ( face->blend->normalizedcoords[j] <= axis->startCoord ||
                  face->blend->normalizedcoords[j] >= axis->endCoord   )

That's the bug, since axis->peakCoord can be equal to one of those values, and if it is, an axisScalar of 1 is desired whereas with your change it will pick up 0.

Re "excessive rounding error", sure, you fused two multiplies together.  Thanks.  If you really care about excessive rounding error though, bug report about not rounding deltas to FUnits is much more "immediate".

On Fri, Nov 2, 2018 at 9:25 AM Behdad Esfahbod <address@hidden> wrote:

On Thu, Nov 1, 2018 at 9:59 PM Alexei Podtelezhnikov <address@hidden> wrote:

> And you broke it.  Four of the harfbuzz/test/shaping/data/text-rendering-tests fail with this.

I made it more accurate with less rounding error while still standard-compliant and faster too.

This doesn't sound like rounding-error level of changes:

Actual:   [A|address@hidden,0|address@hidden,0]
Expected: [A|address@hidden,0|address@hidden,0]

> I actually appreciate if you don't touch that code.  It's been put in place *very* carefully.

I would appreciate more constructive and detailed bug report please.

See my second reply.

 

Are there visual artifacts?

I would say yes, given the huge difference in numbers.

 

  It would be incorrect to optimize fonts for excessive rounding errors in earlier FteeType.

Are you testing this code?  If not, don't touch it.  Serious.  That function was perfected in over two years...

--

behdad
http://behdad.org/

--

behdad
http://behdad.org/