Rasterized artists have wrong transform

Development matplotlib-devel
1

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. :slight_smile: Artists
that are left in vector mode are plotted correctly, while artists that
are rasterized are squished down toward the lower left corner of the
axes.

Looking at the svn log, I suspect it's the changes to the path
simplification code (r6847) doing something funky at the transforms
level. Is that the right place to start looking? Any tips on how to
track this down?

Thanks,
Eric

Sample code to reproduce the problem:

import numpy
from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
basecolors = get_cmap('gist_yarg')
colormap, normer = basecolors, None #LogNorm()
x = y = c = numpy.arange(10) +1
dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
dummy.set_rasterized(True)
dummy.figure.savefig('raster_test.pdf')

2

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 you have a correct output with dpi=72?
If that's the case, can you try the attached patch and see if it
solves your problem (should work with dpi other than 72).

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 and come up with a better solution.

Regards,

-JJ

rasterize.diff (2.4 KB)

···

On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning <eric.bruning@...149...> wrote:

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. :slight_smile: Artists
that are left in vector mode are plotted correctly, while artists that
are rasterized are squished down toward the lower left corner of the
axes.

Looking at the svn log, I suspect it's the changes to the path
simplification code (r6847) doing something funky at the transforms
level. Is that the right place to start looking? Any tips on how to
track this down?

Thanks,
Eric

Sample code to reproduce the problem:

import numpy
from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
basecolors = get_cmap('gist_yarg')
colormap, normer = basecolors, None #LogNorm()
x = y = c = numpy.arange(10) +1
dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
dummy.set_rasterized(True)
dummy.figure.savefig('raster_test.pdf')

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

3

Hi Jae-Joon,

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 you have a correct output with dpi=72?
If that's the case, can you try the attached patch and see if it
solves your problem (should work with dpi other than 72).

I hadn't found a solution (other than rendering to svg), so thanks for
waking up this thread. I can confirm that I get the correct output
when I set dpi=72.

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 and come up with a better solution.

I'll try to take a look at this later this afternoon. I agree that
someone with more knowledge should take a look. The SVG backend seems
to just ignore the dpi setting and forces 72 dpi across the board,
which is why I was able to use it as a workaround.

Thanks,
Eric

···

On Sun, Mar 22, 2009 at 8:55 PM, Jae-Joon Lee <lee.j.joon@...149...> wrote:

Regards,

-JJ

On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning <eric.bruning@...149...> wrote:

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. :slight_smile: Artists
that are left in vector mode are plotted correctly, while artists that
are rasterized are squished down toward the lower left corner of the
axes.

Looking at the svn log, I suspect it's the changes to the path
simplification code (r6847) doing something funky at the transforms
level. Is that the right place to start looking? Any tips on how to
track this down?

Thanks,
Eric

Sample code to reproduce the problem:

import numpy
from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
basecolors = get_cmap('gist_yarg')
colormap, normer = basecolors, None #LogNorm()
x = y = c = numpy.arange(10) +1
dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
dummy.set_rasterized(True)
dummy.figure.savefig('raster_test.pdf')

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

4

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 and come up with a better solution.

I'll try to take a look at this later this afternoon. I agree that
someone with more knowledge should take a look. The SVG backend seems
to just ignore the dpi setting and forces 72 dpi across the board,
which is why I was able to use it as a workaround.

I applied your patch, and it does allow the PDF backend to produced
mixed modes at various DPI.

The SVG backend complains about the change in call signature to
MixedModeRenderer.__init__(). SVG is the only other backend to use
MixedModeRenderer, so that would be an easy fix.

It seems surprising that dpi=72 is part of the renderer assumptions
somewhere along the way.

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.

-Eric

-Eric

5

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 acknowledge this issue but I couldn't find a better solution, so
I hope someone else come up with a better idea.

Regards,

-JJ

6

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 rasterization on and
off? Are you using my per-artist patch (which last I knew wasn't in
trunk) or some other solution?

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 acknowledge this issue but I couldn't find a better solution, so
I hope someone else come up with a better idea.

It's easy for me to critique, but you actually wrote some code :slight_smile:

Thanks,
Eric

···

On Thu, Apr 16, 2009 at 1:38 PM, Jae-Joon Lee <lee.j.joon@...149...> wrote:

7

I remember that I tried to use your patch, but all the links that I
found were broken. So I wrote a few lines for monkey patching. It was
straight forward as I only needed a rasterization of the QuadMesh
class.

Are you planning to commit your patch to the trunk? I'll be glad to
help you if there are any issues.
Regards,

-JJ

···

On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning <eric.bruning@...149...> 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?

8

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
found were broken. So I wrote a few lines for monkey patching. It was
straight forward as I only needed a rasterization of the QuadMesh
class.

Sorry about the broken links. I've attached a diff made against trunk
from a few days ago.

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 noted bugs.

If we don't like the decorator, we can just make a helper function
that is called at the beginning of every artist.draw() method. It's
not a very complicated modification.

Are you planning to commit your patch to the trunk? I'll be glad to
help you if there are any issues.

I'd love to get the patch in trunk, if only so that more people can
try it out and find things to improve (or re-implement).

Thanks,
Eric

mixed-mode.diff (9.18 KB)

···

On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee <lee.j.joon@...149...> wrote:

On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning <eric.bruning@...149...> wrote:

9

I think part of the problem with decorators before was that they came around in 2.4. I think we only support >=2.4 now, so this is no longer an issue. IMO, decorators seem like a sensible way to go.

Ryan

···

On Thu, Apr 23, 2009 at 9:54 PM, Eric Bruning <eric.bruning@…149…> wrote:

On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee <lee.j.joon@…149…> 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 an _rasterized attribute to

the Artist base class. I’ve used it on and off for a few months now

with no noted bugs.

If we don’t like the decorator, we can just make a helper function

that is called at the beginning of every artist.draw() method. It’s

not a very complicated modification.

–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

10

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 and an _rasterized attribute to
the Artist base class. I've used it on and off for a few months now
with no noted bugs.

If we don't like the decorator, we can just make a helper function
that is called at the beginning of every artist.draw() method. It's
not a very complicated modification.

Would there be a case that draw methods of some Artists do not need to
be decorated?
If not, I guess some metaclass black magic might be not harmful. What
do you think? I'm attaching modified version of your patch which
utilize metaclass for decoration.

I personally want that rasterization is also supported in the ps
backend. I guess the missing support of alpha composition would be a
problem. But, in most of the my use case, I want rasterization for
artist with z lower than some specified value (i.e., background images
using pcolormesh), so it is not a problem for me.

Regards,

-JJ

mixed_mode_metaclass.diff (2.59 KB)

···

Are you planning to commit your patch to the trunk? I'll be glad to
help you if there are any issues.

I'd love to get the patch in trunk, if only so that more people can
try it out and find things to improve (or re-implement).

Thanks,
Eric

11

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 noted bugs.

If we don't like the decorator, we can just make a helper function
that is called at the beginning of every artist.draw() method. It's
not a very complicated modification.

Would there be a case that draw methods of some Artists do not need to
be decorated?

Not that I can think of, if rasterization defaults to off and it's a
user setting to turn it on (except perhaps some future modification
where we auto-detect egregious poly counts in a mesh, for instance).

If not, I guess some metaclass black magic might be not harmful. What
do you think? I'm attaching modified version of your patch which
utilize metaclass for decoration.

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 has the downside of being
implicit rather than explicit.

I personally want that rasterization is also supported in the ps
backend. I guess the missing support of alpha composition would be a
problem. But, in most of the my use case, I want rasterization for
artist with z lower than some specified value (i.e., background images
using pcolormesh), so it is not a problem for me.

I'm not too familiar with the PS backend, but I think that's separate
from the issue of how to tell the renderer when to rasterize.

Thanks,
Eric

···

Are you planning to commit your patch to the trunk? I'll be glad to
help you if there are any issues.

I'd love to get the patch in trunk, if only so that more people can
try it out and find things to improve (or re-implement).

Thanks,
Eric

12

Eric,
I think we'd better stick to your decorator solution.

Anyhow, I thought you had a svn commit permission but it seems not. Do
you (and other dwevelopers) mind if I commit this patch to the trunk?

One I thing I want to add your patch is to warn users when they set
"rasterized" attribute of the artists whose draw method is not
decorated. I'll think about it later but feel free to propose any.

Thanks,

-JJ

···

On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eric.bruning@...149...> 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 has the downside of being
implicit rather than explicit.

13

Jae-Joon Lee 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 has the downside of being
implicit rather than explicit.

Eric,
I think we'd better stick to your decorator solution.

Anyhow, I thought you had a svn commit permission but it seems not. Do
you (and other dwevelopers) mind if I commit this patch to the trunk?

It would be especially good for John and Mike to have a look.

As a matter of style, I suggest a name change. "@hook_before_after_draw" is too generic, and brings to mind discussions a long time ago about possibly adding a general hook mechanism; even before rasterization, and before decorators were available, there were thoughts that we might need this. (Now I don't remember what the motivation was, but I think it had to do with coordinating different elements of a plot.) In any case, the decorator is actually very specific to rasterization, so maybe call it "@with_rasterization" or "@allow_rasterization".

I am very anxious to see rasterization support in place; let's just be sure we have a good API and mechanism. The patch looks reasonable to me, but I have no experience in writing decorators, and have not had time to really think about the rasterization API problem.

Eric

···

On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eric.bruning@...149...> wrote:

One I thing I want to add your patch is to warn users when they set
"rasterized" attribute of the artists whose draw method is not
decorated. I'll think about it later but feel free to propose any.

Thanks,

-JJ

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

14

Jae-Joon Lee 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 has the downside of being
implicit rather than explicit.

Eric,
I think we'd better stick to your decorator solution.

Anyhow, I thought you had a svn commit permission but it seems not. Do
you (and other dwevelopers) mind if I commit this patch to the trunk?

It would be especially good for John and Mike to have a look.

As a matter of style, I suggest a name change. "@hook_before_after_draw" is
too generic, and brings to mind discussions a long time ago about possibly
adding a general hook mechanism; even before rasterization, and before
decorators were available, there were thoughts that we might need this.
(Now I don't remember what the motivation was, but I think it had to do
with coordinating different elements of a plot.) In any case, the decorator
is actually very specific to rasterization, so maybe call it
"@with_rasterization" or "@allow_rasterization".

I am very anxious to see rasterization support in place; let's just be sure
we have a good API and mechanism. The patch looks reasonable to me, but I
have no experience in writing decorators, and have not had time to really
think about the rasterization API problem.

I like Eric's suggestion to rename the decorator if its only purpose
is to handle rasterizing. A generic draw hook solution would be fun to
develop, but I don't have time for that learning curve at the moment.
So a raster-specific decorator is good by me; I like
@allow_rasterization.

It's correct that I'd need someone to commit the patch for me. In my
view, renaming the decorator is a simple search-replace that can be
handled by the committer, but I'm happy to help with any changes we
agree on.

One I thing I want to add your patch is to warn users when they set
"rasterized" attribute of the artists whose draw method is not
decorated. I'll think about it later but feel free to propose any.

I have no experience with decorator detection. Presumably you can so
some sort of inspection of self.draw in Artist.set_rasterized.

Thanks,
Eric B

···

On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing <efiring@...229...> wrote:

On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eric.bruning@...149...> >> wrote:

Thanks,

-JJ

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of expert-led,
hands-on workshops and two days of sessions from industry leaders in
dedicated Performance & Operations tracks. Use code vel09scf and Save an
extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

15

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 you use MixedModeRenderer when saving ps
output, i.e., rasterzation for ps backend. The rasterization per
artist is not that useful for ps backend as it does not support alpha
compositions. However, I introduced *rasterization_zorder* attributes
in Axes class, and slightly modified its draw method so that all the
artists whose zorder is below *rasterization_zorder* will be
rasterized (to a single image). My main use case for this is to have
transparent (but rasterized) contour lines or texts overlayed on top
of a background image (for PS backend). Take a look at the example
script I added (examples/misc/rasterization_demo.py).

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.

Regards,

-JJ

rasterization_patch_jj.diff (9.84 KB)

mixed_ps.patch (12.1 KB)

···

On Mon, May 4, 2009 at 10:05 AM, Eric Bruning <eric.bruning@...149...> wrote:

On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing <efiring@...229...> wrote:

Jae-Joon Lee wrote:

On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eric.bruning@...149...> >>> 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 has the downside of being
implicit rather than explicit.

Eric,
I think we'd better stick to your decorator solution.

Anyhow, I thought you had a svn commit permission but it seems not. Do
you (and other dwevelopers) mind if I commit this patch to the trunk?

It would be especially good for John and Mike to have a look.

As a matter of style, I suggest a name change. "@hook_before_after_draw" is
too generic, and brings to mind discussions a long time ago about possibly
adding a general hook mechanism; even before rasterization, and before
decorators were available, there were thoughts that we might need this.
(Now I don't remember what the motivation was, but I think it had to do
with coordinating different elements of a plot.) In any case, the decorator
is actually very specific to rasterization, so maybe call it
"@with_rasterization" or "@allow_rasterization".

I am very anxious to see rasterization support in place; let's just be sure
we have a good API and mechanism. The patch looks reasonable to me, but I
have no experience in writing decorators, and have not had time to really
think about the rasterization API problem.

I like Eric's suggestion to rename the decorator if its only purpose
is to handle rasterizing. A generic draw hook solution would be fun to
develop, but I don't have time for that learning curve at the moment.
So a raster-specific decorator is good by me; I like
@allow_rasterization.

It's correct that I'd need someone to commit the patch for me. In my
view, renaming the decorator is a simple search-replace that can be
handled by the committer, but I'm happy to help with any changes we
agree on.

One I thing I want to add your patch is to warn users when they set
"rasterized" attribute of the artists whose draw method is not
decorated. I'll think about it later but feel free to propose any.

I have no experience with decorator detection. Presumably you can so
some sort of inspection of self.draw in Artist.set_rasterized.

Thanks,
Eric B

Thanks,

-JJ

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of expert-led,
hands-on workshops and two days of sessions from industry leaders in
dedicated Performance & Operations tracks. Use code vel09scf and Save an
extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

16

I am getting the following error when I test on svn HEAD

johnh@...539...:misc> python rasterization_demo.py
Traceback (most recent call last):
  File "rasterization_demo.py", line 49, in ?
    plt.savefig("test_reasterization.eps", dpi=150)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyplot.py",
line 354, in savefig
    return fig.savefig(*args, **kwargs)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 1002, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py",
line 1467, in print_figure
    bbox_inches_restore=_bbox_inches_restore,
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py",
line 1321, in print_eps
    return ps.print_eps(*args, **kwargs)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py",
line 847, in print_eps
    return self._print_ps(outfile, 'eps', *args, **kwargs)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py",
line 879, in _print_ps
    orientation, isLandscape, papertype,
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py",
line 996, in _print_figure
    Ndict += len(renderer.used_characters)
AttributeError: 'MixedModeRenderer' object has no attribute 'used_characters'

Also, a minor potential buglet. In the following,

+ if dsu[0][0] < rasterization_zorder:
+ renderer.start_rasterizing()
+ dsu_rasterized = [l for l in dsu if l[0] < rasterization_zorder]
+ dsu = [l for l in dsu if l[0] >= rasterization_zorder]
+ else:
+ dsu_rasterized = []

I think one could construct a sufficiently empty axes that len(dsu)==0
so I suggest

+ if len(dsu) and dsu[0][0] < rasterization_zorder:

It might also be worthwhile employing a consistent usage when wrapping
the draw methods. We have

+ @allow_rasterization
     def draw(self, renderer, *args, **kwargs):

+ @martist.allow_rasterization
     def draw(self, renderer):

and

+ @artist.allow_rasterization
     def draw(self, renderer):

If we take the time upfront to be consistent, any search replace
things we need to do later will be easier.

Thanks,
JDH

···

On Tue, May 5, 2009 at 1:08 PM, Jae-Joon Lee <lee.j.joon@...149...> 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.

17

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.000000000 -0400
+++ lib/matplotlib/backends/backend_ps.py 2009-05-05
14:44:36.000000000 -0400
@@ -993,7 +993,7 @@
         Ndict = len(psDefs)
         print >>fh, "%%BeginProlog"
         if not rcParams['ps.useafm']:
- Ndict += len(renderer.used_characters)
+ Ndict += len(ps_renderer.used_characters)
         print >>fh, "/mpldict %d dict def"%Ndict
         print >>fh, "mpldict begin"
         for d in psDefs:
@@ -1001,7 +1001,7 @@
             for l in d.split('\n'):
                 print >>fh, l.strip()
         if not rcParams['ps.useafm']:
- for font_filename, chars in renderer.used_characters.values():
+ for font_filename, chars in ps_renderer.used_characters.values():
                 if len(chars):
                     font = FT2Font(font_filename)
                     cmap = font.get_charmap()

If we take the time upfront to be consistent, any search replace
things we need to do later will be easier.

I'll post a revised patch shortly.
Thanks,

-JJ

···

Thanks,
JDH

18

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 ways the base artist module is
imported for the subclasses of artist.

Thanks,
Eric

19

I'm attaching the revised patch (I may split the patch for commit).

Regards,

-JJ

rasterization_mixed_ps.patch (22.7 KB)

···

On Tue, May 5, 2009 at 3:22 PM, Eric Bruning <eric.bruning@...149...> wrote:

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 ways the base artist module is
imported for the subclasses of artist.

Thanks,
Eric

20

Still encountering troubles ....

johnh@...539...:misc> python rasterization_demo.py
Traceback (most recent call last):
  File "rasterization_demo.py", line 41, in ?
    ax4.set_rasterization_zorder(-10)
AttributeError: 'AxesSubplot' object has no attribute 'set_rasterization_zorder'

···

On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee.j.joon@...149...> wrote:

I'm attaching the revised patch (I may split the patch for commit).