[Tikzdevice-bugs] Arial and Other Things

Charlie Sharpsteen chuck at sharpsteen.net
Mon Aug 2 16:19:34 CEST 2010


Hi Lorenzo,

Thanks again for submitting this example.  I actually came across this
bug earlier this year and thought I had solved it:

  http://github.com/Sharpie/RTikZDevice/issues/1

But your example led Cameron and I to re-examine the way string widths
and metrics are calculated and we discovered a subtle bug that I think
was the root cause of this issue.  The problem is that the tikzDevice
must calculate widths and font metrics for arbitrary strings of LaTeX
such as:

$\\alpha$

Which is 9 characters long in an R script but only 1 character when
typeset.  The solution we use is to compile a small "stub" of a LaTeX
file which dumps the character metrics to a log file.  We then scan
the log file and retrieve the numbers we need.  This approach came for
a post Cameron made to comp.text.tex:

  http://groups.google.com/group/comp.text.tex/browse_thread/thread/1846e8c3cb8edb5b/4fbcb097aa22b31b?lnk=gst&q=cameron+bracken#4fbcb097aa22b31b

We have used Heiko Oberdiek's solution with slight modifications.  The
problem is that the template provided in that post did not include a
\begin{document} statement.  Apparently, there are some font setup
things related to the \renewcommand{\rmdefault}{phv} you tried that
don't happen unless \begin{document} is in the source file.  We never
noticed because this issue did not affect Computer Modern or alternate
font packages like Mathpazo.
So, \begin{document} has been added to the font metrics stub and it
appears to be solving the problem.  I have added it to a build of
0.5.0 that is now a candidate for being the version that will be
published to CRAN.  You should be able to install it from R-Forge in
the next couple of days once it finishes building:

install.packages( 'tikzDevice', repos = 'http://r-forge.r-project.org' )

Thanks again for taking the time to make this bug report!


P.S.

In response to your earlier question about setting fonts in a similar
fashion to other R graphics devices such as pdf(): we don't allow this
as Cameron mentioned.  The reason is that we want the fonts used in
production of graphics to be the exact same fonts that are used to set
the text in a LaTeX paper.  If we allowed R to choose fonts, the
graphic would end up being designed using fonts such as Helvetica.
However, when the user goes to typeset their paper and specifies
Helvetica, LaTeX may use a Helvetica clone such as Nimbus or Heros.
These fonts are designed to look the same as Helvetica, but there are
subtle differences.  The end effect would spoil the typographic
harmony we are trying to achieve with this device.  See this page for
more information on the fonts LaTeX uses:

  http://www.tug.dk/FontCatalogue/helvetica/

So- all decisions concerning are left to LaTeX.  I do agree that we
need to hammer out an easier way of allowing users to specify font
choices.  This will probably come when we figure out what to do about
UTF8 support as it ties into issues with LaTeX fonts.

-Charlie

On Fri, Jul 30, 2010 at 5:29 AM, Lorenzo Isella
<lorenzo.isella at gmail.com> wrote:
>
> I see. Would it be possible to find out more about how you fixed the
> plot (i.e.: is there a patch or something I can use as a temporary quick
> and dirty solution)?
> Last but not least: once this glitch has been ironed out, will it be
> communicated via this mailing list?
> Cheers and have a nice weekend
>
> Lorenzo
>
>
> On Thu, 2010-07-29 at 16:56 -0600, Cameron Bracken wrote:
> > Hi Lorenzo-
> >
> > We specifically don't allow the user to set the font family in the
> > traditional way because we expect the user to do that though LaTeX or
> > the document header options. Unfortunately this is directly related to
> > the previous problem:
> >
> > There is definitely a bug in selecting fonts. It seems as though
> > Computer Modern was always used regardless of the font choice but I
> > never noticed because I used fonts with very similar metrics to cm.
> > Anyway, I hacked the code and got it to work (you can see from the
> > attached plot), but there is no general solution yet.  We will have to
> > figure out how we want to approach this problem from a user
> > perspective since the expected methods do not work.
> >
> > -Cameron
> >
> >
> >
> > On Thu, Jul 29, 2010 at 12:40 PM, Lorenzo Isella
> > <lorenzo.isella at gmail.com> wrote:
> > > On Tue, 2010-07-27 at 10:28 -0700, Charlie Sharpsteen wrote:
> > >> Thanks for taking the time to put together this example Lorenzo, I
> > >> will play with it and see if I can't figure something out.
> > >
> > > Hi,
> > > In case it matters, please take a look at
> > >
> > > http://bit.ly/9ATz9V
> > >
> > > where it is explained how to use arial fonts in R. I tried the
> > > suggestion (BTW, the path is /usr/share/fonts/truetype/msttcorefonts/ on
> > > my Ubuntu machine).
> > > The recipe allowed me to use arial fonts in ggplot2 plots (where I was
> > > using simply pdf() and not tikzDevice to generate the pdf file).
> > > I do not know if I can specify the font family in a tikzDevice call, but
> > > you probably do ;-).
> > > Cheers
> > >
> > > Lorenzo
> > >
> > > _______________________________________________
> > > Tikzdevice-bugs mailing list
> > > Tikzdevice-bugs at lists.r-forge.r-project.org
> > > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/tikzdevice-bugs
> > >
>
>


More information about the Tikzdevice-bugs mailing list