On Thu, Aug 28, 2008 at 4:18 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>
>> First of all, I borrowed this idea from the PyX which is in GPL.
>> Although there is little of copying, other than the basic idea, I'm
>> not 100%
On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> First of all, I borrowed this idea from the PyX which is in GPL.
> Although there is little of copying, other than the basic idea, I'm
> not 100% sure if this could be BSD-compatible.
I think it is fine to borrow the idea;
Hello,
AFAIK, current backends (I only tested agg, pdf, and ps) do not
properly respect the text baseline when text is rendered using TeX.
The get_text_width_height_descent() method in Agg and PS backends
simply return 0 for the descent value. While PDF backend uses the
dviread module to figure ou
Michael Droettboom wrote:
> I think we want to use std::vector where possible for new code, and
> convert as we go through old code. Manual malloc/free is just too error
> prone. (We're forced to do some by interfacing with Python, but it
> should be kept to a minimum).
My understanding is th
On RHEL4, I get the following message:
This OpenGL does not support framebuffer objects
I understand that I'm probably just suffering from a relatively old
Mesa/OpenGL stack here. And obviously, just because some older systems
won't support this is not a reason to not include it as an optio
Thanks!
It works as I expected.
-JJ
On Thu, Aug 28, 2008 at 8:43 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> This should now be fixed in SVN r6052.
>
> Cheers,
> Mike
>
> Jae-Joon Lee wrote:
>>
>> Hi,
>>
>> The clip_on and clip_box arguments (and maybe clip_path also) in
>> plot() comman
I'm going to again defer the real question of the functionality and
interface etc. to Eric and/or John etc., though it seems good in general.
I just have a couple of follow on comments related to implementation
details below.
Grégory Lielens wrote:
> std::vector would have been nice, but I trie
Sorry about that, and thanks for your investigation. It's easy enough
to change the default.
I think (and it was a while ago, so I may be misremembering) I probably
made that change myself in error. (There used to be two completely
separate code paths for doing step plots, that I merged into
On Thu, Aug 28, 2008 at 08:17:26AM -0500, John Hunter wrote:
> On Thu, Aug 28, 2008 at 6:19 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote:
> > Enthought suite is used a lot in scientific area, so mpl and enth
> > almost share their users, so have it enabled would be a plus, but we
> > are mainly inter
Hi John, Hi Eric,
In case this has slipped under the radar, I repost my patch for bilinear interp
in NonUniformImage (including the discussion around it). I think Eric is the
most concerned by this, but you were both
on holidays when I raised the issue in matplotlib newsgroup.
Best regards,
G
Hi,
I just committed a patch that allows for multiple histogram where each
data-set might have a different length (see example
histogram_demo_extended.py). I don't think that it breaks any existing
code, but I would feel much better if someone could check that ...
Manuel
--
Now I see there are more options in 0.98 - 'steps-pre', 'steps-post',
'steps-mid'. The default should be steps-post for backwards
compatibility. In 0.98.3 the default is steps-pre. And sorry for the
testy tone of the previous email :)
Neil
2008/8/28 Neil Crighton <[EMAIL PROTECTED]>:
> linestyl
linestyle='steps' has changed behaviour between 0.91.2 and 0.98.3. The
'step' between two points used to move horizontally and then
vertically from the left point neighbouring right point, now it moves
vertically then horizontally.
Was this change intentional? I hope not, because I've just spent t
On Thu, Aug 28, 2008 at 6:19 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote:
> Enthought suite is used a lot in scientific area, so mpl and enth
> almost share their users, so have it enabled would be a plus, but we
> are mainly interested in generate "no harm", so we'd like to ask you
> to confirm tha
This should now be fixed in SVN r6052.
Cheers,
Mike
Jae-Joon Lee wrote:
> Hi,
>
> The clip_on and clip_box arguments (and maybe clip_path also) in
> plot() command seem to have no effect. For example,
>
> In [29]: p, =plot([1,2,3], clip_on=False)
>
> In [30]: p.get_clip_on()
> Out[30]: True
>
I think this is a bug created by the conversion from 0.91 to 0.98. I'll
look into this and let you know when it has been resolved.
Mike
Jae-Joon Lee wrote:
> Hi,
>
> The clip_on and clip_box arguments (and maybe clip_path also) in
> plot() command seem to have no effect. For example,
>
> In [2
Hello guys,
in a joint effort between Debian and Ubuntu on matplotlib packaging,
we were wondering if include the experimental support for
python-enthought-traits.
...
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
configobj: 4.5.2
enthought.traits: 2.0.5
...
Enthought suite is used a
17 matches
Mail list logo
