Hi David,
that's ok, but I'm surprised this didn't get caught. The problem is even
worse than I thought because PS_FontInfoRec is
also used to define the "fonts_infos" in the PS_BlendRec structure (I don't
think we have any client code that accesses
this though).
I have submitted a fix to the CVS repository (which wasn't too trivial). The
Function FT_Get_FSType_Flags() has
been updated accordingly.
For the record, here's the ChangeLog entry:
Remove ABI-breaking field in public PS_InfoFontRec definition.
Instead, we define a new internal PS_FontExtraRec structure to
hold the additionnal field, then place it in various internal
positions of the corresponding FT_Face derived objects.
* include/freetype/t1tables.h (PS_FontInfoRec): Remove the
`fs_type' field from the public structure.
* include/freetype/internal/psaux.h (T1_FieldLocation),
include/freetype/internal/t1types.h (T1_FontRec, CID_FaceRec),
src/type1/t1load.c, src/type1/t1tokens.h,
src/cid/cidload.c, src/cid/cidtoken.h,
src/type42/t42parse.c: modify the various font parsers to store
the `fs_type' field in a different places, instead of the public
PS_FontInfoRec.
* include/freetype/internal/services/svpsinfo.h (PsInfo service),
src/base/ftfstype.c (FT_Get_FSType_Flags), src/cff/cffdrivr.c,
src/cid/cidriver.c, src/type1/t1driver.c, src/type42/t42drivr.c:
Modify the PsInfo service to add a GetExtra function, use it in
FT_Get_FSType_Flags() and modify the drivers accordingly.
2009/3/3 Bevan, David <dbe...@emtex.com>
> David,
>
>
>
> My apologies, but this *was* discussed on the development mailing list
> (see below).
>
>
>
> I would have used an alternative approach if I had been informed that
> adding a new field to the public structure was not permitted.
>
>
>
> David %^>
>
>
>
>
>
> -----Original Message-----
> From: Werner LEMBERG [mailto:w...@gnu.org]
> Sent: 11 December 2008 17:18
> To: Bevan, David
> Cc: mpsuz...@hiroshima-u.ac.jp; Ghoshal, Ronen; Tu, Houjie;
> freetype-devel@nongnu.org
> Subject: Re: [ft-devel] Accessing FSType (Type 1 or CID)?
>
>
>
>
>
> > If I understand correctly, a field needs adding to PS_FontInfoRec
>
> > (which is part of the public interface; presumably this is OK) and
>
> > FSType processed just like other fields, simply by defining in
>
> > t1tokens.h.
>
>
>
> Yes, I think this should work without breaking backwards binary
>
> compatibility of the library. In any case, the new field should be
>
> at the end of the structure.
>
>
>
> ...
>
>
>
> Werner
>
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
