matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] How to properly use git to implement a feature

[Michael D. <md...@st...>]

On 08/12/2012 09:34 PM, Daniel Hyams wrote:
>
> I was wanting to add a feature to matplotlib...one that I would use in 
> my application.  I also want to contribute the feature back. I'm 
> personally using version 1.1.1 of matplotlib.  Disclaimer...I only 
> know enough about git to be dangerous.
>
> So is it best to branch from v1.1.1, implement the feature, and then 
> try to rebase to master?  Or is it best to branch from master, 
> implement the feature, and then (somehow) backport the patch to the 
> v1.1.1 tagged version?

If something is a bugfix, I generally branch from v1.1.x (i.e. the 
maintenance branch), implement the feature, submit a pull request for 
that, which eventually gets merged into the maintenance branch. Then I 
merge the maintenance branch into master.  The last step can generally 
only be done by people with write permissions to the core repository.  I 
know other projects that work the other way around, but that's the way 
things have generally been done in matplotlib.

>
> Whatever the best choice is, what would the procedure look like to 
> accomplish this?

git checkout -b my_new_feature upstream/v1.1.x
... implement feature ...
git add ...files...
git commit
git push origin my_new_feature
...create a pull request on github...
...after the pull request is merged, v1.1.x gets merged into master...

Mike

>
> -- 
> Daniel Hyams
> dh...@gm... <mailto:dh...@gm...>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] How to properly use git to implement a feature

[Daniel H. <dh...@gm...>]

I was wanting to add a feature to matplotlib...one that I would use in my
application.  I also want to contribute the feature back. I'm personally
using version 1.1.1 of matplotlib.  Disclaimer...I only know enough about
git to be dangerous.

So is it best to branch from v1.1.1, implement the feature, and then try to
rebase to master?  Or is it best to branch from master, implement the
feature, and then (somehow) backport the patch to the v1.1.1 tagged version?

Whatever the best choice is, what would the procedure look like to
accomplish this?

-- 
Daniel Hyams
dh...@gm...

Re: [matplotlib-devel] 'NoneType' object has no attribute 'endswith' when running tests in a chroot

[Sandro T. <mo...@de...>]

(sigh - only now I find the time to work on it)

On Mon, May 21, 2012 at 1:34 PM, Michael Droettboom <md...@st...> wrote:
> This is most likely due to some of the testing dependencies not being
> present.  matplotlib uses ghostscript for rendering PDF and inkscape for
> rendering SVG (but only when testing).  See this documentation:
>
> http://matplotlib.sourceforge.net/devel/coding_guide.html#testing

yep indeed - inkscape was missing, once installed almost all the tests
are passing, but I got some of them fail since the images doesn't
match: how can I report those problem? an issue on github attaching
the images pairs and the tests running output?

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

[matplotlib-devel] Basemap - use BASEMAPDATA also in lib/mpl_toolkits/basemap/pyproj.py

[Sandro T. <mo...@de...>]

Hello,
while updating Basemap package in Debian, I noticed that
lib/mpl_toolkits/basemap/pyproj.py could use the same BASEMAPDATA
variable handling as of lib/mpl_toolkits/basemap/__init__.py , so I'm
applying a patch like this:

Index: basemap-1.0.5+dfsg/lib/mpl_toolkits/basemap/pyproj.py
===================================================================
--- basemap-1.0.5+dfsg.orig/lib/mpl_toolkits/basemap/pyproj.py
2012-08-06 19:26:00.000000000 +0200
+++ basemap-1.0.5+dfsg/lib/mpl_toolkits/basemap/pyproj.py
2012-08-10 21:49:42.941275370 +0200
@@ -236,10 +236,14 @@
 "sphere":       {'a':6370997.0,'b':6370997.0,'description':"Normal Sphere"},
 }

-pyproj_datadir = os.sep.join([os.path.dirname(__file__), 'data'])
-if not os.path.isdir(pyproj_datadir):
-    msg="proj data directory not found. Expecting it at: %s"%pyproj_datadir
-    raise IOError(msg)
+# check to see if environment variable BASEMAPDATA set to a directory,
+# and if so look for the data there.
+if 'BASEMAPDATA' in os.environ:
+    pyproj_datadir = os.environ['BASEMAPDATA']
+    if not os.path.isdir(pyproj_datadir):
+        raise RuntimeError('Path in environment BASEMAPDATA not a directory')
+else:
+    pyproj_datadir = '/usr/share/basemap/data'

 set_datapath(pyproj_datadir)


Maybe you can consider applying it upstream too (except for the part
of setting it to '/usr/share/basemap/data' in case  no variable is
passed, it's a Debian specific change).

Cheers,

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] matplotlib.github.com

[Fernando P. <fpe...@gm...>]

On Fri, Aug 10, 2012 at 1:00 PM, Michael Droettboom <md...@st...> wrote:
> That is the end goal.  I'm talking simply about the static webpage hosting
> here.  If I recall correctly, I think the space limitations on github used
> to be a problem for us, which is why we haven't used it as the canonical web
> hosting.  But that doesn't seem to be a problem anymore.  I was mostly
> hoping that anyone involved in the decision to not go with github's web
> hosting at the time could remember any other downsides.

Glad to hear that!  The github folks have been very flexible in their
application of the quotas and have always said that any OSS project
that has a legitimate need for additional space will always be
granted.  They just don't want github to become somebody's
picture/music/movie backup system for free, that's all.

I have never seen them actually enforce the limits on any OSS project,
but I'd be happy to put you in touch directly with someone there if
you want a more direct clarification on this.

Best,

f

Re: [matplotlib-devel] matplotlib.github.com

[Michael D. <md...@st...>]

On 08/10/2012 03:45 PM, Fernando Perez wrote:
> On Fri, Aug 10, 2012 at 7:26 AM, Michael Droettboom <md...@st...> wrote:
>> Supporting existing links to matplotlib.sourceforge.net is of course
>> very important, and I would put whatever redirects we need to keep those
>> working in any event.
> Actually, why not move all the official domain machinery to
> matplotlib.org?

That is the end goal.  I'm talking simply about the static webpage 
hosting here.  If I recall correctly, I think the space limitations on 
github used to be a problem for us, which is why we haven't used it as 
the canonical web hosting.  But that doesn't seem to be a problem 
anymore.  I was mostly hoping that anyone involved in the decision to 
not go with github's web hosting at the time could remember any other 
downsides.

> That can be managed with the github tools, and
> github/pypi can be used for downloads with a far simpler workflow than
> the particular incarnation of UX hell that is sourceforge's upload
> system...

I plan to move to github for downloads as well.

>
> We've been doing that for a while with ipython since we moved to
> ipython.org, and we've been very happy.  With suitable redirects in
> place, no google rank will be lost nor will users be confused, and
> gradually everyone's bookmarks and habits will transition to mpl.org.
>
> If you guys want to do that and run into any issues, we (ipython) will
> be happy to share how it works for us and help out.
>
Thanks.  Will do.

Mike

Re: [matplotlib-devel] matplotlib.github.com

[Fernando P. <fpe...@gm...>]

On Fri, Aug 10, 2012 at 7:26 AM, Michael Droettboom <md...@st...> wrote:
> Supporting existing links to matplotlib.sourceforge.net is of course
> very important, and I would put whatever redirects we need to keep those
> working in any event.

Actually, why not move all the official domain machinery to
matplotlib.org?  That can be managed with the github tools, and
github/pypi can be used for downloads with a far simpler workflow than
the particular incarnation of UX hell that is sourceforge's upload
system...

We've been doing that for a while with ipython since we moved to
ipython.org, and we've been very happy.  With suitable redirects in
place, no google rank will be lost nor will users be confused, and
gradually everyone's bookmarks and habits will transition to mpl.org.

If you guys want to do that and run into any issues, we (ipython) will
be happy to share how it works for us and help out.

Just a thought...

f

[matplotlib-devel] Fwd: Re: [Matplotlib-users] help me Velocity depth plot in matplotlib

[Damon M. <dam...@gm...>]

----- Forwarded message from Damon McDougall <dam...@gm...> -----

> Date: Fri, 10 Aug 2012 12:47:22 +0100
> From: Damon McDougall <dam...@gm...>
> To: satish maurya <mau...@gm...>
> Cc: mat...@li...
> Subject: Re: [Matplotlib-users] help me Velocity depth plot in matplotlib
> 
> On Fri, Aug 10, 2012 at 02:09:39PM +0530, satish maurya wrote:
> > Dear All,
> > 
> > I want to stairs plot (similar in matlab) matplotlib
> > First i want for i data-set then multiple data-set super impose on that.
> > I attach the figure it's showing velocity-depth stairs plots for
> > superimpose (like hold on in matlab)
> > large data-set.
> > can anybody tell me how to plot that.
> >
> 
> I'm not sure I understand what you're asking. Are you asking how to make
> a stairplot, or are you asking how to make *multiple* plots on one set
> of axes?
> 
> If your question is the former, matplotlib does not currently have a
> stairplot implementation, but it wouldn't be hard to use the usual
> plot() function to achieve the desired effect:
> 
> Before:
> 
> x = arange(0, 10, 1)
> y = x * (10.0 - x)
> plot(x, y)
> 
> After:
> 
> x = arange(0, 10, 1)
> x_m = x - 0.5 # left-hand midpoints
> x_p = x + 0.5 # right-hand midpoints
> y = x * (10.0 - x)
> x_all = dstack((x_m, x, x_p)).flatten()
> y_all = dstack((y, y, y)).flatten()
> plot(x_all, y_all)
> 
> If your question is the latter, you can toggle the hold state just by
> calling
> 
> hold()
> 
> Hope this helps.
> 
> > 
> > see the figure
> > 
> > Thank you
> > 
> > -- 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > *Satish Maurya*
> > *Research Scholar*
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> -- 
> Damon McDougall
> http://damon-is-a-geek.com
> B2.39
> Mathematics Institute
> University of Warwick
> Coventry
> West Midlands
> CV4 7AL
> United Kingdom

----- End forwarded message -----

I have put in a PR regarding this, since this feature exists in Matlab.
This brings the plotting interface of matplotlib more in line with that
of Matlab. You can view the request at:

https://github.com/matplotlib/matplotlib/pull/1068

Feedback welcome.
Best,
Damon

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] matplotlib.org

[Michael D. <md...@st...>]

On 08/10/2012 10:49 AM, Phil Elson wrote:
> Great! Are we going to be able to move away from using the sourceforge
> mailing list too?

I haven't given that much thought.  Are there much better free 
alternatives to justify the disruption?

>
> Presumably these infrastructure costs get covered via the donations
> that mpl receives rather than coming out of your pocket Michael?

We're working out the details, but, yes, domain name registration is 
certainly, IMHO, a valid use of those funds.

>
> I think getting hold of matplotlib.org is a really good idea. Thanks
> for doing that!

You're welcome!
Mike
>
>
>
> On 10 August 2012 15:28, Michael Droettboom <md...@st...> wrote:
>> I have registered matplotlib.org.  It currently just points to
>> matplotlib.sourceforge.net, but it will allow us to have a consistent
>> URL that isn't dependent on any particular host going forward.
>>
>> Mike
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib.github.com

[Phil E. <pel...@gm...>]

> As far as I can see the github docs are as up-to-date as the
> souceforge ones.

Scrub that statement. My browser cache needed clearing.





On 10 August 2012 15:44, Phil Elson <pel...@gm...> wrote:
> I wasn't involved at the time, but was it because
> matplotlib.github.com is slower?
>
> As far as I can see the github docs are as up-to-date as the
> souceforge ones. (although reading the commit log on the docs repo
> doesn't seem to agree with that statement)
>
> All in all, sounds promising.
>
> On 10 August 2012 15:26, Michael Droettboom <md...@st...> wrote:
>> I know we had experimented with moving the main documentation website to
>> matplotlib.github.com a while ago (and in fact there's still an old
>> version of the docs sitting there).  I can't remember the reason we
>> chose to remain at matplotlib.sourceforge.net and searching the mailing
>> list archive isn't helping jog my memory there.
>>
>> I'd like to move to github's hosting if possible because rsyncing to
>> sourceforge is slow as molasses and doesn't always work reliably.
>>
>> Supporting existing links to matplotlib.sourceforge.net is of course
>> very important, and I would put whatever redirects we need to keep those
>> working in any event.
>>
>> Mike
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib.org

[Phil E. <pel...@gm...>]

Great! Are we going to be able to move away from using the sourceforge
mailing list too?

Presumably these infrastructure costs get covered via the donations
that mpl receives rather than coming out of your pocket Michael?

I think getting hold of matplotlib.org is a really good idea. Thanks
for doing that!



On 10 August 2012 15:28, Michael Droettboom <md...@st...> wrote:
> I have registered matplotlib.org.  It currently just points to
> matplotlib.sourceforge.net, but it will allow us to have a consistent
> URL that isn't dependent on any particular host going forward.
>
> Mike
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib.github.com

[Phil E. <pel...@gm...>]

I wasn't involved at the time, but was it because
matplotlib.github.com is slower?

As far as I can see the github docs are as up-to-date as the
souceforge ones. (although reading the commit log on the docs repo
doesn't seem to agree with that statement)

All in all, sounds promising.

On 10 August 2012 15:26, Michael Droettboom <md...@st...> wrote:
> I know we had experimented with moving the main documentation website to
> matplotlib.github.com a while ago (and in fact there's still an old
> version of the docs sitting there).  I can't remember the reason we
> chose to remain at matplotlib.sourceforge.net and searching the mailing
> list archive isn't helping jog my memory there.
>
> I'd like to move to github's hosting if possible because rsyncing to
> sourceforge is slow as molasses and doesn't always work reliably.
>
> Supporting existing links to matplotlib.sourceforge.net is of course
> very important, and I would put whatever redirects we need to keep those
> working in any event.
>
> Mike
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib.org

[Michael D. <md...@st...>]

I have registered matplotlib.org.  It currently just points to 
matplotlib.sourceforge.net, but it will allow us to have a consistent 
URL that isn't dependent on any particular host going forward.

Mike

[matplotlib-devel] matplotlib.github.com

[Michael D. <md...@st...>]

I know we had experimented with moving the main documentation website to 
matplotlib.github.com a while ago (and in fact there's still an old 
version of the docs sitting there).  I can't remember the reason we 
chose to remain at matplotlib.sourceforge.net and searching the mailing 
list archive isn't helping jog my memory there.

I'd like to move to github's hosting if possible because rsyncing to 
sourceforge is slow as molasses and doesn't always work reliably.

Supporting existing links to matplotlib.sourceforge.net is of course 
very important, and I would put whatever redirects we need to keep those 
working in any event.

Mike

Re: [matplotlib-devel] Matplotlib Qt4Agg backend ignores 'resize_event'

[Stefan H. <shm...@gm...>]

Hi Ludwig,

You are right, it didn't work on the MacOSX backend either. I didn't notice
since the backend doesn't support blitting, so I never tried it.

In any case, it is exactly the same problem as in Qt4Agg, with exactly the
same fix: In lib/matplotlib/backends/backend_macosx.py, add the last line to
the "resize()" method of class "FigureCanvasMac":

def resize(self, width, height):
        self.renderer.set_width_height(width, height)
        dpi = self.figure.dpi
        width /= dpi
        height /= dpi
        self.figure.set_size_inches(width, height)
        FigureCanvasBase.resize_event(self)

Then it works.

Cheers,
Stefan




--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-Qt4Agg-backend-ignores-resize-event-tp29298p38468.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

[matplotlib-devel] Patch: fixed conversion from pt to inch in tight_layout

[pwuertz <pw...@go...>]

Hi,

I noticed that when using tight_layout, the figure padding changes for
different figure.dpi settings. This is caused by an error in when converting
from points to inches. A point is always 1/72 inch and does not depend on
the dots per inches. This is the patch for fixing the conversion:

Diff
https://github.com/pwuertz/matplotlib/commit/6edc3d9b04cc6b29475916cc25d5433e7b49b2d2

Pull request
https://github.com/matplotlib/matplotlib/pull/1065



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Patch-fixed-conversion-from-pt-to-inch-in-tight-layout-tp38467.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Re: [matplotlib-devel] bad link on matplotlib website

[Benjamin R. <ben...@ou...>]

On Mon, Aug 6, 2012 at 5:51 PM, Michael Droettboom <md...@st...> wrote:

>  On 08/06/2012 02:10 PM, Benjamin Root wrote:
>
>
>
> On Tue, Dec 6, 2011 at 4:15 PM, Jim Hunziker <lan...@gm...> wrote:
>
>> I'm not sure if this is the right place to report this, but the link
>> to Python(x, y) on
>> http://matplotlib.sourceforge.net/users/installing.html points to a
>> page that no longer exists.
>>
>> --
>> Jim Hunziker
>>
>>
> Starting to go back over my backlog of emails.  I can confirm that this is
> the case.
>
> I assume we should just link to:
>
>   http://www.pythonxy.com/
>
> Correct?  If so, I can fix this in the repository.
>
> Mike
>
>
Yeah, I think so.  Not sure why we linked to the foreward before.

Ben Root

[matplotlib-devel] Patch: set capsize of errorbar via matplotlibrc

[Hans D. <han...@ki...>]

Hi fellow developers,

I am using matplotlib in particle physics where we generally do not plot 
the little end caps of error bars. They add no information, but they 
make the plot harder to read, especially if it is a busy plot.

In physics, we follow the general aesthetic rule to maximise the "data 
to ink ratio", which means that the information should be presented with 
a minimum of optical gimmicks.

So, I end up calling errorbar everytime with capsize=0. I argue that 
having end caps or not is a global style option, and therefore it makes 
sense to put this into matplotlibrc.

I prepared a patch in order to do that and would like you to include it 
into the distribution.

Please tell me what you think of it.

Re: [matplotlib-devel] Asking for code review: Xelatex / PGF backend

[Trémouilles D. <dav...@gm...>]

Thank you very much Peter :-)
I'm going to test...

David

Le 08/08/12 12:59, Peter Würtz a écrit :
>
> Peter Würtz wrote:
>>
>> David Trémouilles wrote:
>>> Is there any reason that the generated figure could not be used with
>>> pdflatex ?
>>>
>> The PGF pictures should work with pdflatex, xelatex and lualatex alike.
>> Xelatex (or lualatex) must be installed though because I use it for
>> obtaining the font metrics when the figure is created. In principle I
>> could use pdflatex for this as well, I just saw no reason to use it
>> anymore when I learned about the newer implementations.
>>
> Ok, the latest commit now allows you to rely on pdflatex only. Xelatex is
> still the default, but you can change that using the rc parameters:
>
> matplotlib.rcParams.update({
>    "font.family": "serif",
>    "pgf.texsystem": "pdflatex",
>    "pgf.preamble": [r"\usepackage{siunitx}",
> r"\usepackage{somefontpackage}"],
> })
>
> System fonts specified in the rc parameters will be ignored since pdflatex
> cannot use them. Font metrics will be obtained from a pdflatex process. If
> you save the figure as pdf, pdflatex will be used to compile the figure.
>
> Hope this helps.

Re: [matplotlib-devel] Asking for code review: Xelatex / PGF backend

[Peter W. <pw...@go...>]

Peter Würtz wrote:
> 
> 
> David Trémouilles wrote:
>> 
>> Is there any reason that the generated figure could not be used with
>> pdflatex ?
>> 
> 
> The PGF pictures should work with pdflatex, xelatex and lualatex alike.
> Xelatex (or lualatex) must be installed though because I use it for
> obtaining the font metrics when the figure is created. In principle I
> could use pdflatex for this as well, I just saw no reason to use it
> anymore when I learned about the newer implementations.
> 

Ok, the latest commit now allows you to rely on pdflatex only. Xelatex is
still the default, but you can change that using the rc parameters:

matplotlib.rcParams.update({
  "font.family": "serif",
  "pgf.texsystem": "pdflatex",
  "pgf.preamble": [r"\usepackage{siunitx}",
r"\usepackage{somefontpackage}"],
})

System fonts specified in the rc parameters will be ignored since pdflatex
cannot use them. Font metrics will be obtained from a pdflatex process. If
you save the figure as pdf, pdflatex will be used to compile the figure.

Hope this helps.
-- 
View this message in context: http://old.nabble.com/Asking-for-code-review%3A-Xelatex---PGF-backend-tp34263853p34271056.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Re: [matplotlib-devel] Asking for code review: Xelatex / PGF backend

[Peter W. <pw...@go...>]

David Trémouilles wrote:
> 
> Is there any reason that the generated figure could not be used with
> pdflatex ?
> 

The PGF pictures should work with pdflatex, xelatex and lualatex alike.
Xelatex (or lualatex) must be installed though because I use it for
obtaining the font metrics when the figure is created. In principle I could
use pdflatex for this as well, I just saw no reason to use it anymore when I
learned about the newer implementations.

So in order to get the font metrics right you should tell the backend which
fonts you are going to use later. You need to disable the default font
configuration that uses the system fonts specified in the matplotlib rc
paramteres and fully configure the latex environment using your own
preamble. This can be done using the rc parameters:

matplotlib.rcParams.update({
  "pgf.rcfonts": False,
  "pgf.preamble": [r"\usepackage{siunitx}",
r"\usepackage{somefontpackage}"],
})

I never thought about it, but if there interest in using this with pdflatex
I could add this as an option. It might just be a little bit confusing since
the font setup will be different when switching from xelatex to pdflatex due
to its limitations.
-- 
View this message in context: http://old.nabble.com/Asking-for-code-review%3A-Xelatex---PGF-backend-tp34263853p34270497.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Re: [matplotlib-devel] The beauty of Breseham's algorithm

[Damon M. <dam...@gm...>]

On Wed, Aug 08, 2012 at 09:26:58AM +0100, Damon McDougall wrote:
> I saw this article on hacker news and wondered if it would be applicable
> to us? http://free.pages.at/easyfilter/bresenham.html
> 
> Perhaps not, but I certainly learned something from it so I thought I'd
> share anyway.
> 
> Best,
> Damon

...and that should be 'Bresenham', not 'Breseham'.

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

[matplotlib-devel] The beauty of Breseham's algorithm

[Damon M. <dam...@gm...>]

I saw this article on hacker news and wondered if it would be applicable
to us? http://free.pages.at/easyfilter/bresenham.html

Perhaps not, but I certainly learned something from it so I thought I'd
share anyway.

Best,
Damon

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] Asking for code review: Xelatex / PGF backend

[Trémouilles D. <dav...@gm...>]

Le 07/08/12 01:17, Peter Würtz a écrit :
> Hi!
> I would like to ask for a code review for a new backend I wrote for creating
> figures with Xelatex/Lualatex. It uses the PGF (Tikz) Package for all
> drawing operations and enables full unicode support and typesetting of
> texts/formulas using Latex. This way, the figures created fit perfectly in
> Latex documents. Furthermore, Xelatex/Lualatex is able to use the fonts
> installed on your operating system. The drawing commands of the PGF pictures
> can be included in Latex documents or can be directly compiled to PDF by the
> backend.
>
> Github project for hosting the code, usage instructions and examples:
> https://github.com/pwuertz/matplotlib-backend-pgf
>
> A document demonstrating the benefits of using Xelatex/PGF:
> https://github.com/pwuertz/matplotlib-backend-pgf/raw/master/demo/demo.pdf
>
> Gallery of the matplotlib examples processed with backend_pgf:
> https://github.com/pwuertz/matplotlib-backend-pgf/wiki/Examples%20Gallery
> A few exceptions are known to fail due to Latex incompatible math-text.
>
> This is a matplotlib branch set up as suggested in the matplotlib developer
> wiki. It includes the code from above and adds new rc-parameters and the
> '.pgf' file type.
> https://github.com/pwuertz/matplotlib/compare/master...pgf-backend
>
> Discussions are usually taking place at the github diff, right? I hope
> you'll find this an interesting option for creating figures with matplotlib.
>
> Cheers,
> Peter
Very interesting work. Thanks.

Is there any reason that the generated figure could not
be used with pdflatex ?

I ask the question before giving it a try (I use pdflatex).

Regards,

David

Re: [matplotlib-devel] Client-side plotting

[Nicolas R. <Nic...@in...>]

Hi,

Great post and I feel the three-way split method you're talking about could also be incredibly useful for the GL backend (see my previous post about GL backend). 


Nicolas


On Aug 6, 2012, at 23:59 , Michael Droettboom wrote:

> For anyone who's interested, I've started blogging about my initial 
> thinking on client-side plotting in the web browser with matplotlib here:
> 
>    http://mdboom.github.com/
> 
> (I hope to get this aggregated into planet.scipy.org soon, too).
> 
> Mike
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel