On 05/08/10 02:09 AM, Werner LEMBERG wrote:
Might there be a key place that does some sort of equivalent of a
PutPixel(i, j, value) that I could watch while debugging my
Cairo-based case? Or does the algorithm not lend itself to that? I
figure someone must be turning on that offending pixel,
- Even though I'm getting different rasterization results between
2.3.9 and 2.3.11, I can't seem to see anything different being
done. The output I attached is the same for both versions,
leading me to suspect I'm not looking at the relevant code.
I suggest that you build your product
While hunting another bug (still not sure mine/gcc/freetype, strange borkage
with type1 hinter, will report later), I found Decompose_Curve reads array past
allocated area, making valgrind unhappy:
=14635== Command: ./ftview 14 /usr/share/fonts/type1/gsfonts/a010013l.pfb
==14635== Parent PID:
Yuriy Kaminskiy wrote:
While hunting another bug (still not sure mine/gcc/freetype, strange borkage
with type1 hinter, will report later),
Looks like borkage was *my* bug, no need to worry about :-) [patch from OP still
valid]
___
Freetype-devel
With -ansi flag, gcc does not (auto)define i386, only __i386__ (so I think
assembler code was never used on i386/unix/gcc builds).
Patch applies to 2.4.1 too (with fuzzyness).
Maybe, it would be better just always use __i386__ (alternative patch).
---
With -ansi flag, gcc does not (auto)define i386, only __i386__ (so I
think assembler code was never used on i386/unix/gcc builds). Patch
applies to 2.4.1 too (with fuzzyness). Maybe, it would be better
just always use __i386__ (alternative patch).
I selected the alternative patch. Thanks
- x3 = SCALED( point[ 0].x );
- y3 = SCALED( point[ 0].y );
if ( flipped )
{
SWAP_( x1, y1 );
SWAP_( x2, y2 );
-SWAP_( x3, y3 );
}
if ( point = limit )
{
+x3
Werner LEMBERG wrote:
- x3 = SCALED( point[ 0].x );
- y3 = SCALED( point[ 0].y );
if ( flipped )
{
SWAP_( x1, y1 );
SWAP_( x2, y2 );
-SWAP_( x3, y3 );
}
if ( point = limit )
