This question already has an answer here:

Please consider the following MWE:





\textcolor{Blue!55!Green}{Text here}


Since the new year's MiKTeX update, the xcolor package must be loaded along with the prologue option in order to counteract interaction bugs with PSTricks, TiKZ, etc. (as noted here).

However, if xcolor+prologue is loaded BEFORE pgfplots, it generates the following GhostScript error: Error: /undefined in color, Operand Stack: XC@mapped.

If xcolor+prologue is loaded AFTER pgfplots, the following error arises during compilation (LaTeX=>PS=>PDF): ! Package xcolor Error: Undefined color 'Blue'.

Any ideas on how to solve this issue?

marked as duplicate by Christian Feuersänger pgfplots Feb 1 at 13:59

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Just updated MiKTeX + Refresh FNDB + Rebuild Fonts after seeing your comment. Still get the same errors on my side. – feculededentier Jan 28 at 17:05
  • Yes, Admin + User, both updated, both refreshed. This is explicitely compiled through the (LaTeX=>PS=>PDF) build profile on a MiKTeX installation. Not sure which engine is used (pdfLaTeX?), but I don't know XeLaTeX. The GhostScript error appears when attempting to convert from PS to PDF. As stated in similar posts, the PS is generated properly, but the conversion process fails. Trying to uninstall, clean and fresh reinstall to see if that solves the problem. – feculededentier Jan 28 at 17:14
  • Same results with clean install and all updates applied. The MWE does compile through XeLaTeX, but I explicitely need it to compile through LaTeX=>PS=>PDF (latex+GhostScript). – feculededentier Jan 28 at 17:43

I can reproduce the problem on texlive. pgfplots defines a color with a space in its name (mapped color). When using the (needed) prologue option this is passed to ghostscript (through the generated xcp file):

 /XC@mapped color{0 0 0}XCrgb

and ghostscript doesn't like this at all.

A similar error can be triggered with


\definecolor{some color}{rgb}{1,0,0}


This is imho a bug in pgfplots. It should change the color name.

  • 2
    Is there anything we can do about it? Until this is resolved, unfortunately, none of my documents will compile... – feculededentier Jan 28 at 17:48
  • Well in your example I can avoid the problem by escaping the space, but as soon as the color is used it explodes again, so you would sit on a bomb ... – Ulrike Fischer Jan 28 at 18:06
  • @UlrikeFischer, before I contact Christian because of this issue and ask him to fix this: Where is the difference to the time before this years TikZ update? Was that working before that or is this a bug that exists quite a long time and just showed up now? Does Herbert's fix mentioned in this comment fix this issue here, too? – Stefan Pinnow Jan 29 at 4:35
  • @StefanPinnow You should ask Herbert about the dvips details. I don't know much about the low-level postscript. But I do know that spaces in internal (color) names is a very bad idea - you always have to think about the need to escape or remove or protect such spaces. And Herberts fix imho does not solve this issue, it made it appear: with the prologue option the color names are copied into the postscript, and so the space harms. – Ulrike Fischer Jan 29 at 7:30
  • 1
    Confirmed: replacing mapped color by mappedcolor (space removed) everywhere in pgfplots.code.tex, pgfplotsmeshplothandler.code.tex and pgfplotsplothandlers.code.tex fixes the issue. Documents now compile normally. – feculededentier Jan 31 at 23:12

This question is actually "just" a result of the proposed solution of tikzpicture won't render 'usable' PS code .

The issue is invalid and the solution for the linked question needs to be changed. I will update it as soon as the solution is ready.

Not the answer you're looking for? Browse other questions tagged or ask your own question.