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 17:06:19 +0900
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5

Hi all,

Just I've committed the patch.

Regards,
mpsuzuki

On 12/27/2013 03:39 PM, suzuki toshiya wrote:
> 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
>>   >
>>   
>>   
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 




reply via email to

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