Re: [Devel] FT_Set_Hint_Flags problem

[Owen Taylor]

On Tue, 2003-04-29 at 11:31, David Turner wrote:

> Owen Taylor wrote:
> > On Thu, 2003-04-24 at 13:04, David Turner wrote:
> > 
> >>I don't know about RH 9, by the way, the "problem" might still persist
> >>as well.
> > 
> > No, I switched over to setting the target, and made that work.
> > (remember the patch that I sent you?)
> > 
> I remember the patch, I just didn't realize it was for RH9 :-)
> 
> > But anyways, from *my* perspective, if we use something that 
> > isn't in the public API, or is marked experimental, and you 
> > break it, that's our problem, and if people complain, just point 
> > them at us. It's my responsibility to:
> > 
> >  A) Make sure that things as well as possible in each version.
> > 
> >  B) Make sure that things work when upgrading between Red Hat
> >     versions.
> >
> I understand your point of view, but mine is that 99% of users
> who encounter this kind of problem will think it's either their
> own fault, or that of FreeType. Only a fraction will ask about it
> on the mailing list, or dare to look at the archives for more
> information. The rest will just grow frustated.
> 
> Leaving the function in the 2.1.4 release code was a very simple
> way to avoid confusion for *many* people, and speed up its adoption
> to more systems.

Well, I'm not going to *object* if you want to do things to try
to make things work smoother on Red Hat; I just want to make
it clear that you should perfectly free to dump responsibility
for any problems from our changes onto us.

> Apart from that, and joke aside, it's free software: you're absolutely
> free to do wathever you want with the code, and I'm free to be a bit
> angry about certain of your changes :-) this should prevent us from
> working together when needed anyway.

Indeed.

>  > But if a new version of the FreeType package requires a new
>  > version of the Pango package, well, that's a side effect I
>  > can't always prevent. What we certainly would avoid is making
>  > 3rd party applications compiled against release depend on
>  > customizations in our packages that might change in future
>  > releases.
> 
> Since we're talking about it, I'd like to find a way to get rid
> of these horrible (IMO) uses of FreeType internals within Pango.
> You did went through various autoconf hacks to make this seamless
> when building the library, but problems arise sometimes when trying
> to build Gnome on non-standard locations or setups.
> 
> Would you be interested if we provided in FT2 an API similar to
> what FT1 does and the code you ported from there to Pango ? I was
> thinking about performing the following:

Certainly, maintaining a separate copy of the code in Pango
is not a task I'm particularly attached too :-)

I've thought at times of taking the current Pango code, removing the
FreeType dependency altogether, and just making it work on the entire
tables in memory. But that's a lot of work for fairly minimal
gain. Plus, I've been sort of hoping that we'll be able to dump the
code at some point and switch to some more commonly maintained
codebase for OpenType handling, such as otlayout work.

My main worry about depending on a temporary port of the freetype1
code inside FreeType2 would be adding another library to the
dependency chain then removing it later, which always causes
confusion and subtle problems.

But thats not a insuperable problem; if the library shipped with
FreeType and came with a .pc file, that would certainly help,
and we've already done a lot of work in the Pango build process
to try to shield applications from dependency changes.

>    - providing an API similar to what FT1 provides to manage
>      OpenType Layout tables. This assumes you didn't make too
>      many changes to the code when "porting" it to
>      Pango + FreeType internals.

The initial changes to the FreeType1 code as integrated into
Pango were are largely mechanical; my memory was that they
basically to remove the freetype-extension parts, and to
pass around FT_Memory objects to a lot of places that didn't
have them.

Sadly, since then there has been divergence in bug fixes. 
Bug fixes have gone into the freetype1 cvs that aren't in Pango
and vice versa.

If the freetype1 code was resurrected and ported to freetype2,
it wouldn't be that hard to identify the half-a-dozen or
so bug fixes in Pango and integrate them back.

>    - bringing back the old stream functions within the library,
>      as simple calls to the new ones. this, to avoid "breaking"
>      old Pango installations when upgrading FreeType.

Note sure that this is work it at this point; the problems
with people upgrading FreeType and breaking Pango seem to be
dying out at this point. 

(Somewhat more common is when people have two copies of FreeType
of different versions, and Pango's configure finds one and
the build finds the other. XFree86 installs including FreeType
headers/libraries are the root of much evil.)

>    - maybe even bring back a dummy FT_Set_Hint_Flags for the
>      same reasons :-)
> 
> I've re-started working on "src/otlayout" but the final code
> will not be available before long. In the mean-time, sort of
> porting the old FT1 code to FT2 should be easy, even if the
> implementation is a bit intimidating..

Regards,
                                              Owen