[Rd] 2 bugs in R's grDevices, and fixes.

[Hin-Tak Leung]

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.