[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: |
Hin-Tak Leung |
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 04:38:43 +0000 (GMT) |
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
>