freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] PureC


From: David Turner
Subject: Re: [Devel] PureC
Date: Sat, 16 Jun 2001 18:39:23 +0200

Hi Wolfgang,

> 
> The first problem is to compile a construct like this one (example from 
> ftimage.h):
> 
>   typedef enum  FT_Glyph_Format_
>   {
>     ft_glyph_format_none      = 0,
>     ft_glyph_format_composite = FT_IMAGE_TAG( 'c', 'o', 'm', 'p' ),
>     ft_glyph_format_bitmap    = FT_IMAGE_TAG( 'b', 'i', 't', 's' ),
>     ft_glyph_format_outline   = FT_IMAGE_TAG( 'o', 'u', 't', 'l' ),
>     ft_glyph_format_plotter   = FT_IMAGE_TAG( 'p', 'l', 'o', 't' )
> 
>   } FT_Glyph_Format;
> 
> PureC only allows INT as element of enumeration. So what can I do? One easy 
> way would be:
> 
> #ifdef __PUREC__
>   typedef enum  FT_Glyph_Format_
>   {
>     ft_glyph_format_none      ,
>     ft_glyph_format_composite ,
>     ft_glyph_format_bitmap    ,
>     ft_glyph_format_outline   ,
>     ft_glyph_format_plotter
> 
>   } FT_Glyph_Format;
> #else........
> 
> I guess, this works if and only if this enumeration is used inside
> FreeType without relation to imported type-data. But I do not know if
> this is so.
> 
client applications should only use the enumeration identifiers,
so changing their values for _specific_ platforms should solve
the problem.

> Can I do so or do you have an other idea?
>

Just to clarify things, we're using an enumeration here is
to allow third-party extensions. For example, imagine that
we want to provide a "MetaFont" font driver for FT2.
We'll need:

  - a "font driver" module to parse/load the font files
    in memory, and generate metrics and glyph images
    from them.

  - a specific "renderer" module, since the glyph images
    produced by MetaFont cannot easily be converted into
    the bezier-based FT_Outline type.
 
If we use 32-bit integers for the glyph format type, we
can easily create a new one without risking conflicts
when two third-parties try to produce their own image
format. Of course, that's extremely unlikely but it's
relatively easy to be safe with enums..

I always thought that enum types were widened to "long"
in ANSI C if one of the constants listed couldn't fit
in an "int" type.

Could one of our ANSI-aware developers here give us
more details about this issue ? I didn't find anything
relevant in the books I own :-(

Now, using a special configuration macro to restrict the
use of simple integers for the glyph format type should
be enough.

Regards,

- David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]