[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ft-devel] Invalid Glyph Format
From: |
Turner, David |
Subject: |
RE: [ft-devel] Invalid Glyph Format |
Date: |
Wed, 29 Jun 2005 13:26:52 +0200 |
Hello Trevor,
> I have asked this before in a way, but...
>
> Is there any specific information anyone could give me about
> error code 0x12
> (Invalid Glyph Format)
>
On which function ?
> Anything specific would be very much appriciated. What might
> cause this,
> where it might be, what structs to look at...
>
It's hard to tell. What were you trying to do.
> I am parting the headers, so although I think all of my types
> sizes match,
> there could be a lingering problem there...
>
> Also I noticed
>
>
> struct FT_Bitmap_
> {
> int rows;
> int width;
> int pitch;
> ubyte* buffer;
> short num_grays;
> char pixel_mode;
> char palette_mode;
> void* palette;
> };
>
> doesnt use the FT_Int and FT_Short, etc, types... Why is
> this? When porting
> to D where the int and short are different byte sizes, will
> the cause the
> problem? How large should these be?
>
the struct don't use the FT_Int/FT_Short types because I
believe it is defined before them.
- FT_Int and FT_Short are just convenient typedefs
for 'int' and 'short' anyway
- they're defined to be coherent with FT_UInt and
FT_UShort, which are themselves equivalent to
'unsigned int' and 'unsigned short', but *much*
shorter to type.
- the D 'short' and 'int' types are always 16-bits and
32-bits, respectively
- with C, the size of 'short' and 'int' depends on the
platform. However, for most modern platforms, which
means any one targetted by the D compiler, this means
the same ones (i.e. 16 and 32 bits respectively)
- similarly, you can replace 'unsigned int' and
'unsigned short' with their D equivalent: uint and ushort
- the signess of 'char' in C depends on the compiler,
so you can use either the D 'byte' or 'ubyte' type
instead. Given that all supported values for these
fields are >= 0, 'ubyte' is preferred.
- do not use the D 'char' for C 'char'. That's because
it's default initializer is 0xFF instead of 0, and this
will cause all kinds of subtle problems when used
naively in D code.
Hope this helps,
- David Turner
- The FreeType Project (www.freetype.org)
> Thanks,
> Trevor Parscal
>
>
>
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>
>