You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
| 2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
| 2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
| 2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
| 2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
| 2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
| 2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
| 2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
| 2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
| 2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
| 2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
| 2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
| 2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
| 2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
(3) |
|
3
(1) |
4
(7) |
5
(11) |
6
(6) |
7
(3) |
8
(6) |
9
|
|
10
(1) |
11
(4) |
12
(5) |
13
(7) |
14
(8) |
15
|
16
(2) |
|
17
(3) |
18
|
19
(1) |
20
(7) |
21
(7) |
22
|
23
|
|
24
(1) |
25
(2) |
26
(7) |
27
(8) |
28
(3) |
29
(6) |
30
|
|
31
|
|
|
|
|
|
|
|
From: Robert K. <rk...@uc...> - 2004-10-27 23:51:00
|
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 |
|
From: John H. <jdh...@ac...> - 2004-10-27 21:35:50
|
>>>>> "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
|
|
From: Carl D. K. <cmk...@gm...> - 2004-10-27 16:40:40
|
> 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! |
|
From: John H. <jdh...@ac...> - 2004-10-27 14:44:16
|
>>>>> "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
|
|
From: Robert K. <rk...@uc...> - 2004-10-27 03:57:51
|
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 |
|
From: Samir P. <mep...@ya...> - 2004-10-27 03:10:07
|
After this fix to pycxx, I was able to create matplotlib fine (with pygtk 2.4 patch). Thanks for a quick response. --- John Hunter <jdh...@ac...> wrote: > >>>>> "Samir" == Samir Patel <mep...@ya...> > writes: > > Samir> I am getting following error while > compiling later version > Samir> of matplotlib with gcc 3.4.2: Any clue? > > This is a pycxx bug that is fixed in pycxx and > matplotlib cvs. See > http://sourceforge.net/mailarchive/message.php?msg_id=9683332 > for the > solution -- replace map(s) with map(m) on the > offending line 2271 in > CXX/Objects.hxx. > > Hope this helps, > JDH > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail |
|
From: John H. <jdh...@ac...> - 2004-10-27 01:59:29
|
>>>>> "Samir" == Samir Patel <mep...@ya...> writes:
Samir> I am getting following error while compiling later version
Samir> of matplotlib with gcc 3.4.2: Any clue?
This is a pycxx bug that is fixed in pycxx and matplotlib cvs. See
http://sourceforge.net/mailarchive/message.php?msg_id=9683332 for the
solution -- replace map(s) with map(m) on the offending line 2271 in
CXX/Objects.hxx.
Hope this helps,
JDH
|
|
From: Dominique O. <dom...@po...> - 2004-10-27 00:49:32
|
> Date: Mon, 25 Oct 2004 20:40:02 -0400
> From: Gary <pa...@in...>
> To: Chris Barker <Chr...@no...>
> CC: mat...@li...
> Subject: Re: [Matplotlib-users] TeX in xlabel ?
>
> 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...
Gary's example
xlabel(r'$\rm{Normalized Temperature} (kT/\epsilon)$'
USED to work, in earlier versions of Matplotlib. It no longer does. I have
posted a similar issue a little while ago:
http://sourceforge.net/mailarchive/message.php?msg_id=9681306
Unfortunately, I haven't really had the time to dig into the code to see what
has changed, but when I do, I'll let you know what I find. The solution
xlabel(r'$\rm{Normalized \ Temperature} (kT/\epsilon)$'
somehow isn't entirely satisfactory.
As far as I can see, \rm{} in Matplotlib should act just the way \mbox{} does in
LaTeX, when you are already in math mode. And certainly, in LaTeX,
$$
xy = 0 \mbox{ but however } x \neq y
$$
produces the expected output in the expected fonts and with the expected
spacing.
Dominique
|