Jouni K. Seppänen wrote: > Eric Firing <efir...@hawaii.edu> writes: > >> John Hunter wrote: >> >>> One possibility would be to have a facecolor/edgecolor property on >>> the gc itself, which would be rgba tuples. Since the gc is almost >>> entirely internal, we can revamp it w/o affecting userland code, >>> though it would be nice to support legacy methods (eg gc.set_alpha >>> could warn and then proceed to set the edge and face alpha channel). >>> Then we would drop the rgbFace argument entirely. Obviously this >>> would require hacking through a bunch of backend code to fix, but the >>> changes would be fairly straightforward and of the busy-work variety. >>> > > One open question is whether set_alpha (even if deprecated) should set or multiply the alpha of the fill and edge color. But I think I'm in favor of creating "one way to do it", which would be to have alpha as the fourth component of any color -- that option also scales well to individual colors in a collection, in a way that any of the more global options don't.
It strikes me that if none of us find the time for this, this task would be a good initial GSoC task... it's not enough work for an entire summer by any means, but it's "busy work" that touches a lot of parts of the code, and therefore a good introduction to the code base. The other related task is to create a gc-like object for collections so that the arguments to draw_collection don't have to change in every backend every time a new feature is added. > This sounds like a good idea. In the pdf backend, GraphicsContextPdf > already defines a _fillcolor attribute, and for example draw_path does > > def draw_path(self, gc, path, transform, rgbFace=None): > self.check_gc(gc, rgbFace) > # ... > > where check_gc just temporarily sets gc._fillcolor to the value of > rgbFace and issues the pdf commands to change the graphics state to > reflect gc. If rgbFace is absorbed into gc, at least the pdf backend > should be easy to change accordingly, and should become less complex in > the process. Currently the same alpha value (gc._alpha) is used for both > strokes and painting operations, but this too should be easy to change > if we decide to drop the _alpha attribute from GraphicsContext and use > the fourth component of the stroke and fill colors for alpha. > > By the way, the PDF imaging model has much richer support for > transparency than just specifying an alpha value for each operation; the > Transparency chapter takes up 64 pages in the PDF spec¹. One thing that > I imagine somebody just might want to have support for in matplotlib are > transparency groups², i.e., blending some objects together and then > blending the group with the background. But I wonder if that's possible > in Agg - I guess we will want to stay pretty close to the greatest > common denominator of Agg, SVG and PDF, and let people with special > needs use other software such as Illustrator to postprocess the files. > > ¹ http://www.adobe.com/devnet/pdf/pdf_reference_archive.html > ² > http://itext.ugent.be/library/com/lowagie/examples/directcontent/colors/transparency.pdf > > >> Maybe we need an MplColorSpec class. At present, functions and methods >> typically accept colors and/or color arrays in a wide variety of forms. >> This is good. My thought is that these should then be converted by >> the accepting function or method to instances of the new class, and that >> instances of the new class should be accepted as color inputs along with >> all the old forms. >> > > replacing the current hack, neat > as it is, where a string representation of a decimal number means a > grayscale color, a string beginning with # means a hexadecimal color, > etc. The pyplot API should of course continue to work as it does now. > > I really like Eric's suggestion here, as it fits in well with my desire to verify arguments early and consistently. But I don't think we need to throw out the convenient string forms of colors to achieve it. Those are really handy, and fairly well known from HTML/CSS/SVG etc., and I worry forcing the user to provide an instance of a particular class to do something as common as setting a color would be annoying verbosity. Of course, they should be free to do so if there's other maintenance advantages as you suggested. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
