[ft-devel] Re: [ft-cvs] freetype2 ./ChangeLog builds/amiga/src/base/fts...

[Chia-I Wu]

On Sun, Feb 19, 2006 at 05:26:14PM +0100, Werner LEMBERG wrote:
> > When FT_OPTIMIZE_MEMORY is defined, `long_metrics' is always NULL
> > while `number_Of_HMetrics' is usually non-zero.  This crashes
> > libXfont and thus xorg.
> > 
> > The only fix I come up with is always set
> > face->horizontal.number_Of_HMetrics to zero, add
> > `number_Of_HMetrics' to the end of `TT_FaceRec' and use it when
> > FT_OPTIMIZE_MEMORY is defined.  `vhea' should be handled similarly.
> This sounds good.  Please provide a patch.
Although this prevents crashes, the multi-byte glyphs are no more
shown, i.e. libXft malfuctions.

There is another problem.  libXfont uses sfnt->find_sbit_image and
sfnt->load_sbit_metrics, which are now moved to the end of
SFNT_Interface.  Therefore, another two functions would be called and
the behavior may be unpredictable.

For a distribution maintainer, if upgrading freetype would render some
package broken (crash or malfunction), it is definitely unacceptable.
As a result, freetype can be upgraded only after the package is patched
and recompiled.  In this point of view, we don't need to pay special
attention to the internal ABI compatibility.  Things are solved in the
package managing level.

Meanwhile, we can still make binaries under /usr/local happier by, say,
keeping those APIs which can be easily kept or which are known to be
used by some rogue client.  If having the degree of intenal ABI
compatibility we have now in the CVS can make _all_ clients happy,
despite the code is ugly, it's worth it.  But we already know that this
is not true.

Any comment?

-- 
Regards,
olv