Re: [Devel] FT_Set_Hint_Flags problem

[Owen Taylor]

On Thu, 2003-04-24 at 13:04, David Turner wrote:
> Werner LEMBERG wrote:
> > David,
> > 
> > 
> > in Sept 2002 you've removed FT_Set_Hint_Flags from freetype.h.  I just
> > found out that the function is still in ftobjs.c.  Shall it be removed?
> > 
> The reason this function is still there, even if it is dormant, is to avoid
> completely breaking RedHat 8.0 systems when users upgrade to a newer FreeType
> release !
> 
> RH 8.0 uses a modified version of FT 2.1.2 and libXft that directly
> call FT_Set_Hint_Flags to modify the "hinting" settings in the
> font control panel. Had this function disappeared from the library,
> any user installing a more recent version of FT2 would break many
> things on his machine.
> 
> 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?)

> Maybe we need a new "tag" to warn users that something shouldn't
> be used for production code, since "EXPERIMENTAL" or "INTERNAL" seem
> to be ignored constantly by certain people. what about one of the
> followings:
> 
>   - YOU_DONT_MEAN_IT_DO_YOU_?
>   - CRASH_IS_SO_FUNNY
>   - INTEGRATION_?_WHAT_INTEGRATION_?
>   - ROT_IN_HELL
>   - OWEN_DONT_TOUCH_THIS__PLEAAAASE
> 
> Aaaaaaaaah, feel better :-)

Well, generally how I get scheduled time to work on stuff is by
being able to make it appear in Red Hat releases; I tried
to coordinate the FT_Set_Hint_Flags() upstream to give the
best possibility that it would be the final way things work
but it turned out at some point that we need to ship, and
after that point FreeType went a different way.

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.

And while installing non-Red versions of FreeType on a Red Hat
system is *not* formally supported in any way, I'm quite happy 
to work  with people to resolve their problems. It's not the 
FreeType projects responsibility.

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.

Regards,
                                               Owen