>>>>> In <[EMAIL PROTECTED]> >>>>> Branden Robinson <[EMAIL PROTECTED]> wrote:
>> On Sat, Jun 07, 2003 at 11:20:01PM +0900, ISHIKAWA Mutsumi wrote: >> > >> I got a report in private mail (grrr) from a person who ran into the >> > >> very problem you describe, so I appreciate you tracking this down and >> > >> fixing it. Your analysis looks reasonable and I agree with your >> > >> solution. >> > >> > Sorry, I found my mistakes by my self. >> > >> > 1) PS_FontInfoRec was not changed between FreeeType 2.1.3 and >> > 2.1.4. It makes after FreeType 2.1.4 release (please see >> > freetype-2.1.4/debian/patches/001-freetype-2.1.4+cvs20030601.diff). >> >> If this is true, then, FreeType maintainer: *please stop doing this*. >> >> Debian needs to have FreeType packages that are compatible with the rest >> of the world's FreeType packages. >> >> Perhaps what we really need is a freetype-snapshot package, which ships >> a libfreetype6-snapshot package which Conflicts/Replaces/Provides: >> libfreetype6. For reasons that should be obvious, there should be no >> snapshot -dev package at all. >> >> Please, please, please, I beg of you, do not break binary compatibility >> in library packages. Humm, I found a message from Werner LEMBERG posted to [EMAIL PROTECTED] I believe libfreetype6 incompatible between 2.1.4-3 and 2.1.4-4. Application build with libfreetype6_2.1.4-4 (use PS_FontInfoRec) will crash with libfreetype6_2.1.4-3. Application build with libfreetype6_2.1.4-3 (use PS_FontInfoRec) will crash with libfreetype6_2.1.4-4. But SONAME is not changed yet (on upstream). >>>>> In <[EMAIL PROTECTED]> >>>>> Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> > >> > You might want to reconsider the change... >> > >> > * src/type1/t1tokens.h: Change italic_angle, is_fixed_pitch, >> > underline_position, and underline_thickness to pointers. Change >> > the type of the latter two to `fixed'. >> > >> > in current freetype6 without a change in version numbering of the shared >> > libraries. >> >> Our normal strategy is to increase the shared library version number >> right before a new release (as suggested by libtool). We will do >> that, of course, but not now. >> >> Is there a better strategy? >> >> >> Werner -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>