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
|
From: John H. <jdh...@ac...> - 2004-11-06 22:30:15
|
>>>>> "Greg" == Greg Wilson <gvw...@cs...> writes: Greg> Hi. I'm trying to graph the progress of a small software Greg> project over time. My program, and a sample data file, are Greg> attached. If I call ax.autoscale_view(), I get labels on my Greg> X axis, but the graph runs from 2002 to 2006, even though my Greg> data is only for Oct and Nov of 2004. If I comment out the Greg> autoscale_view() call, I get a much more reasonable range, Greg> but lose the ticks on the axis. What am I doing wrong? The problem is you are using a YearLocator for your major ticks. This will place ticks on every year, which is likely not what you want since your date range is only a few days. I see that section of the code is a cut and paste from the date_demo code. plot_date will try and pick the right tick locators and formatters automatically. I suggest you just try plot_date with the default (don't set the locator or formatter manually) and if you are dissatisfied try setting locators and formatters appropriate for the scale of data you are plotting - eg a DayLocator for the major ticks and an hour locator for the minor ones (note you can configure the locators to tick every day, every 2nd day, every 12th hour, etc...) JDH |
From: Greg W. <gvw...@cs...> - 2004-11-06 18:04:31
|
Hi. I'm trying to graph the progress of a small software project over time. My program, and a sample data file, are attached. If I call ax.autoscale_view(), I get labels on my X axis, but the graph runs from 2002 to 2006, even though my data is only for Oct and Nov of 2004. If I comment out the autoscale_view() call, I get a much more reasonable range, but lose the ticks on the axis. What am I doing wrong? Thanks, Greg |
From: Chris <Ch...@Fu...> - 2004-11-04 11:10:08
|
Dear friends, I just start to use matplotlib, which looks quite promising for me. I need to draw a couple of arrows in my 2D plot. Is there a simple way to get it work? Any suggustions are welcome. Best regards, Shen |
From: Paul B. <ba...@st...> - 2004-11-01 20:21:13
|
John Hunter wrote: >>>>>>"Carl" == Carl Dr Kleffner <cmk...@gm...> writes: >>>>>> >>>>>> > > Carl> I would like to try this. Due to time constraints, it may > Carl> take some time. As far as I understand I have to use the > Carl> GlyphIDs as well as the map code from cmap_format_4 to > Carl> create a latex_to_umbelleek dictionary. Any hints from font > Carl> experts are appreciated. > >The minimum you need to do is provide a dictionary that maps TeX >symbol name to the fontname/glyphindex for that symbol. Eg for \pm in >bakoma, the font name is cmsy10.ttf, the glyph index is 8 , the >character code is 167 (hex is 0xa7) and the glyph name is plusminus. >The entry in the latex_to_bakoma dict is > > r'\pm' : ('cmsy10', 8), > > >From the fontname and glyph index, we can get the character code and >glyphname from the ttf file. I have written a little helper script >for you. It's brute force and ain't terribly pretty, but it (mostly, >see below) works. > > http://matplotlib.sf.net/share/font_table.py > >This creates a font grid table png using the agg backend and >matplotlib's ft2font module - you'll probably want to get the latest >CVS matplotlib for this to work properly - I'm not 100% sure this is >required but it is at least strongly recommended. > >It will produce font grid images for the font specified on the command >like, like the following for umr10.ttf > > http://matplotlib.sf.net/share/umr10.ttf.png > >You can use these grid tables to get the hex charcode code of the >symbol you want, and the output of the script lists the glyphind, >ccode, hex(ccode), and name, sorted by charcode, so you can look up >the glyphind form the hex code. Ie > > 1) Pick a new tex symbol. > > 2) Find the corresponding character in one of the umbellek font > table pngs, or by using the glyph names listed when you run the > font_table script. > > 3) Use the font_table output to get the glyphind corresponding to > the symbol/name of interest. > > 4) GOTO 1 > >There is probably a better way, but with a combination of glyphnames >and grid tables you can knock this out in several hours of tedious >work. Any other information you want to attach while you are in the >thick of it (mathml names, unicode chars) would be a great, but is not >necessary. > > Carl> I would like to add codes for accented chars: r'ä': > Carl> ('umr10', <code>) Should _mathtext_data.py contain a > Carl> encoding line, i.e. # -*- coding: latin1 -*- to allow > Carl> non-Ascii chars? > >Perhaps others can give input here about what would be the best way to >proceed. My inclination is to use the TeX names like \"a where >possible, but by all means add them if you have them - getting the >codes is the relatively tedious part, providing the proper interface >to them can be worked out later. It may require some changes to the >parser to support \"a and friends, but this is no problem. > > A possible alternative approach to getting the proper glyph from the TTF file is to map the LaTeX name into the PostScript name and then use the PS name to find the glyph index from ft2font::get_name_index(). This or a similar approach is what I had in mind when I first implemented the TTF code. This assumes that the glyphs associated with the PS names adhere to the Adobe PS naming definition. In this case, the PS name could be used to create on-the-fly a lookup dictionary of the fontname/index. My memory is a bit hazy on this issue, but I seem to recall that the TeX font names are not completely consistent with the Adobe PS names. In addition, there needed to be a mechanism to distinguish between the same glyph in different Bakoma fonts. I'm guessing that the more recent fonts probably adhere to the PS font naming convention and therefore it might be worthwhile persuing this approach again. It sure would make it easier to create the math font tables and to use other fonts that contain such mathematical glyphs. >Now, on to the "mostly working" part of the font_table script, which >is why I CCd Paul on this email. The font_table script is working on >the um*.ttf fonts but failing on the bl*.ttf fonts. The reason it is >failing is that FT2Font::get_charmap is returning an empty dict. >These fonts are not empty, eg ft2font reports 1 face, 2 charmaps, and >124 glyphs for blsy.ttf, but get_charmap is returning empty, because >the call to > > FT_ULong code = FT_Get_First_Char(face, &index); > >is returning 0 for code and index. > >Any ideas? > > John, you appear to have solved this one yourself. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218 |
From: Jochen V. <vo...@se...> - 2004-11-01 20:09:15
|
Hello Alan, On Mon, Nov 01, 2004 at 11:52:07AM -0500, Alan G Isaac wrote: > http://sourceforge.net/mailarchive/forum.php?thread_id=3D5562487&forum_id= =3D33405 Thanks, this looks incredibly useful. I will have a closer look as soon as I find time. All the best, Jochen --=20 http://seehuhn.de/ |
From: Jochen V. <vo...@se...> - 2004-11-01 20:04:04
|
Hello Cory, On Mon, Nov 01, 2004 at 04:24:34PM +0000, Cory Davis wrote: > I'm not suggesting that this is a good way to to so, but it works (the > last time I tried). Hope this helps. Thank you very much, it works beautifully. All the best, Jochen --=20 http://seehuhn.de/ |
From: Alan G I. <ai...@am...> - 2004-11-01 16:51:07
|
On Mon, 1 Nov 2004, Jochen Voss apparently wrote: > I would like to (mis-)use matplotlib to draw some things which > are not graphs of functions. For this it would be nice to > be able to fix the aspect ratio of the figure to 1. What is > a good way to do so? http://sourceforge.net/mailarchive/forum.php?thread_id=5562487&forum_id=33405 hth, Alan Isaac |
From: Cory D. <cd...@st...> - 2004-11-01 16:24:54
|
Hi there, I'm not suggesting that this is a good way to to so, but it works (the last time I tried). Hope this helps. def setDataAspectRatioByFigSize(ax,r): """Same idea as matlab. Adjusts the figure size to fix the aspect ratio""" xlim=ax.get_xlim() dxlim=xlim[1]-xlim[0] ylim=ax.get_ylim() dylim=ylim[1]-ylim[0] pos=ax.get_position() dxpos=pos[2] dypos=pos[3] f=gcf() figsize=f.get_size_inches() dxfig=figsize[0] dyfig=dylim*dxpos*dxfig/r/dypos/dxlim f.set_figsize_inches(dxfig,dyfig) def setDataAspectRatioByAxisPos(ax,r): """Same idea as matlab. Adjusts the axis position to fix the aspect ratio""" xlim=ax.get_xlim() dxlim=xlim[1]-xlim[0] ylim=ax.get_ylim() dylim=ylim[1]-ylim[0] pos=ax.get_position() dxpos=pos[2] dypos=pos[3] centreypos=pos[1]+0.5*dypos f=gcf() figsize=f.get_size_inches() dxfig=figsize[0] dyfig=figsize[1] dypos=dylim*dxpos*dxfig/r/dyfig/dxlim ax.set_position([pos[0],centreypos-0.5*dypos,dxpos,dypos]) Cheers, Cory On Mon, 2004-11-01 at 16:02, Jochen Voss wrote: > Hello, > > I would like to (mis-)use matplotlib to draw some things which > are not graphs of functions. For this it would be nice to > be able to fix the aspect ratio of the figure to 1. What is > a good way to do so? > > Jochen -- )))))))))))))))))))))))))))))))))))))))))))) Cory Davis Meteorology School of GeoSciences University of Edinburgh King's Buildings EDINBURGH EH9 3JZ ph: +44(0)131 6505092 fax +44(0)131 6505780 cd...@st... co...@me... http://www.geos.ed.ac.uk/contacts/homes/cdavis )))))))))))))))))))))))))))))))))))))))))))) |
From: Jochen V. <vo...@se...> - 2004-11-01 16:02:25
|
Hello, I would like to (mis-)use matplotlib to draw some things which are not graphs of functions. For this it would be nice to be able to fix the aspect ratio of the figure to 1. What is a good way to do so? Jochen --=20 http://seehuhn.de/ |
From: matthew a. <ma...@ca...> - 2004-11-01 04:33:14
|
Hi, I thought I'd mention some small isuues I found with using py2exe to deploy matplotlib 0.63.2 on Japanese Windows 2000. * pytz seems to need a copy of C:\Python23\Lib\site-packages\pytz\zoneinfo in the installed folder, otherwise it gives a KeyError on UTC when matplotlib is imported * pygtk.require() is not compatible with py2exe, so I added a wrapper to backend_gtk.py to check for freezing: if not hasattr(sys, 'frozen'): try: # Don't want to check this for py2exe import pygtk pygtk.require('2.0') except: print sys.exc_info()[1] raise SystemExit('PyGTK version 1.99.16 or greater is required to run the GTK/GTKAgg Matplotlib backend') * font_manager.py throws an exception, I suspect to do with Japanese font names or font directory names: File "c:\Python23\lib\site-packages\matplotlib\font_manager.py", line 111, in win32InstalledFonts key, direc, any = _winreg.EnumValue( local, j) WindowsError: [Errno 234] from this site: http://www.google.com.au/search?q=cache:B8BlgKwVYxcJ:www.cubelab.com/ymasuda/python/index_jp.html+matplotlib+local+None+windowserror&hl=en I found a workaround to add local = None at line 107 of font_manager.py to give this: for fontdir in MSFontDirectories: try: local = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, fontdir) except OSError: continue local = None if not local: return glob.glob(os.path.join(directory, '*.'+fontext)) * gtk 2.2.? was crashing (segfault) on Japanese Win2k so I upgraded to the latest (2.4.13) and now it seems to work. However now I get various dprecation warnings about the GTK toolbar when I show a plot. And IPython seems to break with GTK 2.4.x. * Generally getting it all to work required quite a bit of fiddling and munging various recipes I found on email lists and in the pygtk FAQ. This included copying the matplotlib shared data into the installation and experimenting with different locations for it, and copying the gtk runtime into the installation and modifying the path within python so it could be found. Thanks for matplotlib! Cheers, Matthew. |
From: John H. <jdh...@ac...> - 2004-10-29 18:03:47
|
>>>>> "Carl" == Carl Dr Kleffner <cmk...@gm...> writes: >> Carl> I will take that script (and use the output of the ttx Carl> fonttool as well) to estimate the glyph ids for each latex Carl> symbol. This will take a week or so. If it is not possible Carl> to reach the charmap values by get_charmap for the belleek Carl> fonts one could use an additional dict with the charmaps Carl> values. I believe I have fixed the problem with the bl*.ttf fonts. I exposed FT_Set_Charmap via font.set_charmap in ft2font and calling font.set_charmap(0) seems to cure the problem with the bl* fonts. Apparently, there isn't a default charmap set for those fonts - no exactly sure. In any case, I updated CVS -- make sure you have at least revision 1.10 of ft2font.cpp and the updated script at http://matplotlib.sf.net/share/font_table.py Have fun :-) Perhaps we should move further discussion on this issue over to the matplotlib-devel list. JDH |
From: Carl D. K. <cmk...@gm...> - 2004-10-29 14:59:37
|
Dear John > ... > Perhaps others can give input here about what would be the best way to > proceed. My inclination is to use the TeX names like \"a where > possible, but by all means add them if you have them - getting the > codes is the relatively tedious part, providing the proper interface > to them can be worked out later. It may require some changes to the > parser to support \"a and friends, but this is no problem. > I will take that script (and use the output of the ttx fonttool as well) to estimate the glyph ids for each latex symbol. This will take a week or so. If it is not possible to reach the charmap values by get_charmap for the belleek fonts one could use an additional dict with the charmaps values. > Now, on to the "mostly working" part of the font_table script, which > is why I CCd Paul on this email. The font_table script is working on > the um*.ttf fonts but failing on the bl*.ttf fonts. The reason it is > failing is that FT2Font::get_charmap is returning an empty dict. > These fonts are not empty, eg ft2font reports 1 face, 2 charmaps, and > 124 glyphs for blsy.ttf, but get_charmap is returning empty, because > the call to > > FT_ULong code = FT_Get_First_Char(face, &index); > > is returning 0 for code and index. > > Any ideas? > > JDH > Maybe because this fonts use charmaps values beyond 0x20: <cmap_format_4 platformID="3" platEncID="0" version="0"> <map code="0x1" name="Delta"/><!-- <control> --> <map code="0x2" name="Theta"/><!-- <control> --> <map code="0x3" name="Lambda"/><!-- <control> --> A cmap value for 0x0 is missing: <map code="0x0" name=".null"/> (um fonts) But this is just a wild guess. Regards Carl -- Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD ++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++ |
From: John H. <jdh...@ac...> - 2004-10-29 14:21:14
|
>>>>> "Carl" =3D=3D Carl Dr Kleffner <cmk...@gm...> writes: Carl> I would like to try this. Due to time constraints, it may Carl> take some time. As far as I understand I have to use the Carl> GlyphIDs as well as the map code from cmap_format_4 to Carl> create a latex_to_umbelleek dictionary. Any hints from font Carl> experts are appreciated. The minimum you need to do is provide a dictionary that maps TeX symbol name to the fontname/glyphindex for that symbol. Eg for \pm in bakoma, the font name is cmsy10.ttf, the glyph index is 8 , the character code is 167 (hex is 0xa7) and the glyph name is plusminus. The entry in the latex_to_bakoma dict is r'\pm' : ('cmsy10', 8), From the fontname and glyph index, we can get the character code and glyphname from the ttf file. I have written a little helper script for you. It's brute force and ain't terribly pretty, but it (mostly, see below) works. http://matplotlib.sf.net/share/font_table.py This creates a font grid table png using the agg backend and matplotlib's ft2font module - you'll probably want to get the latest CVS matplotlib for this to work properly - I'm not 100% sure this is required but it is at least strongly recommended. It will produce font grid images for the font specified on the command like, like the following for umr10.ttf http://matplotlib.sf.net/share/umr10.ttf.png You can use these grid tables to get the hex charcode code of the symbol you want, and the output of the script lists the glyphind, ccode, hex(ccode), and name, sorted by charcode, so you can look up the glyphind form the hex code. Ie 1) Pick a new tex symbol. 2) Find the corresponding character in one of the umbellek font table pngs, or by using the glyph names listed when you run the font_table script. 3) Use the font_table output to get the glyphind corresponding to the symbol/name of interest. 4) GOTO 1 There is probably a better way, but with a combination of glyphnames and grid tables you can knock this out in several hours of tedious work. Any other information you want to attach while you are in the thick of it (mathml names, unicode chars) would be a great, but is not necessary. Carl> I would like to add codes for accented chars: r'=E4': Carl> ('umr10', <code>) Should _mathtext_data.py contain a Carl> encoding line, i.e. # -*- coding: latin1 -*- to allow Carl> non-Ascii chars? Perhaps others can give input here about what would be the best way to proceed. My inclination is to use the TeX names like \"a where possible, but by all means add them if you have them - getting the codes is the relatively tedious part, providing the proper interface to them can be worked out later. It may require some changes to the parser to support \"a and friends, but this is no problem. Now, on to the "mostly working" part of the font_table script, which is why I CCd Paul on this email. The font_table script is working on the um*.ttf fonts but failing on the bl*.ttf fonts. The reason it is failing is that FT2Font::get_charmap is returning an empty dict. These fonts are not empty, eg ft2font reports 1 face, 2 charmaps, and 124 glyphs for blsy.ttf, but get_charmap is returning empty, because the call to FT_ULong code =3D FT_Get_First_Char(face, &index); is returning 0 for code and index. Any ideas? =20 JDH |
From: Carl D. K. <cmk...@gm...> - 2004-10-29 06:47:23
|
> >>>>> "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. > > ... > > JDH > I would like to try this. Due to time constraints, it may take some time. As far as I understand I have to use the GlyphIDs as well as the map code from cmap_format_4 to create a latex_to_umbelleek dictionary. Any hints from font experts are appreciated. I would like to add codes for accented chars: r'ä': ('umr10', <code>) Should _mathtext_data.py contain a encoding line, i.e. # -*- coding: latin1 -*- to allow non-Ascii chars? Regards Carl -- NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis! |
From: Robert K. <rk...@uc...> - 2004-10-29 02:15:01
|
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 |
From: John H. <jdh...@ac...> - 2004-10-29 02:04:42
|
>>>>> "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 |
From: John H. <jdh...@ac...> - 2004-10-28 22:07:30
|
>>>>> "Dan" == Dan <da...@ya...> writes: Dan> I compiled matplotlib fine. But when importing it, I got this Dan> message: ..snip.. Dan> import matplotlib >>>> matplotlib.use('Agg') import matplotlib.matlab as Mat Dan> LazyValue::init_type Value::init_type BinOp::init_type Dan> Point::init_type Interval::init_type Bbox::init_type You have compiled matplotlib with VERBOSE set to True in setup.py. Set VERBOSE=False and > rm -rf build and recompile. Should work... JDH |
From: Dan <da...@ya...> - 2004-10-28 21:55:02
|
I compiled matplotlib fine. But when importing it, I got this message: Python 2.3.4 (#1, Oct 25 2004, 20:36:25) [GCC 3.3.1 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os,sys,time, string import Numeric as N import matplotlib >>> matplotlib.use('Agg') >>> import matplotlib.matlab as Mat LazyValue::init_type Value::init_type BinOp::init_type Point::init_type Interval::init_type Bbox::init_type Func::init_type FuncXY::init_type Transformation::init_type SeparableTransformation::init_type NonseparableTransformation::init_type Affine::init_type init_nc_transforms _transforms_module::new_value _transforms_module::new_value _transforms_module::new_point Point::Point _transforms_module::new_value _transforms_module::new_value _transforms_module::new_point Point::Point _transforms_module::new_bbox Bbox::Bbox _transforms_module::new_value _transforms_module::new_value _transforms_module::new_point Point::Point _transforms_module::new_value _transforms_module::new_value _transforms_module::new_point Point::Point _transforms_module::new_bbox Bbox::Bbox _transforms_module::new_value _transforms_module::new_value _transforms_module::new_point Point::Point _transforms_module::new_value _transforms_module::new_value _transforms_module::new_point Point::Point _transforms_module::new_bbox Bbox::Bbox _transforms_module::new_func _transforms_module::new_func _transforms_module::new_separable_transformation BBoxTransformation::BBoxTransformation SeparableTransformation::SeparableTransformation Glyph::init_type FT2Font::init_type init_nc_image Image::init_type __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail |
From: Robert K. <rk...@uc...> - 2004-10-28 03:35:02
|
[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 |
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 |