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 Fo
It'd be much better if you could find a way to embedded the FreeType
functionality within
the FontForge sources directly, instead on relying on something so fragile.
We discussed this before. It would divorce ff from freetype fixes which
to me is far worse.
If that's the only point, wh
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' ma
> > 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
On Thu, 2006-02-16 at 05:58, david turner wrote:
> Just keeping TT_RunIns reachable is not enough, we must also prevent
> modifications of many
> internal structures of the TrueType driver and interpreter that you're
> relying on.
Well, one point of rummaging in the source tree is to get access t
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
> 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 sufficien
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*, a
> >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 upgrades their
> programs adequat
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
> - 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 modi
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 never
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 address
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
14 matches
Mail list logo
