freetype-devel
[Top][All Lists]
Advanced

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

[ft-devel] FTC_FaceID type definition (Cache migration)


From: Ian Britten
Subject: [ft-devel] FTC_FaceID type definition (Cache migration)
Date: Tue, 03 Jun 2008 14:26:28 -0300
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050322)

Hi all,
[ NB - Reposting from the general FT list to the -devel list ]

I'm trying to upgrade some older code that is using FT 2.1.7 to
the newest version.  In this case, the code was unfortunately
using the (old, unsupported) FT cache.  As such, I'm trying to
migrate the code without having to do a wholesale rewrite.

What I'm currently wondering is about the change to the actual
type of the FTC_FaceID.  In v2.1.7, it was:
        typedef FT_Pointer  FTC_FaceID;
where FT_Pointer was just a void*.  What this allowed us to do
was simply use a pointer to one of our cached C++ objects as
the FTC_FaceID.

Now, in v2.3.5, it appears as:
        typedef struct FTC_FaceIDRec_*  FTC_FaceID;
implying that the FTC_FaceID must actually be a
FTC_FaceIDRec_ structure, and preventing us from using a pointer
to our cached C++ object as before.

Before I start hacking/slashing our code to address this, can
someone give me a 'heads-up' on what the change implies?  (I
didn't see anything about it in the ChangeLogs, but I'm guessing
it's too internal for that).  For example:
- Is FT allocating/deallocating these structures anwhere?
- Is the structure expected to have any particular fields?
[ In other words, why wasn't a void* good enough, and what
problems/limitations were fixed by making it non-void? ]

I can think of a couple of possible shims that I could do to
bridge the change, but I just want to ensure I understand the
implications and expectations of the change first.

Many thanks for any info!
Ian




reply via email to

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