Currently, the second page of example 30 shows how we implement linear gradients in PLplot using a combination of plscmap1la and plshades. That method should give good results for perfectly opaque colours, but does a poor job with transparency gradients (see http://plplot.sourceforge.net/examples-data/demo30/x30.02.png) presumably because the edges of the plshades rectangles that approximate the gradient are slightly misaligned with the underlying pixel matrix causing either full transparency for the gaps between edges or double opacity if there is overlap between the edges.
Here are some current PLplot examples where we could use a properly implemented transparency gradient. * Second page of example 30 which is currently pretty ugly. * The transparency gradient in our logo (currently implemented with the examples/python/svg_760x120_gradient.patch SVG patch). * A natural-looking rainbow would make a wonderful background to the peace flag in example 24, and I am pretty sure such a rainbow would look best if implemented with the help of a transparency gradient. The PostScript (level 3), PDF, and SVG specifications as well as the QT and cairo libraries all natively support gradients and are bound to do a better job with transparency gradients than the plscmap1la/plshades approach. Therefore, I propose that we implement PLplot support for gradients for those drivers (e.g., ps, psttf, pdf, svg, qt, and cairo) that natively support gradients with a software fallback using the plscmap1la/plshades approach for those drivers that don't natively support gradients. To help decide on the API for such gradient support within PLplot, here are the details of the native gradient support in the SVG specification and QT and cairo libraries. SVG-1.1 (see http://www.w3.org/TR/SVG11/pservers.html for more details) examples/python/svg_760x120_gradient.patch illustrates how to do a basic linear transparency gradient within SVG. Much like plscmap1la you define the gradient function at a series of stop points (known as control points for plscmap1la). For this case, I used default coordinate transformations to orient the gradient relative to the rectangle. According to the specification you can complicate this simple picture by repeating or padding gradients for the range of stop points not covered. I don't think we need to support those complications within PLplot (just like we don't support them for plscmap1la where we demand the beginning and ending control points are 0. and 1.). SVG also supports circular gradients where the gradient occurs from some focal point (often the center of a circle) to the edge of a circle. Eventually, we might want to support that, but for now I think we should stick with linear gradients. Qt-4.5 (see http://doc.trolltech.com/4.5/demos-gradients.html) >From this demo, it appears Qt-4.5 support for gradients is very similar to what you can do with SVG. Qt supports linear, circular, and conical(?) gradients. cairo (see http://www.cairographics.org/tutorial/) It appears from this tutorial that cairo support of gradients is similar to the SVG specification including linear and circular gradients. >From this quick tour of the SVG, QT, and cairo cases, I conclude we should support a new addition to our API which allows the user to draw a linear gradient within a rectangle. The suggested prototype of this API addition would look like this; void plgradient(PLBOOL itype, PLINT npts, PLFLT *pos, PLFLT *coord1, PLFLT *coord2, PLFLT *coord3, PLFLT *coord4, PLBOOL * rev, PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax, PLFLT angle); where arguments itype through rev have the same meanings as for plscmap1la; xmin, ymin, xmax, and ymax specify the rectangle in world coordinates; and angle (degrees) represents the direction of the gradient within that rectangle. The quadrant of the angle would specify which corners of the rectangle would correspond to the minimum and maximum of the gradient. I hope to develop plgradient this week using the plscmap1la/plshades software fallback method and also change example 30 to use plgradient. After that, some hard slogging will remain to implement svg, etc., driver changes so that native linear gradients are used rather than the software fallback. The goals of this final phase of the work are to generate our SVG logo without the need for a gradient patch; generate good-looking results for page 2 of example 30; and generate a realistic rainbow background for example 24. Comments are invited. In particular do you think that the proposed prototype for plgradient needs any changes? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
