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 <[email protected]> wrote:
> On Thu, Nov 1, 2018 at 9:59 PM Alexei Podtelezhnikov <[email protected]>
> 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|B@520,0|C@1094,0]
> Expected: [A|B@584,0|C@1196,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/
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
