On Wed, 2006-02-15 at 17:31, Werner LEMBERG wrote:
- do the required modifications, encapsulating each of the old
internals in a configuration macro
(e.g. FT_CONFIG_OPTION_OLD_INTERNALS)
Sounds good. We should mention in the docs that these steps are
performed only *once*, and that
As the author of a rogue client for which no patch is contemplated
(and for which we decided last year that there was no good way to
provide a patch) I must beg that
TT_RunIns
remain reachable.
We add `TT_RunIns' manually to the list of exported symbols. This
should be sufficient,
George Williams a écrit :
On Wed, 2006-02-15 at 17:31, Werner LEMBERG wrote:
- do the required modifications, encapsulating each of the old
internals in a configuration macro
(e.g. FT_CONFIG_OPTION_OLD_INTERNALS)
Sounds good. We should mention in the docs that these steps
We add `TT_RunIns' manually to the list of exported symbols. This
should be sufficient, shouldn't it?
That's all I want.
Please, please, please.
It's already implemented so in the GNU makefile since a few weeks.
Werner
___
Freetype-devel
On Thu, 2006-02-16 at 06:15, Werner LEMBERG wrote:
As the author of a rogue client for which no patch is contemplated
(and for which we decided last year that there was no good way to
provide a patch) I must beg that
TT_RunIns
remain reachable.
We add `TT_RunIns' manually to the
On Thu, 2006-02-16 at 07:08, david turner wrote:
I still don't understand why you absolutely want the ability to
dynamically peek into the
internals of the libfreetype installed on the system, especially since
it will not have the
bytecode interpreter on most distros anyway...
I want
Hello everyone,
I'd like to re-activate the debate regarding how we're going to
install/name the
next FreeType release in order to avoid some of the ugly problems discussed
previously.
As far as I have understood:
* Installing the next release as libfreetype6.so is going to break any
rogue
Hi David,
Any comments ?
I'm delighted to see such a mature attitude in the project, an attitude
which levels the project with those of giants like Microsoft and Sun,
who go through the same kind of hoops to maintain binary compatibility.
BTW, I'm not a FreeType developer so I cannot
Ilya Konstantinov a écrit :
but there are still cases where a program obtains a FT_Face object
through libfreetype7, then call an internal function in libfreetype6,
You're talking about libraries which accept/offer FreeType structures
in their public APIs, e.g. (just an example -- I
- immediately freeze development on the current code base
- perform a massive diff between the content of
include/freetype/internal between the 2.1.10 release and the
current CVS, and study how we can stub each type, field and
function defined here.
- do the required
Hi Werner,
Werner LEMBERG a écrit :
Sounds good. We should mention in the docs that these steps are
performed only *once*, and that we are not going to maintain those
hacks.
I think that we'll need to maintain them for quite some time, between 6
and 18 months,
to ensure that everybody
11 matches
Mail list logo
