[Tikzdevice-bugs] Context and tikz?

[mat]

Charlie

Wonderful!! It's exactly what I needed! And you did it so fast, 
congratulations!

The way you did it is really nice, since it seems the color def are not 
rewritten each time, which allows one to set them "globally". Now for 
the pentone color: as I understood it, the most standard case will be 
one spot color, used with different "tints" (ie percentage). For my case 
for example, it implied this:
\definecolor[PantoneBlue][c=1, m=0.58,y=0,k=0.29]

\definespotcolor[PantoneBlueHundredSpot][PantoneBlue][p=1,e=Pantone 294 C]
\definespotcolor[PantoneBlueSixtySpot][PantoneBlue][p=0.6,e=Pantone 294 C]
\definespotcolor[PantoneBlueFourtySpot][PantoneBlue][p=0.4,e=Pantone 294 C]
....

So a function like:
define_metap_tint( Rname='PantoneBlueFourty', colRef='Pantone 294 C', 
tint=0.4)

could be very useful!!! One more remark: as the code stands now, it 
allows only "R color names" since:
  grDevices::col2rgb(rgb_value)
only accept R color names. I changed for my purpose in:
if ( is.character(rgb_value) ) {
     if(rgb_value%in%colors()) {
         rgb_value <- grDevices::col2rgb(rgb_value)
} else {
       rgb_value <- grDevices::col2rgb(eval(parse(text=rgb_value))))
}
#might be wrong as I'm writing trying to remember

would something like this make sense?

Finally, the colors defs:
  \definecolor
    [Red]
    [r=1.000,g=0.000,b=0.000]
did not appear in the tex file? Is this expected? Could it be made 
automatical?

I think as it stands the feature is already nice, so it can only improve 
:-) And sure, adding the possibility to have spotcolors in R with 
tikzDevice is a really nice feature, great you intend to work on it!!!!!

Finally, yes I hope it will work for the printer. Would be nice to find 
some professional but unfortunately all the graphical designer we 
consulted have no idea of these low-levels manipulation, and none could 
understand the "hacking" done. So we can't really know until printing 
whether fine or not ( a big issue is whether the black color should also 
be written with such "separation" code, so that the printer put black on 
second scale... no idea is necessary or not).

Thanks so much!!


Le 19. 04. 11 04:16, Charlie Sharpsteen a écrit :
> Hi Mat,
>
> On Mon, Apr 18, 2011 at 6:54 AM, Matthieu Stigler 
> <matthieu.stigler at gmail.com <mailto:matthieu.stigler at gmail.com>> wrote:
>
>     Charlie
>
>     Thanks a lot for actually looking at my r-list e-mail, and trying
>     to sort out, much appreciated!!!
>
>     So for the bad news: too bad indeed, hoped it would be possible,
>     and would have been an elegant solution (current solution is to
>     hack the .ps, very ugly).
>
>     For the good news, I could not evaluate how good they are :-) I'm
>     getting more and more confused, discovering new Tex-like things at
>     each e-mail :-) Basically, your suggestion is: should use context
>     which should entail METAPOST figure code, right? And METAPOST code
>     could be generated from the tikz one? I am totally fine to forget
>     about features like raster or polypath, but you think conversion
>     from tikz to metapost would be easy? Just watched the tikz and
>     metapost code and still seemed quite different, no? If it would be
>     done once, I guess it's on the far roadmap? We are in the
>     situation where we need to be able to convert to pentone our R
>     plots in a few days :-(
>
>
> Sorry for the confusion. What I ment is that the tikzDevice could be 
> modified to produce METAPOST code instead of TikZ code because the 
> syntax of the two languages is similar. Till Tantau, the creator of 
> TikZ, was inspired by METAPOST and adopted a lot of ideas such as the 
> path construction syntax. Over the weekend, I took a stab at 
> re-building the tikzDevice as a METAPOST device. The results are 
> available in the `experimental/metapost` branch of the git repostiory:
>
> https://github.com/Sharpie/RTikZDevice/tree/experimental/metapost
> https://github.com/Sharpie/RTikZDevice/tarball/experimental/metapost
>
> To use this branch, will need to install 'roxygen' and run `make 
> install` inside the package source. There are a few caveats with this 
> branch:
>
>     * The new device has full support for filling and
>       drawing---however I didn't have time over the weekend to
>       translate the text handling routines. Font metrics are still
>       calculated by LaTeX instead of ConTeXt which causes some of the
>       text strings to be mis-aligned.  Additionally, there is no
>       support for applying colors or font sizes to text.
>     * There is no documentation.
>     * If we do add METAPOST support to a later release (which I hope
>       we will!), it may have a completely different interface and
>       functionality.
>
> After installing the package, a new `metapost` device will be available:
>
>     metapost('my_plot.tex')
>
> The output must be typeset with ConTeXt MKIV (I did my testing with 
> the version from TeX Live 2010). If you have not run ConTeXt before, 
> you may need to do some set up:
>
>     luatools --generate
>     context --make
>
> The `metapost` device produces output similar to `tikz` in the 
> `standAlone = TRUE` mode, so the resulting `.tex` files are compiled 
> directly:
>
>     context my_plot.tex
>
> I also re-wired the way colors are handled so that spot colors can be 
> defined:
>
>     metapost('spot_colors.tex')
>     % Define a spot color
>     define_metap_color("Red", 'red', 'Spot Color Red')
>
>     plot(BOD, col = 'red')
>
>     dev.off()
>
> The `define_metap_color` function takes three parameters:
>
>     * The first is a string containing only letters, no spaces or
>       numbers, that is used as the color name in the TeX output.
>
>     * The second is a string containing a R color name, or a RGB
>       vector c(r,g,b) containing the rgb value as numbers in the range
>       0-255
>
>     * The third parameter is the spot color name and is optional. If
>       used, it will cause the creation of a spot color channel that
>       will be named using the contents of the string.
>
> For example, the call used above would cause the following color 
> definition in the ConTeXt file:
>
>      \definecolor
>        [Red]
>        [r=1.000,g=0.000,b=0.000]
>
>      \definespotcolor
>        [RedSpot]
>        [Red]
>        [p=1,e=Spot Color Red]
>
>
> All the points in the BOD graph will be defined using the color 
> RedSpot and the resulting PDF output should have a new color channel 
> named "Spot Color Red" that contains the information for the points. 
>  If you want to use PANTONE colors, you will have to look up the color 
> names in a PANTONE swatch book and compute (or guess) the 
> corresponding RGB values:
>
>     define_metap_color('PantoneBlue', 'blue', 'PANTONE 308 CV')
>
>
> Now, this will assign all colors matching R's RBG vale for 'blue' to 
> the 'PANTONE 308 CV' spot color channel. I don't know if assigning 
> colors to spot channels is all that is required to do a professional 
> print job, so I would definitely encourage consulting a professional 
> before attempting to use any of these PDFs in a large scale print job.
>
> I don't know if this experiment will help you or not, but it gave me 
> some good ideas on where to take the tikzDevice for future releases. 
>  It would be nice to add color separation to our list of features someday!
>
> -Charlie
>
>     Thanks so much, your help is very precious!
>
>     Mat
>