[Tikzdevice-bugs] metapost device: problem with calculating font space?
Matthieu Stigler
matthieu.stigler at gmail.com
Tue Apr 26 16:16:21 CEST 2011
Le 25/04/2011 21:46, Charlie Sharpsteen a écrit :
>
> * On Mon, Apr 25, 2011 at 10:24 AM, mat
> <matthieu.stigler at gmail.com <mailto:matthieu.stigler at gmail.com>>
> wrote:
>
> Le 22. 04. 11 21:59, Charlie Sharpsteen a écrit :
>
> sorry, it's just a stupid error from me: I run usually R CMD
> INSTALL, and tried this instead of make install!! Once this used
> (after however a few tricks changing chown and chmod on the R
> created files) it works!!! Indeed, plots are much better now, and
> space better organized, thanks!!!!!
>
>
> Glad it helped!
>
>
> I tried to adapt the metap function for my own needs (define a
> single spot colors and then its "childs") but got confused, as the
> script you wrote is quite complex!!! Idea is:
> -define.metap.color should just define generic spot color, no real
> color will be associated to it. Would format just
>
> \definecolor[PantoneBlue][c=1, m=0.58,y=0,k=0.29]
>
> -define.metap.tint should define the real colors used, which are
> just tints (%) of the defined spot colors. Would defined just:
>
> \definespotcolor[PantoneBlueSixtySpot][PantoneBlue][p=0.6,e=Pantone 294 C]
>
>
> See: metap_tint <- function(color_name, color_ref, p=1) {
> # color_name: A name for the color. Should only contain letters.
> # color_ref: The spot color it is based on
> # p: the "tint" associated
> if ( grepl('[^a-zA-Z]', color_name) ) {
> stop("MetaPost color names cannot contain any characters other
> than ASCII letters!")
> }
>
> if(!color_ref%in%sapply(getOption('metapColors'), function(x)
> x$color_name)){
> stop("color_ref not defined!")
> } else {
> color_ref_detail <-
> getOption('metapColors')[sapply(getOption('metapColors'),
> function(x) x$color_name)==color_ref][[1]]
> }
>
> return(
> structure(
> list(color_name = color_name, color_ref=color_ref, spot_name
> = color_ref_detail$spot_name, p=p),
> class = 'metap_tint'
> )
> )
>
> }
>
>
> and its format counterpart:
>
> format.metap_tint <- function(color, ...) {
> # Generates ConTeXt code for defining colors and spot colors.
> color_def <- c(
> "\n\\definespotcolor\n\t",
> paste("[", color$color_name, "]\n\t", sep = ''),
> paste("[", color$color_ref, "]\n\t", sep = ''),
> paste("[p=", color$p, ", e=", color$spot_name, "]\n\t", sep
> = '')# sprintf("[p=1,e=%s]\n", color$spot_name)
> )
>
> return( color_def )
> # list(color_name = color_name, spot_name =
> color_ref_detail$spot_name, p=p),
> # class = 'metap_tint'
> }
>
>
> But then I got confused where each color should be defined and
> exported :-( Any clear idea on how I should proceed?
>
> Thanks!!
>
> Matthieu
>
>
> The problem with adding tint is that we have to pay attention to the
> information received by the C-level routines of the device which is
> all we have available to search the list of user defined colors for a
> matching name. What the C code receives is documented in the R
> Internals manual:
>
> http://cran.r-project.org/doc/manuals/R-ints.html#Colours
>
> We get four pieces of information--- R, G, B and Alpha (which is used
> to denote transparency). Adding tint would require a fifth piece
> of information to be sent to the C routines which at the moment does
> not appear to be possible unless the R graphics engine was re-written
> to support alternative color models that could contain more
> information than RGBA.
>
> An alternative would be to re-purpose the Alpha channel to denote tint
> instead of transparency. Then we would be able to map the A component
> of RGBA to tint, but we would loose the ability to specify
> transparency. If you were willing to make this tradeoff, then I think
> the following would need to happen:
>
> In metapColors.R:
>
> * col2rgb would need to be called with `alpha=TRUE` so that the
> alpha information is stored in rgb_value vectors.
> * format.metap_color would need to set `p` according to the new
> alpha component, rgb_value[4]. Divide it by 255 to get a percentage.
> * rgb2col would need to be modified to store alpha as well by
> adding it into the `rgb` call.
>
> In metapDevice.c:
>
> * In MetaP_DrawStyle the else statement of the check on R_OPAQUE
> (line 1442) should be eliminated.
> * MetaP_GetColorName will have to be modified to pass a vector of
> RBGA instead of just RGB to get_or_set_color in metapColors.R
> (line 1579).
>
> Plus squashing the odd bug that will pop up :)
>
> -Charlie
well, actually my idea was a little bit different: the mechanism as you
did works perfectly fine, so I would not modify a lot the approach. The
underlying idea, as I understood it, is that one lets the user define
himself all the colors he will want to be mapped into spotcolor. That
means the question of what is p=0.5 of Pantone x is left to the user,
and the metapost() and meta.color() only see that the defined colors are
matched afterwards to the spotcolor specs, by defining the relevant
\definecolor.
It is clear an (highly) interesting extension would be to be able only
to specify rgb color of one spotcolor, and let metapost() find out what
is the corresponding rgb values... But if we say user defines himself
how the spotcolor and his tints are shown in the screen, then there are
only a few modifications needed to make the use of the tints available....
Maybe by:
-What format.metap_color () does is perfectly fine: export color, to
list. But then problem is it gets every time its own definition... In
one way it would describe what format.metap_tiny() would ideally do:
define color, export to list... The best in my opinion would then to
allow for p and color ref
-Add a metap_spotcolor: is not matched by any actual color, just leads
to def of the spotcolor
-modifying format.metap to:
-write only once \definecolor[PantoneBlue][c=1, m=0.58,y=0,k=0.29]
for parent color
-write for every metap color line
\definespotcolor[PantoneBlueHundredSpot][PantoneBlue][p=1,e=Pantone 294 C]
I don't know if I am very clear... but do you understand the approach I
am describing? Does it makes sense to you?
Thanks!!
Mat
More information about the Tikzdevice-bugs
mailing list