[Top][All Lists]
[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
- Re: [ft] ftmac.c,
mpsuzuki <=