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 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')
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
On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning <eri...@gm...> 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. :) 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
Hi Jae-Joon,
On Sun, Mar 22, 2009 at 8:55 PM, Jae-Joon Lee <lee...@gm...> 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 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
>
> Regards,
>
> -JJ
>
>
> On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning <eri...@gm...> 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. :) 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>> 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
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
On Thu, Apr 16, 2009 at 1:38 PM, Jae-Joon Lee <lee...@gm...> 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 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 :) Thanks, Eric
On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning <eri...@gm...> 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 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 Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee <lee...@gm...> wrote: > On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning <eri...@gm...> 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 > 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
On Thu, Apr 23, 2009 at 9:54 PM, Eric Bruning <eri...@gm...>wrote: > On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee <lee...@gm...> > 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. 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 -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
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 >> >> 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 >
>> 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 >> >
On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eri...@gm...> 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? 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
Jae-Joon Lee wrote: > On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eri...@gm...> 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 > > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing <ef...@ha...> wrote: > Jae-Joon Lee wrote: >> >> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eri...@gm...> >> 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 >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
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 On Mon, May 4, 2009 at 10:05 AM, Eric Bruning <eri...@gm...> wrote: > On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing <ef...@ha...> wrote: >> Jae-Joon Lee wrote: >>> >>> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eri...@gm...> >>> 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 >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >
On Tue, May 5, 2009 at 1:08 PM, Jae-Joon Lee <lee...@gm...> 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
johnh@flag: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
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
>
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
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 <eri...@gm...> 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 >
On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote: > I'm attaching the revised patch (I may split the patch for commit). Still encountering troubles .... johnh@flag: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:52 PM, John Hunter <jd...@gm...> wrote: > On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> 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 around. Give me a few minutes to test....
On Tue, May 5, 2009 at 2:54 PM, John Hunter <jd...@gm...> wrote: > On Tue, May 5, 2009 at 2:52 PM, John Hunter <jd...@gm...> wrote: >> On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> 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 around. Give me a few minutes to test.... OK thanks for the fixes. Looks good from my end. JDH
Thanks for your work on this patch JJ, glad to see it ready to go!
The patches are now committed to the trunk (r7089, 7090, 7091). Regards, -JJ On Tue, May 5, 2009 at 5:16 PM, Eric Bruning <eri...@gm...> wrote: > Thanks for your work on this patch JJ, glad to see it ready to go! >