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

[Hin-Tak Leung]

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.