On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen j...@iki.fi wrote:
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.
Yes, supporting arbitrary affine transform would not be difficult. On
the other hand, I'm not sure if that feature is practically useful,
assuming that other rasterizing backend won't implement it. I'll think
about it.
* 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.
One benefit of compositing would be an indirect support of alpha
compositing in the ps backend, although it is not clear this is
practically useful. Checking whether compositing is required seems not
very straight forward to me. We may try to sort out images that needs
to be composited and those does not. Anyhow, I am personally happy
with the current behavior so I may leave it as is, and let others take
it if they want.
* 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).
What I meant was the case when the dpi of the image painted on the
canvas is much higher than the dpi of the canvas itself (I mean the
dpi of the typical postscript output device). Anyhow, I guess the
current behavior is good enough, and it seems more reasonable to let
users do the down-sampling explicitly if they want.
Regards,
-JJ
--
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
--
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
