matplotlib-devel Mailing List for matplotlib (Page 3)

Hi,
currently, PS backend does not work well with some fonts. For
instance, it displays a dotted square instead of whitespace with
Arial, and some strange dots instead of whitespace with Times New
Roman. This patch fixes it by omitting glyphs named ".notdef" from PS
output.

"Nicolas Grilly" <nic...@ga...> writes:
> Here is a patch I promised some time ago, to improve the PDF backend.
Thanks; on first look this seems really nice! So far I have one
request to you and one to John:
Nicolas: would it be easy for you to strip the ^M (carriage-return)
characters from your files and then re-run diff? I see in your patch
several parts where the only change seems to be an addition of ^M at
the end of each line, but there could be significant changes hidden
within these parts. (Perhaps just give the -b option to diff? Though
that might backfire if some other whitespace changes are significant,
e.g. if you have changed the indentation of some code blocks.)
John: Is Adobe's licensing of the AFM files compatible with
matplotlib's license? I think it is, but I'm no license expert. The
readme file distributed with the files contains the following text:
 Font Metrics for the 14 PDF Core Fonts
 ======================================
 This directory contains font metrics for the 14 PDF Core Fonts (files with .afm 
 extension), downloaded from http://partners.adobe.com/public/developer/font/index.html.
 This file and the 14 PostScript(R) AFM files it accompanies may be used, copied, 
 and distributed for any purpose and without charge, with or without modification, 
 provided that all copyright notices are retained; that the AFM files are not 
 distributed without this file; that all modifications to this file or any of 
 the AFM files are prominently noted in the modified file(s); and that this 
 paragraph is not modified. Adobe Systems has no responsibility or obligation 
 to support the use of the AFM files.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 2/13/07, Nicolas Grilly <nic...@ga...> wrote:
> Here is a patch I promised some time ago, to improve the PDF backend.
Jouni,
I'm going to leave this up to you, but Nicolas this looks very nice. Thanks!
JDH

Here is a patch I promised some time ago, to improve the PDF backend.
I use it to produce charts and integrate them in documents generated
by pdfTeX and ConTeXt. It's very handy because pdfTeX natively handles
PDF graphics, without any conversion.
The patched backend is able to use the 14 PDF core fonts. These fonts
are embedded in every PDF viewing applications. So you can produce
charts contained in very small PDF files, easy to integrate in LaTeX
or ConTeXt through pdfTeX.
My patch is the attached file mpl_pdf_backend_patch.patch.
You also need to untar the attached file pdfcorefonts.tar in
lib/matplotlib/mpl-data/fonts in order to create a directory
pdfcorefonts holdings AFM files for the 14 PDF core fonts.
Does this patch work for you? Do you agree to commit it in SVN?
Thanks,
Nicolas Grilly
A summary of changes:
- Created a directory lib/matplotlib/mpl-data/fonts/pdfcorefonts,
 holding AFM files for the 14 PDF core fonts. These fonts are
 embedded in every PDF viewing applications.
- setup.py: Added the directory pdfcorefonts to package_data.
- lib/matplotlib/__init__.py: Added the default parameter
 'pdf.use14corefonts'. When True, the PDF backend use only
 the 14 PDF core fonts.
- lib/matplotlib/afm.py: Added some keywords found in recent
 AFM files. Added a little workaround to handle Euro symbol.
- lib/matplotlib/fontmanager.py: Added support for 14 PDF
 core fonts. These fonts have a dedicated cache (file
 pdfcorefont.cache), not the same as for other AFM files
 (file .afmfont.cache). Also cleaned comments to conform to
 CODING_GUIDE.
- lib/matplotlib/backends/backend_pdf.py:
 Added support for 14 PDF core fonts.
 Fixed some issues with incorrect character widths and
 encodings (works only for the most common encoding,
 WinAnsiEncoding, defined by the official PDF Reference).
 Removed parameter 'dpi' because it causes alignment issues
 (the notion of DPI seems useless in a vectorial format, unless
 we use it for image magnification, like in backend_ps.py).

I suppose the year of the last entries of CHANGELOG is 2007, not 2006.
Regards,
Nicolas Grilly

On 2/13/07, John Hunter <jd...@gm...> wrote:
> On 2/12/07, Andrew Straw <str...@as...> wrote:
> > Great, thanks for checking that in.
> >
> > It looks like images/*.png didn't make it in.
>
> OK, I committed these. I'm not sure why they didn't go in the first
> time since they were in my mpl-data/images dir when I added it. Give
> it a test drive.
I've checked out this (with the PNG files !) and it works perfectly. Thanks!
Nicolas

On 2/12/07, Andrew Straw <str...@as...> wrote:
> Great, thanks for checking that in.
>
> It looks like images/*.png didn't make it in.
OK, I committed these. I'm not sure why they didn't go in the first
time since they were in my mpl-data/images dir when I added it. Give
it a test drive.

John Hunter wrote:
 > Thanks for the suggestion -- I did this automagically with
> 
> # add british equivs
> for k, v in cnames.items():
> if k.find('gray')>=0:
> k = k.replace('gray', 'grey')
> cnames[k] = v
Just noticed that 'lightgrey' is still in the cnames dict, which means 
that 'lightgray' is an invalid name. Here's the patch.
Cheers,
Martin

> # add british equivs
> for k, v in cnames.items():
> if k.find('gray')>=0:
> k = k.replace('gray', 'grey')
> cnames[k] = v
Neat, that's a much better idea.
> Note that in pylab, you can get some extra information by doing
> 
>>>> help(colors)
Thanks. I really like all the new auto-generated kwarg properties that 
are showing up in the docstrings now. I just noticed them today as I 
upgraded to 0.90.
Martin

Andrew Straw wrote:
> Great, thanks for checking that in.
>
> It looks like images/*.png didn't make it in.
> 
And, grr, I can't put them in, either:
$ svn commit -m "added .png files that didn't make it into new mpl-data 
location" images
Adding (bin) images/back.png
svn: Commit failed (details follow):
svn: COPY of back.png: 403 Forbidden (https://svn.sourceforge.net)
> John Hunter wrote:
> 
>> On 2/12/07, Andrew Straw <str...@as...> wrote:
>>
>> 
>> 
>>> So, I sent the patch file to John, who'll hopefully commit it if he
>>> approves. To paraphrase Robert Kern, "Working code ends all arguments".
>>> So, since this was the nested way, and the biggest reason against it was
>>> that it require code change, well, I changed the code, and perhaps the
>>> arguments are ended?
>>>
>>> Because I did change a fair amount of data_path -using code, it'd be
>>> good to exercise all your favorite font and image finding sections of
>>> code. The bits I tried worked for me, of course, but no guarantees...
>>> 
>>> 
>> OK, with a sledgehammer and a prayer, I got it in. I got the same
>> error you did, and then had to physically remove mpl-data and it's
>> contents from svn and commit, restore everything in the new order and
>> commit again. It compiled, installed and ran, passing the tests I
>> threw at it.
>>
>> I only ran about half of backend driver before I grew impatient, so
>> others may want to do some additional testing. I copied your note
>> from CHANGELOG to API_CHANGES.
>>
>> I suggest flushing your old mpl-data in site-packages/matplotlib as
>> well as your ~/.matplotlib/ttffont.cache file before testing.
>>
>> Thanks for settling the argument!
>>
>> JDH
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier.
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Great, thanks for checking that in.
It looks like images/*.png didn't make it in.
John Hunter wrote:
> On 2/12/07, Andrew Straw <str...@as...> wrote:
>
> 
>> So, I sent the patch file to John, who'll hopefully commit it if he
>> approves. To paraphrase Robert Kern, "Working code ends all arguments".
>> So, since this was the nested way, and the biggest reason against it was
>> that it require code change, well, I changed the code, and perhaps the
>> arguments are ended?
>>
>> Because I did change a fair amount of data_path -using code, it'd be
>> good to exercise all your favorite font and image finding sections of
>> code. The bits I tried worked for me, of course, but no guarantees...
>> 
>
> OK, with a sledgehammer and a prayer, I got it in. I got the same
> error you did, and then had to physically remove mpl-data and it's
> contents from svn and commit, restore everything in the new order and
> commit again. It compiled, installed and ran, passing the tests I
> threw at it.
>
> I only ran about half of backend driver before I grew impatient, so
> others may want to do some additional testing. I copied your note
> from CHANGELOG to API_CHANGES.
>
> I suggest flushing your old mpl-data in site-packages/matplotlib as
> well as your ~/.matplotlib/ttffont.cache file before testing.
>
> Thanks for settling the argument!
>
> JDH
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On 2/12/07, Martin Spacek <sc...@ms...> wrote:
> Looking through colors.py, I noticed that most of the grey cnames use
> the spelling 'gray' (the US standard I think), although 'lightgrey'
> shows up as a valid name, while 'lightgray' does not. After looking
> around the web a bit for what the correct html names are, I found most
> sites display 'gray' and 'grey' as synonymous, for all the different
> intensities (darkslate, light, dim, etc).
>
> So, here's a patch that does the same, allowing ColorConverter to accept
> both spellings for all the intensities.
>
Thanks for the suggestion -- I did this automagically with
# add british equivs
for k, v in cnames.items():
 if k.find('gray')>=0:
 k = k.replace('gray', 'grey')
 cnames[k] = v
Note that in pylab, you can get some extra information by doing
>>> help(colors)
colors()
 This is a do nothing function to provide you with help on how
 matplotlib handles colors.
 Commands which take color arguments can use several formats to
 specify the colors. For the basic builtin colors, you can use a
 single letter
 b : blue
 g : green
 r : red
 c : cyan
 m : magenta
 y : yellow
 k : black
 w : white
 For a greater range of colors, you have two options. You can
 specify the color using an html hex string, as in
 color = '#eeefff'
 or you can pass an R,G,B tuple, where each of R,G,B are in the
 range [0,1].
 You can also use any legal html name for a color, like 'red',
 'burlywood' and 'chartreuse'
 The example below creates a subplot with a dark
 slate gray background
 subplot(111, axisbg=(0.1843, 0.3098, 0.3098))
 Here is an example that creates a pale turqoise title
 title('Is this the best color?', color='#afeeee')

On 2/12/07, Andrew Straw <str...@as...> wrote:
> So, I sent the patch file to John, who'll hopefully commit it if he
> approves. To paraphrase Robert Kern, "Working code ends all arguments".
> So, since this was the nested way, and the biggest reason against it was
> that it require code change, well, I changed the code, and perhaps the
> arguments are ended?
>
> Because I did change a fair amount of data_path -using code, it'd be
> good to exercise all your favorite font and image finding sections of
> code. The bits I tried worked for me, of course, but no guarantees...
OK, with a sledgehammer and a prayer, I got it in. I got the same
error you did, and then had to physically remove mpl-data and it's
contents from svn and commit, restore everything in the new order and
commit again. It compiled, installed and ran, passing the tests I
threw at it.
I only ran about half of backend driver before I grew impatient, so
others may want to do some additional testing. I copied your note
from CHANGELOG to API_CHANGES.
I suggest flushing your old mpl-data in site-packages/matplotlib as
well as your ~/.matplotlib/ttffont.cache file before testing.
Thanks for settling the argument!
JDH

Looking through colors.py, I noticed that most of the grey cnames use 
the spelling 'gray' (the US standard I think), although 'lightgrey' 
shows up as a valid name, while 'lightgray' does not. After looking 
around the web a bit for what the correct html names are, I found most 
sites display 'gray' and 'grey' as synonymous, for all the different 
intensities (darkslate, light, dim, etc).
So, here's a patch that does the same, allowing ColorConverter to accept 
both spellings for all the intensities.
Also, just thought I'd point out that, only after using MPL for many 
months have I finally noticed that commands like plot() accept 'color' 
as a kwarg, which allows far more than just the basic 8 or so single 
character color names. What a great feature! I only discovered it 
because I had grown annoyed by the lack of an easy way to make stuff 
grey. Perhaps the color kwarg and the fact that it takes html names, hex 
values, and rgb tuples should be mentioned more explicitly in the 
docstrings for some of the more common plotting commands?
Cheers,
Martin

Thanks for tackling this.
On 2/12/07, Andrew Straw <str...@as...> wrote:
> Charlie Moad wrote:
> >> Although my understanding of setup* is minimal, I agree; I think that
> >> keeping some organization in the data will be helpful. It looks like
> >> get_data_path() is not called in many places, so if that is essentially
> >> what has to be fixed, it should not be very difficult. It might be
> >> facilitated by making _get_data_path() accept *args, a set of
> >> subdirectories to be appended.
> >>
> >
> > I think the way to go is what Andrew typed:
> >
> > os.path.join( mpl.get_data_dir(), 'gui', 'blah.glade' )
> >
> OK, I just implemented this nested idea and it appears to work.
>
> I tried to commit it to SVN, but SF's servers were giving me some talk
> about permissions... Sigh.
>
> So, I sent the patch file to John, who'll hopefully commit it if he
> approves. To paraphrase Robert Kern, "Working code ends all arguments".
> So, since this was the nested way, and the biggest reason against it was
> that it require code change, well, I changed the code, and perhaps the
> arguments are ended?
>
> Because I did change a fair amount of data_path -using code, it'd be
> good to exercise all your favorite font and image finding sections of
> code. The bits I tried worked for me, of course, but no guarantees...
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Charlie Moad wrote:
>> Although my understanding of setup* is minimal, I agree; I think that
>> keeping some organization in the data will be helpful. It looks like
>> get_data_path() is not called in many places, so if that is essentially
>> what has to be fixed, it should not be very difficult. It might be
>> facilitated by making _get_data_path() accept *args, a set of
>> subdirectories to be appended.
>> 
>
> I think the way to go is what Andrew typed:
>
> os.path.join( mpl.get_data_dir(), 'gui', 'blah.glade' )
> 
OK, I just implemented this nested idea and it appears to work.
I tried to commit it to SVN, but SF's servers were giving me some talk 
about permissions... Sigh.
So, I sent the patch file to John, who'll hopefully commit it if he 
approves. To paraphrase Robert Kern, "Working code ends all arguments". 
So, since this was the nested way, and the biggest reason against it was 
that it require code change, well, I changed the code, and perhaps the 
arguments are ended?
Because I did change a fair amount of data_path -using code, it'd be 
good to exercise all your favorite font and image finding sections of 
code. The bits I tried worked for me, of course, but no guarantees...

> Although my understanding of setup* is minimal, I agree; I think that
> keeping some organization in the data will be helpful. It looks like
> get_data_path() is not called in many places, so if that is essentially
> what has to be fixed, it should not be very difficult. It might be
> facilitated by making _get_data_path() accept *args, a set of
> subdirectories to be appended.
I think the way to go is what Andrew typed:
os.path.join( mpl.get_data_dir(), 'gui', 'blah.glade' )

Looking in detail at the contents of the mpl-directory, I notice that
A) the gui/ subdirectory off the main MPL source direcotry (the one with 
setup.py) does not exist in SVN
B) the file "lineprops.glade" referenced by 
backends/backend_gtk/DialogLineprops.py
does not exist in SVN
Is it safe to remove references to these things?
-Andrew

Charlie Moad wrote:
>> Well, another option is to maintain a sub-directory structure when
>> creating mpl-data in the source package. The downside is that this will
>> introduce code changes all over the code -- for example, code that
>> previously asked for "os.path.join( mpl.get_data_dir(), 'blah.glade' )"
>> would have to be converted to "os.path.join( mpl.get_data_dir(), 'gui',
>> 'blah.glade' )".
> 
> I think we should maintain a clean tree and make the code changes. I
> bet it would only take one person a diligent hour or two to fix all
> the occurrences as mentioned above. Maybe we could split up the work?
> I would be willing to update the "backends" folder.
Although my understanding of setup* is minimal, I agree; I think that 
keeping some organization in the data will be helpful. It looks like 
get_data_path() is not called in many places, so if that is essentially 
what has to be fixed, it should not be very difficult. It might be 
facilitated by making _get_data_path() accept *args, a set of 
subdirectories to be appended.
Eric

> Well, another option is to maintain a sub-directory structure when
> creating mpl-data in the source package. The downside is that this will
> introduce code changes all over the code -- for example, code that
> previously asked for "os.path.join( mpl.get_data_dir(), 'blah.glade' )"
> would have to be converted to "os.path.join( mpl.get_data_dir(), 'gui',
> 'blah.glade' )".
I think we should maintain a clean tree and make the code changes. I
bet it would only take one person a diligent hour or two to fix all
the occurrences as mentioned above. Maybe we could split up the work?
 I would be willing to update the "backends" folder.
- Charlie

On 2/12/07, John Hunter <jd...@gm...> wrote:
> OK, I see, so the problem was we had to flatten everything and mix all
> these datatypes together? eggs can't handle the existing directory
> structure in the mpl-data? It would clearly be better if it could,
> because dumping all the data files together isn't terribly elegant, so
> I think it would be useful for some egghead to verify this and see if
> there isn't a way to have the best of all worlds. I haven't used eggs
> so can't say anything intelligent, except that I'm happy to defer to
> those who know more about it and let's get it setup that that work
> properly with mpl-data for eggs and and regular old-fashioned mpl
> installs. If this means that we do have to flatten the data directory
> structure, so be it. That's why god gave us 'ls *.EXT '
I think this should work even with distutils alone, without setuptools.
In order to not flatten everything, one solution is to simply create
subfolders in mpl-data.
We could have those folders:
/lib/matplotlib/mpl-data/fonts/afm
/lib/matplotlib/mpl-data/fonts/ttf
/lib/matplotlib/mpl-data/images
-- Nicolas

John Hunter wrote:
> On 2/12/07, Charlie Moad <cw...@gm...> wrote:
>
>> You're changing positions on me now, John! ;)
>
> It's better that way -- that way I can be right both times :-) Or is
> it wrong both times? hmmm...
>
>> I asked about moving everything into the module, but you didn't want
>> to mix the fonts/images/etc, so I made the install merge the data into
>> a folder. I would love to be able to run "setup develop" as well.
>
> OK, I see, so the problem was we had to flatten everything and mix all
> these datatypes together? eggs can't handle the existing directory
> structure in the mpl-data? It would clearly be better if it could,
> because dumping all the data files together isn't terribly elegant, so
> I think it would be useful for some egghead to verify this and see if
> there isn't a way to have the best of all worlds. I haven't used eggs
> so can't say anything intelligent, except that I'm happy to defer to
> those who know more about it and let's get it setup that that work
> properly with mpl-data for eggs and and regular old-fashioned mpl
> installs. If this means that we do have to flatten the data directory
> structure, so be it. That's why god gave us 'ls *.EXT '
Well, another option is to maintain a sub-directory structure when 
creating mpl-data in the source package. The downside is that this will 
introduce code changes all over the code -- for example, code that 
previously asked for "os.path.join( mpl.get_data_dir(), 'blah.glade' )" 
would have to be converted to "os.path.join( mpl.get_data_dir(), 'gui', 
'blah.glade' )".
So, the low energy, low probability-of-breakage approach is indeed to 
pile everything into mpl-data and make judicious use of "ls *.ext". This 
is what we install in site-packages anyway, so it can't be that bad, 
right? :)
-Andrew

On 2/12/07, Andrew Straw <str...@as...> wrote:
> IMO, the way to fix it is to move all the data into
> lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> that setup.py does would be unnecessary and using setuptools' develop
> mode would work out-of-the-box. I'd be happy to move these files in the
> svn repository if people agree this is a good idea.
Me too, I'm +1 on that. This way, in development mode, we can run
matplotlib just by adding directory "lib" to the PYTHONPATH, even if
using standard distutils without setuptools.
NG

On 2/12/07, Charlie Moad <cw...@gm...> wrote:
> You're changing positions on me now, John! ;)
It's better that way -- that way I can be right both times :-) Or is
it wrong both times? hmmm...
> I asked about moving everything into the module, but you didn't want
> to mix the fonts/images/etc, so I made the install merge the data into
> a folder. I would love to be able to run "setup develop" as well.
OK, I see, so the problem was we had to flatten everything and mix all
these datatypes together? eggs can't handle the existing directory
structure in the mpl-data? It would clearly be better if it could,
because dumping all the data files together isn't terribly elegant, so
I think it would be useful for some egghead to verify this and see if
there isn't a way to have the best of all worlds. I haven't used eggs
so can't say anything intelligent, except that I'm happy to defer to
those who know more about it and let's get it setup that that work
properly with mpl-data for eggs and and regular old-fashioned mpl
installs. If this means that we do have to flatten the data directory
structure, so be it. That's why god gave us 'ls *.EXT '
JDH

On 2/12/07, John Hunter <jd...@gm...> wrote:
> On 2/12/07, Andrew Straw <str...@as...> wrote:
> > IMO, the way to fix it is to move all the data into
> > lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> > that setup.py does would be unnecessary and using setuptools' develop
> > mode would work out-of-the-box. I'd be happy to move these files in the
> > svn repository if people agree this is a good idea.
>
> I'm +1 on that. For some reason, I thought we had already decided to
> do that when we moved to support setuptool in the first place.
You're changing positions on me now, John! ;)
I asked about moving everything into the module, but you didn't want
to mix the fonts/images/etc, so I made the install merge the data into
a folder. I would love to be able to run "setup develop" as well.
- Charlie