Re: [Devel] Very bad spacing/kerning on OS X

[Owen Taylor]

On Fri, 2003-07-25 at 06:05, Werner LEMBERG wrote:
> > It seems I've missed a few messages on the mailing list.  Why isn't
> > 2.1.5 not binary compatible with 2.1.4?  I consider this to be a
> > *serious* mistake.
> 
> This fix of a major bug:
> 
>   2003-05-30  Werner Lemberg  <address@hidden>
> 
>         Avoid overwriting of numeric font dictionary entries for
>         synthetic fonts.  [...]
> 
>         [...]
> 
> >       * include/freetype/t1tables.h (PS_FontInfo): Change
> >       italic_angle, is_fixed_pitch, underline_position, and
> >       underline_thickness to pointers.
> 
>         [...]
> 
> Theoretically, it would be possible to avoid that change by collecting
> italic_angle and friends internally, assigning them afterwards to
> PS_FontInfo, but this would be very inelegant and completely different
> to the handling of all other values in that structure.
> 
> This breaks binary compatibility, right?  I'm not completely sure what
> changes are allowed to not break binary compatibility...

If those are public fields, then the change not only breaks binary
compatibility, it breaks source compatibility, since you can't
use a 'FT_Fixed*   underline_thickness;' the same way you were
using 'FT_UShort   underline_thickness'

It appears to me that the fields are public since there is
FT_Get_PS_Font_Info().

>From looking at this:

 A) it's not even clear to me what it means to have underline_thickness
    and friends be pointers. Are they arrays? How long? Is
    it just something I have to dereference? Better inelegant
    implementation than inelegant public API, right?

 B) you can't change the type of a public field and maintain
    source compatibility. If underline_thickness, etc, are
    better as FT_Fixed, then you need to leave the integer
    version around as an approximation and add a
    underline_thickness_fixed field or something like that (*)

> BTW, is there a simple (and reliable) test for binary compatibility?

Not that I know of. Generally, keeping binary compatibility is
just a matter of knowing what things will break it, and not doing
them.

I think you could probably build such a tool, but it would require
some sort of annotation, since whether changes break binary
compatibility frequently depend on other details about how
the structures are used.

Regards,
                                        Owen

(*) Whether adding fields to the end of a structure preserves
    source and binary compatibility depends on how the structure
    is used; as long as long as the structure is always
    allocated/initialized  within the library, it's fine.