Some Microsoft fonts produce unreadable EPS

[petebachant]

Using Arial as font.sans-serif in a figure will produce an EPS file that can't be opened or converted to PDF. In my case, using any other font, e.g. Bitstream Vera Sans or Liberation Sans produces a valid EPS.

[petebachant]

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

[petebachant]

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'

[tacaswell]

I assume this on windows?

[petebachant]

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

[tacaswell]

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

[mdboom]

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.

[petebachant]

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

[MMCMA]

I suppose there is no fix yet to the problem?

[petebachant]

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)

[MMCMA]

Great, thanks.

[MMCMA]

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.

[tacaswell]

@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)?

[MMCMA]

FYI, the problem appears on win10 as well.

[mdboom]

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

[QuLogic]

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