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

[David Turner]

Hi Chia-Wu,

Chia-I Wu a écrit :

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.

  

ok, apparently, the 'find_sbit_image' and 'load_sbit_metrics' fields were added in the middle
of the SFNT_Service structure in FreeType 2.1.8. They've been moved to the end of the structure
because we want to target the internals of 2.1.7.

*However*, I'm ready to make a special exception for this specific case, i.e. re-move the fields
to their 2.1.8 location. That's because it is _very_ unlikely that another rogue client might be
interested by the fields that are replaced/moved by this operation.

this would allow a safe install with an xorg-xserver.

If you agree, I'll do the change myself, with a meaningful comment to explain the exception.

Regards,

- David

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?