On 11/4/10 11:59 AM, kj wrote:
I would like to extend Sage to allow for recursive composition of
graphics arrays. (I.e. to enable having graphics arrays as individual
elements in a larger graphics array; as far as I can tell, Sage's
graphics_array does not support such higher-order graphics arrays.)
For this, the function that generates the graphics array must take a
1d or 2d array of graphics objects as one of its arguments, and return
a graphics object.
In order to do this, it would be helpful for me to understand Sage's
"data model" for graphics. In particular, I need to determine if
Sage's graphics objects are cleanly separate from possible display
channels.
To see why, consider, for example, Mathematica Graphics objects, which
are at the center of its graphics model. As far as I can tell from
Mathematica's documentation, to the user, such a Graphics object can
be interpreted (as a first approximation at least) as nothing more
than an abstract textual representation of a graphic, independent of
any display channel. This textual representation can be interpreted
by various drivers to produced various types of output (e.g. a screen
display or PostScript). The key point is that there appears to be a
clean separation between Mathematica's Graphics objects, and the
channels used for displaying them. (I repeat that all of this is
nothing more than a guess on my part, since Mathematica is a black
box.)
This separation of the abstract Graphics objects from any concrete
display channel greatly simplifies the problem of creating composite
Graphics objects from other Graphics objects, since there's no need to
reconcile any possible differences that may exist in channel
information for the individual components.
Is there a similar separation between the specification of Sage
graphics objects and display channels? To put it differently, how
much information about display channels is encoded in these objects?
Is there a write-up (or just some descriptive UML) on Sage's graphics
model that discusses these topics?
Yes, there is that separation that you describe. Graphics objects are
just python objects that know how to draw themselves when asked. They
draw themselves using matplotlib (see the _render_on_subplot function in
each object, for exampe, in devel/sage/sage/plot/circle.py). Matplotlib
then takes care of the "channel," as you call it, or drawing "backend,"
as matplotlib calls it. That drawing does not happen until the object is
drawn to an actual file. You can see this since, for example, you can
save a graphics object as a png file or a pdf file (two different channels):
sage: a=circle((0,0),1)
sage: a
sage: a.save('test.png')
sage: a.save('test.pdf')
You can see the save method code in the devel/sage/sage/plot/plot.py.
Basically, a matplotlib object is created, and then each object is asked
to draw itself on the canvas (or "axes," in matplotlib terminology).
I think to do what you want, it would be best to understand the
matplotlib model for drawing multiple figures on an image. Matplotlib
is the underlying library we use to draw Sage 2d figures, and is very
powerful. Recently, some new capabilities for drawing arrays of
graphics have been added (in matplotlib 1.0.0). Here are some links to
documentation:
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.subplots
http://matplotlib.sourceforge.net/users/whats_new.html#sophisticated-subplot-grid-layout
http://matplotlib.sourceforge.net/users/gridspec.html#gridspec-guide
In particular,
http://matplotlib.sourceforge.net/users/gridspec.html#gridspec-using-subplotspec
describes how to nest arrays of arrays in matplotlib.
I think we just need to wrap and expose this functionality that is
already in matplotlib in the Sage interface.
Thanks,
Jason
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
