Looks like the EPS file is leaving in lines that should be commented:

%!PS-Adobe-3.0 EPSF-3.0
%%Title: Figures/perf_re_dep.eps
%%Creator: matplotlib version 1.5.1, http://matplotlib.org/
%%CreationDate: Sat Jan 16 20:17:39 2016
%%Orientation: portrait
%%BoundingBox: 36 270 576 522
%%EndComments
%%BeginProlog
/mpldict 10 dict def
mpldict begin
/m { moveto } bind def
/l { lineto } bind def
/r { rlineto } bind def
/c { curveto } bind def
/cl { closepath } bind def
/box {
m
1 index 0 r
0 exch r
neg 0 r
cl
} bind def
/clipbox {
box
clip
newpath
} bind def
%!PS-Adobe-3.0 Resource-Font
%%Title: Arial
%%Copyright: © 2015 The Monotype Corporation. All Rights Reserved. 
Hebrew OpenType Layout logic copyright © 2003 & 2007, Ralph Hancock & John Hudson. This layout logic for Biblical Hebrew is open source software under the MIT License; see embedded license description for details.
%%Creator: Converted from TrueType to type 3 by PPR

Something going wrong with the carriage returns right before Hebrew?:

b'%%Copyright: \xa9 2015 The Monotype Corporation. All Rights Reserved. \r\rHebrew OpenType Layout logic copyright \xa9 2003 & 2007, Ralph Hancock & John Hudson. This layout logic for Biblical Hebrew is open source software under the MIT License; see embedded license description for details.\r\n'
b'/Notice (\xa9 2015 The Monotype Corporation. All Rights Reserved. \r\rHebrew OpenType Layout logic copyright \xa9 2003 & 2007, Ralph Hancock & John Hudson. This layout logic for Biblical Hebrew is open source software under the MIT License; see embedded license description for details. Arial is a trademark of The Monotype Corporation.) def\r\n'

I assume this on windows?

Indeed. FWIW, the EPS wouldn't open on Linux either. I removed the carriage returns from \r\r\Hebrew and they work now.

I meant generated on windows.

On Sun, Jan 17, 2016, 09:06 Pete Bachant notifications@github.com wrote:

Indeed. FWIW, the EPS wouldn't open on Linux either. I removed the
carriage returns from \r\r\Hebrew and they work now.

—
Reply to this email directly or view it on GitHub
#5862 (comment)
.

That line comes directly from the arial.ttf file in the conversion from TTF to Type 3 in ttconv. I suspect that ttconv needs to escape/sanitize/normalize those newlines rather than just copying it over blindly. Does setting ps.fonttype to 42 work as a workaround (at the expense of some file size)?

#5414 will hopefully someday address this by replacing the font-subsetting code.

Nope, unfortunately, setting rcParams["ps.fonttype"] = 42 has the same issue.

I suppose there is no fix yet to the problem?

I used this as a workaround for now:

def fix_eps(fpath):
    """Fix carriage returns in EPS files caused by Arial font."""
    txt = b""
    with open(fpath, "rb") as f:
        for line in f:
            if b"\r\rHebrew" in line:
                line = line.replace(b"\r\rHebrew", b"Hebrew")
            txt += line
    with open(fpath, "wb") as f:
        f.write(txt)

Great, thanks.

If this adds anything to solving the problem, I don't face the problem on win7 (only on win8.1). Can't check win10 at the moment.

@mdboom Can you point me to where this code is?

Is this something we can report upstream against windows (or who ever the source of that font file is)?

FYI, the problem appears on win10 as well.

@tacaswell: The new font subsetting code lives in freetypy -- not done yet, but it already might do better on this particular problem. https://github.com/matplotlib/freetypy/blob/master/lib/freetypy/subset.py

I believe Microsoft releases Arial, but I doubt we'll convince them to fix it -- I think more likely we'll have to work around it, even if it's to hardcode a workaround to particular non-standard fonts like this.

#6525 has pointed out that this occurs with Calibri as well.