Cfrgtkky

My system: Windows10, MikTeX2.9, WinEdt10.2

I am preparing/updating a set of lecture notes. I ran into the following issue with psfrag. The relevant source snippet:

begin{figure}[ht]

psfrag{X}{$x$}

psfrag{Y}{$y$}

psfrag{A}{$dA_1$}

psfrag{B}{$dA_2$}

psfrag{dr}{$dr$}

psfrag{df}{$dphi$}

psfrag{r1df}{$r_1,dphi$}

psfrag{r2df}{$r_2,dphi$}

begin{center}

includegraphics[width=240pt]{PolarPlaneElement.eps}

caption{Samanmittaiset napakoordinaattien vaihteluvälit vastaavat pinta-alkion

sijainnista riippuen erikokoisia tasoalueita}

label{PolarPlaneElement}

end{center}

end{figure}

I generated the imagefile PolarPlaneElement.eps with Mathematica.
The problem is with substitutions of strings "A" and "B". My theory is that
the problems are related to the fact that in the PostScript image all the other strings are on white background, but these two troublemakers are on
a (monocolored) pink background. Initially I used more descriptive strings
"dA1" and "dA2" instead of the single letter "A" and "B". Switching to single letter strings as instructed here
did help matters, but a problem remains:

While I can get the substituted $dA_1$ to show in the final product, the
original "A" still shows also. In other words, the relevant TeX-formula was added, but the string it was to replace was not removed!

My current test results:

1. If I remove the pink coloring from the eps-image, everything works as expected. Either with "A/B" or "dA1/dA2"


2. If I use the longer strings "dA1", "dA2" on a pink background, then nothing is replaced.


3. A nearly identical psfrag substitution on monocolored background has worked for me in the past. That was on a powerdot slide set. I can't think
   of any key differences in the two images. The successful substitution
   was more or less identical. May be the difference was that in a slide the
   image was scaled differently?

I will keep trying things. Next on the list is to check whether the ordering
of various parts of the image that Mathematica puts together to produce the eps-file will have an effect on psfrag's ability to ID the string within the eps-file. I will post my findings here.

Is this a known bug/difficulty/feature? Can you suggest other things I could try?

Here is the offending eps file.

More testing:

• When I let Mathematica generate the eps-file the order of the
  components seems to matter. My latest idea was to make the text
  components of the image to be the last ones on the list. The outcome
  was that psfrag could not do any substitutions at all. Having the
  text components earlier in the list lead to the "doubled" strings of
  which one was replaced, as observed by commenters.


• I did more testing with the earlier version of the working image (from 2 years ago). Viewing that older eps in Ghostview gave me a surprise - the text on the pink background was nowhere to be seen! When I recreated that eps file with my current Mathematica,
  the same problem appeared with that image also. I have upgraded my Mathematica from version 9 to version 11 in the interim. I view this as evidence that something has changed at Wolfram's end. I will ask at Mathematica.SE, and report here in case somebody else runs into the same problem, no solutions offered there, yet.

Meanwhile, this eps looks like after psfrag has done its magic. See the ghost "A" showing through in the part shown through TeXWorks magnifying glass.

Currently my best attempt is to make Mathematica print those pieces of text using white characters!! When drawn in white the "doubled" graphical outline of the letters won't show. It is still a mystery to me as to why this problem is present only with those pieces of text on colored background, and why it does not apply to all of them. I suspect this is part of the reason - Wolfram made some changes when "up"grading from version 9.

It seems "clear" to me that this problem is due to Wolfram trying to "fix" something that was not broken :-(

Just for the fun of it here is a drawing of this in tikz. I was mainly done by tracing your EPS.

documentclass[tikz]{standalone}

usetikzlibrary{calc} 

begin{document}

begin{tikzpicture}



 % node[anchor=south west,inner sep=0pt] at (0,0) {includegraphics{PolarPlaneElement}};





  begin{scope}[thick,font=footnotesize,line cap=rect]



    draw (0,0.4) -- ++(8.8,0) node[right] {$X$};

    draw (0.19,0) -- ++(0,7.9) node[above] {$Y$};

    coordinate (O) at (0.19,0.4);



%    fill (O) circle (1pt);



    defangA{20}

    defangB{40}



    draw (O) -- ++ (angA:9.2);

    draw (O) -- ++ (angB:11);



    begin{scope}[blue]

      defRadius{1.3}

      draw ($(O)+(angA:Radius)$) arc [start angle=angA,delta

      angle=angB-angA,radius=Radius]

      node[pos=0.35,above right=0mm] {$df$}

      ;



      defRadius{2.95}

      defRadiusDR{1.5}

      draw[fill=pink] ($(O)+(angA:Radius)$)

      coordinate (A1)

      arc [start angle=angA,delta angle=angB-angA,radius=Radius]

      node[pos=0.45,below left=0mm] {$r_1df$}

      -- ++ (angB:RadiusDR)

      coordinate (A2)

      node[pos=0.4,above=0.5mm] {$dr$}

      arc [start angle=angB,delta

      angle=angA-angB,radius=Radius+RadiusDR]

      -- cycle

      node at ($(A1)!0.5!(A2)$) {$A$}

      ;



      defRadius{6.6}

      draw[fill=pink] ($(O)+(angA:Radius)$)

      coordinate (B1)

      arc [start angle=angA,delta angle=angB-angA,radius=Radius]

      node[pos=0.55,below left=0mm] {$r_2df$}

      -- ++ (angB:RadiusDR)

      coordinate (B2)

      node[pos=0.4,above=0.5mm] {$dr$}

      arc [start angle=angB,delta

      angle=angA-angB,radius=Radius+RadiusDR]

      -- cycle

      node at ($(B1)!0.5!(B2)$) {$B$}

      ;



    end{scope}

  end{scope}

end{tikzpicture}

end{document}