I am wondering it it is possible to: 1. Modify the spacing between subplots; currently they are cramped for some plots that I am generating 2. Reduce the font size of the tick labels (not the axis labels); large font size for subplot ticks is contributing to the crowded look mentioned above. Perhaps I am quite blind, but I could not find these in the tutorial nor in a quick search of the mailing list archive. Thanks for any help. c.
Chris Fonnesbeck wrote: >I am wondering it it is possible to: > >1. Modify the spacing between subplots; currently they are cramped for >some plots that I am generating > >2. Reduce the font size of the tick labels (not the axis labels); >large font size for subplot ticks is contributing to the crowded look >mentioned above. > >Perhaps I am quite blind, but I could not find these in the tutorial >nor in a quick search of the mailing list archive. > >Thanks for any help. > > > Did you check the FAQ, specifically http://matplotlib.sourceforge.net/faq.html#TEXTOVERLAP ?
I apologize if the answer to this is published in some painfully obvious
location. It seems like it must be a FAQ, but I can't find it ...
AFAICT, It is not possible to mix text and TeX symbols in a string and
have it come out right. For example, in
xlabel(r'$\rm{Normalized Temperature} (kT/\epsilon)$'
The text comes out in TeX math mode ... not so pretty. Please tell me
what I've overlooked.
-gary
Gary wrote:
> AFAICT, It is not possible to mix text and TeX symbols in a string and
> have it come out right. For example, in
>
> xlabel(r'$\rm{Normalized Temperature} (kT/\epsilon)$'
> The text comes out in TeX math mode ... not so pretty. Please tell me
> what I've overlooked.
well, I'm not sure how this is supported in matplotlib, but in LaTex,you
would do:
Normalized Temperature $(kT/\epsilon)$
or:
$\text{Normalized Temperature} (kT/\epsilon)$
the "$" means put it in math mode, if you don't want "Normalized
Temperature" in math mode, don't put it inside the $$. The second puts
it all in math mode, but the text{} means set this in text mode.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
Chris Barker wrote:
> Gary wrote:
>
>> AFAICT, It is not possible to mix text and TeX symbols in a string
>> and have it come out right. For example, in
>>
>> xlabel(r'$\rm{Normalized Temperature} (kT/\epsilon)$'
>> The text comes out in TeX math mode ... not so pretty. Please tell
>> me what I've overlooked.
>
>
> well, I'm not sure how this is supported in matplotlib, but in
> LaTex,you would do:
>
> Normalized Temperature $(kT/\epsilon)$
>
> or:
>
> $\text{Normalized Temperature} (kT/\epsilon)$
>
> the "$" means put it in math mode, if you don't want "Normalized
> Temperature" in math mode, don't put it inside the $$. The second puts
> it all in math mode, but the text{} means set this in text mode.
>
> -Chris
>
Matplotlib doesn't support \text, and it requires that the first and
last characters of a TeX string be $. I guess it only processes
mathmode. Well, it can't do *everything*. It would be nice to figure
out a workaround...
thx,
-gary
Gary wrote: > Matplotlib doesn't support \text, and it requires that the first and > last characters of a TeX string be $. I guess it only processes > mathmode. Well, it can't do *everything*. Oh well, I've always thought that if you want to support Math in a graphics package, you would actually use TeX, rather than emulating it. Maybe like PyX: http://pyx.sourceforge.net/ The problem, of course, is that requiring a TeX system is a BIG dependency! It would be nice if one could re-package the Tex interpreter to be embedded. I have no idea how big a job that would be. You'd also have all the font issues, of course, but while that would all be a lot of work, I'm not sure it would be more work than trying to re-write TeX! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
On 2004年10月26日, Chris Barker wrote: > Gary wrote: > > > Matplotlib doesn't support \text, and it requires that the first and > > last characters of a TeX string be $. I guess it only processes > > mathmode. Well, it can't do *everything*. > > Oh well, I've always thought that if you want to support Math in a > graphics package, you would actually use TeX, rather than emulating it. > Maybe like PyX: > > http://pyx.sourceforge.net/ > > The problem, of course, is that requiring a TeX system is a BIG > dependency! It would be nice if one could re-package the Tex interpreter > to be embedded. I have no idea how big a job that would be. You'd also > have all the font issues, of course, but while that would all be a lot > of work, I'm not sure it would be more work than trying to re-write TeX! > > -Chris OTOH: many people working in science will already have a TeX system installed, I'd guess. Another thought: What about an optional PyX back-end for matplotlib? (If one is interested in really good postscript output I think PyX is great. Transparency etc. might be problematic with postscript, but a combination of postscript lines, symbols and math with bitmapped graphics should be possible for the PyX back-end). Best, Arnd P.S.: Just to be sure: I am not saying that the postscript output of matplotlib is bad (Haven't even tested it).
>>>>> "Chris" == Chris Barker <Chr...@no...> writes: Chris> Gary wrote: >> Matplotlib doesn't support \text, and it requires that the >> first and last characters of a TeX string be $. I guess it >> only processes mathmode. Well, it can't do *everything*. It is on the goals page (http://matplotlib.sourceforge.net/goals.html) to support embedded math strings like s = r'Mean ($\mu=5) and standard deviation ($\sigma=1$)' This wouldn't be too hard - just takes some time that I haven't had of late. Chris> Oh well, I've always thought that if you want to support Chris> Math in a graphics package, you would actually use TeX, Chris> rather than emulating it. Maybe like PyX: Chris> http://pyx.sourceforge.net/ Yes, but you lose the platform independence and portability by doing this. It would be nice to be able to choose one or the other -- see below. Chris> The problem, of course, is that requiring a TeX system is a Chris> BIG dependency! It would be nice if one could re-package Chris> the Tex interpreter to be embedded. I have no idea how big Chris> a job that would be. You'd also have all the font issues, Chris> of course, but while that would all be a lot of work, I'm Chris> not sure it would be more work than trying to re-write TeX! It would be a monster job. There is basically no way to factor tex into components -- it's a monolithic system, in part because of the heavy use of web macros. And web2c, the conversion of web/pascal to c, is GPLd and less permissive than the matplotlib license. So embedding tex is a no-go, aside from size considerations. But there are some possibilities for improving what matplotlib already offers. One is to fall back on tex where available as a command line tool (as pyx does, I believe), and use other command line tools to convert the dvi to png or some other raster format and then embed it. This would require a few external libs and utilities, but it's certainly doable. Another idea I had while reading Knuth's "TeX: The Program" is to use the layout information in the TFM font metric files. Apparently math fonts have additional layout information in them, like where to place superscripts. I've looked at several tfm parsing implementations, and haven't found one yet that actually extracts this information; most extract the standard font information but not the special math information. But if we could access this info, we could include the tfm files for common raster sizes and use the layout info crafted by the master himself. A third possibility would be to support mathml, using some good mathml renderer. Is there a good, free mathml rendering library - what does mozilla use for this? JDH
John Hunter wrote: >>>>>>"Chris" == Chris Barker <Chr...@no...> writes: > > > Chris> Gary wrote: > >> Matplotlib doesn't support \text, and it requires that the > >> first and last characters of a TeX string be $. I guess it > >> only processes mathmode. Well, it can't do *everything*. > > It is on the goals page (http://matplotlib.sourceforge.net/goals.html) > to support embedded math strings like > > s = r'Mean ($\mu=5) and standard deviation ($\sigma=1$)' did you mean: s = r'Mean ($\mu=5$) and standard deviation ($\sigma=1$)' I think there was a missing "$". That would be nice. > It would be nice to be able to choose one or the other -- that would be nice. > It would be a monster job. There is basically no way to factor tex > into components -- it's a monolithic system, in part because of the > heavy use of web macros. Ah. too bad. It's nice to know you've looked into this some. > And web2c, the conversion of web/pascal to > c, is GPLd and less permissive than the matplotlib license. So > embedding tex is a no-go, aside from size considerations. web2c is essentially a compiler of sorts, isn't it? So there wouldn't be any problem with distributing C code created by it would there? In any case, there are LOTS of commercial TeX distributions out there, so there must be a way. This doesn't address the other big issues, however. AmiPro, the word processor bought by Lotus, then later turned into WordPro, used TeX to format math. I used it for years before I discovered LaTeX because it had such nice math rendering (MS Word's still sucks!). They somehow managed to embed it, so I suppose it can be done! That doesn't mean it's the least bit easy, however. > But there > are some possibilities for improving what matplotlib already offers. good news, of course. > One is to fall back on tex where available as a command line tool (as > pyx does, I believe), and use other command line tools to convert the > dvi to png or some other raster format and then embed it. This would > require a few external libs and utilities, but it's certainly doable. That would be a nice option, but I'd rather see a DVI driver built in to Matplotlib, than a raster format. That's how PyX does it. I guess that would require matplotlib to have the same fonts, however. Another option would be PDF or EPS, but that would probably only be convenient for PS and/or PDF output. > Another idea I had while reading Knuth's "TeX: The Program" is to use > the layout information in the TFM font metric files. Apparently math > fonts have additional layout information in them, like where to place > superscripts. I've looked at several tfm parsing implementations, and > haven't found one yet that actually extracts this information; most > extract the standard font information but not the special math > information. But if we could access this info, we could include the > tfm files for common raster sizes and use the layout info crafted by > the master himself. very cool. > A third possibility would be to support mathml, using some good mathml > renderer. Is there a good, free mathml rendering library - what does > mozilla use for this? good question. That would be nice, too. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
John Hunter wrote: [snip] > One is to fall back on tex where available as a command line tool (as > pyx does, I believe), and use other command line tools to convert the > dvi to png or some other raster format and then embed it. This would > require a few external libs and utilities, but it's certainly doable. +1 for (relatively) low-hanging fruit. > Another idea I had while reading Knuth's "TeX: The Program" is to use > the layout information in the TFM font metric files. Apparently math > fonts have additional layout information in them, like where to place > superscripts. I've looked at several tfm parsing implementations, and > haven't found one yet that actually extracts this information; most > extract the standard font information but not the special math > information. But if we could access this info, we could include the > tfm files for common raster sizes and use the layout info crafted by > the master himself. I wish you luck! > A third possibility would be to support mathml, using some good mathml > renderer. Is there a good, free mathml rendering library - what does > mozilla use for this? Mozilla's MathML is inextricably linked into Gecko[1] and cannot be torn out of it. I've seen some programs out there that render MathML to either rasters or SVG, but they are either commercial or (L)GPL. They are also usually written in Java or C#. Some possibilities gleaned from http://www.w3.org/Math/implementations.html : * GtkMathView: C++, GPL, already has Perl and PHP bindings http://helm.cs.unibo.it/mml-widget/ Okay, that was the only one I found. In any case, I would not want to be directly writing MathML; it is not intended to be human-writable. There are, however, programs that will convert a restricted mathematical subset of LaTeX to MathML[2]. There are also a few non-TeX syntaxes drifting around with converters to MathML. [1] http://www.mozilla.org/projects/mathml/enable.html [2] http://pear.math.pitt.edu/mathzilla/ -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
John Hunter wrote: > Another idea I had while reading Knuth's "TeX: The Program" is to use > the layout information in the TFM font metric files. Apparently math > fonts have additional layout information in them, like where to place > superscripts. I've looked at several tfm parsing implementations, and > haven't found one yet that actually extracts this information; most > extract the standard font information but not the special math > information. But if we could access this info, we could include the > tfm files for common raster sizes and use the layout info crafted by > the master himself. Taking this as a challenge (and having little to do while waiting for images to process), I wrote a TFM parser that handles the extra parameters for math symbols. This format[1] is excruciatingly painful. http://starship.python.net/crew/kernr/tfm.py And then I realized that the output of tftopl(1) is incredibly easy to parse and contains the same information. <sigh> Either way, you now have the information you need for some fonts, at least. [1] http://www.ctan.org/tex-archive/dviware/driv-standard/level-0/dvistd0.pdf -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
>>>>> "Robert" == Robert Kern <rk...@uc...> writes: John> Another idea I had while reading Knuth's "TeX: The Program" John> is to use the layout information in the TFM font metric John> files. Apparently math fonts have additional layout John> information in them, like where to place superscripts. I've John> looked at several tfm parsing implementations, and Robert> I wish you luck! Who needs luck when we've got people like you around! :-) Robert> Taking this as a challenge (and having little to do while Robert> waiting for images to process), I wrote a TFM parser that Robert> handles the extra parameters for math symbols. This Robert> format[1] is excruciatingly painful. Robert> http://starship.python.net/crew/kernr/tfm.py Robert> And then I realized that the output of tftopl(1) is Robert> incredibly easy to parse and contains the same Robert> information. <sigh> Robert> Either way, you now have the information you need for some Robert> fonts, at least. Awesome - impressive work for an afternoon. Thanks for pointing me to that dvi specification reference. I was trying to discern the format from TeX: The Program, which despite its literate style, was less accessible than the reference you pointed to. It is painful, though, as you say, no matter how you slice it. Funny that I missed tftopl in my hunt for a parser, which was sitting right on my system the whole time. In order to use this information in mathtext, we have reconstruct the mapping from TeX symbol name to font and character number for each of the tex symbols we use (cmr10, cmi10, cmex10 and cmsy10) . Currently mathtext hardcodes the mapping from tex name to bakoma fontname/number. A better approach would be to use either the mathml or unicode number as the internal code for each symbol, and then provide mappings from these to the tfm fontname/charnum and to the corresponding tex symbol names - my guess is that this has already been done and we just have to dig it up. Then we could use any of the fonts (Wolfram, Design Science, Symbol, AMS, Bakoma) at http://www.mozilla.org/projects/mathml/fonts/encoding for matplotlib mathtext, since the mapping from mathml/unicode to fontname/charnum already exists on pages like http://www.mozilla.org/projects/mathml/fonts/encoding/cmr.html, and is easily parsed (I already did this when I was working on PS mathtext with type1 fonts before Paul had the bright idea of just embedding the truetype fonts in the ps document and reusing what we already had. In summary, it would be nice to be able to readily go from tex name <-> mathml/unicode name <-> fontname/charnum in a variety of files, including at a minimum the bakoma ttf and the corresponding tfm files. Got some images to process today <wink> Does this sound like the right approach to you? JDH
> Then we could use any of the fonts (Wolfram, Design Science, Symbol, > AMS, Bakoma) at http://www.mozilla.org/projects/mathml/fonts/encoding > for matplotlib mathtext, since the mapping from mathml/unicode to > fontname/charnum already exists on pages like > http://www.mozilla.org/projects/mathml/fonts/encoding/cmr.html, and is > easily parsed (I already did this when I was working on PS mathtext > with type1 fonts before Paul had the bright idea of just embedding the > truetype fonts in the ps document and reusing what we already had. > Any thoughts to use Richard Kinchs Universal Modern fonts as well as the bellek fonts on his site (www.truetex.com) instead of the bakoma fonts? It seems that um and bellek are free to use and redistributable. This is not the case for bakoma in commercial use. The quality of the fonts are excellent. Umlauts and more special signs are included compared to bakoma. The charnums are different however and not included on mozillas encoding page. Regards Carl-M Kleffner > In summary, it would be nice to be able to readily go from tex name > <-> mathml/unicode name <-> fontname/charnum in a variety of files, > including at a minimum the bakoma ttf and the corresponding tfm files. > Got some images to process today <wink> > > Does this sound like the right approach to you? > > JDH > > -- NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!
>>>>> "Carl" == Carl Dr Kleffner <cmk...@gm...> writes: Carl> Any thoughts to use Richard Kinchs Universal Modern fonts as Carl> well as the bellek fonts on his site (www.truetex.com) Carl> instead of the bakoma fonts? It seems that um and bellek are Carl> free to use and redistributable. This is not the case for Carl> bakoma in commercial use. The quality of the fonts are Carl> excellent. Umlauts and more special signs are included Carl> compared to bakoma. The charnums are different however and Carl> not included on mozillas encoding page. I would be very happy to support these fonts, especially if someone (you, perhaps) provided the dictionary mapping tex symbol names to name/charnum, as in the latex_to_bakoma dictionary in matplotlib._mathtext_data. The rest is easy, and I could provide an rc param allowing you to select which fonts to include. We ought to expose the glyph names through FT_Get_Glyph_Name in the ft2font module to facilitate this kind of thing.... I notice that, for example, blex.ttf uses names like ceilingleftbigg ceilingrightbigg braceleftbigg bracerightbigg angbracketleftbigg angbracketrightbigg slashbigg backslashbigg parenleftBigg which would make it fairly easy to do the mapping. Since the bakoma fonts are the only things in the matplotlib distro restricted for free, noncommercial use, this would be a nice addition. If we later decide to go with a mathml/unicode representation internally, it would be trivial to automatically convert the existing dictionaries in _mathtext_data. JDH
John Hunter wrote: > Awesome - impressive work for an afternoon. Thanks for pointing me to > that dvi specification reference. I was trying to discern the format > from TeX: The Program, which despite its literate style, was less > accessible than the reference you pointed to. It is painful, though, > as you say, no matter how you slice it. > > Funny that I missed tftopl in my hunt for a parser, which was sitting > right on my system the whole time. I know how you feel. *Believe* me. In any case, please use tftopl. I'm pretty sure there's a bug in how tfm.py reads the fixed-point values, but I'm giving up in favor of tftopl. > In order to use this information in mathtext, we have reconstruct the > mapping from TeX symbol name to font and character number for each of > the tex symbols we use (cmr10, cmi10, cmex10 and cmsy10) . Currently > mathtext hardcodes the mapping from tex name to bakoma > fontname/number. > > A better approach would be to use either the mathml or unicode number > as the internal code for each symbol, and then provide mappings from > these to the tfm fontname/charnum and to the corresponding tex symbol > names - my guess is that this has already been done and we just have > to dig it up. Does http://www.dessci.com/fr/support/tech/encodings/font_enc.stm help? > Then we could use any of the fonts (Wolfram, Design Science, Symbol, > AMS, Bakoma) at http://www.mozilla.org/projects/mathml/fonts/encoding > for matplotlib mathtext, since the mapping from mathml/unicode to > fontname/charnum already exists on pages like > http://www.mozilla.org/projects/mathml/fonts/encoding/cmr.html, and is > easily parsed (I already did this when I was working on PS mathtext > with type1 fonts before Paul had the bright idea of just embedding the > truetype fonts in the ps document and reusing what we already had. > > In summary, it would be nice to be able to readily go from tex name > <-> mathml/unicode name <-> fontname/charnum in a variety of files, > including at a minimum the bakoma ttf and the corresponding tfm files. > Got some images to process today <wink> > > Does this sound like the right approach to you? More or less. Converting from TeX encodings (which are arcane) to modern standards as soon as possible is almost certainly the best approach. -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
[Sorry for the self-reply] Robert Kern wrote: > Does http://www.dessci.com/fr/support/tech/encodings/font_enc.stm help? No, it in fact does not. -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
>>>>> "Robert" == Robert Kern <rk...@uc...> writes: Robert> [Sorry for the self-reply] Happens to the best of us :-) >> Does >> http://www.dessci.com/fr/support/tech/encodings/font_enc.stm >> help? Robert> No, it in fact does not. Well it may actually, since these pages provide the unicode indices for some of the cm fonts. We already have tex symbol -> char code for the bakoma fonts in _mathtext_data, and they have the char code -> unicode mappings in their "Character List", so it should be trivial to build all the forward and backwards dicts we need. Although I didn't see any explicit reference to bakoma, they appear to be using them; eg, compare the encodings at http://www.dessci.com/en/support/tech/encodings/texcmrom.htm and http://www.mozilla.org/projects/mathml/fonts/encoding/cmr-ttf-encoding.html Or is it just late and I've gone soft in the head? JDH
John Hunter wrote: >>>>>>"Robert" == Robert Kern <rk...@uc...> writes: > > > Robert> [Sorry for the self-reply] > > Happens to the best of us :-) > > >> Does > >> http://www.dessci.com/fr/support/tech/encodings/font_enc.stm > >> help? > > Robert> No, it in fact does not. > > Well it may actually, since these pages provide the unicode indices > for some of the cm fonts. We already have tex symbol -> char code for > the bakoma fonts in _mathtext_data, and they have the char code -> > unicode mappings in their "Character List", so it should be trivial to > build all the forward and backwards dicts we need. Although I didn't > see any explicit reference to bakoma, they appear to be using them; > eg, compare the encodings at > > http://www.dessci.com/en/support/tech/encodings/texcmrom.htm > > and > > http://www.mozilla.org/projects/mathml/fonts/encoding/cmr-ttf-encoding.html > > Or is it just late and I've gone soft in the head? Okay, it does help for mapping the encoding used in the CM TrueType font to Unicode. This is not the same encoding used in the TFM files which is what I was thinking of. -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter