freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft] ftmac.c


From: mpsuzuki
Subject: Re: [ft] ftmac.c
Date: Tue, 20 Jan 2009 00:07:20 +0900

Dear Schmidt,

I'm sorry for lated reply to your post 2 months ago.

On Sat, 22 Nov 2008 23:51:17 -0600
Ryan Schmidt <address@hidden> wrote:

>On Oct 12, 2008, at 02:17, address@hidden wrote:
>> In future, src/base/ftmac.c would be removed and
>> builds/mac/ftmac.c would be left, because Mac OS X enables
>> to implement important features of ftmac.c with only
>> POSIX, and without Carbon frameworks.
>
>Then I don't understand this paragraph. Did you reverse the paths or  
>did you mean it that way? Because based on your first two paragraphs,  
>I would have thought src/base/ftmac.c is the version that will be  
>kept, having had the old pre-Mac OS X code removed, and builds/mac/ 
>ftmac.c will eventually go away.

I want to remove modern src/base/ftmac.c for Mac OS X, and
I want to keep legacy builds/mac/ftmac.c for pre-Mac OS X.
The QuickDraw API on pre-Mac OS X won't be changed anymore,
so the future changes of builds/mac/ftmac.c would be only
bug fix. On the other hand, if we keep src/base/ftmac.c
synchronized to Mac OS X, there are too many issues:

* 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

* As I've shown my experiment with "partial stream", it
  is possible to reduce the memory allocation & maximum
  footprint to handle resource-fork font by POSIX API only.

* 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.

Thus, I want to remove src/base/ftmac.c. I want to provide
Carbon-free implementation which keeps user-visibile behaviour
of FT_New_Face in ftmac.c, but I want to remove all APIs
using Mac OS specific data types in their arguments, like,
FT_New_Face_From_{FSSpec|FSRef|FOND} etc.

How do you think of?

Regards,
mpsuzuki





reply via email to

[Prev in Thread] Current Thread [Next in Thread]