freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] freetype on mac os X question/curious comments Re: Freety


From: suzuki toshiya
Subject: Re: [ft-devel] freetype on mac os X question/curious comments Re: Freetype-devel Digest, Vol 107, Issue 10
Date: Fri, 27 Dec 2013 15:39:30 +0900
User-agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080406)

Hin-Tak Leung wrote:
> If what you said is true, that must mean Mac OS X's shipped freetype
> has some custom patch to reorder the font index?

No. FreeType2 has 2 drivers for Suitcase font format;
one is dependent with Carbon framework, and another is
independent (POSIX/Carbon-free). It is switched by the
configuration (thus it cannot be changed in runtime).

Apple ships FreeType2 that was configured to use
Carbon-dependent driver. It is non default configuration
(default is Carbon-free). And, without my patch, the
face index in the Suitcase font including multiple faces
is different between Carbon driver vs Cabon-free driver.

Maybe some people will wonder "why default configuration
is not set to Carbon driver? Apple does so, so FreeType2
should do so". There are a few reasons;

* The availability of Carbon functions are platform
dependent. There were many differences among ppc, ppc64,
i386, amd64 and arm. It is not easy to have differenciated
configurations for each architectures when a developer
is making an universal binary. Even if it is acceptable,
the different feature set for each architecture would be
confusing. The Carbon-free driver would not have such
problem.

* The Carbon functions to access the resource fork are
declared as deprecated. They might be too old implementations
to guarantee the the safety in the threading or reentrance.

* The Carbon-dependent FreeType2 is dependent with several
frameworks; CoreServices and ApplicationServices. The linker
of Mac OS X is not so flexible to substitute the Carbon-free
FreeType2 by the Carbon-dependent FreeType2, so unexpected
insertion of the Carbon dependency induces some chain reactions
to rebuild many binaries to embed the Carbon dependency
appropriately.

Therefore, instead of making Carbon-dependent driver
default, I wanted to fix the inconsistency between Carbon
driver and Carbon-free driver.

Regards,
mpsuzuki

> BTW, most opensource stuff shipped with Mac OS X is available in source form
> at opensource.apple.com .
> 
> Hin-Tak
> 
> --------------------------------------------
> On Fri, 27/12/13, mpsuzuki <address@hidden> wrote:
> 
>  Subject: Re: [ft-devel] freetype on mac os X question/curious comments Re: 
> Freetype-devel Digest, Vol 107, Issue 10
>  To: address@hidden
>  Cc: address@hidden
>  Date: Friday, 27 December, 2013, 2:34
>  
>  Hi,
>  
>  Attached is a draft of the patch to fix the face reordering
>  problem.
>  I will dig the mailing list archive and add the appropriate
>  reference
>  for the changelog.
>  
>  In my understanding, the problem could be described as
>  following:
>  
>  1) Comparing the ftdump outputs by FreeType2 built with
>  Carbon
>  framework, and that by without Carbon framework, the
>  ordering of
>  the faces in a Suitcase or .dfont format is different.
>  
>  For example, the faces in Helvetica.dfont are shown as:
>  
>  with Carbon
>  -----------
>  Helvetica
>  Helvetica-Bold
>  Helvetica-Oblique
>  Helvetica-BoldOblique
>  
>  without Carbon
>  --------------
>  Helvetica-BoldOblique
>  Helvetica-Oblique
>  Helvetica
>  Helvetica-Bold
>  
>  2) Because Mac OS X bundles FreeType2 with Carbon
>  framework,
>  default fontconfig cache DB assumes the face ordering is
>  same with QuickDraw API.
>  
>  3) If an user installs yet-another FreeType2 without Carbon
>  framework and a client program using it, the fontfile
>  pathname and index obtained by fontconfig are no longer
>  reliable, because the face index might be different.
>  
>  4) As a result, the (yet-another) FreeType2 client program
>  is forced to open the font file and scan all faces by
>  themselves,
>  to identify the appropriate face index.
>  
>  * if I'm misunderstanding the problem, please let me know.
>  
>  ==============================================================
>  
>  What is the cause of the problem? Although I could not find
>  the reliable document how QuickDraw orders the faces in the
>  Suitcase, but it seems that QuickDraw picks the faces in
>  the
>  order of the header that lists the fragmented resources.
>  
>  Carbon-free FreeType2 Suitcase font driver reorders the
>  fragmented resources by their resource ids. If no
>  reordering,
>  the different face index ordering problem seems to be
>  solved.
>  
>  Why the reordering was implemented? It was designed for
>  PostScript Type1 font in Suitcase format. The content of
>  the
>  Type1 font is too large to store in single resource (in the
>  earliest architecture for Type1 in Suitcase - now it is not
>  essential limitation anymore), and fragmented into multiple
>  resources. To concatenate them properly in the restoration
>  of Type1 font data, the ordering of the fragmented
>  resources
>  by their ids is needed. ... but it is not essential for
>  sfnt
>  resource. Usually, 1 sfnt face is stored in 1 sfnt
>  resource,
>  not splitted to multiple resource fragments.
>  
>  Thus, I introduced a switch to enable/disable the
>  fragmented
>  resources. The switch is enabled only for PostScript Type1
>  in
>  Suitcase. An internal header (ftrfork.h) is modified, but
>  I think there is no impact except of the rogue client using
>  the internal header.
>  
>  Regards,
>  mpsuzuki
>  
>  
>  (13/12/20 14:04), Hin-Tak Leung wrote:
>  >   Hi,
>  >
>  >   I guess it is related with the
>  handling of Suitcase format
>  >   font.
>  >   Please let me check.
>  >
>  >   Regards,
>  >   mpsuzuki
>  >
>  >
>  > Thanks for the offer. If you are interested in that bit
>  of code snipplet in context, or the rest
>  > of it, it is in the middle of
>  >
>  > 
> https://svn.r-project.org/R/trunk/src/library/grDevices/src/cairo/cairoFns.c
>  >
>  > I have done git svn blame, but the commit log are
>  simply
>  > 'improve Cairo FT font detection on OS X' and
>  "workaround Mac FT face selection problem".
>  > the latter with a longer changelog/news item with
>  reference to a bug report, but not helpful:
>  >
>  > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=13463
>  >
>  > Hin-Tak
>  >
>  
>  




reply via email to

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