search

Sharpie / RTikZDevice

A R package for producing graphics output as PGF/TikZ code for use in TeX documents.
32 stars 36 forks source link

Distance of tick labels different for x and y axis #49

Closed sebschub closed 12 years ago

sebschub commented 12 years ago

I am rather new to R so forgive me if this is obviously stupid. Using the following example with tikzDevice 0.6.2:

library(tikzDevice)

x <- 1:10
y <- sin(x)

tikz("test.tex",standAlone=TRUE)
plot(x,y)
dev.off()

pdf("test2.pdf")
plot(x,y)
dev.off()
q()

I get rather equal distances of the tick labels to the ticks for x and y axes. The tikzdevice output (when run through pdflatex) has different spacings when comparing x and y axis. The space between ticks and labels of the x axis are larger than for the y axis. Is this expected? What can I do?

Sharpie commented 12 years ago

I get rather equal distances of the tick labels to the ticks for x and y axes. The tikzdevice output (when run through pdflatex) has different spacings when comparing x and y axis. The space between ticks and labels of the x axis are larger than for the y axis. Is this expected?

Unfortunately, this is expected. It has to do with some "magic numbers" defined in the R graphics device header GraphicsDevice.h---here are the relevant entries:

/* I hate these next three -- they seem like a real fudge
 * BUT I'm not sure what to replace them with so they stay for now.
 */
double xCharOffset;         /* x character addressing offset - unused */
double yCharOffset;         /* y character addressing offset */
double yLineBias;         /* 1/2 interline space as frac of line height */
double ipr[2];          /* Inches per raster; [0]=x, [1]=y */
/* I hate this guy too -- seems to assume that a device can only
 * have one font size during its lifetime
 * BUT removing/replacing it would take quite a lot of work
 * to design and insert a good replacement so it stays for now.
 */
double cra[2];          /* Character size in rasters; [0]=x, [1]=y */

As far as I can tell, the culprit is the yLineBias parameter, which the tikzDevice currently leaves at 0. From the comments, it looks like this has something to do with leading. If this is true, than for a "standard" LaTeX article set at 10pt font with 12pt leading the value of yLineBias should be (12pt / 2) / 10pt or 0.6 according to the comment.

However, using 0.6 makes the plot look wayyyy worse. So, currently the tikzDevice leaves the value at 0 because it looks "good enough".

What can I do?

I tried plugging in the magic numbers from the PDF device:

/* Character Addressing Offsets */
/* These offsets should center a single */
/* plotting character over the plotting point. */
/* Pure guesswork and eyeballing ... */
dd->xCharOffset =  0.4900;
dd->yCharOffset =  0.3333;
dd->yLineBias = 0.2;

The results look better to me and the visual diffs in the testsuite don't look too terribly bad. Interestingly, only margin text in base graphics are affected and Grid graphics show no change at all.

I just pushed a development build, 0.6.2-21-4508ecc, to R-Forge. Binaries should be available in about two days. Or, you can check out the source and use it immediately.