Hello, Sorry if this question was answered before. I did a search in the mailing list archives but couldn't find any answer. Is there an easy way to use comma as a decimal separator in texts, especially in tick labels? I know that it is possible to user formatters to do that, but I was wondering if there is an automatic setting or something that could be applied to axes instances, as I have more than 200 scripts to generate plots and I don't want to edit every one of them. Maybe there is a TeX setting (I uset usetex=True)? I tried setting locales, but it didn't work. I also tried to process the texts in the tick labels, but that didn't work also. Maybe I am overseeing something, but any hint would help. Thanks in advance: --- José Alexandre Nalon na...@te...
There isn't a really good way to do this at present. Maybe someone can suggest a workaround that doesn't require modifying matplotlib. However, I was able to produce a patch that will respect the user's current locale here: https://github.com/matplotlib/matplotlib/pull/410 Cheers, Mike On 07/28/2011 06:46 PM, José Alexandre Nalon wrote: > Hello, > > Sorry if this question was answered before. I did a search in the > mailing list archives but couldn't find any answer. > > Is there an easy way to use comma as a decimal separator in texts, > especially in tick labels? I know that it is possible to user > formatters to do that, but I was wondering if there is an automatic > setting or something that could be applied to axes instances, as I > have more than 200 scripts to generate plots and I don't want to > edit every one of them. Maybe there is a TeX setting (I uset > usetex=True)? > > I tried setting locales, but it didn't work. I also tried to > process the texts in the tick labels, but that didn't work also. > Maybe I am overseeing something, but any hint would help. > > Thanks in advance: > > --- > José Alexandre Nalon > na...@te... > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win 100ドル to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hello, Thanks for your work! But, since I don't have much experience with dealing with the sources and compiling, I don't know exactly how to apply this patch. Is there a guide to applying patches to matplotlib or something like that? Any help will be appreciated. --- José Alexandre Nalon na...@te... Em 29/07/2011, às 12:08, Michael Droettboom escreveu: > There isn't a really good way to do this at present. Maybe someone can > suggest a workaround that doesn't require modifying matplotlib. > > However, I was able to produce a patch that will respect the user's > current locale here: > > https://github.com/matplotlib/matplotlib/pull/410 > > Cheers, > Mike > > On 07/28/2011 06:46 PM, José Alexandre Nalon wrote: >> Hello, >> >> Sorry if this question was answered before. I did a search in the >> mailing list archives but couldn't find any answer. >> >> Is there an easy way to use comma as a decimal separator in texts, >> especially in tick labels? I know that it is possible to user >> formatters to do that, but I was wondering if there is an automatic >> setting or something that could be applied to axes instances, as I >> have more than 200 scripts to generate plots and I don't want to >> edit every one of them. Maybe there is a TeX setting (I uset >> usetex=True)? >> >> I tried setting locales, but it didn't work. I also tried to >> process the texts in the tick labels, but that didn't work also. >> Maybe I am overseeing something, but any hint would help. >> >> Thanks in advance: >> >> --- >> José Alexandre Nalon >> na...@te... >> >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help often. >> Plus, you'll get a chance to win 100ドル to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win 100ドル to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
You need to be able to build matplotlib from source (which implies having a compiler etc., which may or may not be easy on your platform). The basic instructions for building from source are here: http://matplotlib.sourceforge.net/users/installing.html and the branch containing the locale fix is available for git checkout or download as a tarball here: https://github.com/mdboom/matplotlib/tree/locale_formatting Mike On 07/29/2011 01:14 PM, José Alexandre Nalon wrote: > Hello, > > Thanks for your work! But, since I don't have much experience > with dealing with the sources and compiling, I don't know > exactly how to apply this patch. Is there a guide to applying > patches to matplotlib or something like that? Any help will > be appreciated. > > --- > José Alexandre Nalon > na...@te... > > > Em 29/07/2011, às 12:08, Michael Droettboom escreveu: > >> There isn't a really good way to do this at present. Maybe someone can >> suggest a workaround that doesn't require modifying matplotlib. >> >> However, I was able to produce a patch that will respect the user's >> current locale here: >> >> https://github.com/matplotlib/matplotlib/pull/410 >> >> Cheers, >> Mike >> >> On 07/28/2011 06:46 PM, José Alexandre Nalon wrote: >>> Hello, >>> >>> Sorry if this question was answered before. I did a search in the >>> mailing list archives but couldn't find any answer. >>> >>> Is there an easy way to use comma as a decimal separator in texts, >>> especially in tick labels? I know that it is possible to user >>> formatters to do that, but I was wondering if there is an automatic >>> setting or something that could be applied to axes instances, as I >>> have more than 200 scripts to generate plots and I don't want to >>> edit every one of them. Maybe there is a TeX setting (I uset >>> usetex=True)? >>> >>> I tried setting locales, but it didn't work. I also tried to >>> process the texts in the tick labels, but that didn't work also. >>> Maybe I am overseeing something, but any hint would help. >>> >>> Thanks in advance: >>> >>> --- >>> José Alexandre Nalon >>> na...@te... >>> >>> ------------------------------------------------------------------------------ >>> Got Input? Slashdot Needs You. >>> Take our quick survey online. Come on, we don't ask for help often. >>> Plus, you'll get a chance to win 100ドル to spend on ThinkGeek. >>> http://p.sf.net/sfu/slashdot-survey >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help often. >> Plus, you'll get a chance to win 100ドル to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win 100ドル to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
I'm still puzzled here. The TeX file is definitely being generated with an unreasonably large size, which is what causes it to blow up. It gets the size from the size of the matplotlib figure, which I assume is being incorrectly calculated by the tight bounding box code. Of course, I can't reproduce that here, so I'm not sure what's going on. Do any of the developers who understand the tight bounding box code have any theories? Mike On 08/05/2011 09:57 AM, José Alexandre Nalon wrote: > Hello! > >> This is puzzling. I can't reproduce this -- I even get nice commas. >> Are you running the locale_formatting branch exactly as it is (i.e. not >> applying it as a patch to another version of matplotlib)? What platform >> are you on? Which backend? What does "echo $LANG" at the commandline say? > I actually am getting this error with a couple of scripts, > but both use bbox_inches='tight', and are 3D plots. I tried > 2D plots with this option and there was no problem. In every > script, I also get the commas. It is probably one of those > bugs that appear because of the configuration of the many > packages that are being used. > > I gathered some information, and I hope it helps. I am using > Kubuntu 10.10, and Texlive distribution. I downloaded the > .tar.gz package from github in your branch, and built it. > At the time of compilation, I didn't have Tk or GTK headers > (since I don't use matplotlib interactively, I don't really > need them). Below, I also included the list of met dependencies, > according to the installation script. I got no errors during > compilation, only a warning (also listed below). Tex file > and others are attached with this message (since my /tmp > directory was wiped in reboot, I had to run the script again, > hence the different names). This is all the information that I > could think of, but if there is anything else, just send a > message. Thanks again for your work! > > nalon@marvin:~/temp/test$ uname -a > Linux marvin 2.6.35-30-generic #56-Ubuntu SMP Mon Jul 11 20:00:22 UTC 2011 > i686 GNU/Linux > > nalon@marvin:~/temp/test$ echo $LANG > pt_BR.UTF-8 > > nalon@marvin:~/temp/test$ latex -v > pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) > kpathsea version 5.0.0 > Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). > There is NO warranty. Redistribution of this software is > covered by the terms of both the pdfTeX copyright and > the Lesser GNU General Public License. > For more information about these matters, see the file > named COPYING and the pdfTeX source. > Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). > Compiled with libpng 1.2.44; using libpng 1.2.44 > Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 > Compiled with poppler version 0.14.2 > > nalon@marvin:~/temp/test$ python > Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) > [GCC 4.4.5] on linux2 > >>>> numpy.__version__ > '1.3.0' >>>> matplotlib.__version__ > '1.1.0' >>>> print matplotlib.rcParams['backend'] > agg > > Here is a relation of met dependencies and their versions > (according to matplotlib installation script): > > Qt: 4.7.0 > PyQt: 4.8.1 > Freetype2: 12.0.6 > Cairo: 1.8.8 > libpng: 1.2.44 > dvipng: 1.13 > ghostscript: 8.71 > latex: 3.1415926 > pdftops: 0.14.3 > > No errors during installation, only these warnings: > > src/path.cpp: In member function ‘Py::Object > _path_module::convert_to_svg(const Py::Tuple&)’: > src/path.cpp:1590: warning: format not a string literal and no format > arguments > src/path.cpp:1590: warning: format not a string literal and no format > arguments > src/path.cpp:1593: warning: format not a string literal and no format > arguments > src/path.cpp:1593: warning: format not a string literal and no format > arguments > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y2’ may be used > uninitialized in this function > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x2’ may be used > uninitialized in this function > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y1’ may be used > uninitialized in this function > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x1’ may be used > uninitialized in this function > > --- > José Alexandre Nalon > na...@te...
Hello, Michael, since it is happening in my setup, if you are willing to direct me, I could try to debug and see what could possibly be happening. I don't discard, however, that this is something that happens only to me, so, unless someone can reproduce the problem, this could be marked as a low priority bug. --- José Alexandre Nalon na...@te... Em sex 05 ago 2011, às 12:49:27, Michael Droettboom escreveu: > I'm still puzzled here. The TeX file is definitely being generated with > an unreasonably large size, which is what causes it to blow up. It gets > the size from the size of the matplotlib figure, which I assume is being > incorrectly calculated by the tight bounding box code. Of course, I > can't reproduce that here, so I'm not sure what's going on. > > Do any of the developers who understand the tight bounding box code have > any theories? > > Mike > > On 08/05/2011 09:57 AM, José Alexandre Nalon wrote: > > Hello! > > > >> This is puzzling. I can't reproduce this -- I even get nice commas. > >> Are you running the locale_formatting branch exactly as it is (i.e. not > >> applying it as a patch to another version of matplotlib)? What platform > >> are you on? Which backend? What does "echo $LANG" at the commandline > >> say? > > > > I actually am getting this error with a couple of scripts, > > but both use bbox_inches='tight', and are 3D plots. I tried > > 2D plots with this option and there was no problem. In every > > script, I also get the commas. It is probably one of those > > bugs that appear because of the configuration of the many > > packages that are being used. > > > > I gathered some information, and I hope it helps. I am using > > Kubuntu 10.10, and Texlive distribution. I downloaded the > > .tar.gz package from github in your branch, and built it. > > At the time of compilation, I didn't have Tk or GTK headers > > (since I don't use matplotlib interactively, I don't really > > need them). Below, I also included the list of met dependencies, > > according to the installation script. I got no errors during > > compilation, only a warning (also listed below). Tex file > > and others are attached with this message (since my /tmp > > directory was wiped in reboot, I had to run the script again, > > hence the different names). This is all the information that I > > could think of, but if there is anything else, just send a > > message. Thanks again for your work! > > > > nalon@marvin:~/temp/test$ uname -a > > Linux marvin 2.6.35-30-generic #56-Ubuntu SMP Mon Jul 11 20:00:22 UTC > > 2011 i686 GNU/Linux > > > > nalon@marvin:~/temp/test$ echo $LANG > > pt_BR.UTF-8 > > > > nalon@marvin:~/temp/test$ latex -v > > pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) > > kpathsea version 5.0.0 > > Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). > > There is NO warranty. Redistribution of this software is > > covered by the terms of both the pdfTeX copyright and > > the Lesser GNU General Public License. > > For more information about these matters, see the file > > named COPYING and the pdfTeX source. > > Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh > > (pdfTeX). Compiled with libpng 1.2.44; using libpng 1.2.44 > > Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 > > Compiled with poppler version 0.14.2 > > > > nalon@marvin:~/temp/test$ python > > Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) > > [GCC 4.4.5] on linux2 > > > >>>> numpy.__version__ > > > > '1.3.0' > > > >>>> matplotlib.__version__ > > > > '1.1.0' > > > >>>> print matplotlib.rcParams['backend'] > > > > agg > > > > Here is a relation of met dependencies and their versions > > (according to matplotlib installation script): > > > > Qt: 4.7.0 > > PyQt: 4.8.1 > > Freetype2: 12.0.6 > > Cairo: 1.8.8 > > libpng: 1.2.44 > > dvipng: 1.13 > > ghostscript: 8.71 > > latex: 3.1415926 > > pdftops: 0.14.3 > > > > No errors during installation, only these warnings: > > > > src/path.cpp: In member function ‘Py::Object > > _path_module::convert_to_svg(const Py::Tuple&)’: > > src/path.cpp:1590: warning: format not a string literal and no format > > arguments > > src/path.cpp:1590: warning: format not a string literal and no format > > arguments > > src/path.cpp:1593: warning: format not a string literal and no format > > arguments > > src/path.cpp:1593: warning: format not a string literal and no format > > arguments > > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y2’ may be > > used uninitialized in this function > > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x2’ may be > > used uninitialized in this function > > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y1’ may be > > used uninitialized in this function > > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x1’ may be > > used uninitialized in this function > > > > --- > > José Alexandre Nalon > > na...@te... > > --------------------------------------------------------------------------- > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
I just installed the fr_FR locale and tested your patch, and I don't see any problem. I suspect that this is the problem of Axes3D (that has recently fixed by Ben), and has nothing with your patch. If I revert Ben's commit, than an error is raised regardless of the value of rcParams["axes.formatter.use_locale"]. Regards, -JJ On Sat, Aug 6, 2011 at 12:49 AM, Michael Droettboom <md...@st...> wrote: > I'm still puzzled here. The TeX file is definitely being generated with > an unreasonably large size, which is what causes it to blow up. It gets > the size from the size of the matplotlib figure, which I assume is being > incorrectly calculated by the tight bounding box code. Of course, I > can't reproduce that here, so I'm not sure what's going on. > > Do any of the developers who understand the tight bounding box code have > any theories? > > Mike > > On 08/05/2011 09:57 AM, José Alexandre Nalon wrote: >> Hello! >> >>> This is puzzling. I can't reproduce this -- I even get nice commas. >>> Are you running the locale_formatting branch exactly as it is (i.e. not >>> applying it as a patch to another version of matplotlib)? What platform >>> are you on? Which backend? What does "echo $LANG" at the commandline say? >> I actually am getting this error with a couple of scripts, >> but both use bbox_inches='tight', and are 3D plots. I tried >> 2D plots with this option and there was no problem. In every >> script, I also get the commas. It is probably one of those >> bugs that appear because of the configuration of the many >> packages that are being used. >> >> I gathered some information, and I hope it helps. I am using >> Kubuntu 10.10, and Texlive distribution. I downloaded the >> .tar.gz package from github in your branch, and built it. >> At the time of compilation, I didn't have Tk or GTK headers >> (since I don't use matplotlib interactively, I don't really >> need them). Below, I also included the list of met dependencies, >> according to the installation script. I got no errors during >> compilation, only a warning (also listed below). Tex file >> and others are attached with this message (since my /tmp >> directory was wiped in reboot, I had to run the script again, >> hence the different names). This is all the information that I >> could think of, but if there is anything else, just send a >> message. Thanks again for your work! >> >> nalon@marvin:~/temp/test$ uname -a >> Linux marvin 2.6.35-30-generic #56-Ubuntu SMP Mon Jul 11 20:00:22 UTC 2011 >> i686 GNU/Linux >> >> nalon@marvin:~/temp/test$ echo $LANG >> pt_BR.UTF-8 >> >> nalon@marvin:~/temp/test$ latex -v >> pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) >> kpathsea version 5.0.0 >> Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). >> There is NO warranty. Redistribution of this software is >> covered by the terms of both the pdfTeX copyright and >> the Lesser GNU General Public License. >> For more information about these matters, see the file >> named COPYING and the pdfTeX source. >> Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). >> Compiled with libpng 1.2.44; using libpng 1.2.44 >> Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 >> Compiled with poppler version 0.14.2 >> >> nalon@marvin:~/temp/test$ python >> Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) >> [GCC 4.4.5] on linux2 >> >>>>> numpy.__version__ >> '1.3.0' >>>>> matplotlib.__version__ >> '1.1.0' >>>>> print matplotlib.rcParams['backend'] >> agg >> >> Here is a relation of met dependencies and their versions >> (according to matplotlib installation script): >> >> Qt: 4.7.0 >> PyQt: 4.8.1 >> Freetype2: 12.0.6 >> Cairo: 1.8.8 >> libpng: 1.2.44 >> dvipng: 1.13 >> ghostscript: 8.71 >> latex: 3.1415926 >> pdftops: 0.14.3 >> >> No errors during installation, only these warnings: >> >> src/path.cpp: In member function ‘Py::Object >> _path_module::convert_to_svg(const Py::Tuple&)’: >> src/path.cpp:1590: warning: format not a string literal and no format >> arguments >> src/path.cpp:1590: warning: format not a string literal and no format >> arguments >> src/path.cpp:1593: warning: format not a string literal and no format >> arguments >> src/path.cpp:1593: warning: format not a string literal and no format >> arguments >> src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y2’ may be used >> uninitialized in this function >> src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x2’ may be used >> uninitialized in this function >> src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y1’ may be used >> uninitialized in this function >> src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x1’ may be used >> uninitialized in this function >> >> --- >> José Alexandre Nalon >> na...@te... > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >