Re: [matplotlib-devel] Subsetting fonts in Postscript
Carl Worth wrote: don't think it is supported in cairo. So I am not sure where these rasters are coming from, unless cairo is converting all text to rasters. Definitely not converting all text to raster, (unless someone's using an ancient version of cairo). I don't know the root cause, but FYI I'm definitely getting rasterized text with the Cairo backend for mathtext_demo.py. (I'm using cairo-1.4.10, which I believe is the latest stable release). Cheers, Mike - 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 7/6/07, Michael Droettboom [EMAIL PROTECTED] wrote: I don't know the root cause, but FYI I'm definitely getting rasterized text with the Cairo backend for mathtext_demo.py. (I'm using cairo-1.4.10, which I believe is the latest stable release). And you are pretty sure it is all the text, not just the mathtext? We do use special fonts for mathtext (the Backoma cm ttf fonts) and perhaps something funny is going on with them? But that should not affect non-mathtext in the same figure. What about simple_demo.py -- do you get rasters there too? JDH - 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 Friday 06 July 2007 08:35:31 am John Hunter wrote:
On 7/6/07, Michael Droettboom [EMAIL PROTECTED] wrote:
I don't know the root cause, but FYI I'm definitely getting rasterized
text with the Cairo backend for mathtext_demo.py. (I'm using
cairo-1.4.10, which I believe is the latest stable release).
And you are pretty sure it is all the text, not just the mathtext? We
do use special fonts for mathtext (the Backoma cm ttf fonts) and
perhaps something funny is going on with them? But that should not
affect non-mathtext in the same figure.
When I set my backend to gtkcairo, and do something like
plot([1,2])
xlabel('$0.0, 0.1$')
it is clear that the ticklabels are not rasters, only the mathtext. My fonts
are the MPL defaults, the search settled on Vera.ttf.
-
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 7/5/07, Carl Worth [EMAIL PROTECTED] wrote: Thanks, John, for sharing this essay. Please allow me to respond to a few points: Hey Carl -- thanks for the response. You have definitely made me reconsider some of my arguments, though my conclusion mostly remains intact. At the end of the day, it is a fact that almost all of the significant software for scientific computing in python is BSD compatible and GPL averse. This in part stems from the position of enthought, who make very substantial contributions to scientific computing in python (scipy, chaco, traits, envisage, tvtk, the annual conference...) and it is my understanding that they do need to release closed source applications built on top of their open source libraries. In the past I have had similar ambitions, and one day may again, so I too am GPL averse. I have no objection to proprietary, closed source software in the commercial domain as many in the free software world do, with the notable exception that I think scientific computing should be done with open source software. I wrote mpl as part of a suite of tools to replace proprietary EEG software (dongle and all) because work done with that software is only reproducible if you have the 50 thousand dollar dongle. There is a particular ideology with the free software foundation that all software must be free that many in the scientific computing community in python do not support. In this community, I think most people prefer open source software because they like to build their own tools, see what is going on under the hood, and fix it if it is broken. There is also the compelling argument, in principle though not in practice, that open algorithms and code is required by peer review. And as coding science geeks who might actually do something one day that will also pay off in dollar terms, I think many of us want to leave open the possibility of building a proprietary product built on these tools, and the GPL is somewhat incompatible with these ambitions. 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). Well, we certainly have had some success with it and we have had people respond, you're right, I just picked it because it was the only thing I'd heard of. The target audience here is a grad student releasing some technical suite of algorithms that they happen to be world experts in -- they are more scientists than coders -- and are not nearly as deep into this world as we are. This is their first significant coding project and they want to share their algorithms, and often they release it as GPL. We pounce on them and say, What about BSD, so it will play more nicely with scipy and friends?. And by and large that is successful. This is not a pitch aimed at mature projects with multiple contributors, where you are certainly right, getting a switch would be almost impossible. 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? I think LGPL is a perfectly good license which satisfies most of my objections. 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. 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. 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. When I get some time, I'll update my essay, which was really just an email posted on the scipy site but is now an essay wink, and incorporate some of your other very good arguments as well. Thanks, JDH - 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
John Hunter wrote: What about simple_demo.py -- do you get rasters there too? No. I get vectors there. I noticed that using the backend GtkCairo seems to use backend_ps.py for Postscript output. Using backend Cairo uses cairo. Maybe probably explains the difference between Darren and my results. Cheers, Mike - 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] Subsetting fonts in Postscript
On 7/5/07, Eric Firing [EMAIL PROTECTED] wrote: The plan is to make the choice of the existing or new behavior be an option, with the default TBD. Is there any reason *not* to do the subsetting? There was some original confusion in a potential loss of quality in truetype/type2 conversions, because of quartic vs cubic spline approximations in the two specifications. When we were concerned that some users may be hit by a loss-of-quality in conversion, we considered making the conversion and subsetting optional. Michael later clarifed that the loss (which happens only in corner cases) would occur in the type3-truetype conversion, and not in the truetype-type3 case we are interested in because type3 uses quartic and truetype uses cubic. Unless there is a good reason to make it optional, I would like to make it as simple as possible and simply do the conversion and embedding every time. This will make support and debugging easier. JDH - 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 7/5/07, Carl Worth [EMAIL PROTECTED] wrote: You might take a look at what kind of PostScript and PDF output you get from cairo right now, (since cairo has many different kinds of font subsetting, (type3, type42 and others), and it's regularly being tested on as many PostScript and PDF viewers as possible). I don't know if there's anything special about the PostScript output you're currently producing that wouldn't make it acceptable to use cairo's PostScript output directly. But even if you just want code, it's inside cairo under the LGPL. Hey Carl, I looked at cairo when we first started with the postscript backend, but in the bad old days it was just a raster dump. I understand it has come a long way since. mpl's postscript backend supports latex expressions in PS output, which requires a fair amount of complex trickery in the postscript backend, though we we could probably do it with embedded rasters in cairo. The postscript backend is also standalone with no dependencies other than mpl and numpy, and adding cairo to the mix might be a bit difficult for across platforms for some users (though this appears to have gotten a lot better too). LGPL means we cannot reuse the code. While I like the idea of using cairo for both raster and vector outputs in principle because it offloads a lot of work onto a large and well supported project, it would probably take a fair amount of work to get all of mpl's functionality into the cairo backend (I don't know this since I have not tested the backend for some time, but does it support, for example unicode_demo, mathtext_demo, usetex, and image_demo ?). JDH - 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
Carl Worth wrote: You might take a look at what kind of PostScript and PDF output you get from cairo right now, (since cairo has many different kinds of font subsetting, (type3, type42 and others), and it's regularly being tested on as many PostScript and PDF viewers as possible). Thanks for the tip. Indeed, using the unicode_test.py example (which probably has a greater than average amount of text in it), the file sizes are (with the size of the font section is parentheses): backend_ps.py: 135763 (127211) cairo: 49102 (39669) Interestingly, the non-font part is slightly larger for Cairo (9433 vs. 8552) I don't know if there's anything special about the PostScript output you're currently producing that wouldn't make it acceptable to use cairo's PostScript output directly. But even if you just want code, it's inside cairo under the LGPL. It may be worthwhile to look at Cairo's font subsetting code if it's determined that the Python Postscript backend has other advantages. I'm sure people who've been here longer than I have can better speak to those pros and cons. Cheers, Mike - 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
Michael Droettboom wrote: Carl Worth wrote: You might take a look at what kind of PostScript and PDF output you get from cairo right now, (since cairo has many different kinds of font subsetting, (type3, type42 and others), and it's regularly being tested on as many PostScript and PDF viewers as possible). Thanks for the tip. Indeed, using the unicode_test.py example (which probably has a greater than average amount of text in it), the file sizes are (with the size of the font section is parentheses): backend_ps.py: 135763 (127211) cairo: 49102 (39669) Interestingly, the non-font part is slightly larger for Cairo (9433 vs. 8552) Though, I should add, there is a bug in Cairo output with unicode_demo.py: The y-axis label reads stream-vera/VeraSe.ttf... Cheers, Mike - 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 7/5/07, Michael Droettboom [EMAIL PROTECTED] wrote: It may be worthwhile to look at Cairo's font subsetting code if it's determined that the Python Postscript backend has other advantages. I'm sure people who've been here longer than I have can better speak to those pros and cons. Unfortunately, because it is LGPL, I don't think we can in good conscience look at the code, because doing so probably violates the spirit of the LGPL which says you can link with it but not reuse the code in a non GPL/LGPL program. Others may have a different interpretation, and if look but don't copy is OK under the LGPL as it is journalism (read and summarize with citation but don't plagiarize) then its fine by me but that's not my current understanding. JDH - 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 7/5/07, Michael Droettboom [EMAIL PROTECTED] wrote: Do you agree that it is still an open question whether it's better to spend time improving the matplotib PS backend, or to fix (if possible) the issues with matplotlib's Cairo integration? It does ultimately come down to a tradeoff: an additional dependency vs. extra maintenance 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. While I would love to see cairo become a full featured backend, and for there to be additional GUI support like tkcairo, wxcairo, etc, we are a lot farther from that goal than we are to getting the font sizes down in the existing postscript backend. And I like the fact the mpl is completely BSD-ish -- relying on a core component which is LGPL would be a step back in my book, though having it as an option would be great. http://www.scipy.org/License_Compatibility burden. Maybe it would be a good start to enumerate the Cairo backend's current shortcomings. As a start, you might try adding cairo to the list of backends in examples/backend_driver.py and see if everything passes, and take a look at the generated images, eg compared to those of Agg, and see if you identify any other discrepancies. Steve Chaplin who wrote the cairo backend can also elaborate. (So far I've seen some minor text bugs, and math rendering is raster dumps.) Do you mean mathtext or usetex? - The former is mpl's own math layout using the cm*.ttf files, and should work like any other text in the file. The latter uses tex and dvipng rasters (at least in agg), but I don't think it is supported in cairo. So I am not sure where these rasters are coming from, unless cairo is converting all text to rasters. JDH - 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
John Hunter wrote: On 7/5/07, Michael Droettboom [EMAIL PROTECTED] wrote: Do you agree that it is still an open question whether it's better to spend time improving the matplotib PS backend, or to fix (if possible) the issues with matplotlib's Cairo integration? It does ultimately come down to a tradeoff: an additional dependency vs. extra maintenance 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. No, not a ton of work. And this context is helpful. While I would love to see cairo become a full featured backend, and for there to be additional GUI support like tkcairo, wxcairo, etc, we are a lot farther from that goal than we are to getting the font sizes down in the existing postscript backend. And I like the fact the mpl is completely BSD-ish -- relying on a core component which is LGPL would be a step back in my book, though having it as an option would be great. http://www.scipy.org/License_Compatibility Agreed. Do you mean mathtext or usetex? - The former is mpl's own math layout using the cm*.ttf files, and should work like any other text in the file. The latter uses tex and dvipng rasters (at least in agg), but I don't think it is supported in cairo. So I am not sure where these rasters are coming from, unless cairo is converting all text to rasters. mathtext_demo.py -- It originally looked like the math text was rasterized, but the tick labels are not. On closer inspection, it seems all the text is rasterized. The fonts are not rasterized when using the Cairo backend with unicode_demo.py. Haven't looked into that any deeper... Cheers, Mike - 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 Thursday 05 July 2007 03:46:13 pm John Hunter wrote: On 7/5/07, Michael Droettboom [EMAIL PROTECTED] wrote: Do you agree that it is still an open question whether it's better to spend time improving the matplotib PS backend, or to fix (if possible) the issues with matplotlib's Cairo integration? It does ultimately come down to a tradeoff: an additional dependency vs. extra maintenance 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. It was a fair amount of work figuring out how to support latex. Jouni started work on a dvi parser, see dviread.py in matplotlib/lib/matplotlib, which could greatly simplify the gymnastics we currently use to support latex in ps output. If dviread were to be further developed, latex could also be used in conjunction with the pdf backend (Jouni's reason for starting dviread), the svg backend, and I guess it would work with cairo as well. But making dviread robust will probably take more work than options 1 or 2, so it is probably best to pursue one of those options for now. While I would love to see cairo become a full featured backend, and for there to be additional GUI support like tkcairo, wxcairo, etc, we are a lot farther from that goal than we are to getting the font sizes down in the existing postscript backend. And I like the fact the mpl is completely BSD-ish -- relying on a core component which is LGPL would be a step back in my book, though having it as an option would be great. Why can't we all just get along? Do you mean mathtext or usetex? - The former is mpl's own math layout using the cm*.ttf files, and should work like any other text in the file. The latter uses tex and dvipng rasters (at least in agg), but I don't think it is supported in cairo. So I am not sure where these rasters are coming from, unless cairo is converting all text to rasters. I think he is right, gtkcairo converts mathtext to rasters. usetex is not support in gtkcairo. Darren - 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 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
Carl, 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. 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. Eric Carl Worth wrote: On Thu, 5 Jul 2007 13:26:22 -0500, John Hunter wrote: On 7/5/07, Carl Worth [EMAIL PROTECTED] wrote: I don't know if there's anything special about the PostScript output you're currently producing that wouldn't make it acceptable to use cairo's PostScript output directly. But even if you just want code, it's inside cairo under the LGPL. I looked at cairo when we first started with the postscript backend, but in the bad old days it was just a raster dump. I understand it has come a long way since. [...] - 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 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
Re: [matplotlib-devel] Subsetting fonts in Postscript
Carl Worth wrote: On Thu, 05 Jul 2007 13:22:11 -1000, Eric Firing wrote: [...] 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? It's done, except that it is '-dCairo.pdf'. Also, examples/backend_driver.py now supports case-insensitive specifation of backends, and the same form of cairo specification. See docstring at the top. I found that the cairo backend writes ps files but not eps--it enlists backend_ps for eps files. Does pycairo not have a way to specify eps rather than ps output? Eric -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. - 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
