matplotlib-users Mailing List for matplotlib

Hi Mike,
MD> It's worth noting -- these viewer differences do pop up from time to
MD> time. Since I don't have Foxit (or Windows) installed, I wonder if
MD> you could run an experiment. If you generate the PDF with mpl's
MD> Cairo backend, do you see the same behavior? If not, we can
MD> analyse the differences in the PDFs and possibly come up with a
MD> solution that will work.
I'm having real difficulty getting the cairo backend installed. If
anyone has any experience with pkg-config and windows, please let me
know. Specifically, I get the error:
Package 'cairo was not found in the pkg-config search path. Perhaps you
should add the directory containing `'cairo.pc' to the PKG_CONFIG_PATH
environment variable
...although I have, in fact, created this environment variable in windows.
Anyway, I have created a pdf using the wxagg backend, which yields the 
same result (markeredgewidth is always 1 when viewing with foxit). I 
will create a figure tonight from home (kubuntu) using the cairo 
backend, then examine it tomorrow at work (windows/foxit) and report back.
-- 
Christopher Brown, Ph.D.
Department of Speech and Hearing Science
Arizona State University

On Monday 05 May 2008 02:07:27 pm G Jones wrote:
> Hello,
> I don't know if this is a bug or not, but I notice that
> notify_axes_change is defined in each FigureManager* __init__
> function, and usually it is then passed to
> self.canvas.figure.add_axobserver(notify_axes_change), but this is not
> the case in FigureManagerQt, it is defined but never used in both
> backend_qt and backend_qt4.
Thanks for the report. It was kind of amusing, the line passing 
notify_axes_change to add_axobserver was improperly indented, so it never got 
called. Its fixed in the trunk for both backends.
Darren

Hello,
I don't know if this is a bug or not, but I notice that
notify_axes_change is defined in each FigureManager* __init__
function, and usually it is then passed to
self.canvas.figure.add_axobserver(notify_axes_change), but this is not
the case in FigureManagerQt, it is defined but never used in both
backend_qt and backend_qt4.
Glenn

On Mon, May 5, 2008 at 12:29 PM, Diwaker Gupta <diw...@gm...> wrote:
> I tried several different viewers (gv, kghostview etc), but all of
> them seem to have the same problem. What is strange is that all other
> text on the graph seems to render fine. I'm attaching the EPS for
> reference.
I suspect gv and kghostview are using the same rendering engine, so
these are probably not separate trials. I see the same thing on gv on
my system, but when I zoom in the problem disappears. Thus it looks
like a problem with the gv downsampling algorithm, at least in my
version. It doesn't appear to have anything to do with mpl.
JDH

On Mon, May 5, 2008 at 5:15 AM, Michael Droettboom <md...@st...> wrote:
> Try different Postscript viewers available on your platform -- it's
> possible one of them may produce better results. And, of course, the most
> important thing with Postscript is how it renders on your printer. If
> you're still seeing non-antialised fonts in everything, please attach the
> .eps file to this list and I'll have a look at it for anything strange.
I tried several different viewers (gv, kghostview etc), but all of
them seem to have the same problem. What is strange is that all other
text on the graph seems to render fine. I'm attaching the EPS for
reference.
Diwaker
-- 
http://floatingsun.net/

Eric Firing wrote:
> Diwaker Gupta wrote:
> 
>> Folks,
>>
>> I'm trying to make a simple plot where the xtick labels are rotated by
>> 45 degrees. The rotation works fine, but it destroys the anti aliasing
>> of the labels. The rest of the plot renders just fine. I'm using the
>> PS backend (savefig to an EPS). Something like this:
>>
>> labels = ["one", "two", "three"]
>> xticks(arange(len(labels)), labels, rotation="45")
>>
>> Is this a known issue? Any work arounds?
>>
>> Thanks,
>> Diwaker
>> 
>
> If your output is Postscript, then the antialiasing of text is being 
> done (or not done) by whatever is rendering your .ps file, not by mpl. 
> So there is nothing mpl can do about it.
> 
Try different Postscript viewers available on your platform -- it's 
possible one of them may produce better results. And, of course, the 
most important thing with Postscript is how it renders on your printer. 
If you're still seeing non-antialised fonts in everything, please attach 
the .eps file to this list and I'll have a look at it for anything strange.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

It's worth noting -- these viewer differences do pop up from time to 
time. Since I don't have Foxit (or Windows) installed, I wonder if you 
could run an experiment. If you generate the PDF with mpl's Cairo 
backend, do you see the same behavior? If not, we can analyse the 
differences in the PDFs and possibly come up with a solution that will work.
Cheers,
Mike
Christopher Brown wrote:
> Christopher Brown wrote:
> 
>> With mpl 0.91.2, the markeredgewidth property does not seem to have an 
>> effect when using the pdf backend (seems to always be 1, regardless of 
>> what I set it to, and it seems to be fine with other backends). Here is 
>> a minimal example:
>> 
>
> Interestingly, the error only shows up in the pdf viewer foxit (what I 
> happened to be using at the time). Other viewers display the markers 
> properly. Although it is still unclear to me whether it is an 
> mpl/pdf-backend error or a foxit rendering error.
>
> Sorry to trouble you all.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> 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

Diwaker Gupta wrote:
> Folks,
> 
> I'm trying to make a simple plot where the xtick labels are rotated by
> 45 degrees. The rotation works fine, but it destroys the anti aliasing
> of the labels. The rest of the plot renders just fine. I'm using the
> PS backend (savefig to an EPS). Something like this:
> 
> labels = ["one", "two", "three"]
> xticks(arange(len(labels)), labels, rotation="45")
> 
> Is this a known issue? Any work arounds?
> 
> Thanks,
> Diwaker
If your output is Postscript, then the antialiasing of text is being 
done (or not done) by whatever is rendering your .ps file, not by mpl. 
So there is nothing mpl can do about it.
Eric

Folks,
I'm trying to make a simple plot where the xtick labels are rotated by
45 degrees. The rotation works fine, but it destroys the anti aliasing
of the labels. The rest of the plot renders just fine. I'm using the
PS backend (savefig to an EPS). Something like this:
labels = ["one", "two", "three"]
xticks(arange(len(labels)), labels, rotation="45")
Is this a known issue? Any work arounds?
Thanks,
Diwaker
-- 
http://floatingsun.net/

Hello,
I did some quick tests of using pylab.figure() to create a figure
window, and then accessing the canvas to do blitted animation, which
is working well. I also reimplemented the resizeEvent handler to
update the region to be blitted. However, I have one major problem,
that when I click the X on the figure window, the window closes and
then my application wittingly tries to blit it and gives the error:
 self.SpecCanvas.blit(self.total_bbox)
 File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py",
line 144, in blit
 self.update(l, self.renderer.height-t, w, h)
RuntimeError: underlying C/C++ object has been deleted
I tried reimplementing the closeEvent handler, but my new handler
never seems to be executed. I am setting the close event handler like
this:
 self.SpecCanvas.closeEvent = closePyl
 def closePyl(self,event):
 print "hi"
 event.ignore()
 self.parent().SpecCanvas = None
Any ideas about how to keep the window from being destroyed before I
have a chance to know about it?
Also, should I be using ion() or ioff() for this type of application?
It seems that either works fine, and I can zoom/pan even while
blitting.
Thanks,
Glenn