Thank you for applying these changes! Other comment/answers below.
On Sat, Jul 19, 2008 at 5:43 PM, Andrew Ross
> 1) Rather than changing comments to // to nest them inside /* ... */ I
> would suggest just using
> #if 0
> around the code block. (I've implemented this.) We try to avoid C++
> style comments in C code.
Thank you for this tip. Using "#if 0 .. #endif" had not occurred to me.
> 2) I notice you commented out the call to plP_image in rdbug_image since
> the API has changed. <more, cut>
Yes, from what I can tell these functions are only important for the
fast_img rendering path because the "slow" rendering path effectively
treats each pixel as a polygon to be individually plotted so no
special handling is required.
I think something like a fast_img rendering path may be more useful
for Postscript, PDF and similar vector-based output targets because,
at least for untransformed images, it could greatly reduce the output
size of plots if a plotted image were represented as a blob of binary
image data rather than a large set of individual polygons. I don't
know enough about Postscript, PDF, Cairo or the related PLplot output
drivers to be sure how to address this though.
> 3) Your patch breaks various other language bindings. For now I have
> disabled plimagefr support in f77 / f95. These require a bit of work to
> support pltr and I've not had time today. If someone else would like to
> take this on it would be great. Hez, you might like to look at how
> plcont and plvect work (with internal plfcont and plfvect functions) to
> aid the f77 / f95 bindings. Best to make the plimagefr consistent. This
> will be an internal change for the C API though so I've gone ahead and
> commited your existing version for now.
It will probably take me some time to address this, but I can
certainly take a stab at it.
> 4) Other languages will need plimagefr support adding once we've
> finalised the API. Also all (non-C) versions of example 20 will need
I tried to keep the interface to the function as similar to the
plimage and plshade* routines as possible. The argument list is quite
long, but I don't know if there is any reasonable way around that.
> 5) You example transformation in example 20 is quite subtle. Perhaps
> something like a shear would be more obvious and generally useful
I like your new transformation in example 20 much more than the one I
had initially included. It should be much more generally useful.
Thanks to both you and Alan for taking the time to review and apply my
recent string of patches.
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science