[Tikzdevice-bugs] Context and tikz?

[Charlie Sharpsteen]

On Tue, Apr 19, 2011 at 4:37 PM, mat <matthieu.stigler at gmail.com> wrote:

>   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!
>

It would be awesome to implement custom color spaces, but the obstacle is
that R is hardwired to use RGB on a very basic level. The way R passes color
information to graphics devices is through single C variables of type `int`
inside a R_GE_gcontext "object" that is basically the C-level representation
of all the stuff you can set with `par`:

typedef struct {
   ...
   int col; /* pen color */
   int fill;  /* fill color */
   ...
} R_GE_gcontext;


`int` variables are 32 binary digits long which means they can be subdivided
int 4 equal sections of 8 bits. 8 bits can store 2^8 = 256 values, so out of
a single integer we can split out four components: R, G, B and Transparency
(also called Alpha).  Each of these components can take on a value of 0-255.
 Or, we can divide by the total of 255 and treat them as 255 discrete values
between 0 - 100%.  So, with R, G and B specifying the color the only thing
that is really left over to hold tinting information is the Alpha value.

So, when the C end of the device wants to know the name of a color, all it
has are RGB values to offer for matching against the list of colors that
have been defined. So, we're kind of stuck with RGB unless we:

   - Implement functions that can convert between RGB and CMYK or other
   color spaces. These are well defined, but complicated enough that the work
   would take more than a weekend :-)  The last 13 pages of the xcolor manual (
   http://ctan.mackichan.com/macros/latex/contrib/xcolor/xcolor.pdf)
   describe the math involved.


   - Implement an alternate color model for R and provide a new set of
   functions like `par` to control it. But this would be a little weird as
   graph code would have to be customized for the output graph---i.e. code that
   produces a nice looking graph on the `pdf` device wouldn't "just work" on
   the `metapost` device.

There are probably other ways around this, but it would take some time and
clever thinking to work out an elegant approach.


 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?
>

I think Pantone inks are mixed from something like 13 different pigments
according to a chemical formula and the CMYK values are just an
approximation. Some of their inks, such as metallic golds, have no CMYK
equivalent. The only thing that matters is which parts of the graphic need
to be printed with a given ink and how much ink needs to be laid down.  So
we can define a color using RGB for viewing and then as long as that color
also exists by it's self on a separate channel, it should be available for
printing with whatever ink is required. You should even be able to do dirty
tricks like define it as "red" in RGB, but then print it using a bright blue
Pantone ink.

  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 :-)
>

Well, the idea is that the CMYK definition puts four channels of color into
the document-- C Y M and K. All the black elements of your graphics are
confined solely to the K channel, so the printer should be able to run the
job using just the information on the K channel along with whatever spot
color channels you are using.  If this isn't the case, you can easily change
the default definition of black so that it is a spot color---the default is
the "#000000" entry in the deviceUtils.R file. Or, calling
`define_metap_color` with `dev_num` of -1 will also alter this global list:

define_metap_color("Black", c(0, 0, 0), spot_name = "Pantone Black", dev_num
= -1)



>  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
>
>
>
>