[Tikzdevice-bugs] Arial and Other Things

[Lorenzo Isella]

Thanks for the through explanation. Looking forward to downloading and
installing tikzDevice as soon as it is ready.
Cheers

Lorenzo


On Mon, 2010-08-02 at 07:19 -0700, Charlie Sharpsteen wrote:
> 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
> > > >
> >
> >