Re: Patches for t2gload (yet again)

[Tom Kacvinsky]

Hi David,

> 
> > 
> > Here are some more patches for t2gload.c.  I made a mistake with my
> > previous patch to start_point.  I changed it back.  Otherwise, the
> > patches for flex path construction don't work.
> > 
> What do you mean ? Do I have to incorporate the patch you just sent
> me ??
> 

Doh!  My mistake.  I wasn't too clear.  The relevant part of the patch
is start_point.  I had changed some stuff before, thinking that i was
getting rid of a point duplication on a contour.  which it did.  but
that change broke stuff, so I changed it back to what it was
originally.

David, I really, truly am sorry that I am putting you through this.
Next time, I will be *much* more careful about the changes I make, and
only submit patches for what needs to be "fixed" (note the quotes).

> 
> > And I am puzzling over this one.  I changed va to be FT_Int32 instead
> > of FT_Int, and some problem I had went away.  I am not sure why this
> > change works, or, more to the point, why leaving val as FT_Int doesn't
> > work.  I am looking into this right now.  I suspect it has to do with
> > sign promotion issues of some sort.
> >
>  
> Yes, I haven't looked too deep at it, but it sure seems strange..
> 
> 

I found it.  The "offending" lines are the lines which make an integer
out of a 1 or 2 byte encoded stream.  The following code:

#include <stdlib.h>

int main () {

  char k = 248;
  long m;

  m = ( k - 247 ) * 256 + 32 + 108;
  m <<= 16;

  printf ("%d %08X.\n", m >> 16, m >> 16);

  return (0) ;

}

Produced the output:

-65140 FFFF018C.

Which is *way* off of the expected value of 396.  By changing m to be
an int instead of long, the problems went away. DEC's C compiler is
treating signed chars as it should.  Thus, 248 as a signed char is -8,
and from there, you can see where things go wrong.  But the resulting
number is outside of the range of a signed int, so why shoving the
result into a signed int "fixes" it, I don't know.

I suggest a cast as follows:

m = ((unsigned char)k - 247) * 256 + ....

which does work.  Another option (not likely, though), is to make all
byte streams unsigned chars instead of signed chars...

Tom