John Hunter wrote: > On Wed, Jun 11, 2008 at 12:25 PM, Michael Droettboom <[EMAIL PROTECTED]> > wrote: > >> Ok. I think I have that worked out -- would you mind testing on docutils >> 0.4? (I don't think I broke anything that wasn't already broken...) >> > > OK, sorry I've been causing so much trouble, but I guess it is good > that at least one of works on python 2.4 sometimes. > > What I really wanted to talk about is that I think this new support is > a killer feature, and I would like to see it widely accessible and > advertised. I think people will find the ability to do turnkey math > text to be useful in many contexts where a full blown tex/dvipng > install is impractical. This is particularly true for folks > distributing apps to windows. Potential use cases are math in GUI > buttons, menus and other widgets, There is the mathtext_wx.py example for this. I was hoping experts in the other GUI toolkits could port this example to Gtk, Qt, Tk etc. (assuming it's doable). > math blitted into a vtk or other > canvas, webapp servers wanting to use math pngs etc... > > So I'd like at a minimum to move your latex2png into the mathtext > module (or the text module or wherever it belongs), probably rename it > mathtext2png to avoid confusion, and import that function into the > mathpng sphinx extension. I also think we should provide a math2array > which returns an rgba array that people can do what they want with. > I'm happy to do all this easy stuff now that you have done the hard > part, but I just wanted to bounce it off you in case you had any > suggestions. I'm curious about a couple of things in the mathpng > func: > > * why do you hardcode the math font to be 'cm'? > Just so that the documentation will always look the same, even if the machine on which the documentation is being generated specifies wacky math fonts. I considered adding a parameter to the "math" directive to select the fontset, but then realized that wouldn't work for LaTeX (where *real* TeX is used to render the math). I thought it best to have reasonable consistency between the HTML and PDF versions of the docs, so opted for "cm" as the default. > * why do you hardcode the dpi to be 120 -- is that just a stylistic > choice? It seemed to look the best inlined in HTML on my browser with my fonts. Totally subjective choice. For people with different monitor resolutions, font sizes etc. that obviously doesn't work. But that's more a limitation of HTML (or the HTML that Sphinx currently generates) than anything else. Note also that the inline math images are not baseline-adjusted. For that, we need to get a proper baseline out of mathtext, which currently isn't possible. > BTW, in semi-related news, it appears sphinx (at least my > version) ignores the scale on the image directives, which is why the > html images appear large and the PDF ones appear small. This is odd, > because on my system rst2html respects the scale directive so it > appears to be a buglet. > Could be. > Very nice work on the auto-generated symbol tables, btw. I consider that somewhat of a work in progress. It was important (to me at least) to have them somewhat sorted into categories, rather than just a jumbled or alphabetized list, but I still think they could be ordered better, and categorized at a finer level to pick things out faster. (See the "Comprehensive LaTeX Symbol List" for a reasonable way to do this). All that just takes busy work -- the infrastructure is already there.
Another shortcoming is that the table is automatically "chunked" into 20 rows, since otherwise LaTeX will create a table that extends beyond the bottom of the page. But the chunking makes things look much less neat and is totally arbitrary. Finer-grained categories would be a good way around this. > I am eagerly > studying this sphinxext stuff -- very powerful. You know, Stefan > called for a sphinx presentation the other day for scipy 08, and I > think this kind of stuff would make a great talk if you are planning > on attending. > There does seem to be a recent convergence around Sphinx in the Scipy world, and matplotlib seems to be forging ahead a little bit (maybe that's just my impression from being in the middle of matplotlib more so than other projects). It would be great to have something like a Sphinx/Documentation BoF to share our experiences thus far, or perhaps a lightning talk (which at SciPy are 10 minutes) to outline what matplotlib has done wrt documentation. If Darren were going, he'd be ideal to give that talk, but I could probably manage as well. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
