RE: [Devel] Re: [Freetype] Bug with spaces in latest CVS release

[Ian Brown]

Scott,

I remember when I was reading PCL true type data, glyph 0x03 always gave me problems because the windows driver would download it for the space character and it always contained 0 contours. This is okay of course, but there was something tricky involved with how this had to be converted from PCL representation to the glyf table. In the end I stored a flag in the PCL processor to say whether the space character had been defined or not.

I just mention it because the fact that you have changed something to account for a contour count of zero might have a bearing on the earlier problem you were having.

BTW: how did you cope with freetype requiring the tables 'names' and 'psnames' when PCL does not provide them? Did you synthesize them, or did you do what I did and locally patch freetype not to require these tables.

The patch I made is below, if you're interested. I'm not sure why freetype requires these tables ... other than the fact that the spec. says they are required.

RCS file: /export/cvsroot/IJSTOOLKIT/freetype-2.0.4/src/sfnt/sfobjs.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
300,302c300
<          LOAD_( charmaps )    ||
<          LOAD_( names )       ||
<          LOAD_( psnames )     )
---
>          LOAD_( charmaps )    )
303a302,305
>
>       /* For PCL make these tables not required. */
>     LOAD_( names );
>     LOAD_( psnames );

*****CVS exited normally with code 1*****

ps: If want, you can send me your PCL file and I can tell you if it contains a corrupt glyph. We've never come across a problem with a Windows PCL driver downloading illegal glyphs, and we also use freetype 2.0.4

Ian Brown
Software Development Director
PrintSoft Systems GmbH