Re: [ft-devel] freetype on mac os X question/curious comments Re: Freetype-devel Digest, Vol 107, Issue 10

[Hin-Tak Leung]

If what you said is true, that must mean Mac OS X's shipped freetype
has some custom patch to reorder the font index?

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
 >