[CJK] can create png but not eps

Hello everybody,

I have a final problem with my graph. As a last step I produce an *.eps file that I use in conjunction with LaTeX.

Here is the last part of my code:

# plt.title('Title')
xlab = plt.xlabel(u'输入 1')
#xlab.set_position((0.2, 0.1))
ylab = plt.ylabel(u'输入 2')
plt.grid(True)
plt.subplots_adjust(bottom=0.2)
plt.show()
plt.savefig('dea.eps')

plt.show() produces the correct output,

but

plt.savefig('dea.eps') produces an error (the error message is attached).

The error is clearly linked to the Chinese, as it runs through if I take the Chinese out of the code.
Also, plt.savefig('dea.png') works fine.

Could anyone indicate where I would have to look for the mistake? The matplotlibrc should be fine, but I am not sure.

Your help would be greatly appreciated!

Many thanks,

David

dea.py-error.txt (6.38 KB)

matplotlibrc (17.5 KB)

The font you are using (SimHei) does not have any glyph names -- these are used in the Postscript backend to refer to glyphs outside of the ASCII range. More specifically, it looks like it has at least one invalid glyph name (glyph names can only contain ASCII characters) -- loading it in FontForge complains about this. I haven't come across such a font before, but maybe that's common in CJK fonts. I don't know. I'm looking through the spec to find a way that glyphs can be referenced without a name, but I'm not finding one. Note, the PDF backend has the same issue.

Do you have the same problem if you remove "SimHei" from the font.sans-serif list and thus use "Adobe Song Std" instead? (I was able to find an online download of SimHei to test with, but not Adobe Song Std).

As a workaround, the Cairo backend seems to handle this font just fine. You can add

  import matplotlib
  matplotlib.use('GtkCairo')

to the top of your script.

Mike

David wrote:

···

Hello everybody,

I have a final problem with my graph. As a last step I produce an *.eps file that I use in conjunction with LaTeX.

Here is the last part of my code:

# plt.title('Title')
xlab = plt.xlabel(u'输入 1')
#xlab.set_position((0.2, 0.1))
ylab = plt.ylabel(u'输入 2')
plt.grid(True)
plt.subplots_adjust(bottom=0.2)
plt.show()
plt.savefig('dea.eps')

plt.show() produces the correct output,

but

plt.savefig('dea.eps') produces an error (the error message is attached).

The error is clearly linked to the Chinese, as it runs through if I take the Chinese out of the code.
Also, plt.savefig('dea.png') works fine.

Could anyone indicate where I would have to look for the mistake? The matplotlibrc should be fine, but I am not sure.

Your help would be greatly appreciated!

Many thanks,

David

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

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
------------------------------------------------------------------------

_______________________________________________
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

Dear Michael,

thanks for your input. So far, though, no luck.

I have deleted "SimHei" in matplotlibrc, and I can then continue generating CJK characters. The png is generated, the eps is not. Thus, no change. The error output is also the same:

RuntimeError: Face has no glyph names
WARNING: Failure executing file: <dea.py>

I have tried

  import matplotlib
  matplotlib.use('GtkCairo')

as you suggested, but they had no effect whatsoever. Even the error output is the same.

I attach my code, maybe that gives a hint.

Note: in line 327 and 328 of the matplotlibrc I have added

ps.fonttype=42
pdf.fonttype=42

whereas I have uncommented

pdf.fonttype : 3

Any ideas? I would most welcome any hint and suggestion!

Many thanks,

David

dea.png

dea.py (1002 Bytes)

···

On 17/03/10 04:15, Michael Droettboom wrote:

The font you are using (SimHei) does not have any glyph names -- these
are used in the Postscript backend to refer to glyphs outside of the
ASCII range. More specifically, it looks like it has at least one
invalid glyph name (glyph names can only contain ASCII characters) --
loading it in FontForge complains about this. I haven't come across such
a font before, but maybe that's common in CJK fonts. I don't know. I'm
looking through the spec to find a way that glyphs can be referenced
without a name, but I'm not finding one. Note, the PDF backend has the
same issue.

Do you have the same problem if you remove "SimHei" from the
font.sans-serif list and thus use "Adobe Song Std" instead? (I was able
to find an online download of SimHei to test with, but not Adobe Song Std).

As a workaround, the Cairo backend seems to handle this font just fine.
You can add

import matplotlib
matplotlib.use('GtkCairo')

to the top of your script.

Mike

David wrote:

Hello everybody,

I have a final problem with my graph. As a last step I produce an
*.eps file that I use in conjunction with LaTeX.

Here is the last part of my code:

# plt.title('Title')
xlab = plt.xlabel(u'输入 1')
#xlab.set_position((0.2, 0.1))
ylab = plt.ylabel(u'输入 2')
plt.grid(True)
plt.subplots_adjust(bottom=0.2)
plt.show()
plt.savefig('dea.eps')

plt.show() produces the correct output,

but

plt.savefig('dea.eps') produces an error (the error message is attached).

The error is clearly linked to the Chinese, as it runs through if I
take the Chinese out of the code.
Also, plt.savefig('dea.png') works fine.

Could anyone indicate where I would have to look for the mistake? The
matplotlibrc should be fine, but I am not sure.

Your help would be greatly appreciated!

Many thanks,

David

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

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

Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
------------------------------------------------------------------------

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

David wrote:

Dear Michael,

thanks for your input. So far, though, no luck.

I have deleted "SimHei" in matplotlibrc, and I can then continue generating CJK characters. The png is generated, the eps is not. Thus, no change. The error output is also the same:

RuntimeError: Face has no glyph names
WARNING: Failure executing file: <dea.py>

I have tried

import matplotlib
matplotlib.use('GtkCairo')

as you suggested, but they had no effect whatsoever. Even the error output is the same.

I'm surprised that isn't having any effect. The Cairo backend should not be running any code in backend_ps.py -- where the source of the error is. If you put "backend: GtkCairo" in your matplotlibrc, does that work?

What version of matplotlib are you running?

I attach my code, maybe that gives a hint.

Note: in line 327 and 328 of the matplotlibrc I have added

ps.fonttype=42
pdf.fonttype=42

whereas I have uncommented

pdf.fonttype : 3

Any ideas? I would most welcome any hint and suggestion!

I don't think these settings will resolve the problem -- either font type (42 or 3) still expects glyph names.

Mike

···

On 17/03/10 04:15, Michael Droettboom wrote:

The font you are using (SimHei) does not have any glyph names -- these
are used in the Postscript backend to refer to glyphs outside of the
ASCII range. More specifically, it looks like it has at least one
invalid glyph name (glyph names can only contain ASCII characters) --
loading it in FontForge complains about this. I haven't come across such
a font before, but maybe that's common in CJK fonts. I don't know. I'm
looking through the spec to find a way that glyphs can be referenced
without a name, but I'm not finding one. Note, the PDF backend has the
same issue.

Do you have the same problem if you remove "SimHei" from the
font.sans-serif list and thus use "Adobe Song Std" instead? (I was able
to find an online download of SimHei to test with, but not Adobe Song Std).

As a workaround, the Cairo backend seems to handle this font just fine.
You can add

import matplotlib
matplotlib.use('GtkCairo')

to the top of your script.

Mike

David wrote:

Hello everybody,

I have a final problem with my graph. As a last step I produce an
*.eps file that I use in conjunction with LaTeX.

Here is the last part of my code:

# plt.title('Title')
xlab = plt.xlabel(u'输入 1')
#xlab.set_position((0.2, 0.1))
ylab = plt.ylabel(u'输入 2')
plt.grid(True)
plt.subplots_adjust(bottom=0.2)
plt.show()
plt.savefig('dea.eps')

plt.show() produces the correct output,

but

plt.savefig('dea.eps') produces an error (the error message is attached).

The error is clearly linked to the Chinese, as it runs through if I
take the Chinese out of the code.
Also, plt.savefig('dea.png') works fine.

Could anyone indicate where I would have to look for the mistake? The
matplotlibrc should be fine, but I am not sure.

Your help would be greatly appreciated!

Many thanks,

David

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

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

Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
------------------------------------------------------------------------

_______________________________________________
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

Dear Michael,

I deeply appreciate your help with this!

I have tried

import matplotlib
matplotlib.use('GtkCairo')

as you suggested, but they had no effect whatsoever. Even the error
output is the same.

I'm surprised that isn't having any effect. The Cairo backend should not
be running any code in backend_ps.py -- where the source of the error
is. If you put "backend: GtkCairo" in your matplotlibrc, does that work?

No, in fact, after adding that line to matplotlibrc the CJK isn't even rendered in the png anymore! *

My error message has changed:

In [1]: run dea.py
/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py:614: DeprecationWarning: Use the new widget gtk.Tooltip
   self.tooltips = gtk.Tooltips()

(this with "backend: GtkCairo" in matplotlibrc and the following two lines in my dea.py:

import matplotlib
matplotlib.use('GtkCairo')

Incidentally, if I uncomment those two lines, then the (Western) font of my graph actually changes.

What version of matplotlib are you running?

In [2]: matplotlib.__version__
Out[2]: '0.99.0'

Note: in line 327 and 328 of the matplotlibrc I have added

ps.fonttype=42
pdf.fonttype=42

I haven taken those out again, because I got an error message.

I continue to be at a loss!

David

* I had the same problem yesterday, I solved it by reinstalling a backup of matplotlibrc. Weird.

matplotlibrc (17.5 KB)

···

On 17/03/10 20:34, Michael Droettboom wrote:

whereas I have uncommented

pdf.fonttype : 3

Any ideas? I would most welcome any hint and suggestion!

I don't think these settings will resolve the problem -- either font
type (42 or 3) still expects glyph names.

Mike

On 17/03/10 04:15, Michael Droettboom wrote:

The font you are using (SimHei) does not have any glyph names -- these
are used in the Postscript backend to refer to glyphs outside of the
ASCII range. More specifically, it looks like it has at least one
invalid glyph name (glyph names can only contain ASCII characters) --
loading it in FontForge complains about this. I haven't come across such
a font before, but maybe that's common in CJK fonts. I don't know. I'm
looking through the spec to find a way that glyphs can be referenced
without a name, but I'm not finding one. Note, the PDF backend has the
same issue.

Do you have the same problem if you remove "SimHei" from the
font.sans-serif list and thus use "Adobe Song Std" instead? (I was able
to find an online download of SimHei to test with, but not Adobe Song
Std).

As a workaround, the Cairo backend seems to handle this font just fine.
You can add

import matplotlib
matplotlib.use('GtkCairo')

to the top of your script.

Mike

David wrote:

Hello everybody,

I have a final problem with my graph. As a last step I produce an
*.eps file that I use in conjunction with LaTeX.

Here is the last part of my code:

# plt.title('Title')
xlab = plt.xlabel(u'输入 1')
#xlab.set_position((0.2, 0.1))
ylab = plt.ylabel(u'输入 2')
plt.grid(True)
plt.subplots_adjust(bottom=0.2)
plt.show()
plt.savefig('dea.eps')

plt.show() produces the correct output,

but

plt.savefig('dea.eps') produces an error (the error message is
attached).

The error is clearly linked to the Chinese, as it runs through if I
take the Chinese out of the code.
Also, plt.savefig('dea.png') works fine.

Could anyone indicate where I would have to look for the mistake? The
matplotlibrc should be fine, but I am not sure.

Your help would be greatly appreciated!

Many thanks,

David

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

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

Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
------------------------------------------------------------------------

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

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

David wrote:

Dear Michael,

I have tried

import matplotlib
matplotlib.use('GtkCairo')

as you suggested, but they had no effect whatsoever. Even the error
output is the same.

I'm surprised that isn't having any effect. The Cairo backend should not
be running any code in backend_ps.py -- where the source of the error
is. If you put "backend: GtkCairo" in your matplotlibrc, does that work?

No, in fact, after adding that line to matplotlibrc the CJK isn't even rendered in the png anymore! *

My error message has changed:

In [1]: run dea.py
/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py:614: DeprecationWarning: Use the new widget gtk.Tooltip
  self.tooltips = gtk.Tooltips()

This is just a warning, and a benign one. It is not an exception as before.

(this with "backend: GtkCairo" in matplotlibrc and the following two lines in my dea.py:

import matplotlib
matplotlib.use('GtkCairo')

Incidentally, if I uncomment those two lines, then the (Western) font of my graph actually changes.

I'm completely stumped by this. The font rendering does look slightly different in the Cairo backend vs. the Agg backends, but I wouldn't expect major differences -- the font choice itself should be the same. I do see in the matplotlibrc that you attached that the "TkAgg" backend is being specified, not "GtkCairo".

I am able to get the Cairo backend to work just fine using matplotlib 0.99.0. What version of cairo and pycairo do you have installed?

What version of matplotlib are you running?

In [2]: matplotlib.__version__
Out[2]: '0.99.0'

Note: in line 327 and 328 of the matplotlibrc I have added

ps.fonttype=42
pdf.fonttype=42

I haven taken those out again, because I got an error message.

The error message may be related to using '=' rather than a ':'. In any case, these settings don't affect by the Cairo backend so should have no effect.

I think this is just a problem related to configuration. Once you get the Cairo backend selected (and confirm that is the case), then hopefully all will work.

Mike

···

On 17/03/10 20:34, Michael Droettboom wrote:

I continue to be at a loss!

David

* I had the same problem yesterday, I solved it by reinstalling a backup of matplotlibrc. Weird.

whereas I have uncommented

pdf.fonttype : 3

Any ideas? I would most welcome any hint and suggestion!

I don't think these settings will resolve the problem -- either font
type (42 or 3) still expects glyph names.

Mike

On 17/03/10 04:15, Michael Droettboom wrote:

The font you are using (SimHei) does not have any glyph names -- these
are used in the Postscript backend to refer to glyphs outside of the
ASCII range. More specifically, it looks like it has at least one
invalid glyph name (glyph names can only contain ASCII characters) --
loading it in FontForge complains about this. I haven't come across such
a font before, but maybe that's common in CJK fonts. I don't know. I'm
looking through the spec to find a way that glyphs can be referenced
without a name, but I'm not finding one. Note, the PDF backend has the
same issue.

Do you have the same problem if you remove "SimHei" from the
font.sans-serif list and thus use "Adobe Song Std" instead? (I was able
to find an online download of SimHei to test with, but not Adobe Song
Std).

As a workaround, the Cairo backend seems to handle this font just fine.
You can add

import matplotlib
matplotlib.use('GtkCairo')

to the top of your script.

Mike

David wrote:

Hello everybody,

I have a final problem with my graph. As a last step I produce an
*.eps file that I use in conjunction with LaTeX.

Here is the last part of my code:

# plt.title('Title')
xlab = plt.xlabel(u'输入 1')
#xlab.set_position((0.2, 0.1))
ylab = plt.ylabel(u'输入 2')
plt.grid(True)
plt.subplots_adjust(bottom=0.2)
plt.show()
plt.savefig('dea.eps')

plt.show() produces the correct output,

but

plt.savefig('dea.eps') produces an error (the error message is
attached).

The error is clearly linked to the Chinese, as it runs through if I
take the Chinese out of the code.
Also, plt.savefig('dea.png') works fine.

Could anyone indicate where I would have to look for the mistake? The
matplotlibrc should be fine, but I am not sure.

Your help would be greatly appreciated!

Many thanks,

David

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

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

Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
------------------------------------------------------------------------

_______________________________________________
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

Dear Mike, dear list,

thanks for the continued help!
Here are my 'news':

import matplotlib
matplotlib.use('GtkCairo')

Incidentally, if I uncomment those two lines, then the (Western) font
of my graph actually changes.

I'm completely stumped by this.

Just now I couldn't reproduce this. However, the fonts in the png and eps are quite different.

When I run my dea.py with the attached matplotlibrc, then I get both a png and an eps, however, the Chinese is still not rendered (see attachments)

I noticed the following in the ~rc:
cairo.format : png # png, ps, pdf, svg

But having it in or out makes no difference.

I

do see in the matplotlibrc that you attached that the "TkAgg" backend is
being specified, not "GtkCairo".

I changed this now.

I am able to get the Cairo backend to work just fine using matplotlib
0.99.0. What version of cairo and pycairo do you have installed?

python-cairo: 1.8.6-1ubuntu1

In [15]: cairo.version
Out[15]: '1.8.6'

I wasn't able to find pycairo on my system (even after installing python-cairo-dev). I belive pycairo and python-cairo are in fact the same thing.

Google found this:

"Just for your info if your interested in programming with cairo on ubuntu. I wanted to add svg, ps and pdf support to cairo (the ubuntu packages don't support these cairo render backends yet.)"
https://wiki.ubuntu.com/CairoPythonUbuntu

Could this be the reason for my troubles (under Ubuntu)?

ps.fonttype=42
pdf.fonttype=42

I haven taken those out again, because I got an error message.

The error message may be related to using '=' rather than a ':'. In any
case, these settings don't affect by the Cairo backend so should have no
effect.

I changed the = for a colon, yielding a nasty message:

david@...859...:~/Documents/PhD/Dissertation/LaTeX/figures$ python dea.py
/usr/lib/pymodules/python2.6/matplotlib/__init__.py:653: UserWarning: Duplicate key in file "/etc/matplotlibrc", line #329
   warnings.warn('Duplicate key in file "%s", line #%d'%(fname,cnt))

Hopefully we will get to the bottom of this! I am sorry to bother you with all this -- and appreciate your efforts!

Greeting from Beijing,

David

matplotlibrc (17.6 KB)

dea.eps (18.2 KB)

dea.png

dea.py (1.05 KB)

···

On 18/03/10 22:22, Michael Droettboom wrote:

David wrote:

Dear Mike, dear list,

thanks for the continued help!
Here are my 'news':

import matplotlib
matplotlib.use('GtkCairo')

Incidentally, if I uncomment those two lines, then the (Western) font
of my graph actually changes.

I'm completely stumped by this.

Just now I couldn't reproduce this. However, the fonts in the png and eps are quite different.

When I run my dea.py with the attached matplotlibrc, then I get both a png and an eps, however, the Chinese is still not rendered (see attachments)

I noticed the following in the ~rc:
cairo.format : png # png, ps, pdf, svg

But having it in or out makes no difference.

The Cairo backend is still not being selected. By looking at the comments in the file, it's clear that the .eps file attached is being produced by the main matplotlib PS backend.

I think I've figured out what may be the problem. The Cairo backend is not able to produce a .eps file, only a .ps (haven't investigated enough yet to determine if this is a shortcoming of Cairo itself or just the Cairo backend in matplotlib). In any case, first confirm that you have the Cairo backend selected (which still doesn't seem to be working for you, and I'm not sure why). See this page for more info on selecting backends:

http://matplotlib.sourceforge.net/faq/installing_faq.html#backends

You can confirm you are using the Cairo backend by printing matplotlib.get_backend().

Once that's resolved, try saving a ".ps" file (not ".eps"). That should work. You can always use ps2eps after the fact on this file.

I

do see in the matplotlibrc that you attached that the "TkAgg" backend is
being specified, not "GtkCairo".

I changed this now.

I am able to get the Cairo backend to work just fine using matplotlib
0.99.0. What version of cairo and pycairo do you have installed?

python-cairo: 1.8.6-1ubuntu1

In [15]: cairo.version
Out[15]: '1.8.6'

I wasn't able to find pycairo on my system (even after installing python-cairo-dev). I belive pycairo and python-cairo are in fact the same thing.

Yes, they are. pycairo is the official name of the project. python-cairo is the name of the Ubuntu/Debian package for that project.

Google found this:

"Just for your info if your interested in programming with cairo on ubuntu. I wanted to add svg, ps and pdf support to cairo (the ubuntu packages don't support these cairo render backends yet.)"
CairoPythonUbuntu - Ubuntu Wiki

Could this be the reason for my troubles (under Ubuntu)?

That seems to be very old. Also, if that were the case, matplotlib would raise an exception like this: "cairo has not been compiled with PS support enabled".

ps.fonttype=42
pdf.fonttype=42

I haven taken those out again, because I got an error message.

The error message may be related to using '=' rather than a ':'. In any
case, these settings don't affect by the Cairo backend so should have no
effect.

I changed the = for a colon, yielding a nasty message:

david@...859...:~/Documents/PhD/Dissertation/LaTeX/figures$ python dea.py
/usr/lib/pymodules/python2.6/matplotlib/__init__.py:653: UserWarning: Duplicate key in file "/etc/matplotlibrc", line #329
  warnings.warn('Duplicate key in file "%s", line #%d'%(fname,cnt))

That means exactly what it says: you have the same setting appearing more than once in the file. Each setting can only appear at most once. But again, these settings are not used by the Cairo backend, so are irrelevant to the solution at hand.

Hope this helps.

Mike

···

On 18/03/10 22:22, Michael Droettboom wrote:

Hopefully we will get to the bottom of this! I am sorry to bother you with all this -- and appreciate your efforts!

Greeting from Beijing,

David

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

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello Mike, dear list,

I am now able to generate a ps (and png) file with CJK characters (eps does NOT work).

But my paths was rather surprising:
* I put SimHei back at first position in matplotlibrc:
  font.sans-serif: SimHei, ~
* the following I took out of my dea.py:
  #import matplotlib
  #matplotlib.use('GtkCairo')
* also, I have taken out:
  #rcParams['font.sans-serif'] = ['Adobe Song Std']
  #rcParams['font.sans-serif'] = ['SimHei']
Note here that when I take the 'Adobe Song' line out, no CJK gets produced. The 'SimHei' line makes no difference.

I can confirm that:
In [9]: matplotlib.get_backend()
Out[9]: 'GTKCairo'

And: no eps gets generated.

Basically I therefore followed the instructions here [Chinese]:
http://hi.baidu.com/lijiangshui/blog/item/a0aad703cd65ee7e3812bb49.html

While eps generation continues not to work, my system is now, via ps2eps, productive.

Thanks for all your help, Mike!

David

dea.ps (19.7 KB)

dea.py (1.08 KB)