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

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?

-
Could this be an issue with the font? I can't replicate the PDF export problem on Windows using Verdana, Consolas or Vivaldi: it definitely uses the selected font for operators and the custom Mathematica fonts are not used. And I have never had this problem on my Mac at home. I have Mathematica 9 on both machines. Maybe try Consolas for the time being? –  Verbeia May 20 '13 at 21:58
Looks more like a Mac problem (for PDF at least). I can't get other fonts to display their own operators - looks like it defaults to something else. –  cormullion May 20 '13 at 22:13
With Consolas, again only SVG export works. PDF export gives a rectangle with a question mark in it for ×. If the issues are non-existent in Windows, then I guess it's a Mac-specific problem like cormullion suggested. That's sad. Why oh why... –  Taiki May 21 '13 at 18:11
There are some similar problems that appear to be Mac-only... –  cormullion May 21 '13 at 22:09
After reading your and many other related topics I have an impression that the Mac version is inferior in terms of working with fonts. Apologies for venting my frustration here, but I'm disappointed in its typesetting capability in general, and the statement that Mathematica has by far the world's most sophisticated and convenient mathematical typesetting technology. (I pretty much love all else though!) –  Taiki May 22 '13 at 12:47

## 2 Answers

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

-
Thank you. This really helps me investigate the problem! –  Taiki May 23 '13 at 18:26

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. If this can be regarded as a bug, please someone flag my reply as an answer.

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...

-