The patches are now committed to the trunk (r7089, 7090, 7091).
Regards,
-JJ
On Tue, May 5, 2009 at 5:16 PM, Eric Bruning wrote:
> Thanks for your work on this patch JJ, glad to see it ready to go!
>
--
The NEW KODAK
Thanks for your work on this patch JJ, glad to see it ready to go!
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Koda
On Tue, May 5, 2009 at 2:54 PM, John Hunter wrote:
> On Tue, May 5, 2009 at 2:52 PM, John Hunter wrote:
>> On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee wrote:
>>> I'm attaching the revised patch (I may split the patch for commit).
>>
>> Still encountering troubles
>
> Oops, ignore me. Look
On Tue, May 5, 2009 at 2:52 PM, John Hunter wrote:
> On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee wrote:
>> I'm attaching the revised patch (I may split the patch for commit).
>
> Still encountering troubles
Oops, ignore me. Looks like I just reapplied the *old* patch that was
laying aroun
On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee wrote:
> I'm attaching the revised patch (I may split the patch for commit).
Still encountering troubles
jo...@flag:misc> python rasterization_demo.py
Traceback (most recent call last):
File "rasterization_demo.py", line 41, in ?
ax4.set_ra
I'm attaching the revised patch (I may split the patch for commit).
Regards,
-JJ
On Tue, May 5, 2009 at 3:22 PM, Eric Bruning wrote:
> To avoid confusion, how about renaming draw_wrapper._rasterized to
> draw_wrapper._supports_rasterization ?
>
> This helps to distinguish from artist._rasteri
To avoid confusion, how about renaming draw_wrapper._rasterized to
draw_wrapper._supports_rasterization ?
This helps to distinguish from artist._rasterized, which has a
different purpose.
The lack of consistency in decoration language for different artists
is my fault. It reflects the different w
Thanks John,
Sorry for the buggy patch. The error occurs when usetex=False and
ps.useafm=False, which was not my setup.
Here is a patch to fix it.
--- lib/matplotlib/backends/backend_ps.py.orig 2009-05-05
14:44:31.0 -0400
+++ lib/matplotlib/backends/backend_ps.py 2009-05-05
14:44:3
On Tue, May 5, 2009 at 1:08 PM, Jae-Joon Lee wrote:
> Any comment or suggestion will be welcomed.
> I'm planning to commit this change to the svn soon, unless others come
> up with some issues.
I am getting the following error when I test on svn HEAD
jo...@flag:misc> python rasterization_demo.p
I'm attaching a slightly modified version of the patch, originally by
Eric Bruning.
I changed the name to "allow_rasterization", and added some code to
check if the draw method is decorated when set_rasterized is called
(I'll be glad to hear any better idea for this).
The second patch is to let yo
On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing wrote:
> Jae-Joon Lee wrote:
>>
>> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning
>> wrote:
>>>
>>> I like that this solution doesn't litter every call to draw with
>>> rasterize checks. But it means that the rasterization support had
>>> better be rob
Jae-Joon Lee wrote:
> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning wrote:
>> I like that this solution doesn't litter every call to draw with
>> rasterize checks. But it means that the rasterization support had
>> better be robust, since Artist authors might not know they're
>> interacting with
On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning wrote:
> I like that this solution doesn't litter every call to draw with
> rasterize checks. But it means that the rasterization support had
> better be robust, since Artist authors might not know they're
> interacting with the rasterization code. It
>> The discussion about what to do with my patch fizzled. I created a
>> decorator that made mixed-mode switching a one-line change per artist
>> type. I also added get/set_rasterized and an _rasterized attribute to
>> the Artist base class. I've used it on and off for a few months now
>> with no n
Hi Eric,
>
> Sorry about the broken links. I've attached a diff made against trunk
> from a few days ago.
Thanks!
>
> The discussion about what to do with my patch fizzled. I created a
> decorator that made mixed-mode switching a one-line change per artist
> type. I also added get/set_rasterized
On Thu, Apr 23, 2009 at 9:54 PM, Eric Bruning wrote:
> On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee
> wrote:
>
> The discussion about what to do with my patch fizzled. I created a
> decorator that made mixed-mode switching a one-line change per artist
> type. I also added get/set_rasterized and
On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee wrote:
> On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning wrote:
>> On a somewhat related note, how are you turning rasterization on and
>> off? Are you using my per-artist patch (which last I knew wasn't in
>> trunk) or some other solution?
>
> I remem
On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning wrote:
> On a somewhat related note, how are you turning rasterization on and
> off? Are you using my per-artist patch (which last I knew wasn't in
> trunk) or some other solution?
I remember that I tried to use your patch, but all the links that I
f
On Thu, Apr 16, 2009 at 1:38 PM, Jae-Joon Lee wrote:
> Eric and others,
>
> I just committed the fix for this problem to the trunk.
> It should also work with the svg backend.
Thanks, that's fantastic. I'm glad to have the fix in place.
On a somewhat related note, how are you turning rasterizati
Eric and others,
I just committed the fix for this problem to the trunk.
It should also work with the svg backend.
>
> From a design perspective, is it appropriate for the renderer to store
> a reference to a figure? Many (all?) of the renderers seem entirely
> decoupled from the figure.
>
I ack
>> I don't quite like my solution but it seems to work.
>> It passes over the figure instance when initializing the
>> MixedRenderer, and let the renderer change the dpi of the figure when
>> changing the backend.
>> I hope some other developer who better understands the dpi thing take
>> a look an
Hi Jae-Joon,
On Sun, Mar 22, 2009 at 8:55 PM, Jae-Joon Lee wrote:
> Hi Eric,
>
> Have you find a solution for your problem?
> I recently encountered a similar problem.
> In my case, the images (I'm rasterizing the pcolormesh) are in wrong
> size if the output dpi is other than 72.
> And I guess t
Hi Eric,
Have you find a solution for your problem?
I recently encountered a similar problem.
In my case, the images (I'm rasterizing the pcolormesh) are in wrong
size if the output dpi is other than 72.
And I guess this is related with the changes Jouni made in revision 6730.
So, can you see if
I just updated to the latest svn, and unveiled a bug that's evident
when using mixed-mode rendering in the PDF backend. I'm suspect I'm
the only one running my patch that enables set_rasterized on a
per-artist basis, so I'm the only one that's seeing it. :) Artists
that are left in vector mode are
24 matches
Mail list logo
