matplotlib-devel Mailing List for matplotlib

On 03/06/2011 02:08 AM, Jouni K. Seppänen wrote:
> Eric Firing<ef...@ha...> writes:
>
>> Newer versions of the libraries can also be used, although this is not
>> critical. v1.0.x still needs the 1.2 series of libpng, but master can
>> now handle
>>
>> ZLIBVERSION=1.2.5
>> PNGVERSION=1.5.1
>> FREETYPEVERSION=2.4.4
>
> With the old versions (including freetype 2.3.11) the test suite passes
> for me (163 tests, 50 knownfail because I don't have a working inkscape
> on my Mac), but with the new versions I get 18 failures. All seem to be
> caused by text being rendered in different locations, or with different
> fonts. I'm attaching two examples of this: in the font_styles test, two
> of the styles do not work, and in image_clip the text inside the circle
> is in completely different coordinates.
>
>
>
>
>
> Is this a known problem? Again, with the old libraries all tests pass
> for me, except for the svg images for which I don't have comparison
> tools, so I believe this to be caused by the dependencies, most likely
> freetype.
I have to admit I did not do these tests; I was experimenting with a 
borrowed machine, and I ran out of time.
However, I have run nosetests on a build of master on Ubuntu 10.10, with 
freetype 2.4.2, and I see the same failure that you showed on the 
font_styles test. Same test on a build of v1.0.x, same failure. Fails 
for png and svg; passes for pdf, but the images being compared are ugly 
low-res bitmapped things.
The major change between the freetype 2.3 series and 2.4 seems to be "In 
addition to many bugfixes, the TrueType bytecode interpreter is now 
enabled by default. All users should upgrade."
Eric

On Sun, Mar 6, 2011 at 4:46 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Fernando Garcia Bermudez <fg...@ee...> writes:
>
>> Do you know if these changes will trickle to the py3 repo after
>> merging into master?
>
> I don't know if we have a process in place for that. It depends on how
> you view the py3 repo: if it's just another feature branch, it shouldn't
> do any merges from master just for the sake of it, but if it's kind of
> like "next" or "pu" (proposed updates) in some workflows, it makes sense
> for it to be occasionally brought up to date (possibly even by
> rebasing).
I guess the py3 master will not be merged back into the matplotlib
repo until the last maintenance branch supporting python-2.5 and older
has been created (perhaps 1.1.x or 1.2.x). Since it is a long-running
line of development, I think it makes sense to occasionally bring it
up to date with the master branch. I've already done this once or
twice. I don't think we want to deal with rebasing. I rebased the py3
master branch once right after you merged the maintenance branches
with --strategy=ours, since that provided a much improved point of
reference, but it was a headache to coordinate with even one other dev
to deal with any unmerged branches out there effected by the rebase.
Maybe once the osx make binaries issue is resolved and the make.osx
branch is merged into master, someone with a working windows build
environment could test building binaries with python-2.6 and 2.7. If
it looks ok, that might be a good point to merge matplotlib/master
into py3/master.
Darren

Hi,
According to the legend doc,
 If label is set to '_nolegend_', the item will not be shown in
 legend.
But I think the documented behavior a bit ambiguous. For example,
consider the example below.
 l1, = plot([1,2,3], label="_nolegend_")
 l2, = plot([2,3,1])
 legend(["my line"])
I suppose the legend should show *l2* with "my line" label. But the
current master branch shows "l1" with "my line" label.
In other words, in the current implementation, when the legend command
is called with a single nonkeyword argument (which is interpreted as a
list of labels), the given labels are applied to all the artists
regardless whether the artist has a label of "_nolegend_" or not.
While there could be some cases that have relied on this behavior, I'm
inclined to fix this so that artists w/ "_nolegend_" are ignored.
However, fixing this requires "hist" command to be modified (there
could be more commands that need modification).
Unless there is no objection from other developers, I'll go ahead and
commit the patch to fix this.
Regards,
-JJ

Fernando Garcia Bermudez <fg...@ee...> writes:
> Do you know if these changes will trickle to the py3 repo after
> merging into master?
I don't know if we have a process in place for that. It depends on how
you view the py3 repo: if it's just another feature branch, it shouldn't
do any merges from master just for the sake of it, but if it's kind of
like "next" or "pu" (proposed updates) in some workflows, it makes sense
for it to be occasionally brought up to date (possibly even by
rebasing).
But it's fine for even feature branches to merge from master, e.g. if
there is a feature in master that the branch is going to depend on.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Sat, Mar 5, 2011 at 23:52, Jouni K. Seppänen <jk...@ik...> wrote:
> Thanks; pull request #17 is IMHO ready for merging into v1.0.x, but
> let's wait to see if anyone has further comments. I created pull request
> #30 for merging into master; that one also has newer dependency versions
> as suggested by Eric.
>
Do you know if these changes will trickle to the py3 repo after merging into
master? I initially came up with the patch while compiling the old py3k
branch and when I realized it also applied to matplotlib Darren suggested I
submit the pull request there. I'm asking this because there's another tiny
change that pertains to the py3 version of the patch and I wonder whether I
should wait or start the pull process now.
-- Fernando

Fernando Garcia Bermudez
<fg...@ee...> writes:
> I tested your changes (up to mpl_install_std) and merged the pull request.
> Upon solving the binaries issue we could probably close this pull request.
> Or we could open an issue for that particular matter.
Thanks; pull request #17 is IMHO ready for merging into v1.0.x, but
let's wait to see if anyone has further comments. I created pull request
#30 for merging into master; that one also has newer dependency versions
as suggested by Eric.
On master, I was able to almost run "make binaries", except somehow
bdist_mpkg didn't agree with the makefile about all the version numbers
in the mpkg filename, so hdiutil failed due to a missing input file. I
do think that problem is unrelated to these changes.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Eric Firing <ef...@ha...> writes:
> While in the middle of overhauling make.osx, I think it makes sense to 
> go ahead and fix the ARCH_FLAGS variable, and then use it throughout in 
> place of the hardwired ARCH_FLAGS. That will make it easier to use the 
> makefile on a range of OS X and Xcode versions. It is also simply a 
> cleaner design.
I think I fixed this - my commit is now part of
https://github.com/matplotlib/matplotlib/pull/17
> Newer versions of the libraries can also be used, although this is not 
> critical. v1.0.x still needs the 1.2 series of libpng, but master can 
> now handle
>
> ZLIBVERSION=1.2.5
> PNGVERSION=1.5.1
> FREETYPEVERSION=2.4.4
I think we should keep the changes to v1.0.x minimal - in master it
makes sense to upgrade to the newest versions. I'll make a separate pull
request for master.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
Definitely a minor issue but I see the csd demo image a bit clipped from the
left and the top subplot mixed with the bottom one on
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.csd
Looks fine when I locally run the csd_demo.py example.
-- 
Gökhan