Last year we implemented an object oriented plotting style system for our users
and I was able to convince our management that we should open source it. You
can find it here: https://github.com/nasa/mplStyle
Many (most?) of the existing MPL style systems seem to be built around RC
parameters
e specific questions feel free to send
them to me.
Ted
From: Thomas Caswell [tcasw...@gmail.com]
Sent: Thursday, January 08, 2015 11:14 AM
To: Drain, Theodore R (392P); matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] Date overhau
sday, January 08, 2015 10:57 AM
To: Drain, Theodore R (392P); matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] Date overhaul?
One of the other driving factors to over-haul the default date handling is that
floats do not have enough precision to deal with nano-second resoluti
I agree w/ the original poster that it would help to have a MEP to clearly
define what the goals of the overhaul are
Something else to keep in mind: we at least don't normally plot dates in
"earth" based time systems. ~10 years ago we contracted with John Hunter to
add the arbitrary unit sys
OK. I'm working on getting permission from management to make this available
but nothing is going to happen (end if fiscal year) until early October. I'll
let you know more as soon as I can.
It might be nice to start a list of functional requirements that a style system
should meet. In imple
We've written a style system that lives on top of the MPL code that has a
similar syntax to what you're proposing. A simple example:
style = smgr.create( "Big Title" )
style.axes.title.font.family = "sans-serif"
style.axes.title.font.size = 24
style.apply( figure )
- Styles get created using an x.
OK - I'll start the ball rolling...
One feature that would be nice to have is positioning options that are not
pixel based. See the annotate function for some possibilities:
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.annotate
I'm not sure if all of these opti
We've had users run into the same problem (and have a similar reaction). At
least on our end, there was a key assumption that users were making about how a
plotting system worked. They expected to be able to do something like this:
... plot stuff here
if outputFile:
P.savefig( "plot.png" )
10 8:39 AM
To: Drain, Theodore R (343P)
Cc: matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
On 22 March 2010 11:32, Drain, Theodore R (343P)
wrote:
> I'd like to throw another vote in for this feature as well. We have a lo
I'd like to throw another vote in for this feature as well. We have a lot of
cases like this and not being able to zoom to the limits of the window is a
real head ache.
Back in the old days (when we were maintaining our own plot library), we solved
this by allowing the bounding rectangle to be
FYI: Thanks for the help John.
This is case where having path.simplify = True causes the plot to be incorrect.
Attached are two different images (not quite the same data as the original
post- but the same affect). One with path.simplify as true and one as false.
Notice the bottom right plot
Wow - thanks for the detailed update. I feel bad for making you type that much
:)
Thanks for fixing that problem.
Ted
> -Original Message-
> From: John Hunter [mailto:jdh2...@gmail.com]
> Sent: Sunday, September 20, 2009 7:35 PM
> To: Drain, Theodore R (343P)
> C
John,
I've run into this problem quite a few times and I'd love to figure out some
way to fix it. As an example, here's the kind of scenario this occurs in:
I embed MPL in a few different GUI's that plot data either in real-time or via
the user selecting things. There is a saved state which co
FYI: The main reason we needed Arc was related to zooming accuracy and
performance. We're drawing ellipses on a planetary scale (1000's of km) and
then drawing other items (targeting points, error ellipses, etc) in only a
small part of the planetary ellipse (1-10 km). Drawing a complete ellips
Another vote here for changing resolution=1 to be the default. It seems
strange to plot values on a line plot and not have the values connected. At
least in my area, every polar plot of real-world data we make needs to set this
flag to 1 or the wrong plot is created.
Ted
> -Original Mess
(nitpick mode on)
Saying they can ignore it more easily seems like a bit of a stretch to me. If
you're writing a converter you MUST include the axis in the function signature
since callers will be passing it in. Whether or not you use it in the
converter implementation is obviously dependent
Message-
> From: John Hunter [mailto:jdh2...@gmail.com]
> Sent: Tuesday, January 06, 2009 7:03 AM
> To: Drain, Theodore R
> Cc: matplotlib-devel@lists.sourceforge.net
> Subject: Re: [matplotlib-devel] John: Thoughts on a standard test
> system
>
> On Mon, Dec 22, 200
Another (still slightly hacky) way might be to define an optional attribute of
the file object. Something like this:
if hasattr( outputFile, "mplFormat" ):
format = getattr( outputFile, "mplFormat" )
Then have set PdfFile.mplFormat to be "pdf". This is a little less hacky in
that it doesn
John,
Sometime in January, we are going to spend some time fixing a few minor MPL
bugs we've hit and a probably work on a few enhancements (I'll send you a list
in Jan before we start anything - it's nothing major). We're also going to
work on writing a set of tests that try various plots w/ un
Nope - no windows users (yet - but we'll test it first if we ever have to
deliver there).
That will work perfectly - Thanks!!!
Ted
> -Original Message-
> From: Jeff Whitaker [mailto:jsw...@fastmail.fm]
> Sent: Wednesday, December 17, 2008 5:03 AM
> To: Drain
Jeff,
Is it possible to install the basemap data into a different directory?
I'm trying to set up a tool delivery layout for our users that allows me to
rapidly update packages that tend to change. We have a core set of software
that our code is built on and it's a lot of work for us to update
see if there are any fuzzy image comparison
algorithms they can recommend.
Ted
> -Original Message-
> From: Gael Varoquaux [mailto:gael.varoqu...@normalesup.org]
> Sent: Thursday, December 11, 2008 10:06 PM
> To: Andrew Straw
> Cc: Drain, Theodore R; matplotlib-devel@list
John,
One thing that would help w/ a rapid delivery/response cycle would be more
comprehensive tests.They would let other developers try out various ideas
and see what breaks before you release it.
We’ve implemented an automated approach where we run an MPL script using Agg,
save the output
> > Things I struggled with:
> > * When a bar is dragged towards one of the figure edges too quickly,
> it gets
> > stuck in its last recorded position on the graph (that should be the
> figure
> > edge).
>
> I think the cause of this is when your mouse leaves the axes, the axes
> stops processing
24 matches
Mail list logo
