Steve Checkoway | 7 Aug 22:25 2010

Problem with colors

If I use the following MP program, I get a red X exactly as I would expect. If I change red to any of cyan,
magenta, or yellow, I get an error. I'm not entirely sure what I'm doing wrong.

If I change the \color{yellow} to \color[rgb]{1,1,0} then I can get yellow text. (Presumably, I can do the
same with cyan or magenta, but I didn't test it.)

$ cat foo.mp
prologues := 3;
outputtemplate := "%j.mps";
verbatimtex
%&latex
\documentclass{article}
\usepackage{color}
\begin{document}
etex
beginfig(1);
label(btex \color{red}X etex, origin);
endfig;
end

$ cat foo.log
This is MetaPost, version 1.208 (kpathsea version 5.0.0) (mem=mpost 2010.07.27)  7 AUG 2010 13:19
**foo
(./foo.mp
>> cmyk
! Improper type.
<to be read again> 
                   (
<argument> withcolor.cmyk(
                          0,0,1,0)
(Continue reading)

Taco Hoekwater | 8 Aug 07:39 2010

Re: Problem with colors

On 08/07/2010 10:25 PM, Steve Checkoway wrote:
> If I use the following MP program, I get a red X exactly as I would expect. If I change red to any of cyan,
magenta, or yellow, I get an error. I'm not entirely sure what I'm doing wrong.
>
> If I change the \color{yellow} to \color[rgb]{1,1,0} then I can get yellow text. (Presumably, I can do the
same with cyan or magenta, but I didn't test it.)

Can you post the .mpx file contents? I cannot predict what
in the dvi (and therefore in the mpx) file.

Best wishes,
Taco
--
http://tug.org/metapost/

Steve Checkoway | 8 Aug 15:12 2010

Re: Problem with colors


On Aug 7, 2010, at 22:39 , Taco Hoekwater wrote:

> On 08/07/2010 10:25 PM, Steve Checkoway wrote:
>> If I use the following MP program, I get a red X exactly as I would expect. If I change red to any of cyan,
magenta, or yellow, I get an error. I'm not entirely sure what I'm doing wrong.
>> 
>> If I change the \color{yellow} to \color[rgb]{1,1,0} then I can get yellow text. (Presumably, I can do
the same with cyan or magenta, but I didn't test it.)
> 
> Can you post the .mpx file contents? I cannot predict what
> in the dvi (and therefore in the mpx) file.

Sure.

% Written by metapost version 1.208
begingroup save _p,_r,_s,_n; picture _p; _p=nullpicture;
string _n[];
vardef _s(expr _t,_f,_m,_x,_y)(text _c)=
  addto _p also _t infont _f scaled _m shifted (_x,_y) _c; enddef;
_n0="cmr10";
_s("X",_n0,1.00000,0.0000,0.0000, withcolor cmyk(0,0,1,0)
);
setbounds _p to (0,0.0000)--(7.4720,0.0000)--
 (7.4720,6.8078)--(0,6.8078)--cycle;
_p endgroup
mpxbreak

It looks like that should be withcmykcolor (0,0,1,0).

(Continue reading)

Troy Henderson | 8 Aug 15:19 2010
Picon

Re: Problem with colors

Replace

label(btex \color{red}X etex, origin);

with

label(btex X etex, origin) withcolor red;

or

label(btex X etex, origin) withcmykcolor (1,0,0,0); % This gives cyan

There appears to be no built-in synonyms (although you could easily write your own) for the base cmykcolors cyan, magenta, and yellow.  Black is already synonymous with the RGB (0,0,0).  Specifically, you could do

cmykcolor cyan,magenta,yellow;
cyan:=(1,0,0,0);
magenta:=(0,1,0,0);
yellow:=(0,0,1,0);

label(btex X etex,origin) withcmykcolor cyan;

---

Troy Henderson

--
http://tug.org/metapost/
Taco Hoekwater | 8 Aug 15:43 2010

Re: Problem with colors

On 08/08/2010 03:12 PM, Steve Checkoway wrote:
>
> % Written by metapost version 1.208
> begingroup save _p,_r,_s,_n; picture _p; _p=nullpicture;
> string _n[];
> vardef _s(expr _t,_f,_m,_x,_y)(text _c)=
>    addto _p also _t infont _f scaled _m shifted (_x,_y) _c; enddef;
> _n0="cmr10";
> _s("X",_n0,1.00000,0.0000,0.0000, withcolor cmyk(0,0,1,0)
> );
> setbounds _p to (0,0.0000)--(7.4720,0.0000)--
>   (7.4720,6.8078)--(0,6.8078)--cycle;
> _p endgroup
> mpxbreak
>
> It looks like that should be withcmykcolor (0,0,1,0).

Or it could be withcolor (0,0,1,0), the problem was that
the macro 'cmyk' is undefined.

> Someone offlist suggested that I try \usepackage[usenames,dvipsnames]

There is also a dvipsnam.mp (part of mfpic) which defines the
macro cmyk, or you could add this definition somewhere in your
mp input file (but before the label, of course):

   vardef cmyk (expr c, m, y, k) = (c, m, y, k)  enddef;

Best wishes,
Taco
--
http://tug.org/metapost/

Steve Checkoway | 8 Aug 15:40 2010

Re: Problem with colors


On Aug 8, 2010, at 06:19 , Troy Henderson wrote:

> Replace
> 
> label(btex \color{red}X etex, origin);
> 
> with
> 
> label(btex X etex, origin) withcolor red;
> 
> or
> 
> label(btex X etex, origin) withcmykcolor (1,0,0,0); % This gives cyan
> 
> There appears to be no built-in synonyms (although you could easily write your own) for the base
cmykcolors cyan, magenta, and yellow.  Black is already synonymous with the RGB (0,0,0).  Specifically,
you could do
> 
> cmykcolor cyan,magenta,yellow;
> cyan:=(1,0,0,0);
> magenta:=(0,1,0,0);
> yellow:=(0,0,1,0);
> 
> label(btex X etex,origin) withcmykcolor cyan;

That all appears to work. It seems that withcolor (0,0,1,0) works as well. (I guess it treats quadruples as
cmyk and triples as rgb.) Given that, adding the definition
def cmyk = enddef;
appears to make my original example work.

--

-- 
Steve Checkoway

--
http://tug.org/metapost/

Johannes Kanig | 8 Aug 21:18 2010
Picon

outputtemplate and file names

Hi,

I have encountered a very strange behaviour of metapost (version
1.208) in connection with outputtemplate. The file is attached.

The file should (and does) generate 13 figures; the bug is that one
output file is incorrectly named.

Here come the details about the file.

* It uses mp-tool and mp-spec from context.
* It sets prologues to 0.
* Before each beginfig, it changes the outputtemplate variable to the
desired output file name
* It does so using the code from the manual:

if scantokens(mpversion) < 1.200:
filenametemplate
else:
outputtemplate :=
fi
  "AAAAAAAAAAAAAA.mps";

* All 13 figures are very simple (one line), except one (the third),
which is still quite simple (only a few lines).
* All figures are created correctly.
* But the 12th figure is incorrectly named; its name is shortened.

I'm sorry that the test file is so long, but the bug disappears if I:
* remove the (useless) inputs of mp-tool and mp-spec;
* remove the prologue:=0;
* remove a figure;
* set outputtemplate directly without if-then-else;
* simplify the third figure.

Also sorry for the stupid filenames, but I found it simpler like that ...

What is the best solution here? The aim was to name output files
directly instead of the "[jobname.i]" scheme. I guess I will go back
to using the standard naming scheme and moving files around
afterwards...

Johannes

--

-- 
Johannes Kanig
johannes.kanig <at> gmail.com
Attachment (zzzzzzzzzzzz.mp): application/octet-stream, 3331 bytes
--
http://tug.org/metapost/
Taco Hoekwater | 9 Aug 15:28 2010

Re: outputtemplate and file names

On 08/08/2010 09:18 PM, Johannes Kanig wrote:
> Hi,
>
> I have encountered a very strange behaviour of metapost (version
> 1.208) in connection with outputtemplate. The file is attached.

This bug is fixed in the repository, but I have not made a new
release yet. It is also included as a hotfix in the TeXLive source
tree, so metapost 1.211 in TeXLive 2010 will not have this bug.

Best wishes,
Taco

--
http://tug.org/metapost/

Nicola | 24 Aug 16:22 2010
Picon

Bug in 1.502 with graph.mp

I apologize if this has been reported already, but

input graph;
end.

causes a segfault in mpost 1.502, which seems to happen on loading 
texnum.mp.

Nicola

--
http://tug.org/metapost/

Taco Hoekwater | 24 Aug 18:29 2010

Re: Bug in 1.502 with graph.mp


Nicola wrote:
> I apologize if this has been reported already, but
> 
> input graph;
> end.
> 
> causes a segfault in mpost 1.502, which seems to happen on loading 
> texnum.mp.

What are your MPXCOMMAND and TEX settings and the exact terminal
output? (it does not crash here).

Best wishes,
Taco
--
http://tug.org/metapost/


Gmane