[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
>