Andrew, Thank you for applying these changes! Other comment/answers below.
On Sat, Jul 19, 2008 at 5:43 PM, Andrew Ross <[EMAIL PROTECTED]> wrote: > 1) Rather than changing comments to // to nest them inside /* ... */ I > would suggest just using > #if 0 > ... > #endif > 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 > updating. 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 > example? 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. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
