[Tikzdevice-bugs] Context and tikz?

[Charlie Sharpsteen]

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



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


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