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.
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.
I haven't thought about this carefully, but I think it could help
improve the cohesion of the code.
Perhaps a more "object-oriented" way to deal with color specifications
would be to let ColorSpec objects be constructed by the user, and
require these objects to be used in the OO api: instead of
ax.bar(x, y, color='0.5', edgecolor='r')
require
ax.bar(x, y, color=ColorSpec('0.5'), edgecolor=ColorSpec('r'))
or perhaps even something like
ax.bar(x, y,
color=ColorSpec(grayscale=0.5),
edgecolor=ColorSpec(named='r'))
to avoid parsing strings in the API - 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.
IMHO this would be more Pythonic (in the vein of "Explicit is better
than implicit" and "In the face of ambiguity, refuse the temptation to
guess"), although a departure from how matplotlib currently works. It
would encourage the users of the OO API to select their colors once and
put them in variables, so the example above would really read
facecolor = ColorSpec(grayscale=0.5)
edgecolor = ColorSpec(named='red')
# ...
ax.bar(x, y, color=facecolor, edgecolor=edgecolor)
which - as a part of a longer program - would likely be easier to
maintain than the first version of the example.
> I suspect that this refactoring might, without loss
> of backwards compatibility, make it possible to considerably simplify,
> clarify, and generalize the handling of colors (again, both single
> values and arrays), and provide a less-confusing framework for setting
> and overriding defaults. I think that as things are now, color spec
> checking and/or conversion are often done repeatedly in a single
> pipeline. With the class, all this would happen only the first time a
> color spec is encountered.
>
> The class might include mapping, or the present color mapping might
> yield an instance of the class; I have not thought about this aspect.
>
> Eric
--
Jouni K. Seppänen
http://www.iki.fi/jks
------------------------------------------------------------------------------
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
