latex2e
latex2e copied to clipboard
Different behavior for .mps and .eps
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:
-
pdflatex & lualatex: first square is red, second square is black
-
xelatex: Both squares are black
-
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}
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)
Yes, Ulrike describes the cause correctly. However, the problem remains that different engines deliver different results.
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.
xelatex
sets also the default color to 0 g
This issue has been automatically marked as stale because it has not had recent activity.
@FrankMittelbach suggests using a key to define the behaviour: I might look at l3graphics
first for testing
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?
Thinking a bit more, I guess we should be talking about normalcolor
here, so just normalcolor
, ensure-normalcolor
, apply-normalcolor
, ...?
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.
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
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
.
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 doinginitcolor=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!
)
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
?
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
)
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.
- 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)
well
\default@color
sounds imho more logical and consistent. But the issue started withdifferent 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.)
Just to throw another hat in the ring: fallback-color
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
Well, it's a fallback in the sense that it is the colour used if the graphic file doesn't explicitly set a colour.
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.
This issue has been automatically marked as stale because it has not had recent activity.