freetype-devel
[Top][All Lists]
Advanced

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

[ft-devel] Progress towards binary backwards compatibility


From: david turner
Subject: [ft-devel] Progress towards binary backwards compatibility
Date: Fri, 17 Feb 2006 13:35:45 +0100
User-agent: Thunderbird 1.5 (Windows/20051201)

Hello everyone,

I commited yesterday night a massive patch to the current CVS in order to respect the layout of internal objects of FreeType 2.1.7. Note that the current code is not ready for release yet, we need to change the build system to export the FT_BASE functions again, and there are still some issues with the cache sub-system (more
details below).

I've been doing quite a lot of archeology and googling to see what not-to-bleeding
edge distributions are currently using, and 2.1.7 seems to be appropriate.

Note that we've made other subtle changes to the internal layouts between 2.1.7 and 2.1.10, but none that seems to have any impact (at least none I could have found through googling mailing lists), so I've reverted all layouts to be compatible
with 2.1.7 anyway.

I've also discovered that Debian Woody uses 2.0.9, while Sarge uses 2.1.2.
There is no way we'll be able to support complete binary compatibility with these
versions, because the changes we've made to object layouts have been too
important. However, I'll later inspect the state of exported internal functions,
since most of them may be implementable.

I also discovered that we changed one *public* structure in 2.1.8, which is
extremely BAAAAAD. The culprit is the PS_PrivateRec defined in freetype/t1tables.h,
which gained an "expansion_factor" field towards the end of its structure.
Very fortunately, nobody seems to be interested by the fields that it has shifted ('language_group', 'password' and 'min_feature'), so this probably had zero impact
on production code.

Now, let's talk about the cache sub-system. As die-hard FreeType developers know, this portion of the code is still dubbed "beta" or "experimental", and has changed quite
a lot, both in object layout and APIs, since its original version.

Unfortunately, I've found that some projects have been using it in production code,
this includes at least the following:

- FireFox (or even Mozilla), which contains a module used to perform client-side anti-aliased rendering through core X11 and FreeType 2. This code uses the old
  FTC_ImageCache types, including FTC_ImageDesc which disappeared in 2.1.8

- GNUStep, which uses it to cache font data. At least they acknowledge that
  our API is "in flux"

- NGL, which is a C++ OpenGL wrapper which uses the cache sub-system
extensively, though in a rather stupid way (e.g. it sets "max_faces" to 65536,
 meaning that every opened FT_Face will be kept opened for the program's
 duration)

unfortunately, it is not possible to support all versions of the cache sub-system, mainly because some function signatures have been changed rather heavily, without any simple way to detect which kind of structures/parameters they're being passed
on.

I'll try some hack tonight that should at least save the day for FireFox, maybe
GNUStep, but certainly not NGL. I'll post my results tomorrow.

From now, and if no other problem is detected, we should consider the current layout and internal APIs as gospel. The only acceptable things to do is to add new functions, and eventually add fields at the end of internal structures, *only* if these are not
allocated in arrays.

More on this later,

- David


***********************************************************************************
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the address@hidden and destroy the original 
message.
***********************************************************************************




reply via email to

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