Different behavior for .mps and .eps

[rolfn]

Brief outline of the bug

The following example document loads two identical graphics files as .mps and .eps via \includegraphics. Both are valid eps files. I get different results depending on the TeX compiler:

1. pdflatex & lualatex: first square is red, second square is black

2. xelatex: Both squares are black

3. latex+dvips+ps2pdf: Both squares are black

From the user's point of view, it seems advantageous to me if graphics that do not themselves cause color settings can be colored from the outside. In any case, different behavior is unfavorable.

Minimal example showing the bug

\RequirePackage{latexbug}       % <--should be always the first line (see CONTRIBUTING)!
\begin{filecontents*}[force]{foo.mps}
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 0 0 1000 1000 
%%Page: 1 1
newpath 0 0 moveto
1000 0 lineto
1000 1000 lineto
0 1000 lineto
closepath fill
showpage
%%EOF
\end{filecontents*}
\begin{filecontents*}[force]{foo.eps}
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 0 0 1000 1000 
%%Page: 1 1
newpath 0 0 moveto
1000 0 lineto
1000 1000 lineto
0 1000 lineto
closepath fill
showpage
%%EOF
\end{filecontents*}
\documentclass{article}
\usepackage{graphicx,xcolor}    
\begin{document}
  \color{red!70}
  \rule{10mm}{30mm}\hfill \includegraphics[height=30mm]{foo.mps} \hfill 
  \includegraphics[height=30mm]{foo.eps} \hfill \rule{10mm}{30mm}
\end{document}

grf-test2.log

[daleif]

Perhaps also mention https://tex.stackexchange.com/questions/659801/different-behavior-for-mps-and-eps, where Ulrike already gave the explanation for the difference.

Personally I can see the usefulness in both (either no effect from color or getting the effect from coloring)

[rolfn]

Yes, Ulrike describes the cause correctly. However, the problem remains that different engines deliver different results.

[u-fischer]

Well at first handling of graphics is something that is engine specific. If you want the best result for more than one engine you often have to provide more than one version of the same graphic.

Apart from this I don't see what latex or graphics-def can do here. We can not add a \color{black} to \includegraphics or the the mps code of pdftex/luatex and so destroy their ability to change color only to get them in line with the other engines.

Imho it could only work if you find a ghostscript option (or convince them to add one) for the pdfwriter device so that it doesn't add the black. Then epstopdf could perhaps be changed.

[hvoss49]

xelatex sets also the default color to 0 g

[stale]

This issue has been automatically marked as stale because it has not had recent activity.

[josephwright]

@FrankMittelbach suggests using a key to define the behaviour: I might look at l3graphics first for testing

[josephwright]

A key here would be able to enforce the standard colour as black across all engines: I guess what I need is a suggestion on a key name. I suppose enforce-black or ensure-black might be the most obvious: thoughts?

[josephwright]

Thinking a bit more, I guess we should be talking about normalcolor here, so just normalcolor, ensure-normalcolor, apply-normalcolor, ...?

[u-fischer]

normalcolor sounds imho wrong, it gives the impression the color would change if you change the normal/default color. ensure-black doesn't sounds right either, as you would get a colored and not a black square if the eps contains its own color commands.

Perhaps init-black? Or perhaps simply initcolor=color with the default value (and only value in xetex/dvips) black? This would be flexible in case some future development actually allows to change the color with xetex and/or dvips to.

Btw: you have the same problem with xform/xobjects: pdflatex and lualatex allow color injection but not the other backend.

[FrankMittelbach]

I guess it should produce "normalcolor" by default but is there a usecase that it should be anyhting other than that, ie a different color? If so the key could by default use normalcolor but could explicitly set via key=color to something else?

So I would not put "normal" in the key name but perhaps initcolor or init-color. Just see that Ulrike has the same suggestion

[josephwright]

OK, so we think init-color which starts with an empty value? So no value means 'whatever is prevailing', a color (expression?) means you get the colour that it defines. Documentation then deals with the fact this is only applicable (at present) in pdfTeX/LuaTeX PDF mode? I think we add the key at the same time to graphics and l3graphics.

[u-fischer]

I would say

• key is not used or initcolor=false: behaviour as now (so you get color injection with pdflatex/lualatex and black with xetex)
• initcolor is doing initcolor=black
• initcolor=red sets this color and we document that it doesn't work with xetex etc.

(and if people really define a color with the name false they can probably use initcolor=false!)

[FrankMittelbach]

sounds good, except that I wouldn't bother with false! but just say if you define it you get it. And perhaps we should also allow initcolor=true as the long form for initicolor. Question: is it best to make the default explicitly black or should it be explicitly \normalcolor?

[u-fischer]

well \default@color sounds imho more logical and consistent. But the issue started with different behavior is unfavorable. So the question is if we accept that initcolor can give different behaviour with the engines if the default color is not black and that users who want to be sure to get uniform behaviour across engines would have to use initcolor=black explicitly (and there is also the question of the color model: we then probably should ensure that black then always use 0 g)

[josephwright]

and there is also the question of the color model: we then probably should ensure that black then always use 0 g

Well if the user is forcing CMYK they won't, but otherwise the standard setting for black is using the gray model.

[josephwright]

• key is not used or initcolor=false: behaviour as now (so you get color injection with pdflatex/lualatex and black with xetex)

Keys always have a value, even if it's empty ... I guess you mean that we initialise with an empty stored value, and that we set the default to black so initcolor = black and initcolor are the same.

(I favour init-color over initcolor, but I can live with either)

[josephwright]

well \default@color sounds imho more logical and consistent. But the issue started with different behavior is unfavorable.

Well we can only fix stuff to some extent, and we likely don't want to break existing usage. (Perhaps \DocumentMetadata could set the key always-active, which would then given consistent behaviour and make colouring images opt-in.)

[Skillmon]

Just to throw another hat in the ring: fallback-color

[FrankMittelbach]

that doesn't seem to fit the bill if I understand the problem. It is not a fallback color, it is a color that is explicitly set at the beginning of the graphic, for some workflow paths it is set unconditionally (without any key) and for others it is not set at all and with this key we can force pdftex and luatex to also explicitly set a color at this point

[Skillmon]

Well, it's a fallback in the sense that it is the colour used if the graphic file doesn't explicitly set a colour.

[FrankMittelbach]

true enough as an interpretation, but when I read fallback I would think more about something is failing and then I get a fallbackcolor but not expect that "fallback color" to apply if I explicitly set "red" on the outside, whereas with init-color I can immediately see why my "red" does no longer apply.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.