[Tikzdevice-bugs] Context and tikz?

mat matthieu.stigler at gmail.com
Wed Apr 20 01:37:21 CEST 2011


A few more thought (although it's getting really late :-))

Le 20. 04. 11 01:13, mat a écrit :
> 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...

intuitively, I consider it as the xcolor thing of
\colorlet{boxborder}{blue!60}

but technically not sure what it has really for impact on ink. I am not 
aware of the R transparency concept you evoked? Is is internal actually? 
Although, this suggest that an interesting (but I guess very 
complicated) option would to allow the user to define also in the R 
plots for normal one spotcolor and use its derivatives like in 
xcolor.... But the actual solution of letting users create thei own 
colors and make the matching themselves is not bad, and quite simpler 
for implementation!

Oh, one more note: actually, all the pantone colors are defined in terms 
of cmyk, not rgb. Maybe could be nice to add a fourth option when 
defining the colors to let the users set it up himself?



>>
>>     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 :-)
>>
I am very confused on this issue... the problem is that using pantone, 
we want to avoid any cmyk definition, so I don't know exactly how the 
"black" should be defined. Could be either as the gray used for text and 
so, or maybe need some special "separation" mention, to precise comes on 
other plate? I guess we will figure out at time of run :-)

thanks

>>     Thanks so much!!
>>
>>
>> You're welcome! Hope it helps with the book!
> will be happy to send you the link soon!
>
> Thanks again!!
>
>
>>
>> -Charlie
>



More information about the Tikzdevice-bugs mailing list