Re: [matplotlib-devel] polar_demo output
On Thu, 6 Sep 2007 19:44:51 -0500, John Hunter wrote: A minor correction -- all the backends support rectangular clipping -- but only agg supports polygon clipping currently. The polar axes uses a polygon approximation to a circle for the axes border which is used to clip the lines. I think this would be fairly easy to add to ps, pdf, and svg since i think they all have support for polygon clipping. I'm not sure what the cairo status is. I'm not sure about the cairo backend in matplotlib. But cairo itself definitely has very good for polygon, (and curve-based path), clipping. So it should be extremely trivial to add that to the cairo backend in matplotlib if it's not there already. And I'd be glad to help anyone doing this if they got stuck. -Carl pgpwZgNN6l13H.pgp Description: PGP signature - 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-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] contourf masking bug
On Thu, 12 Jul 2007 09:29:06 -1000, Eric Firing wrote: So one reason why the backends are a bit of a kludge is because we have tried to throw some extra stuff into the GTK drawing model as an afterthough. We could redo all the collection stuff w/ compounds paths. What's the GTK drawing model here that is problematic? Is that pre-cairo stuff? And can using cairo directly help at all? -Carl pgpWrQYtE8QUH.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Embedded fonts in SVG
On Tue, 10 Jul 2007 13:43:49 -0400, Michael Droettboom wrote: major SVG renderers support seems to be the issue at first glance. None of the big open source options -- Firefox, inkscape, rsvg -- seem to support it. That's my understanding as well. Until there's something readily available to test with, there's probably not much point. It's a classic chicken-and-egg. I know the cairo-svg maintainer is hoping to add SVGFont stuff to cairo's SVG output to try to boostrap past this problem. -Carl pgp3SQ7aM8AQv.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OT: licensing discussion
On Sat, 7 Jul 2007 02:16:34 +0900, Bill Baxter wrote: Carl Worth wrote: http://www.scipy.org/License_Compatibility Thanks, John, for sharing this essay. Please allow me to respond to a few points: I can't answer your question about GPL in the gub'ment, but I would really like to know where I can read Carl Worth's rebuttal to the above URL. I sent that in the middle of a matplotlib-devel thread yesterday. It appears to be archived here: http://sourceforge.net/mailarchive/message.php?msg_name=87ps36a32z.wl%25cworth%40cworth.org -Carl pgpaZjNzAxbdb.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
On Fri, 6 Jul 2007 08:20:59 -0500, John Hunter wrote: On 7/5/07, Carl Worth [EMAIL PROTECTED] wrote: Hey Carl -- thanks for the response. You're quite welcome. Thank you for receiving it as intended---as an alternate viewpoint based on my experience. I think LGPL is a perfectly good license which satisfies most of my objections. Good. That's the most important point I wanted to get across. It seemed like an obvious hole in the original essay to me. Eric Jones of enthought has said he is reluctant to use LGPL code. I get the general sense that he simply doesn't want to risk a legal battle with the FSF, which may not be entirely rational, but their zealotry on some of these issues may simply scare some of the people in the commercial space. I won't comment on hearsay, but I'd love to have a conversation with anyone about merits and risks of the LGPL. As for the FSF and commercial involvement, I think the last 18 months of the GPLv3 drafting process has shown quite conclusively that the FSF has very effectively engaged some very significant commercial interests. Here's one point of evidence of that: GNU-Linux Software License Revision Praised By SIFMA http://www.sifma.org/news/47167838.shtml And much more information on a similar theme is available in this excellent talk recently given by Eben Moglen: http://www.groklaw.net/article.php?story=20070630094005112 Perhaps you are right that the better answer for the scientific computing community in python is to reconsider the LGPL stance in scipy, but until that happens, and it is not my decision and I view it as unlikely, the best thing for this community is to use a set of compatible licenses in which we can share code, and the fact remains that we cannot include any LGPL code in our code unless we want our code to be LGPL as well. I made the caveat earlier that it's often good to not change licensing once a community has formed around it. Similarly, it's also often good to go with the same license as the wider community you're trying to be a part of. So again, you're probably doing the right thing. But I can also point to my own experience. When I first started what later would become cairo, (it was called Xr at the time), I had expected it to be a library that formed part of the X Window System. So I chose the MIT license that was the basis of that community's code. Later though, as cairo matured, and we realized it had much wider scope than just an X library, I didn't feel constrained to choose the MIT license for purpose of compatibility with X. So we floated the idea of changing the license from MIT to to LGPL and that idea was extremely well-received in the cairo community and ultimately successful. Here's the thread that started it for interest: [Cairo] Possible license change: MIT - LGPL http://lists.freedesktop.org/archives/cairo/2003-November/000737.html Sometimes I just want to rip out a small algorithm from a library and insert it into mpl, without having to bring in the entire library as a dependency. Unless I want my code to be LGPL, I can't do that. There are some ironies in free software licensing decisions. You can choose an MIT/BSD license in order to have the widest possible fan out, (that is, the number of projects that can take your code), but that might also limit your fan in, (the number of projects from which you can accept code into your project). So you're suffering from limited fan-in I would say due to having chosen a BSD-ish license but wanting to benefit from other LGPL code. -Carl pgplsV8awjdq4.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OT: licensing discussion
On Fri, 06 Jul 2007 10:05:22 -0700, Christopher Barker wrote: Sorry to spam this list with this, but it came up here... Carl, you have clearly thought this out a lot, and have a real experience with this, so I have a issue that you may have some insights into: Yes, I have thought about licensing a lot. And I'll gladly share my opinions, (but no legal advice, of course, etc. etc.). I work for the US federal government, and we are not allowed to copyright our work, so be definition, any code we write is in the public domain. Fantastic! And that's just as government work should be. (I used to work for a University research lab doing mostly government-funded project. Sadly, I saw lots of government funds getting poured down the drain to fund projects that resulted in proprietary software that wen nowhere.) This means that we can not release code under the GPL, as you have to hold copyright to do that. This makes our managers nervous about using GPL'd libs (LGPL is fine, I'm a big fan of LGPL) You don't have to release code under the GPL. As you said, you can't. Just keep publishing that public domain code. The FSF has unfortunately only ALMOST addressed these issues in their FAQ: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLUSGov http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLUSGov The FSF answer looks remarkably clear to me. I don't see the almost at all. From the answers to these FAQs, it's clear that we can release our code into the public domain, and it can then be combined with GPL code in a GPL project, so we can contribute to GPL and LGPL projects. Yes, definitely. However, it still looks like we can't actually release a program ourselves under the GPL, and if a given program contains GPL code, then IIUC, it MUST be released under the GPL, so we've got a problem. Oops. I think you made a mistake here. Read the answer from the FSF again: Can the US Government release improvements to a GPL-covered program? Yes. If the improvements are written by US government employees in the course of their employment, then the improvements are in the public domain. However, the improved version, as a whole, is still covered by the GNU GPL. There is no problem in this situation. And keep rereading that until the part that says There is no problem in this situation really sinks in. I don't know how I could word the reply more clearly than the FSF did. And if you think there's specific text in the GPL that contradicts this advice from the FSF, I'd suggest you contact the FSF about it, (but frankly, I can't find any such text). So if I were in your situation, I would contribute to GPL projects by sending public-domain contributions. I would also start any new projects by releasing public-domain code, (which others could then take and modify and release their modifications under the GPL if desired). Anyway, what all this means is that so far we've avoided GPL code for our projects -- something to keep in mind, the US gov't is a major user of Open Source Projects. Please reconsider this, (or invite your lawyers to, or write to the Free Software Foundation as needed). PS: Google is remarkably unhelpful to me in figuring all this out. If anyone has useful references about the US Federal gov't developed and released software an the GPL -- please send me the links! A quick scan through the Linux kernel source code, (obviously one of the most popular GPL-released projects), shows plenty of contributions from people with .gov email addresses, (both NSA and LLNL feature prominently). So you might find some helpful people to contact there who are more directly in circumstances similar to yours, (feel free to contact me off-list if you've got any questions about how to track down some potentially helpful email addresses there). -Carl pgpknlcDvcLB6.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OT: licensing discussion
On Fri, 06 Jul 2007 14:03:30 -0700, Christopher Barker wrote: to, so maybe I'm missing something. In essence, I see a distinction between contributing to a project someone else is releasing, and creating a derived work that I release myself. Maybe there is no difference. I'll reply only to the problematic case. (And we're definitely off-topic for the matplotlib-devel list, so I suggest we take any further discussion privately unless someone steps up and says please, continue here). 2) I have written a substantial application that makes some use of some GPL'd code. I want to put that app up on a government-run web site, and let people use it at their will. As I understand it, I am now releasing the application, and as it includes some GPL code, it MUST be released under the GPL. But I can't do that, because I don't hold copyright over the stuff I've written on the taxpayers time. So what do I do? From what authority do you derive the I can't do that part? Think about that. You say because I don't hold copyright, but what does that mean? Copyright would give you the ability to impose limits on the recipients, (specifically with respect to activities such as copying, creating derived works, public performance, etc.). You don't have any right to impose such limits, but you also don't need any rights. I would suggest that all of the parts that you have written by annotated with appropriate statements indicating their public-domain status. The question is, can you combine these public-domain files with other files that you obtained via the GPL? That's a question of creating a derived work which is something that requires the copyright holder's permission. And the copyright holder has given you that permission as long as the derived work is made available under the terms of the GPL. So, yes, you have permission to release the combined work under the terms of the GPL. Recipients can then modify and redistribute the combined work under the terms of the GPL. Recipients can _also_ extract any public-domain portions of the work and use those in any way whatsoever, since they are public-domain. I could post all the code I wrote myself (released into the public domain), then post instructions how to combine it with the GPL code, compile it, and viola, you have your app, but that's not exactly making things as accessible as I'd like. Does such a person have an ability that you do not? Your only unique position is that you cannot assert any copyright in the things you created. Nor can your hypothetical third party doing the combining, right? So I see no problem with you being the party doing the combining. Can the US Government release a program under the GNU GPL? If the program is written by US federal government employees in the course of their employment, it is in the public domain, which means it is not copyrighted. Since the GNU GPL is based on copyright, such a program cannot be released under the GNU GPL. That wasn't what you asked though. You asked if you could combine original software written by the government with software available under the GPL and release the combination. And that's exactly what the FSF answers in the next question: Sure, contributing is no problem, it's the releasing of derived works that has me concerned. But what's the distinction there? Releasing a derived work is certainly an action that requires the copyright holder's permission, but you have that permission explicitly in the GPL. There's never any relicensing. The parts that are public-domain are still public-domain. The parts that are available only under the terms of the GPL are still available only under the terms of the GPL. You cannot relicense at all unless you are the copyright holder. The only question is in the case of a combined work whether there is a set of permissions that doesn't violate the terms of any of the pieces. (This is the general license compatibility question.) And in the case of GPL+public domain, the answer is yes, and the set of permissions is the GPL. I think one possible point of confusion is the wording of improvements in the FSF GPL FAQ explaining that the government can release improvements to a GPL-covered program. This might be interpreted as somehow implying that its only legitimate if the improvements are somehow less significant than the GPL program. A more clear answer might just say that the government, (or anyone else for that matter), can legitimately combine GPL software with public domain software and release the result under the GPL. But you certainly don't need the FSF FAQ to give you that permission explicitly. The GPL itself gives you all the permission you need. So again, I'll go back to my original question, by what authority do you see any problem? Would you be violating anybody's copyright by releasing a program combining GPL components and government-written public-domain components? That is, would you be taking any
Re: [matplotlib-devel] Subsetting fonts in Postscript
On Thu, 5 Jul 2007 14:46:13 -0500, John Hunter wrote: The postscript backend as it stands is in good shape, and is full featured (Darren can tell you how much work he has put into supporting and enhancing the latex support). The last major issue with it is the font size issue, and with your help a solution is on the horizon. So it is definitely a good use of time to fix this last bit. It doesn't sound like your option 2 is a ton of work, but correct me if I'm wrong. For what it's worth, I think I'd be inclined to agree with you there. If your existing code is working just fine, then switching to cairo is just more work. But if you do start having to do any serious maintenance, then you might want to reconsider. http://www.scipy.org/License_Compatibility Thanks, John, for sharing this essay. Please allow me to respond to a few points: In my experience, the benefits of collaborating with the private sector are real, whereas the fear that some private company will steal your product and sell it in a proprietary application leaving you with nothing is not. In my experience, there is real harm that can come when proprietary modifications to a license made available under a permissive license are not contributed back. An extremely clear case is that of the X Window System which went through a period of several independent software vendors trying to out-compete each other on their own proprietary modifications to the system, (resulting in the near death of the system altogether). I've had some discussions with Jim Gettys about that process and how the MIT license for X has played out over the years. You argue that a project most needs the extra users provided by a permissive license during its formative years until it reaches critical mass and the network effects kick in. Jim actually argues the point differently and says that the extra protections of the GPL are most necessary during the formative period, but not at all needed once the project reaches critical mass. So I've heard him express that he wishes there were a way to allow a project to grow under the GPL and then change to something like the MIT license once it reaches critical mass. There is a lot of GPL code in the world, and it is a constant reality in the development of matplotlib that when we want to reuse some algorithm, we have to go on a hunt for a non-GPL version. So that's a cost that you need to weigh against the decision to not be able to accept any GPL code into your project. But I think the fact that there _is_ a lot of GPL code in the world is a strong argument against your original thesis that a license more permissible than the GPL is necessary to bootstrap a free software project to critical mass. There _is_ a lot of GPL code, which means there _are_ a lot of users of that code, and a lot of those users are businesses that don't have a problem using, (and modifying, and contributing back to), GPL code. There are two unpalatable options. 1) Go with GPL and lose the mind-share of the private sector 2) Forgo GPL code and retain the contribution of the private sector. You've chosen (2) along with a decision to try to campaign authors of GPL code to relicense their code as BSD/MIT (ish) whenever you want to use it. I would guess you'll find that quite difficult in many cases, (I don't agree that the GPL is most often chosen without intention just because it is famous). I think an easier route to take path (2) is to use the LGPL for your library, and then only have to convince authors to re-license the subset of their GPL application code as LGPL that you're actually interested in incorporating into your library. I would predict that you will be more successful at that more often than convincing people to relicense GPL to BSD/MIT (ish). You only bring the LGPL up at the end of your essay as almost an afterthought and dismiss it with a very vague, but many companies are still loath to use it out of legal concerns. Do you have actual evidence to point to for that? It would be simpler if there were direct experiments we could run to measure some of these things, but there aren't, (and conditions do continue to change). My experience with the cairo project suggests that we've been able to achieve a very successful library implementation, (with plenty of corporate contribution), with an LGPL (and MPL) license. This is a very tough decision because their is a lot of very high quality software that is GPL and we need to use it; Network effects are strong---when they're good, don't fight them. :-) And I've even been annoyed enough with having to get code relicensed from GPL to LGPL+MPL for use in cairo that I'm thinking the next library I invent might be simply GPL from the beginning. Which brings me to my final point. I think it's very interesting (and worthwhile) to debate license decisions like this. But at the end
Re: [matplotlib-devel] Subsetting fonts in Postscript
On Thu, 05 Jul 2007 13:22:11 -1000, Eric Firing wrote: I have made a few changes in svn to facilitate testing cairo with backend_driver (and to fix a bug that turned up), and I will do a bit more on this later today or tomorrow. Cool. I've started downloading all the matplotlib source history with git-svn, so once that's done I'll take a look. Hopefully it's obvious how to run through the cairo backend with the test suite---otherwise I'll ask. The result of a quick pass through the backend_driver test with png output is quite encouraging, though. There are some bugs in string placement, image handling, and clipping, but most things work, including mathtext. Default fonts seem to be different. If there's anything I can do to help I'll do what I can---let me know. Oh, and I meant to say that it's a bit annoying that savefig(somefile) doesn't work with the cairo backend. My understanding is that this is supposed to automatically select the correct file extension based on the backend type, (with the implicit assumption that any given backend only supports one backend type). That seems like a useful way of using savefig, and I don't think it's correct to break it just because cairo supports multiple file types. My suggestion would be to make it default to .png if no additional information is provided, and then to also add some sort of pseudo backends so that the other cairo-supported file types could easily be obtained with this same savefig call. For example something like: python myscript.py -dCairoPDF What do you think? Would that be simple to implement? -Carl PS. I'd be more inclined to name the backends things like cairo-pdf than CairoPDF but it seems that the latter better fits the existing convention for matplotlib backend naming. pgpkwqB6ms90i.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] cairo patch #3: snap dash lengths
I noticed on the simple_plot.py example that the grid was coming out pretty ugly without any snapping on the dashes. Here's a little patch that adds that. -Carl PS. As should be obvious, this patch depends on my first patch that adds the _snap variable. 0001-Snap-the-dash-lengths-as-well.patch Description: Binary data pgp2lRqaflsJh.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Re-enable clipping for cairo backend
Here's a second[*] patch for the cairo backend. This one re-enables clipping. All the necessary code was present already, but disabled with a comment claiming problems on two of the examples. I double-checked both examples but found no problems, (whereas, obviously without clipping things don't work at all after panning/zooming). -Carl [*] Apparently my first patch hit the list before my subscription request was completely processed. So it's either been queued up for moderation or deleted by now. Please let me know if I should re-send it. 0001-cairo-Re-enable-clipping.patch Description: Binary data pgpvWTxSP759R.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] cairo patch #4: Fix draw_arc
The draw_arc code was putting all arcs centered on the origin instead of the proper location. This patch fixes that. With this, plus my earlier patch #2 to enable clipping, the line_styles.py example is now rendering quite well with the cairo backend. However my patch #1 to add the snapping is messing up line_styles in some places. For example, where there is a strokes sine wave the snapping is interfering with its proper shape. Obviously, snapping smooth, curved user data being plotted like that is a really bad idea. Things that should be snapped are things like frames, grid lines, ticks, and object borders, particularly when aligned with an axis. -Carl 0001-cairo-Fix-implementation-of-draw_arc.patch Description: Binary data pgpOjyeXV2lU6.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
