Just before the holiday, I asked the freetype developers what is the context
of these two comments about freetype in the code of R's grDevices:
======= R/src/library/grDevices/src/cairo/cairoFns.c around line 720 ==== /*
some FreeType versions have broken index support,
fall back to index 0 */
if (!FT_New_Face(ft_library,
(const char *) file, index, &face) ||
(index && !FT_New_Face(ft_library,
(const char *) file, 0, &face))) {
FcFontSetDestroy (fs);
#ifdef __APPLE__
/* FreeType is broken on OS X in that face index
is often wrong (unfortunately even for Helvetica!)
- we try to find the best match through enumeration.
And italic and bold are swapped */
if (style == 2) style = 1; else if (style == 1) style = 2;
=========================================================================
It turned out that the R developers are accumulating a few mistakes,
which over the years gradually "somewhat" cancel each others out, at
the expenses of other applications misbehaving on Mac OS X.
Freetype is shipped with, and part of Mac OS X.
The bottom line is that there are two ways of building freetype on Mac OS X,
one against the Carbon API (i.e. Mac OS Classic), and the other against
the POSIX API(i.e. modern unix systems). Apple have always shipped the
Carbon build.
The "problem", or "broken" issues experienced by R users are
because
the official binary of R has a private copy of freetype, and also
that is built differently from Apple's. The two copies both read and write
the public fontconfig's cache for fonts' metadata, with unpredictable
results to any application that uses fonts - which basically means every
GUI-based application.
The two builds differ by the "--with-old-mac-fonts" option, which
"allow Mac resource-based fonts to be used". They differ also on
treatments
of dfonts (an intermediate font format from the transition of
Classic to X). Helvetica, Times, Courier, Geneva, Monaco are still currently
shipped as dfonts on Mac OS X.
Here are the two correct ways of doing things:
1. put either build in /usr/local, and use just one of it dynamically,
for everything.
2. if a private copy of freetype needs to be bundled, and that this
private copy interacts with the public font cache, it has to be
a Carbon build.
The freetype developers also kindly offer a 3rd option
- e2d2b1544f24413fa62e0c845184b429eb227e9d -
made on 27th Dec, to make the POSIX build matches the behavior of
the Carbon build on caching dfonts. For those unfortunate people
who alternate between using different builds on a daily or even hourly
basis, forced upon them by application binary builders.
Somewhat related, I have finally gotten round to make two small bundles,
which replace the small cairo.dll/cairo.so' in the official
windows or Mac R binaries, to fix quite a few problems with them,
the first of which was reported almost a year ago. Just move the two
small files in the official binaries aside and replace them by these:
R-2.15.3-library-grDevices-libs-winCairo.zip
R.framework-Versions-2.15-Resources-library-grDevices-libs-cairo.tgz
The windows dlls had been tested and verified to fix the original
problem. BTW, it is quite a challenge to try to plot
R graphs with non-latin texts using English windows. (also posted).
I'll post the test results for Mac OS X when I get round to it. Those
should be easier to do.
YMMV. The move/rename can always be reverted if things don't work out.
The code mentioned above at the begining should be removed (and was
removed before building the bundle). It penalizes some mac R users who
build R himself/herself to end up with a broken build.
Hin-Tak Leung
2014-Jan-06 14:54 UTC
[Rd] [R] The URL for the replacement dll/so bundle - Re: 2 bugs in R's grDevices, and fixes. [SCL:4]
Hin-Tak Leung wrote: ...> Somewhat related, I have finally gotten round to make two small bundles, > which replace the small cairo.dll/cairo.so' in the official > windows or Mac R binaries, to fix quite a few problems with them, > the first of which was reported almost a year ago. Just move the two > small files in the official binaries aside and replace them by these: > > R-2.15.3-library-grDevices-libs-winCairo.zip > R.framework-Versions-2.15-Resources-library-grDevices-libs-cairo.tgz > > The windows dlls had been tested and verified to fix the original > problem. BTW, it is quite a challenge to try to plot > R graphs with non-latin texts using English windows. (also posted). > I'll post the test results for Mac OS X when I get round to it. Those > should be easier to do. > > YMMV. The move/rename can always be reverted if things don't work out.... Forgot to put the URL in. http://sourceforge.net/projects/outmodedbonsai/files/R/ The constituting library bundles are a bit further. ______________________________________________ R-help at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Hin-Tak Leung
2014-Jan-06 14:54 UTC
The URL for the replacement dll/so bundle - Re: 2 bugs in R's grDevices, and fixes.
Hin-Tak Leung wrote: ...> Somewhat related, I have finally gotten round to make two small bundles, > which replace the small cairo.dll/cairo.so' in the official > windows or Mac R binaries, to fix quite a few problems with them, > the first of which was reported almost a year ago. Just move the two > small files in the official binaries aside and replace them by these: > > R-2.15.3-library-grDevices-libs-winCairo.zip > R.framework-Versions-2.15-Resources-library-grDevices-libs-cairo.tgz > > The windows dlls had been tested and verified to fix the original > problem. BTW, it is quite a challenge to try to plot > R graphs with non-latin texts using English windows. (also posted). > I'll post the test results for Mac OS X when I get round to it. Those > should be easier to do. > > YMMV. The move/rename can always be reverted if things don't work out.... Forgot to put the URL in. http://sourceforge.net/projects/outmodedbonsai/files/R/ The constituting library bundles are a bit further.
Since R 3.0.3 is just around the corner and the problem is still there, here is a repost from around the new year. Hin-Tak Leung wrote:> Just before the holiday, I asked the freetype developers what is the context > of these two comments about freetype in the code of R's grDevices: > > ======= R/src/library/grDevices/src/cairo/cairoFns.c around line 720 ====> /* some FreeType versions have broken index support, > fall back to index 0 */ > if (!FT_New_Face(ft_library, > (const char *) file, index, &face) || > (index && !FT_New_Face(ft_library, > (const char *) file, 0, &face))) { > FcFontSetDestroy (fs); > > #ifdef __APPLE__ > /* FreeType is broken on OS X in that face index > is often wrong (unfortunately even for Helvetica!) > - we try to find the best match through enumeration. > And italic and bold are swapped */ > if (style == 2) style = 1; else if (style == 1) style = 2; > =========================================================================> > It turned out that the R developers are accumulating a few mistakes, > which over the years gradually "somewhat" cancel each others out, at > the expenses of other applications misbehaving on Mac OS X. > > Freetype is shipped with, and part of Mac OS X. > The bottom line is that there are two ways of building freetype on Mac OS X, > one against the Carbon API (i.e. Mac OS Classic), and the other against > the POSIX API(i.e. modern unix systems). Apple have always shipped the > Carbon build. > > The "problem", or "broken" issues experienced by R users are because > the official binary of R has a private copy of freetype, and also > that is built differently from Apple's. The two copies both read and write > the public fontconfig's cache for fonts' metadata, with unpredictable > results to any application that uses fonts - which basically means every > GUI-based application. > > The two builds differ by the "--with-old-mac-fonts" option, which > "allow Mac resource-based fonts to be used". They differ also on treatments > of dfonts (an intermediate font format from the transition of > Classic to X). Helvetica, Times, Courier, Geneva, Monaco are still currently > shipped as dfonts on Mac OS X. > > Here are the two correct ways of doing things: > > 1. put either build in /usr/local, and use just one of it dynamically, > for everything. > > 2. if a private copy of freetype needs to be bundled, and that this > private copy interacts with the public font cache, it has to be > a Carbon build. > > The freetype developers also kindly offer a 3rd option > - e2d2b1544f24413fa62e0c845184b429eb227e9d - > made on 27th Dec, to make the POSIX build matches the behavior of > the Carbon build on caching dfonts. For those unfortunate people > who alternate between using different builds on a daily or even hourly > basis, forced upon them by application binary builders. > > Somewhat related, I have finally gotten round to make two small bundles, > which replace the small cairo.dll/cairo.so' in the official > windows or Mac R binaries, to fix quite a few problems with them, > the first of which was reported almost a year ago. Just move the two > small files in the official binaries aside and replace them by these: >http://sourceforge.net/projects/outmodedbonsai/files/R/> R-2.15.3-library-grDevices-libs-winCairo.zip > R.framework-Versions-2.15-Resources-library-grDevices-libs-cairo.tgz > > The windows dlls had been tested and verified to fix the original > problem. BTW, it is quite a challenge to try to plot > R graphs with non-latin texts using English windows. (also posted). > I'll post the test results for Mac OS X when I get round to it. Those > should be easier to do. > > YMMV. The move/rename can always be reverted if things don't work out. > > The code mentioned above at the begining should be removed (and was > removed before building the bundle). It penalizes some mac R users who > build R himself/herself to end up with a broken build.
Since R 3.0.3 is just around the corner and the problem is still there, here is a repost from around the new year. Hin-Tak Leung wrote:> Just before the holiday, I asked the freetype developers what is the context > of these two comments about freetype in the code of R's grDevices: > > ======= R/src/library/grDevices/src/cairo/cairoFns.c around line 720 ====> /* some FreeType versions have broken index support, > fall back to index 0 */ > if (!FT_New_Face(ft_library, > (const char *) file, index, &face) || > (index && !FT_New_Face(ft_library, > (const char *) file, 0, &face))) { > FcFontSetDestroy (fs); > > #ifdef __APPLE__ > /* FreeType is broken on OS X in that face index > is often wrong (unfortunately even for Helvetica!) > - we try to find the best match through enumeration. > And italic and bold are swapped */ > if (style == 2) style = 1; else if (style == 1) style = 2; > =========================================================================> > It turned out that the R developers are accumulating a few mistakes, > which over the years gradually "somewhat" cancel each others out, at > the expenses of other applications misbehaving on Mac OS X. > > Freetype is shipped with, and part of Mac OS X. > The bottom line is that there are two ways of building freetype on Mac OS X, > one against the Carbon API (i.e. Mac OS Classic), and the other against > the POSIX API(i.e. modern unix systems). Apple have always shipped the > Carbon build. > > The "problem", or "broken" issues experienced by R users are because > the official binary of R has a private copy of freetype, and also > that is built differently from Apple's. The two copies both read and write > the public fontconfig's cache for fonts' metadata, with unpredictable > results to any application that uses fonts - which basically means every > GUI-based application. > > The two builds differ by the "--with-old-mac-fonts" option, which > "allow Mac resource-based fonts to be used". They differ also on treatments > of dfonts (an intermediate font format from the transition of > Classic to X). Helvetica, Times, Courier, Geneva, Monaco are still currently > shipped as dfonts on Mac OS X. > > Here are the two correct ways of doing things: > > 1. put either build in /usr/local, and use just one of it dynamically, > for everything. > > 2. if a private copy of freetype needs to be bundled, and that this > private copy interacts with the public font cache, it has to be > a Carbon build. > > The freetype developers also kindly offer a 3rd option > - e2d2b1544f24413fa62e0c845184b429eb227e9d - > made on 27th Dec, to make the POSIX build matches the behavior of > the Carbon build on caching dfonts. For those unfortunate people > who alternate between using different builds on a daily or even hourly > basis, forced upon them by application binary builders. > > Somewhat related, I have finally gotten round to make two small bundles, > which replace the small cairo.dll/cairo.so' in the official > windows or Mac R binaries, to fix quite a few problems with them, > the first of which was reported almost a year ago. Just move the two > small files in the official binaries aside and replace them by these: >http://sourceforge.net/projects/outmodedbonsai/files/R/> R-2.15.3-library-grDevices-libs-winCairo.zip > R.framework-Versions-2.15-Resources-library-grDevices-libs-cairo.tgz > > The windows dlls had been tested and verified to fix the original > problem. BTW, it is quite a challenge to try to plot > R graphs with non-latin texts using English windows. (also posted). > I'll post the test results for Mac OS X when I get round to it. Those > should be easier to do. > > YMMV. The move/rename can always be reverted if things don't work out. > > The code mentioned above at the begining should be removed (and was > removed before building the bundle). It penalizes some mac R users who > build R himself/herself to end up with a broken build.