Jae-Joon Lee <lee.j.j...@gmail.com> writes:

> While extending this to other backend such as pdf and svg should be
> straight forward, I want to hear how others think about the overall
> approach, e.g., api change and such. The current approach is to
> minimize change in backends.

While the backend API is being changed, would it be similarly easy to
support arbitrary affine transformations? It would make the API more
symmetric, since many other draw_* methods take an affine
transformation, and I guess at least the PS and PDF backends could
easily support this.

> * If there are multiple images (and the ps backend is used), the
> images are resampled as they are compositted into a single image.

The Figure.draw method already has some logic for not compositing
multiple images:

        if len(self.images)<=1 or not_composite or \
                not allequal([im.origin for im in self.images]):

I suppose this could also include a check for whether all images have
the same transformation. Anyway, I'm not quite sure what the win from
compositing is for a vector backend.

> * The current solution forces not to resample whenever
> interpolation=="nearest", I think this is generally good behavior.
> However, on the highly extreme case of very high resolution of image
> (e.g., image dpi > 1000 ?), it might be better if the image is
> resampled (i.e., downsampled).

This sounds like it would make sense for naive users but could get very
annoying for somebody who really does want high resolution (e.g. for
zooming in in a viewer application).

-- 
Jouni K. Seppänen
http://www.iki.fi/jks


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to