Setting OperatorSubstitution to False has issues with PDF and EPS exports. Are these bugs?

Question

In Plot, I would like to use my own font, eg Inconsolata, for operators such as ×, so I set OperatorSubstitution to False as follows.

Plot[
  x,
  {x, 0, 10^10},
  BaseStyle -> {PrivateFontOptions -> {"OperatorSubstitution" -> False}}, 
  LabelStyle -> {FontFamily -> "Inconsolata"}
]

There are three vector formats into which I can export the figure: SVG, EPS, and PDF. Only the SVG export gives the correct result, ie the character × is in the font specified. The others have the following issues. My first question is: Are they bugs?

• PDF export: operators are omitted altogether.
• EPS export: the instruction of setting OperatorSubstitution is omitted, ie font substitution for operators still occur.

I'm using Mathematica 9 for Mac.

My second question is: Is there any way to work around the issue with PDF export?

Answer 1

comment w/code In case this helps sort things out, taking the custom font out of the picture, compare

Export["file.eps",  Plot[x, {x, 0, 10^10}]

with :

Export["file.eps",  Plot[x, {x, 0, 10^10}, 
     BaseStyle -> {PrivateFontOptions -> {"OperatorSubstitution" -> False}}]]

with windows in the eps file you can see the difference: "4 x" appears as

9 /Times-Roman-MISO Msf
0 9.264 m
(4) N
9 /Mathematica1 Msf
5.56 9.264 m
(\264) N

vs

9 /Times-Roman-MISO Msf
0 9.264 m
(4) N
5.56 9.264 m
(\327) N

Take a look at what your mac version is doing. And note you might have an issue if your custom font doesn't have the \327 character defined which is "ISO latin" x

Answer 2

Thanks to george2079's answer, now I know what happens with EPS export in this case. The issue with PDF export might be related to this explanation.

Export (in Mathematica for Mac, at least the V9 that I'm using) always exports an EPS file in the Mac OS Roman encoding regardless of

• $SystemCharacterEncoding
• ExternalDataCharacterEncoding in the Global Preferences
• CharacterEncoding option of Export

(None of these is set to MacintoshRoman on my machine. Yet in the EPS file MacintoshRomanEncoding is present.)

This is particularly problematic for the particular example case brought up in this topic because the multiplication sign is not in the Mac OS Roman character set (but present in ISO-8859-1)! That's why Windows users don't have my problem.

In Fact, Mathematica for Mac does a good job here; it puts the correctness of the symbols in the top priority. If we have a look in the EPS source file of

Export["file.eps", Plot[
  x, {x, 0, 10^10},
  BaseStyle -> {PrivateFontOptions -> {"OperatorSubstitution" -> False}}, 
  LabelStyle -> {FontFamily -> "Inconsolata"}
]]

we can see that, even though OperatatorSubstitution has been set to False, Mathematica invokes the Mathematica1 font anyway when encountering a character (in this case, ×) which is not in the character set of the encoding (Mac OS Roman). For Mathematica1 in any encoding, × corresponds to the octal code \264. If we remove the line that specify the use of Mathematica1 (9 /Mathematica1 Msf), expectedly we get the Japanese currency sign (the actual character that \264 corresponds to in the Mac OS Roman encoding).

In the first example from george2079, we can see that whatever the encoding the EPS file has been exported in, the octal code for × is \264 because the universal Mathematica1 is being used. In the next example, Mathematica is told not to use Mathematica1. That octal code is then converted to \327, the × in the ISO-8859-1 (or compatible) encoding. This doesn't happen in my Mathematica for Mac, because there's no × code to convert to under the Mac OS Roman encoding (and Mathematica retains the line 9 /Mathematica1 Msf).

What Mathematica for Mac does bad is the stubborn enforcement of Mac OS Roman.

There must really be some way to use other encodings in Export in Mathematica for Mac. It would be a bit ridiculous if there wasn't...