can any windows 0.91.2 user reproduce

Community matplotlib-users
1

I know. In version 0.90.1 (and earlier) all greek symbols were included in the EPS.
Now they are not anymore, and I cannot get any of the options to include them.
Does anybody know how to fix this?

Mark

···

Date: Tue, 25 Mar 2008 10:43:43 -0400

From: Alan G Isaac <aisaac@…310…>

Subject: Re: [Matplotlib-users] can any windows 0.91.2 user reproduce

    this    bug?

To: matplotlib-users@lists.sourceforge.net

Message-ID: <Mahogany-0.67.0-900-20080325-104343.00@…310…>

Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1

On Tue, 25 Mar 2008, Jim Vickroy apparently wrote:

I loaded the eps file in Adobe Photoshop and the chi

letter was displayed along the x-axis. – jv

Sounds like perhaps the symbol is not embedded in the EPS file.

Cheers,

Alan Isaac

2

The *intention* is that the fonts *should* be included (with the exception of ps.useafm == True). That was definitely not a deliberate change.

However, as one of the ones who hasn't been able to reproduce this problem, I'm afraid I'm not of much help. From reading the code, I'm still completely stumped as to why the font is not embedded. Someone will have to step through with a debugger on one of the broken systems to figure this out, I'm afraid.

All the magic happens in "convert_ttf_to_ps", which is C code, called from backend_ps.py. I'd start by seeing if that function is even called, and if not, why...

Cheers,
Mike

Mark Bakker wrote:

···

I know. In version 0.90.1 (and earlier) all greek symbols were included in the EPS.
Now they are not anymore, and I cannot get any of the options to include them.
Does anybody know how to fix this?
Mark

    Date: Tue, 25 Mar 2008 10:43:43 -0400
    From: Alan G Isaac <aisaac@...310... <mailto:aisaac@…310…>>
    Subject: Re: [Matplotlib-users] can any windows 0.91.2 user reproduce
           this bug?
    To: matplotlib-users@lists.sourceforge.net
    <mailto:matplotlib-users@lists.sourceforge.net>
    Message-ID: <Mahogany-0.67.0-900-20080325-104343.00@...310...
    <mailto:Mahogany-0.67.0-900-20080325-104343.00@…310…>>
    Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1

    On Tue, 25 Mar 2008, Jim Vickroy apparently wrote:
    > I loaded the eps file in Adobe Photoshop and the chi
    > letter **was** displayed along the x-axis. -- jv

    Sounds like perhaps the symbol is not embedded in the EPS file.

    Cheers,
    Alan Isaac

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------------------------------------------------

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

3

I was able to replicate the bug and find the source of the problem. I
am not 100% sure how to fix it, but someone who knows os.stat better
might. The problem is that matplotlib.cbook.get_realpath_and_stat

class GetRealpathAndStat:
    def __init__(self):
        self._cache = {}

    def __call__(self, path):
        result = self._cache.get(path)
        if result is None:
            realpath = os.path.realpath(path)
            stat = os.stat(realpath)
            stat_key = (stat.st_ino, stat.st_dev)
            result = realpath, stat_key
            self._cache[path] = result
        return result
get_realpath_and_stat = GetRealpathAndStat()

is returning the same stat ino and dev for all the font files, and
thus the renderer.used_characters dictionary is getting improper keys
-- always (0,0). So the first font in the gate, in this case Vera, is
getting a place in the dict and subsequent fonts (the cm* ones) are
not. The basic problem is that the inode and dev appear to be unix
only.

Michael: if you let me know better what this key is supposed to be
doing (can we not simply use the filename for windows?) then I can
attempt or test some fixes.

JDH

···

On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom <mdroe@...86...> wrote:

The *intention* is that the fonts *should* be included (with the
exception of ps.useafm == True). That was definitely not a deliberate
change.

However, as one of the ones who hasn't been able to reproduce this
problem, I'm afraid I'm not of much help. From reading the code, I'm
still completely stumped as to why the font is not embedded. Someone
will have to step through with a debugger on one of the broken systems
to figure this out, I'm afraid.

4

The hackish:

    if stat_key==(0,0):
        stat_key = (path, path)

does produce a working chi enabled EPS file, FYI

JDH

···

On Tue, Mar 25, 2008 at 12:50 PM, John Hunter <jdh2358@...287...> wrote:

        result = self._cache.get(path)
        if result is None:
            realpath = os.path.realpath(path)
            stat = os.stat(realpath)
            stat_key = (stat.st_ino, stat.st_dev)

5

John -

What you are saying makes sense, because whatever option I give, I always get Vera included in my eps file but nothing else.

Thanks for looking into this,

Mark

···

On Tue, Mar 25, 2008 at 6:50 PM, John Hunter <jdh2358@…287…> wrote:

On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom <mdroe@…86…> wrote:

The intention is that the fonts should be included (with the

exception of ps.useafm == True). That was definitely not a deliberate

change.

However, as one of the ones who hasn’t been able to reproduce this

problem, I’m afraid I’m not of much help. From reading the code, I’m

still completely stumped as to why the font is not embedded. Someone

will have to step through with a debugger on one of the broken systems

to figure this out, I’m afraid.

I was able to replicate the bug and find the source of the problem. I

am not 100% sure how to fix it, but someone who knows os.stat better

might. The problem is that matplotlib.cbook.get_realpath_and_stat

class GetRealpathAndStat:

def __init__(self):

    self._cache = {}



def __call__(self, path):

    result = self._cache.get(path)

    if result is None:

        realpath = os.path.realpath(path)

        stat = os.stat(realpath)

        stat_key = (stat.st_ino, stat.st_dev)

        result = realpath, stat_key

        self._cache[path] = result

    return result

get_realpath_and_stat = GetRealpathAndStat()

is returning the same stat ino and dev for all the font files, and

thus the renderer.used_characters dictionary is getting improper keys

– always (0,0). So the first font in the gate, in this case Vera, is

getting a place in the dict and subsequent fonts (the cm* ones) are

not. The basic problem is that the inode and dev appear to be unix

only.

Michael: if you let me know better what this key is supposed to be

doing (can we not simply use the filename for windows?) then I can

attempt or test some fixes.

JDH