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.
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'
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.
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.
Activity
petebachant commented on Jan 17, 2016
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 PPRpetebachant commented on Jan 17, 2016
Something going wrong with the carriage returns right before Hebrew?:
tacaswell commented on Jan 17, 2016
I assume this on windows?
petebachant commented on Jan 17, 2016
Indeed. FWIW, the EPS wouldn't open on Linux either. I removed the carriage returns from \r\r\Hebrew and they work now.
tacaswell commented on Jan 17, 2016
I meant generated on windows.
On Sun, Jan 17, 2016, 09:06 Pete Bachant notifications@github.com wrote:
mdboom commented on Jan 18, 2016
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 commented on Jan 18, 2016
Nope, unfortunately, setting rcParams["ps.fonttype"] = 42 has the same issue.
MMCMA commented on Mar 16, 2016
I suppose there is no fix yet to the problem?
petebachant commented on Mar 16, 2016
I used this as a workaround for now:
MMCMA commented on Mar 16, 2016
Great, thanks.
MMCMA commented on Mar 18, 2016
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 commented on Mar 18, 2016
@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 commented on Mar 21, 2016
FYI, the problem appears on win10 as well.
mdboom commented on Mar 21, 2016
@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 commented on Jun 1, 2016
#6525 has pointed out that this occurs with Calibri as well.