matplotlib-users Mailing List for matplotlib (Page 8)

I'm having troubles saving figures as PDF.
Matplotlib version 0.90.1
Simple example below.

Cheers,
Alan Isaac


Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylab
>>> fig = pylab.figure()
>>> pylab.plot([1,2,3])
[<matplotlib.lines.Line2D instance at 0x016FF828>]
>>> fig.savefig('c:/temp/temp.pdf')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python25\Lib\site-packages\matplotlib\figure.py", line 759, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_tkagg.py", line 188, in print_figu
re
    **kwargs)
  File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py", line 497, in print_figure

    printfunc(filename, dpi, facecolor, edgecolor, orientation, **kwargs)
  File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 1395, in print_figur
e
    file.close()
  File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 401, in close
    self.writeFonts()
  File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 456, in writeFonts
    fontdictObject = self.embedTTF(filename)
  File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 508, in embedTTF
    widths = [ get_char_width(charcode) for charcode in range(firstchar, lastchar+1) ]
  File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 505, in get_char_wid
th
    unicode = cp1252.decoding_map[charcode] or 0
AttributeError: 'module' object has no attribute 'decoding_map'
>>>

Michael Droettboom wrote:
> Bill Dandreta wrote:
>> This info may or may not be useful. If I save a plot with savefig()
>> without specifying a figsize, sometimes the figure gets clipped. What
>> gets saved is the portion of the image that show() displays. I
>> determined experimentally that figsize=(13,10) causes show() to open the
>> image at full screen size and so far using that size saves an unclipped
>> image.
>
> Is this with 0.90.1 or a SVN version?  What backend are you using?
dev-python/matplotlib
     Installed versions:  0.90.1  (01:40:48 06/08/07)  (doc examples gtk tk)

dev-lang/python
     Installed versions:  2.4.4-r5  (2.4)  (19:12:16 09/23/07)  (berkdb
-bootstrap -build doc examples gdbm ipv6 ncurses -nocxx -nothreads
readline ssl tk -ucs2)

$ pkg-config --version libpng
0.21

~/.matplotlib/matplotlibrc:
backend      : GTKAgg
numerix      : numpy
units        : True

-- 
Bill

wjd...@at...

Gentoo Linux X86_64 2.6.20-gentoo-r8

Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/

All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth.

Hmmm.  I'm very surprised that this change could cause that.  All it 
does is add an additional metadata chunk to the PNG file, which 
shouldn't have any affect on the image data itself.  simple_plot.py 
works fine for me in GIMP 2.0.5 both before and after this change.  Can 
you verify that this plot was working before the change to save the 
resolution in the PNG file?  If so, can you send me the source for your 
plot and the PNG file?  Also, what version of libpng are you using? 
(pkg-config --version libpng should display this on most recent Linux 
distros).

Cheers,
Mike

Wayne E. Harlan wrote:
> Not quite.  The figure opens at the correct size in the gimp but all I 
> see is background - no plot stuff.
> 
> Wayne
> 
> Michael Droettboom wrote:
>> This is now added in SVN, and only for the Agg backend(s).  It won't 
>> work with some of the other ways to save PNG files, such as Gdk, Wx 
>> (non-Agg) and Cairo.  If anyone was any thoughts about how to support 
>> saving the resolution in those backends, please share.
>>
>> Also note that resolution is saved in "dots per meter" in PNG files, 
>> so rounding error makes things slightly off -- for instance, 100 dpi 
>> is shows up as 99.999998 dpi in the GIMP.
>>
>> Cheers,
>> Mike
>>
>> Michael Droettboom wrote:
>>> I'll look into this.  I actually made a similar fix on another 
>>> project I used to work on...  It should be theoretically possible, 
>>> barring any roadblocks from how matplotlib is doing things.
>>>
>>> Cheers,
>>> Mike
>>>
>>> Wayne E. Harlan wrote:
>>>> I would like to follow up on my first response to Bill.  It probably 
>>>> should be a new thread, but I'll start here.  When png files are 
>>>> saved with a DPI=300 argument, and I open them in the Gimp, the dpi 
>>>> is only 72 (default ?).  As I understand it, the dpi setting in the 
>>>> graphics file tells the application opening it how big to display 
>>>> it.  When I use savefig with a DPI=300 and the plot figure I am 
>>>> saving was created with figsize=(6,4.5) I expect the figure to open 
>>>> in word or swriter at the size I specified (6" by 4.5") with the 
>>>> appropriate number of pixels.  However, at present, that does not 
>>>> happen.  The number of pixels in the figure is correct but I have to 
>>>> resize it manually to get the right size.  Can this be fixed ?
>>>>
>>>> Thanks,
>>>>
>>>> Wayne
>>>>
>>>> Bill Dandreta wrote:
>>>>> I resolved the problem. It was unrelated to mpl. xv and gimp were
>>>>> complied w/o png support. Recompiling with png support resolved the 
>>>>> problem.
>>>>>
>>>>>   
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems?  Stop.
>>>> Now Search log events and configuration files using AJAX and a browser.
>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>

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

Not quite.  The figure opens at the correct size in the gimp but all I 
see is background - no plot stuff.

Wayne

Michael Droettboom wrote:
> This is now added in SVN, and only for the Agg backend(s).  It won't 
> work with some of the other ways to save PNG files, such as Gdk, Wx 
> (non-Agg) and Cairo.  If anyone was any thoughts about how to support 
> saving the resolution in those backends, please share.
>
> Also note that resolution is saved in "dots per meter" in PNG files, 
> so rounding error makes things slightly off -- for instance, 100 dpi 
> is shows up as 99.999998 dpi in the GIMP.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
>> I'll look into this.  I actually made a similar fix on another 
>> project I used to work on...  It should be theoretically possible, 
>> barring any roadblocks from how matplotlib is doing things.
>>
>> Cheers,
>> Mike
>>
>> Wayne E. Harlan wrote:
>>> I would like to follow up on my first response to Bill.  It probably 
>>> should be a new thread, but I'll start here.  When png files are 
>>> saved with a DPI=300 argument, and I open them in the Gimp, the dpi 
>>> is only 72 (default ?).  As I understand it, the dpi setting in the 
>>> graphics file tells the application opening it how big to display 
>>> it.  When I use savefig with a DPI=300 and the plot figure I am 
>>> saving was created with figsize=(6,4.5) I expect the figure to open 
>>> in word or swriter at the size I specified (6" by 4.5") with the 
>>> appropriate number of pixels.  However, at present, that does not 
>>> happen.  The number of pixels in the figure is correct but I have to 
>>> resize it manually to get the right size.  Can this be fixed ?
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> Bill Dandreta wrote:
>>>> I resolved the problem. It was unrelated to mpl. xv and gimp were
>>>> complied w/o png support. Recompiling with png support resolved the 
>>>> problem.
>>>>
>>>>   
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>

Bill Dandreta wrote:
> Wayne E. Harlan wrote:
>> I would like to follow up on my first response to Bill.  It probably 
>> should be a new thread, but I'll start here.  When png files are saved 
>> with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 
>> (default ?).  As I understand it, the dpi setting in the graphics file 
>> tells the application opening it how big to display it.  When I use 
>> savefig with a DPI=300 and the plot figure I am saving was created with 
>> figsize=(6,4.5) I expect the figure to open in word or swriter at the 
>> size I specified (6" by 4.5") with the appropriate number of pixels.  
>> However, at present, that does not happen.  The number of pixels in the 
>> figure is correct but I have to resize it manually to get the right 
>> size.  Can this be fixed ?
> This info may or may not be useful. If I save a plot with savefig()
> without specifying a figsize, sometimes the figure gets clipped. What
> gets saved is the portion of the image that show() displays. I
> determined experimentally that figsize=(13,10) causes show() to open the
> image at full screen size and so far using that size saves an unclipped
> image.

Is this with 0.90.1 or a SVN version?  What backend are you using?

Cheers,
Mike


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

Wayne E. Harlan wrote:
> I would like to follow up on my first response to Bill.  It probably 
> should be a new thread, but I'll start here.  When png files are saved 
> with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 
> (default ?).  As I understand it, the dpi setting in the graphics file 
> tells the application opening it how big to display it.  When I use 
> savefig with a DPI=300 and the plot figure I am saving was created with 
> figsize=(6,4.5) I expect the figure to open in word or swriter at the 
> size I specified (6" by 4.5") with the appropriate number of pixels.  
> However, at present, that does not happen.  The number of pixels in the 
> figure is correct but I have to resize it manually to get the right 
> size.  Can this be fixed ?
This info may or may not be useful. If I save a plot with savefig()
without specifying a figsize, sometimes the figure gets clipped. What
gets saved is the portion of the image that show() displays. I
determined experimentally that figsize=(13,10) causes show() to open the
image at full screen size and so far using that size saves an unclipped
image.

-- 
Bill

wjd...@at...

Gentoo Linux X86_64 2.6.20-gentoo-r8

Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/

All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth.

This is now added in SVN, and only for the Agg backend(s).  It won't 
work with some of the other ways to save PNG files, such as Gdk, Wx 
(non-Agg) and Cairo.  If anyone was any thoughts about how to support 
saving the resolution in those backends, please share.

Also note that resolution is saved in "dots per meter" in PNG files, so 
rounding error makes things slightly off -- for instance, 100 dpi is 
shows up as 99.999998 dpi in the GIMP.

Cheers,
Mike

Michael Droettboom wrote:
> I'll look into this.  I actually made a similar fix on another project I 
> used to work on...  It should be theoretically possible, barring any 
> roadblocks from how matplotlib is doing things.
> 
> Cheers,
> Mike
> 
> Wayne E. Harlan wrote:
>> I would like to follow up on my first response to Bill.  It probably 
>> should be a new thread, but I'll start here.  When png files are saved 
>> with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 
>> (default ?).  As I understand it, the dpi setting in the graphics file 
>> tells the application opening it how big to display it.  When I use 
>> savefig with a DPI=300 and the plot figure I am saving was created with 
>> figsize=(6,4.5) I expect the figure to open in word or swriter at the 
>> size I specified (6" by 4.5") with the appropriate number of pixels.  
>> However, at present, that does not happen.  The number of pixels in the 
>> figure is correct but I have to resize it manually to get the right 
>> size.  Can this be fixed ?
>>
>> Thanks,
>>
>> Wayne
>>
>> Bill Dandreta wrote:
>>> I resolved the problem. It was unrelated to mpl. xv and gimp were
>>> complied w/o png support. Recompiling with png support resolved the problem.
>>>
>>>   
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

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

I'll look into this.  I actually made a similar fix on another project I 
used to work on...  It should be theoretically possible, barring any 
roadblocks from how matplotlib is doing things.

Cheers,
Mike

Wayne E. Harlan wrote:
> I would like to follow up on my first response to Bill.  It probably 
> should be a new thread, but I'll start here.  When png files are saved 
> with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 
> (default ?).  As I understand it, the dpi setting in the graphics file 
> tells the application opening it how big to display it.  When I use 
> savefig with a DPI=300 and the plot figure I am saving was created with 
> figsize=(6,4.5) I expect the figure to open in word or swriter at the 
> size I specified (6" by 4.5") with the appropriate number of pixels.  
> However, at present, that does not happen.  The number of pixels in the 
> figure is correct but I have to resize it manually to get the right 
> size.  Can this be fixed ?
> 
> Thanks,
> 
> Wayne
> 
> Bill Dandreta wrote:
>> I resolved the problem. It was unrelated to mpl. xv and gimp were
>> complied w/o png support. Recompiling with png support resolved the problem.
>>
>>   
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

Okay, I got further. I needed to use CC for c++ files.

But now I see another error:

/opt/SUNWspro/bin/cc -DNDEBUG -O -Kpic -I/usr/local/include/python2.5
-c lib/matplotlib/enthought/traits/ctraits.c -o
build/temp.solaris-2.10-i86pc-2.5/lib/matplotlib/enthought/traits/ctraits.o
"lib/matplotlib/enthought/traits/ctraits.c", line 174: Warning: String
literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 174: Warning: String
literal converted to char* in formal argument format in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 355: Warning: String
literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 355: Warning: String
literal converted to char* in formal argument format in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 371: Warning: String
literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 371: Warning: String
literal converted to char* in formal argument format in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 387: Warning: String
literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 387: Warning: String
literal converted to char* in formal argument format in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 405: Warning: String
literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 405: Warning: String
literal converted to char* in formal argument format in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 448: Warning: String
literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 448: Warning: String
literal converted to char* in formal argument format in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 502: Error:
Unexpected type name "PyObject" encountered.
"lib/matplotlib/enthought/traits/ctraits.c", line 502: Error: Operand
expected instead of "class".
"lib/matplotlib/enthought/traits/ctraits.c", line 502: Error: Multiple
declaration for has_traits_object.
"lib/matplotlib/enthought/traits/ctraits.c", line 502: Error: ","
expected instead of "*".
"lib/matplotlib/enthought/traits/ctraits.c", line 502: Error: Use ";"
to terminate declarations.
"lib/matplotlib/enthought/traits/ctraits.c", line 502: Error: A
declaration was expected instead of ",".
"lib/matplotlib/enthought/traits/ctraits.c", line 503: Error: Multiple
declaration for PyObject.
"lib/matplotlib/enthought/traits/ctraits.c", line 503: Error: ","
expected instead of "*".
"lib/matplotlib/enthought/traits/ctraits.c", line 508: Error: A
declaration was expected instead of "if".
"lib/matplotlib/enthought/traits/ctraits.c", line 508: Error: No
direct declarator preceding "(".
"lib/matplotlib/enthought/traits/ctraits.c", line 510: Error: No
direct declarator preceding "(".
"lib/matplotlib/enthought/traits/ctraits.c", line 511: Error: obj is
not defined.
"lib/matplotlib/enthought/traits/ctraits.c", line 513: Error: value is
not defined.
"lib/matplotlib/enthought/traits/ctraits.c", line 515: Error: obj is
not defined.
"lib/matplotlib/enthought/traits/ctraits.c", line 517: Error: value is
not defined.
"lib/matplotlib/enthought/traits/ctraits.c", line 518: Error: result
is not defined.
"lib/matplotlib/enthought/traits/ctraits.c", line 518: Error: Expected
an expression.
"lib/matplotlib/enthought/traits/ctraits.c", line 518: Error:
Identifier expected instead of ",".
"lib/matplotlib/enthought/traits/ctraits.c", line 520: Error: result
is not defined.
"lib/matplotlib/enthought/traits/ctraits.c", line 560: Warning: String
literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 560: Warning: String
literal converted to char* in formal argument format in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 1007: Warning:
String literal converted to char* in initialization.
"lib/matplotlib/enthought/traits/ctraits.c", line 1054: Warning
(Anachronism): Using _object*(*)(_typeobject*,_object*,_object*) to
initialize extern "C" _object*(*)(_typeobject*,_object*,_object*).
"lib/matplotlib/enthought/traits/ctraits.c", line 1085: Error: Only a
function may be called.
"lib/matplotlib/enthought/traits/ctraits.c", line 1088: Error: Only a
function may be called.
"lib/matplotlib/enthought/traits/ctraits.c", line 2155: Warning:
String literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 2656: Warning:
String literal converted to char* in formal argument m in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 2656: Warning:
String literal converted to char* in formal argument format in call to
PyObject_CallMethod(_object*, char*, char*, ...).
"lib/matplotlib/enthought/traits/ctraits.c", line 3324: Warning:
String literal converted to char* in initialization.
"lib/matplotlib/enthought/traits/ctraits.c", line 3325: Warning:
String literal converted to char* in initialization.
"lib/matplotlib/enthought/traits/ctraits.c", line 3326: Warning:
String literal converted to char* in initialization.
"lib/matplotlib/enthought/traits/ctraits.c", line 3335: Error:
Multiple declaration for trait_type.
"lib/matplotlib/enthought/traits/ctraits.c", line 3632: Warning:
String literal converted to char* in initialization.
"lib/matplotlib/enthought/traits/ctraits.c", line 3632: Warning:
String literal converted to char* in initialization.
"lib/matplotlib/enthought/traits/ctraits.c", line 3743: Error: In this
declaration "getclassname" is of an incomplete type "void".
"lib/matplotlib/enthought/traits/ctraits.c", line 3743: Error:
Unexpected type name "PyObject" encountered.
"lib/matplotlib/enthought/traits/ctraits.c", line 3743: Error: Operand
expected instead of "class".
Compilation aborted, too many Error messages.
error: command '/opt/SUNWspro/bin/cc' failed with exit status 1

Trying to compile on Solaris using Sun Studio 12.

any ideas?

% python2.5 setup.py build
building for GTK requires pygtk; you must be able to "import gtk" in
your build/install environment
TKAgg requires TkInter
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc ->
build/lib.solaris-2.10-i86pc-2.5/matplotlib/mpl-datarunning build_ext
building 'matplotlib._agg' extension
/opt/SUNWspro/bin/cc -DNDEBUG -O -Kpic -Iagg23/include -Isrc -Iswig
-I/usr/local/include/python2.5 -c src/agg.cxx -o
build/temp.solaris-2.10-i86pc-2.5/src/agg.o
cc: No input file specified, no output generated
error: command '/opt/SUNWspro/bin/cc' failed with exit status 1

I would like to follow up on my first response to Bill.  It probably 
should be a new thread, but I'll start here.  When png files are saved 
with a DPI=300 argument, and I open them in the Gimp, the dpi is only 72 
(default ?).  As I understand it, the dpi setting in the graphics file 
tells the application opening it how big to display it.  When I use 
savefig with a DPI=300 and the plot figure I am saving was created with 
figsize=(6,4.5) I expect the figure to open in word or swriter at the 
size I specified (6" by 4.5") with the appropriate number of pixels.  
However, at present, that does not happen.  The number of pixels in the 
figure is correct but I have to resize it manually to get the right 
size.  Can this be fixed ?

Thanks,

Wayne

Bill Dandreta wrote:
> I resolved the problem. It was unrelated to mpl. xv and gimp were
> complied w/o png support. Recompiling with png support resolved the problem.
>
>   

Eric Firing wrote:
> Bill Dandreta wrote:
>> There appears to be a problem with .png files that matplotlib
>> creates. Some programs (like GIMP <http://www.gimp.org/> and xv)
>> <http://www.trilon.com/xv/> do not identify them as png files and
>> cannot display them.
>
> Would you be more specific, please?  I can't reproduce the problem.  I
> don't have xv, but on my ubuntu feisty machine the "file" command and
> gimp both recognize mpl-generated png files (using Agg backend).
>
> Do you have mpl-generated png files that are recognized by some
> display programs but not by gimp and xv?  If so, what are the programs
> that recognize them?  What version of mpl was used, and what backend? 
> Please provide an example.
I resolved the problem. It was unrelated to mpl. xv and gimp were
complied w/o png support. Recompiling with png support resolved the problem.

-- 
Bill

wjd...@at...

Gentoo Linux X86_64 2.6.20-gentoo-r8

Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/

All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth.

Bill Dandreta wrote:
> There appears to be a problem with .png files that matplotlib creates. 
> Some programs (like GIMP <http://www.gimp.org/> and xv) 
> <http://www.trilon.com/xv/> do not identify them as png files and cannot 
> display them.

Would you be more specific, please?  I can't reproduce the problem.  I 
don't have xv, but on my ubuntu feisty machine the "file" command and 
gimp both recognize mpl-generated png files (using Agg backend).

Do you have mpl-generated png files that are recognized by some display 
programs but not by gimp and xv?  If so, what are the programs that 
recognize them?  What version of mpl was used, and what backend?  Please 
provide an example.

Eric

Wayne E. Harlan wrote:
> Bill:
>
> I do not have that problem using mpl-0.90.1 or svn which I checked out
> and installed yesterday.  I have gimp-2.2.17 and have no problems
> opening them on my linux system or my two XP systems at work.  The
> issue I do find is that when I specify the DPI in the savefig command,
> it does not properly get encoded into the png, although the size of
> the graphic is set accordingly.  So maybe that is a clue to what's
> happening to you.  You are saving them as "something.png", right ?
>
I discovered the problem, xv and gimp were compiled without png support.

Thanks for your input.

-- 
Bill

wjd...@at...

Gentoo Linux X86_64 2.6.20-gentoo-r8

Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/

All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth.

Bill:

I do not have that problem using mpl-0.90.1 or svn which I checked out 
and installed yesterday.  I have gimp-2.2.17 and have no problems 
opening them on my linux system or my two XP systems at work.  The issue 
I do find is that when I specify the DPI in the savefig command, it does 
not properly get encoded into the png, although the size of the graphic 
is set accordingly.  So maybe that is a clue to what's happening to 
you.  You are saving them as "something.png", right ?

Wayne

Bill Dandreta wrote:
> There appears to be a problem with .png files that matplotlib creates. 
> Some programs (like GIMP <http://www.gimp.org/> and xv) 
> <http://www.trilon.com/xv/> do not identify them as png files and 
> cannot display them.
>

There appears to be a problem with .png files that matplotlib creates.
Some programs (like GIMP <http://www.gimp.org/> and xv)
<http://www.trilon.com/xv/> do not identify them as png files and cannot
display them.

-- 
Bill

wjd...@at...

Gentoo Linux X86_64 2.6.20-gentoo-r8

Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/

All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth.

Eric Firing wrote:

> The TkAgg backend works on my system, stock ubuntu feisty with only 
> numpy and mpl from svn.  tk/tcl is 8.4.
>
> Eric
>
Eric:

My processor is a 32 bit Athlon from about 5 or 6 years ago.  The 
Tkinter was built along with python and I did one particular sed:

sed -i 's|#    -ltk8.2 -ltcl8.2|    -ltk8.4 -ltcl8.4|' Setup.dist

so python would look for the version of tcl/tk that I have.  I'll review 
that whole process later and report back if I find something interesting.
------------------------------------------------------------------------

Just want to follow up with you on the results.  Since my Xorg 7.2 is 
installed in /usr, I found that the original installation of Python and 
Tkinter needed some changes to Modules/Setup.dist.  I used the following
sed's:

sed -i 's|# _tkinter| _tkinter|' Setup.dist  ---to enable tkinter
sed -i 's|#	-L/usr/local|	-L/usr|' Setup.dist  ---to locate tcl/tk libs
sed -i 's|#	-I/usr/local|	-I/usr|' Setup.dist  ---to locate tcl/tk headers
sed -i 's|#	-L/usr/X11R6|	-L/usr|' Setup.dist  ---to locate X11 libs
sed -i 's|#	-I/usr/X11R6|	-I/usr|' Setup.dist  ---to locate X11 headers
sed -i 's|#	-ltk8.2 -ltcl8.2|	-ltk8.4 -ltcl8.4|' Setup.dist  ---for correct version
sed -i 's|#	-lX11|	-lX11|' Setup.dist  ---required to build tkinter

So I completely removed python, numpy, mpl, etc and reinstalled everything, 
including the GTK requirements that got me going last time.  The installed 
matplotlibrc called for the GTKAgg backend and that worked.  But when I changed
that to call for TkAgg, the same thing happened as last time (the window appears
briefly and then segfaults).  So I'm puzzled but at least I have a working 
installation with GTK.

Thanks,

Wayne

I am trying to draw a stacked bar chart where the 1st section is much
much larger than the others.

Is there a way to have a break in the chart passing through the 1st bar
that indicates part of the bar is missing?

-- 
Bill

wjd...@at...

Gentoo Linux X86_64 2.6.20-gentoo-r8

Reclaim Your Inbox with http://www.mozilla.org/products/thunderbird/

All things cometh to he who waiteth as long as he who waiteth worketh like hell while he waiteth.

Here's some (incomplete) code snippets I used to place an extra 
x-axis below the normal one. I hope this helps. I agree that more 
axes can always be added at an arbitrary offset, although I did not 
try that.

import numpy as N
import matplotlib
matplotlib.use("TkAgg")
import pylab as PLT
from matplotlib.font_manager import FontProperties # For setting 
legend font props.


     f1 = PLT.figure(1, figsize=(7.5,4.0))
     ax1 = f1.add_axes([0.2, 0.25, 0.6, 0.6]) # This is "normal" axis
     PLT.hold(False)
     ax1.set_autoscale_on(False) # So that I can turn off autoscaling
     PLT.plot(lt, drift, '-', linewidth=3, label=legtext)

     # This axis is LT. Set the ticks manually.
     xticks = N.array([5.0, 8.0, 11.0, 14.0, 17.0, 20.0])
     ax1.set_xticks(xticks.tolist())
     ax1.set_autoscale_on(False) # So that I can turn off autoscaling

     # Now manually create the second axis (UT) slightly below
     PLT.hold(False)
     ax2 = f1.add_axes([0.2, 0.15, 0.6, 0.6], frameon=False)
     ax2.set_yticks([])
     # Apply offset to get UT scale for second axis
     ax2.set_xlim([xticks[0]+offset, xticks[len(xticks)-1]+offset])
     ax2.set_xticks((xticks+offset).tolist())
     # Make tick lines invisible
     xtl = PLT.getp(ax2, 'xticklines')
     PLT.setp(xtl, 'visible', False)
     # Label the X ticks for first (LT) and second (UT) axes
     PLT.text(1.1, -0.1, 'LT', transform=ax1.transAxes)
     PLT.text(1.1, -0.25, 'UT', transform=ax1.transAxes)

-Tony

-- 
Tony Mannucci
Supervisor, Ionospheric and Atmospheric Remote Sensing Group
  Mail-Stop 138-308,                     Tel > (818) 354-1699
  Jet Propulsion Laboratory,              Fax > (818) 393-5115
  California Institute of Technology,     Email > Ton...@jp...
  4800 Oak Grove Drive,                   http://genesis.jpl.nasa.gov
  Pasadena, CA 91109

> On 10/5/07, James Boyle <bo...@ll...> wrote:
> > I wish to plot 3 lines on a single graph - each line requires a=20
> > separate y scaling but shares a common x.
> > The case for 2 such lines is handled by twinx as in the=20
> two_scales.py=20
> > example.
> >
> > I have not found an example of 3 lines ( or greater). In=20
> the case of=20
> > more than 2 scales the y axis scale would have to float, to=20
> the right=20
> > or left of the y axes defined for the first 2 lines.
>=20
> This is on the wish list, but is currently unsupported.
>=20
> JDH

Hmmm, unsupported, but working. See attached.  Maybe I've misunderstood,
though.

Anyway, I'm not complete sure of your context, but this plot was
generated in code, rather than using pylab.  I don't use pylab and I
don't know if there's an analogue to what I'll describe below.

Unfortunately the code used to generate this particular chart is much
more than what you're looking for (our current matplotlib based "plot"
object is currently 1500 lines of code on top of MPL).  It does,
however, allow me to plot a line on any of 4 independent "y" axes, and 2
"x" axes (and a bunch of other bells and whistles).

The underlying structure creates a "master" figure (X1Y1) and then
subsequent figures overlaid on top (ie in the same location by using
axes.get_position()).  Each subsequent figure uses an appropriate
"sharex=3D" in the call figure.add_axes(...).  Also significant are to
turn the frame off (frameon=3DFalse), and assign a label to each figure
(label=3D'myLabel') so that MPL doesn't try to combine figures for you.

In principle, I don't see why this can't be done for an arbitrary number
of subfigures, but practically, the plot start getting cluttered and
confusing pretty quickly.

I can't post the code, but if you have some more questions, I can try to
help!

Cheers,
Anthony.

> On 10/5/07, James Boyle <bo...@ll...> wrote:
>> I wish to plot 3 lines on a single graph - each line requires a 
>> separate y scaling but shares a common x.  I have not 
>> found an example of 3 lines ( or greater).


On Fri, 5 Oct 2007, John Hunter wrote:
> This is on the wish list, but is currently unsupported. 


If you just need an EPS or PDF, you can use PyX:
http://pyx.sourceforge.net/gallery/graphs/manyaxes.html

hth,
Alan Isaac

On 10/5/07, James Boyle <bo...@ll...> wrote:
> I wish to plot 3 lines on a single graph - each line requires a
> separate y scaling but shares a common x.
> The case for 2 such lines is handled by twinx as in the two_scales.py
> example.
>
> I have not found an example of 3 lines ( or greater). In the case of
> more than 2 scales the y axis scale would have to float, to the right
> or left of the y axes defined for the first 2 lines.

This is on the wish list, but is currently unsupported.

JDH

I wish to plot 3 lines on a single graph - each line requires a  
separate y scaling but shares a common x.
The case for 2 such lines is handled by twinx as in the two_scales.py  
example.

I have not found an example of 3 lines ( or greater). In the case of  
more than 2 scales the y axis scale would have to float, to the right  
or left of the y axes defined for the first 2 lines.

Thanks for any help.

---Jim

The short answer to your two messages is that pcolor and contour 
required gridded data in 2D arrays, and it looks like you are supplying 
1D arrays.  Look at the differences between what you have below and what 
is in the pcolor_demo that you started with.  Meshgrid is generating 2D 
arrays for X and Y so that Z is also 2D.  There are other ways of doing 
it, and for a Cartesian grid, X and Y don't actually have to be 
2D--although I find that there is now a bug in svn such that 1D x and y 
don't work.  I will fix that.  But in any case, Z *must* be a 2D array.

If the data you really want to plot are not already on a grid, then you 
will need to use a gridding routine, which is not included in mpl.

Eric


yadin Bocuma Rivas wrote:
> I i have tree lists of values
> list x of 100... values
> list y of 100.. values
> list mag of 100.. values
> list x and y are coordiantes of points
> and list Mag is magnitude of something at that point
> 
> how can i plot this quantities using pcolor
> 
> from __future__ import division
> from matplotlib.patches import Patch
> from pylab import *
> 
> def func3(x,y):
>     return (1- x/2 + x**5 + y**3)*exp(-x**2-y**2)
> 
> 
> # make these smaller to increase the resolution
> dx, dy = 0.5, 0.5
> 
> X = arange(-3.0, 3.0001, dx)
> 
> Y = arange(-3.0, 3.0001, dy)
> 
> Mag= X**2+Y**2
> 
> pcolor(X, Y, Mag, shading='flat')
> colorbar()
> axis([-3,3,-3,3])
> savefig('pcolor_demo')
> show()
> 
> 
> ------------------------------------------------------------------------
> 
> ¡Sé un mejor ambientalista!
> Encuentra consejos para cuidar el lugar donde vivimos en:
> http://telemundo.yahoo.com/promos/mejorambientalista.html
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,

I just encountered something odd.
I have (with import numpy as n and import pylab as pl) :
>>> x = n.arange(0, 2*n.pi, n.pi/30)
>>> z = n.array([n.cos(x), n.sin(x)]).T
If I draw a boxplot on z :
>>> pl.boxplot(z)
the values z are modified.
Is this a feature or a bug ?

Matthieu