1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231
|
=======================
MEP26: Artist styling
=======================
.. contents::
:local:
Status
======
**Rejected**
Branches and Pull requests
==========================
Abstract
========
This MEP proposes a new stylesheet implementation to allow more
comprehensive and dynamic styling of artists.
The current version of matplotlib (1.4.0) allows stylesheets based on
the rcParams syntax to be applied before creation of a plot. The
methodology below proposes a new syntax, based on CSS, which would
allow styling of individual artists and properties, which can be
applied dynamically to existing objects.
This is related to (and makes steps toward) the overall goal of moving
to a DOM/tree-like architecture.
Detailed description
====================
Currently, the look and appearance of existing artist objects (figure,
axes, Line2D, etc.) can only be updated via ``set_`` and ``get_`` methods
on the artist object, which is quite laborious, especially if no
reference to the artist(s) has been stored. The new style sheets
introduced in 1.4 allow styling before a plot is created, but do not
offer any means to dynamically update plots or distinguish between
artists of the same type (i.e. to specify the ``line color`` and ``line
style`` separately for differing `.Line2D` objects).
The initial development should concentrate on allowing styling of
artist primitives (those `.Artist`\s that do not contain other
`.Artist`\s), and further development could expand the CSS syntax rules
and parser to allow more complex styling. See the appendix for a list
of primitives.
The new methodology would require development of a number of steps:
- A new stylesheet syntax (likely based on CSS) to allow selection of
artists by type, class, id, etc.
- A mechanism by which to parse a stylesheet into a tree
- A mechanism by which to translate the parse-tree into something
which can be used to update the properties of relevant
artists. Ideally this would implement a method by which to traverse
the artists in a tree-like structure.
- A mechanism by which to generate a stylesheet from existing artist
properties. This would be useful to allow a user to export a
stylesheet from an existing figure (where the appearance may have
been set using the matplotlib API)...
Implementation
==============
It will be easiest to allow a '3rd party' to modify/set the style of an artist
if the 'style' is created as a separate class and store against the artist as a
property. The `.GraphicsContextBase` class already provides a the basis of a
``Style`` class and an artist's `~.Artist.draw` method can be refactored to use
the ``Style`` class rather than setting up its own `.GraphicsContextBase` and
transferring its style-related properties to it. A minimal example of how this
could be implemented is shown here: https://github.com/JamesRamm/mpl_experiment
IMO, this will also make the API and code base much neater as
individual get/set methods for artist style properties are now
redundant... Indirectly related would be a general drive to replace
get/set methods with properties. Implementing the style class with
properties would be a big stride toward this...
For initial development, I suggest developing a syntax based on a much
(much much) simplified version of CSS. I am in favour of dubbing this
Artist Style Sheets :+1: :
BNF Grammar
-----------
I propose a very simple syntax to implement initially (like a proof of
concept), which can be expanded upon in the future. The BNF form of
the syntax is given below and then explained ::
RuleSet ::= SelectorSequence "{"Declaration"}"
SelectorSequence :: = Selector {"," Selector}
Declaration ::= propName":" propValue";"
Selector ::= ArtistIdent{"#"Ident}
propName ::= Ident
propValue ::= Ident | Number | Colour | "None"
``ArtistIdent``, ``Ident``, ``Number`` and ``Colour`` are tokens (the basic
building blocks of the expression) which are defined by regular
expressions.
Syntax
------
A CSS stylesheet consists of a series of **rule sets** in hierarchical
order (rules are applied from top to bottom). Each rule follows the
syntax ::
selector {attribute: value;}
Each rule can have any number of ``attribute: value`` pairs, and a
stylesheet can have any number of rules.
The initial syntax is designed only for `.Artist` primitives. It does
not address the question of how to set properties on `.Container` types
(whose properties may themselves be `.Artist`\s with settable
properties), however, a future solution to this could simply be nested
``RuleSet``\s
Selectors
~~~~~~~~~
Selectors define the object to which the attribute updates should be
applied. As a starting point, I propose just 2 selectors to use in
initial development:
Artist Type Selector
Select an `.Artist` by it's type. E.g `.Line2D` or `.Text`::
Line2D {attribute: value}
The regex for matching the artist type selector (``ArtistIdent`` in the BNF grammar) would be::
ArtistIdent = r'(?P<ArtistIdent>\bLine2D\b|\bText\b|\bAxesImage\b|\bFigureImage\b|\bPatch\b)'
GID selector
~~~~~~~~~~~~
Select an `.Artist` by its ``gid``::
Line2D#myGID {attribute: value}
A ``gid`` can be any string, so the regex could be as follows::
Ident = r'(?P<Ident>[a-zA-Z_][a-zA-Z_0-9]*)'
The above selectors roughly correspond to their CSS counterparts
(http://www.w3.org/TR/CSS21/selector.html)
Attributes and values
~~~~~~~~~~~~~~~~~~~~~
- ``Attributes`` are any valid (settable) property for the `.Artist` in question.
- ``Values`` are any valid value for the property (Usually a string, or number).
Parsing
-------
Parsing would consist of breaking the stylesheet into tokens (the
python cookbook gives a nice tokenizing recipe on page 66), applying
the syntax rules and constructing a ``Tree``. This requires defining the
grammar of the stylesheet (again, we can borrow from CSS) and writing
a parser. Happily, there is a recipe for this in the python cookbook
as well.
Visitor pattern for matplotlib figure
-------------------------------------
In order to apply the stylesheet rules to the relevant artists, we
need to 'visit' each artist in a figure and apply the relevant rule.
Here is a visitor class (again, thanks to python cookbook), where each
``node`` would be an artist in the figure. A ``visit_`` method would need
to be implemented for each mpl artist, to handle the different
properties for each ::
class Visitor:
def visit(self, node):
name = 'visit_' + type(node).__name__
meth = getattr(self, name, None)
if meth is None:
raise NotImplementedError
return meth(node)
An ``evaluator`` class would then take the stylesheet rules and
implement the visitor on each one of them.
Backward compatibility
======================
Implementing a separate ``Style`` class would break backward
compatibility as many get/set methods on an artist would become
redundant. While it would be possible to alter these methods to hook
into the ``Style`` class (stored as a property against the artist), I
would be in favor of simply removing them to both neaten/simplify the
codebase and to provide a simple, uncluttered API...
Alternatives
============
No alternatives, but some of the ground covered here overlaps with
MEP25, which may assist in this development
Appendix
========
Matplotlib primitives
---------------------
This will form the initial selectors which stylesheets can use.
* Line2D
* Text
* AxesImage
* FigureImage
* Patch
|