[Tikzdevice-bugs] Context and tikz?

[Matthieu Stigler]

Le 20/04/2011 05:08, Charlie Sharpsteen a écrit :
> ---------- Forwarded message ----------
> From: Charlie Sharpsteen<chuck at sharpsteen.net>
> Date: Tue, Apr 19, 2011 at 8:08 PM
> Subject: Re: [Tikzdevice-bugs] Context and tikz?
> To: mat<matthieu.stigler at gmail.com>
>
>
>
>
> On Tue, Apr 19, 2011 at 4:13 PM, mat<matthieu.stigler at gmail.com>  wrote:
>
>>   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>  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 did some quick reading and it looks like normal transparency is
> equivalent to tinting *only when* there is nothing underneath the
> transparent element. However, PDF supports 12 different methods (!!!) of
> handling transparency---one of which may be equivalent to tinting. Tinting
> could always be implemented using ConTeXt parameters---but this would
> involve writing a lot more code as we would need to support defining a
> seperate color for each tint.  Changing the PDF transparency method, which
> is defined as "normal"  in metapDevice.c, is a lot easier:
>
>   printOutput(tikzInfo, " withcolor transparent(  \"normal\"  , %4.2f,
> \\MPcolor{%s});\n",
>     alpha / 255.0, color_name);
>
>
>
>
>>    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)
>>
> Ahh, I think there may be some confusion. Consider the color definitions
> below:
>
> define_metap_color("FiretruckRed", "red")
> define_metap_color("OceanBlue", c(0, 0, 160), "Blue Spot Color")
>
> The first parameter, "FiretruckRed", is not an R color---it is the name we
> will assign to this color at the ConTeXt level.  The color R cares about is
> in the second parameter which may be a string such as "red" or a RGB vector
> such as c(0, 0, 160).  Strings such as "red" get expanded by `col2rgb` into
> their vector equivalents: c(255, 0, 0). These vectors are then encoded as a
> hexadecimal string so they can easily be used as names for values in an R
> list. In the case of "red", it gets transformed into c(255, 0, 0) and then
> to "#FF0000".
>
> After this expansion, the list of defined colors ends up looking like:
>
> list(
>    "#FF0000" = metap_color( "FiretruckRed", c(255, 0, 0) ),
>    "#0000A0" = metap_color( "OceanBlue", c(0, 0, 160), "Blue Spot Color" )
> )
>
> At the C level, when R is drawing a graphic it sends three integers
> representing the Red Green and Blue components of the color that is being
> used.  The MetaPost device needs to know the name ConTeXt will eventually
> use for these colors, so it calls back to R and passes the RGB vector.  Say
> you use:
>
> plot(1, col = 'red')
>
> The C routines receive something like:
>
> R_RED = 255; R_GREEN = 0; R_BLUE = 0
>
> The C code of the metapost device then calls the R function
> get_or_set_color(c(255, 0, 0)) which transforms c(255, 0, 0) to the
> hexadecimal string "#FF0000" and looks it up in the color list, finds an
> entry and returns "FiretruckRed" as the color name to be written into the
> output.  If this function was passed c(0, 0, 160) it would hash to "#0000A0"
> and return "OceanBlue". If it was passed the vector for green, c(0, 255, 0)
> it would find that the entry in the color list for "#00FF00" was NULL. In
> this case `get_or_set_color` creates a value in the list, assigns it a
> generic name "MetaPostColorA" and returns that.
>
> When the device is closed, it writes out the color definitons for each
> components in the color list. For non-spot colors like "FiretruckRed" it
> just writes a \definecolor[FiretruckRed].  For spot colors like "OceanBlue"
> it first defines the RGB color with:
>
>      \definecolor[OceanBlue]
>
> This is the color a PDF viewer will use to show the document.  It then
> defines a spot color "OceanBlueSpot" and replaces all instances of
> "OceanBlue" in the document with "OceanBlueSpot". "OceanBlue" will still
> contain the color used for viewing, but there will be a new spot color
> channel that can be used in printing.
>
>
ok, thanks for info. My point was simply that now you can't use a custom 
name color:



## Custom color name: no!
myCol<-rgb(192,203,227,maxColorValue=255)

   metapost('spot_colors2.tex')

     define_metap_color("Red", 'myCol', 'Spot Color Red')

     plot(BOD, col = 'myCol')

     dev.off()
>>
>>
>>>   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?
>>
> Yes, it is not defining red like it should have. I pushed a small tweak to
> metapColors.R which I think fixes the problem.
>
>
it did!

Now two things I would suggest that could greatly improve the features:
-Allow custom cmyk def of spot:  define_metap_color("Red", 'red', 'Spot 
Color Red', cmyk=c(0,0.2,0.03,1)). This is because pantone needs 
ultimately a cmyk def
-Allow tints: define_metap_tint(Rname="Red", parent='red', pantname="a" 
p=0.8), which would write:
something like:

   metapost('spot_colors.tex')

     define_metap_color("PantoneBlue", 'red', 'PANTONE 294 C') # adds 
both \definecolor[PantoneBlue] and 
\definespotcolor[PantoneBlueSpot][PantoneBlue][p=1,e=PANTONE 294 C]
     define_metap_tint(Rname="blue", parent="PantoneBlue", 
pantName='PantoneBlueEighty', p=0.8) # adds only 
\definespotcolor[PantoneBlueEightySpot][PantoneBlue][p=0.8,e=PANTONE 294 C]

     plot(BOD, col = 'red')
     lines(BOD, col='blue')

     dev.off()

you see the idea? Would be great!!!
>>
>>    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
>>
>>
>>
> _______________________________________________
> 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