[Tikzdevice-bugs] Context and tikz?

[mat]

Le 19. 04. 11 23:57, Charlie Sharpsteen a écrit :
> On Tue, Apr 19, 2011 at 2:13 PM, mat <matthieu.stigler at gmail.com 
> <mailto:matthieu.stigler at gmail.com>> wrote:
>
>     Charlie
>
>     Wonderful!! It's exactly what I needed! And you did it so fast,
>     congratulations!
>
>
> Just make sure you double-check that the text in your plot still looks 
> OK as I didn't have time to implement proper calculations of text size 
> for `metapost`---the device still falls back to using LaTeX which does 
> things differently from ConTeXt.
>
>     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!!!
>
>
> I'll look into the tinting---I left it at a default of 1 because I 
> don't fully understand how it works and would need to read up a little 
> bit more. I think you may be able to achieve a similar effect using 
> R's transparency settings---in my experiments an object printed with 
> 100% opacity was represented in the spot color channel by a solid 
> black shape which I presume indicates a full layer of ink. An object 
> set to 60% opacity was represented in a shade of gray which I would 
> presume means that less ink is being laid down.
>
> The part I am not sure about is if setting the opacity achieves the 
> same effect as tinting the color.
>
I unfortunately do not know this...
>
>     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?
>
>
> I'm not sure exactly what your code is trying to do---but feel free to 
> modify the functions any way you see fit!  The only important bit is 
> that the color definition has to accept a vector of three integers as 
> a valid input as that is what is emitted by the C code of the device. 
>  Automatically translating character strings into RGB values is just 
> a convenience for us humans.
well with actual code, color name within the plot has to be a R color 
name. However, if user defines his own, it does not work (it is 
character, but will create error with col2rgb)

>
>     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?
>
>
> The color definitions should get written into the tex file when 
> dev.off() is called. If you have an example of a plot where this isn't 
> happening, send it to me and I'll try to puzzle out what is going wrong.
code would be same as before:

library(tikzDevice)

metapost("try.tex")
define_metap_color("Red", 'red', 'Spot Color Red')
   op<-par(bg=11,bty="n", cex=2, mar=c(3,4,1,2)+0.1)
   x <- runif(100)
   plot(x, las=1, yaxt="n",tcl=0, ann=F, type="l", lwd=2, col="blue")
   grid(col="white", lty="solid", nx=NA, ny=NULL, lwd=2)
   lines(x, col="red", lwd=2)
   axis(1, tcl=0, labels=FALSE, col="black", lwd=1, 
at=as.Date(c("1970-01-01","2011-01-01")))
   axis(2, las=2, tick=FALSE)
   par(op)
dev.off()

does not produce the expected definitions, right?
>
>     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).
>
>
> I originally had the definition of black default to a spot color, but 
> I reversed it as I figured that it is already separated onto the K 
> channel of CMYK in the PDF.  It would be pretty easy to change back to 
> a spot color, just edit the appropriate entry in the `setTikzDefaults` 
> function in deviceUtils.R. I'm hoping that isolating colors 
> on separate channels in the PDF will be enough for a professional 
> printer to easily set up a run, but I am not a professional so I don't 
> know for sure :-)
>
>     Thanks so much!!
>
>
> You're welcome! Hope it helps with the book!
will be happy to send you the link soon!

Thanks again!!


>
> -Charlie