Re: [ft] ftmac.c

[mpsuzuki]

On Mon, 19 Jan 2009 18:35:53 -0600
Ryan Schmidt <address@hidden> wrote:
>> * Since Mac OS X 10.5, CoreFoundation is announced to be
>>   danger in Unix-like programs which can fork. So Carbon-free
>>   implementation is expected. This is the most serious
>>   motivation to obsolete src/base/ftmac.c.
>>   http://lists.nongnu.org/archive/html/freetype/2007-11/msg00000.html
>
>Agreed, this is a problem. In MacPorts we had been using --with-old- 
>mac-fonts at a user's request, but we've had to remove that option on  
>Leopard and up to work around this problem.
>
>http://trac.macports.org/ticket/15909

Thank you for notice.

>> * At present, FT2 has some interfaces to ATS font management.
>>   it was originally introduced by me to provide a migration
>>   from obsolete QuickDraw font management to modern one, but
>>   it is completely wrong decision. Now it should be replaced
>>   by CGFont for newer Mac OS X, the introduction of ATS to
>>   FT2 was wrong decision. Also as you posted 64-bit issue of
>>   cairo/pango universal binary, it is difficult to select
>>   popular API which are available on all architechtures of
>>   Mac OS X.
>
>It does sound difficult. The Mac OS X font APIs seem to be changing  
>often. Hopefully CGFont will be the one that sticks. But that's only  
>on Leopard and newer, right? Will you keep ATS for Tiger and earlier  
>then?

I want to drop the interface to ATS, and I don't want to
introduce a replacement interface to CGFont. The reasons
are following.

* I don't find many applications using FT_New_Face_From_FOND(),
  FT_GetFile_From_Mac_Name(), FT_New_Face_From_FSSpec() etc,
  but I find many complains from the developers and users
  who got unresolved symols troubles. I'm questionable if
  these APIs are worthful to be kept in Mac OS X. I guess
  the support of Mac-specific font formats via standard API
  would be sufficient.

* CGFont is not generally available. The current implementation
  of the interfaces in ftmac.c exposes all functions even on
  unsupported platforms. For example, FT_GetFile_From_Mac_Name()
  (an interface to QuickDraw font manager) is exposed on 64-bit
  platforms, although the function just returns an error to
  indicate the feature is not implemented on such platforms.
  Yet I've never removed such symbols, to avoid the troubles
  caused by unresolved symbols. But reconsidering the design
  itself, I think such design is not good, because,

  - FT2 client programmers have to check the feature availability
    by odd procedure: invoking the function with empty (but not
    crashing) parameters to the function and analyze what kind
    of error is returned.

  - The number of non-working functions is increased to avoid
    unresolved symbol error. Even if FT2 client programmer
    writes some fallbacks for the cases that legacy framework
    (e.g. QuickDraw) is unavailable, it requires the symbol of
    non-working function. I think it's a pity. It is expected
    that FT2 client programmer can write a program which can
    work with FT2 library with working function symbol, with
    unworking function symbol, and WITHOUT unworking function
    symbol. Today, if I'm forced to provide an interface to
    CGFont, I should provide the feature as a registered service
    and should not expose any CGFont specific function in public
    FT2 APIs.

  - If FT2 is configured to use CGFont framework, FT2 library
    itself is dependent with CGFont framework. It is possible
    that a FT2 client program carries over the dependency,
    even if it doesn't call CGFont interface at all.
    Turner had ever proposed to resolve the symbols of such
    interfaces, in runtime, by dynamic loader. I've written
    a proof of idea of his proposal, but it was not welcomed.

http://lists.nongnu.org/archive/html/freetype/2007-09/msg00023.html
http://lists.nongnu.org/archive/html/freetype-devel/2007-09/msg00005.html

    Becasuse it was complicated for other MacOS developers,
    and the API set of the dynamic loader of Mach-O was NOT
    stable (in Mac OS X 10.0, dynamic loader APIs are almost
    same with NeXTSTEP. In later, they are deprecated and
    more SunOS-like interfaces are introduced). Thus, we have
    to drop older Mac OS X (< 10.3), or we have to be afraid
    of the removal of legacu dynamic loader APIs. I don't
    think the Mac OS X specific APIs are worthful to make
    version-dependent binaries.

Regards,
mpsuzuki