Balisage Paper: XML for Art: A Case Study

The Power of Small Domain-Specific Languages

The problem with SVG is that while, yes, it is XML, key parts are designed for compactness, not for manipulation. For example, consider the snippet of SVG in Figure 1. The paths consist of a coded series of operators (M, A, and C) and control points. The transforms consist of a series of operators concatenated together. While it is easy enough to generate strings in output, manipulating a series of geometric paths (for example, to prune crossing paths) requires that we operate at a higher level.

...
  <g transform="translate(-56 -50) scale(0.875 0.875) skewX(10) skewY(9)">
    <g transform="scale(1 1) skewX(2.489)">
      <path d="M 340 543
               A 540 487 -17.161 0 0 291 629 312 621 -4.358 0 0 512 465 
               C 389 396 467 376 343 367 420 452 544 542 355 380" 
            class="Swoosh" style="stroke-width:7"/>
    </g>
  </g>
  <g transform="translate(-62 -50) scale(0.75 0.75) skewX(19) skewY(17)">
    <g transform="scale(1 1) skewX(2.489)">
      <path d="M 340 543
               A 540 487 -17.161 0 0 291 629 312 621 -4.358 0 0 512 465
               C 389 396 467 376 343 367 420 452 544 542 355 380" 
            class="Swoosh" style="stroke-width:7"/>
    </g>
  </g>
  <g transform="translate(-68 -50) scale(0.625 0.625) skewX(25) skewY(25)">
    <g transform="scale(1 1) skewX(2.489)">
      <path d="M 340 543 
               A 540 487 -17.161 0 0 291 629 312 621 -4.358 0 0 512 465 
               C 389 396 467 376 343 367 420 452 544 542 355 380" 
            class="Swoosh" style="stroke-width:7"/>
    </g>
  </g>
...
          

Having made the decision to create the algorithms using higher level constructs, there is actually a considerable advantage to emitting those higher level constructs as well. This allows me to abstract some of the messy geometric details, and even postpone some of the rendering choices. Now I can test variations in the fundamental algorithms separately from variations in rendering.

It is the classic separation of content and form in a new guise: the separation of algorithmic aesthetic choices from stylistic aesthetic choices.

Consider the scrap of domain-specific XML in Figure 2. The algorithm and its randomizers make decisions about the number and lengths of threads and drops. In this case, initial experiments focused on the overall shape of the threads. I shifted the thread length algorithm from the same normal distribution for each thread to one where the mean was the length of the preceding thread. A fixed default rendering was applied in this phase of the process to enable me to make such aesthetic judgements.

<art:canvas width="720" height="720" ...>
  <art:thread x="6">
    <art:drop y="0" length="20"/>
    <art:drop y="25" length="13"/>
    <art:drop y="43" length="15"/>
    <art:drop y="63" length="15"/>
  </art:thread>
  <art:thread x="24">
    <art:drop y="0" length="26"/>
    <art:drop y="31" length="9"/>
    <art:drop y="45" length="20"/>
    <art:drop y="70" length="12"/>
  </art:thread>
  <art:thread x="34">
    <art:drop y="0" length="15"/>
    <art:drop y="20" length="29"/>
    <art:drop y="54" length="26"/>
  </art:thread>
   ...
</art:canvas>
        

With the raw output in hand, the next phase of experimentation can render the same basic form in many different ways. This allows for a somewhat "scientific" approach to the experimentation: limiting what I vary at any given moment to see what works best overall.

Figure 3: Using small domain-specific language to vary effects

Default rendering parameters

 

Small adjustment (max-stroke-width=8)

 

More radical shape adjustment (drop-shape=chevron)

Various renderings of same set of randomized drop threads

Note that we are not necessarily talking about small stylistic variations here. The entire shape can be rendered in entirely different ways.

It can be tricky to decide where to draw that line.

Consider the iterated random swooshes in section “Generative Art”. The concept of an "echo", where a design element is repeated several times but offset, skewed, and shrunk slightly with each repetition, plays heavily there. It comes up in a lot of my other works as well. It would be tempting to create an echo element in the DSL which just has a count of how many echoes to make. However, using the same degree of offset, skew, and shrinkage in each echo is boring (too orderly), so echoes are created with slight random variations in these values. But if I want to keep randomization out of rendering, I have a problem, and either echo never makes it to the DSL, or it becomes much more complex with specific information about how the shape is modified in each repetition, blunting the utility of an echo element in the DSL in the first place. An intermediate position is to make a library function for creating echoes of a base shape.

What is manifest in the DSL versus what is introduced in the stylesheet versus what is a library function is a fluid and evolving boundary. The result has been elements at various levels from quite abstract all the way down to SVG pass-through. A particular project or set of related projects often move from less abstract to more abstract as work proceeds.

Stylesheet Framework

Transforming the domain specific language is the job of a set of stylesheets, which are organized with a set of defined parameters and customization layers, similar to the setup with the DocBook stylesheets (see DocBook). There is a main shared stylesheet (render.xsl) which includes a stylesheet that defines various parameters (param.xsl). The entry-point stylesheet for any particular project imports the main shared stylesheet and overrides various parameters and templates as required. The entry-point stylesheet will also define parameters and templates for elements that are specific to that project.

Figure 4 shows a project-specific entry-point stylesheet. It functions as a customization layer on top of the imported render.xsl. In addition to overriding default values for several standard parameters (stroke-class and max-stroke-width), and specifying values for the hooks for project-specific information (project-style-defs and project-styles), it defines several project-specific parameters (drop-shape et al). The project-specific element art:drop has a template that defines how it should be rendered to SVG.

<!-- Entrypoint stylesheet: render-thread.xsl -->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" ...>

  <xsl:import href="render.xsl"/>

  <!-- Overrides for default parameters -->
  <xsl:param name="stroke-class">BlueSwoosh</xsl:param>
  <xsl:param name="max-stroke-width">4</xsl:param>

  <xsl:param name="project-style-defs">
    <svg:linearGradient id="BlueGradient" 
         gradientUnits="userSpaceOnUse" 
         x1="0" x2="0" y1="0" y2="50"
    >
      <svg:stop offset="0%" stop-color="#FFFFEE" />
      <svg:stop offset="100%" stop-color="#0000E0" />
    </svg:linearGradient>
  </xsl:param>

  <xsl:param name="project-styles">
    .BlueSwoosh { 
      fill:none;
      stroke:url(#BlueGradient); 
      stroke-linecap:<xsl:value-of select="$stroke-cap"/>; 
      stroke-linejoin:<xsl:value-of select="$stroke-join"/> 
    }
  </xsl:param>

  <!-- Project-specific parameters -->
  <xsl:param name="drop-shape">line</xsl:param>
  <xsl:param name="drop-fill">none</xsl:param>
  <xsl:param name="drop-opacity">1</xsl:param>
  <xsl:param name="gap">5</xsl:param>

...
  <!-- Project-specific templates -->
  <xsl:template match="art:drop">
    <svg:g transform="translate(0,{@y + $gap*count(preceding-sibling::art:drop)})">
      <svg:g class="{$stroke-class}"
             stroke-width="{max((1,$max-stroke-width - (@y idiv 100)))}">
        <xsl:choose>
...
          <xsl:when test="$drop-shape='chevron'">
            <svg:path d="m 0 {$gap} L -5 {@length} m 0 {$gap} L 5 {@length}"/>
          </xsl:when>
          <xsl:when test="$drop-shape='circle'">
            <svg:circle cx="0" cy="{$gap + (@length idiv 2)}" r="{@length idiv 4}"
                        fill="{$drop-fill}" fill-opacity="{$drop-opacity}"/>
          </xsl:when>
          <xsl:otherwise>
            <svg:path d="m 0 {$gap} L 0 {@length}"/>
          </xsl:otherwise>
        </xsl:choose>
      </svg:g>
    </svg:g>
  </xsl:template>
</xsl:stylesheet>
        

Figure 5 shows the base shared stylesheet. The main base stylesheet provides templates for shared elements (e.g. art:canvas). A separate included stylesheet (param.xsl) defines various parameters. The stylesheet uses several modes to provide projects the means to put information into the appropriate part of the SVG result: as metadata, as definitions to be referenced, or as body content to be rendered.

<!-- Base stylesheet: render.xsl -->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" ...>

  <xsl:include href="param.xsl"/>

  ...

  <xsl:template match="/">
    <xsl:apply-templates select="*"/>
  </xsl:template>

  <xsl:template match="art:canvas">
    <svg:svg version="1.1"
      width="{@width}px" height="{@height}px"
      viewBox="0 0 {@width} {@height}"
    >
      <xsl:apply-templates select="." mode="metadata"/>
      <svg:defs>
        <xsl:apply-templates select="." mode="defs"/>
      </svg:defs>
      <svg:style type="text/css">
        <xsl:apply-templates select="." mode="styles"/>
      </svg:style>
      <svg:g>
        <xsl:apply-templates select="." mode="body"/>
      </svg:g>
    </svg:svg>
  </xsl:template>

  <!-- Embed metadata -->
  <xsl:template match="art:canvas" mode="metadata">
    <xsl:apply-templates select="art:metadata"/>
    <xsl:if test="empty(art:metadata)">
      <art:metadata style="display:none">
        <xsl:call-template name="dump-parameters"/>
      </art:metadata>
    </xsl:if>
  </xsl:template>

  <!-- SVG defs -->
  <xsl:template match="art:canvas" mode="defs">
    <xsl:copy-of select="$global-style-defs"/>
    <xsl:copy-of select="$project-style-defs"/>
    <xsl:apply-templates select="* except art:metadata" mode="defs"/>
  </xsl:template>

  <!-- CSS styles -->
  <xsl:template match="art:canvas" mode="styles">
    <xsl:copy-of select="$global-styles"/>
    <xsl:copy-of select="$project-styles"/>
    <xsl:apply-templates select="* except art:metadata" mode="styles"/>
  </xsl:template>

  <!-- Main body:
       Do children in body mode for any background elements
       In default mode to the rest
    -->
  <xsl:template match="art:canvas" mode="body">
    <xsl:variable name="fill">...</xsl:variable>
    <xsl:variable name="opacity">...</xsl:variable>
    <xsl:variable name="filter">...</xsl:variable>
    <svg:rect x="0" y="0" width="{@width}" height="{@height}">
      <xsl:if test="$fill ne ''">
        <xsl:attribute name="fill">
          <xsl:value-of select="$fill"/>
        </xsl:attribute>
      </xsl:if>
      <xsl:if test="$opacity ne ''">
        <xsl:attribute name="opacity">
          <xsl:value-of select="$opacity"/>
        </xsl:attribute>
      </xsl:if>
      <xsl:if test="$filter ne ''">
        <xsl:attribute name="filter">
          <xsl:value-of select="$filter"/>
        </xsl:attribute>
      </xsl:if>
    </svg:rect>
    <xsl:apply-templates select="* except art:metadata" mode="body"/>
    <xsl:apply-templates select="* except art:metadata"/>
  </xsl:template>

  ...
  <!-- vertical arrangement of objects, e.g. drops -->
  <xsl:template match="art:thread">
    <svg:g transform="translate({@x},0)">
      <xsl:apply-templates/>
    </svg:g>
  </xsl:template>

  <!-- horizontal line of objects, e.g. glyphs -->
  <xsl:template match="art:line"> 
    <svg:g transform="translate(0,{@y})">
      <xsl:apply-templates/>
    </svg:g>
  </xsl:template>
...
</xsl:stylesheet>
        

Finally, as components evolve, some of the project-specific templates and parameters migrate into component stylesheets, which can then be used by later projects.

Mathematics

All algorithms rely on basic arithmetic operations: addition, subtraction, division, multiplication. Modulus and calculations of minimums and maximums come into play sometimes as well.

The randomizer library depends on a number of standard mathematical XPath functions, as we saw in Figure 6, such as math:pi, math:sqrt, math:pow. Various standard shapes depend on these as well, such as the shape function that generates the starbursts we saw in Figure 7.

Geometry

Trigonometric functions are crucial. Creating the branching tree of Figure 10, for example, requires being able to compute a destination point giving a starting point, an angle, and a stroke length, which means using sines and cosines. Standard XPath functions provide the basics here.

It is useful, however, to have more. The underlying engine provides a comprehensive set of extensions for geospatial data types and operations such as region intersection or distance between points. These can all be applied in a flat coordinate system. That is: they function as useful (Euclidean) geometric functions. Despite a general inclination to encapsulate platform dependencies, the geospatial data types (especially the point data type) were too compelling to avoid or hide.

A library is layered on top of the base geospatial functions to provide some basic utility and convenience functions, however. It also makes things easier in an SVG environment. For example, points in SVG space are integers in x-y space over a visible canvas, not floating point numbers in latitude-longitude space, so the library defines x and y coordinate accessors and functions to snap points to the grid, constrain them to the canvas, and scale back and forth between the unit square and the canvas.

Key geometric operations here are implemented using the operations provided by the underlying platform, but they could be implemented using basic mathematical and trigonometric functions, if necessary. Other engines may implement their own geometric capabilities, perhaps following the EXPath geospatial API.

...
let $hull := geom:convex-hull($shape)
let $center := geom:centroid($hull)
let $distance := 1.2 * geom:distance-from-center($hull, "max")
let $angle := rand:randomize($BEARING)
let $new-start-point := geom:point-at($center, $angle, $distance)
...
        

String Manipulation

Basic string operations come into play for creating the SVG data: concatenation and normalization. There is heavy use of the standard XPath functions string-join, concat, and normalize-string.

Lindenmeyer systems are systems of string rewriting rules. Stochastic Lindenmeyer systems add a probability to certain rules, creating alternative rewrite pathways. Such systems can be a very powerful means of creating naturalistic and complex forms. The rewrite rules run over several generations to create a coded string. For example, the strings generated for Figure 10 look like ...[[X]-X]+F[-FX]+X]+F+[[X]-X]-F[... That string then needs to be parsed and interpreted and converted into something to be rendered. Here F means draw a line in current direction, + means turn to the right, and so on. In my framework translation means generating some domain specific XML.

Figure 10: L-system tree

Tree generated with stochastic Lindenmeyer system

Depending on the complexity of the system and the mapping, more or less powerful string matching and manipulation functions are required. Basics such as string-to-codepoints, substring-before, and substring-after, as well tokenize and the power-tool analyze-string get a lot of use.

Higher-order Functions

It might not seem obvious at first, but fold-left sees a lot of action. Wherever we need to compute a value that depends on the previously computed value it pops up: Markov sequences, probability distribution sums, Lindenmeyer systems, and as a basis of many algorithms (such as the one behind the examples in Figure 3). Figure 11 shows how fold-left is used in computing Zipf cumulative probability sums.

declare function rand:zipf-sums(
  $α as xs:double,
  $n as xs:integer
) as xs:double*
{
   let $c := 
     fold-left(
       function($z,$i) {
         $z + 1 div (math:pow(xs:double($i), $α))
       },
       0,
       1 to $n
     )
   let $c := 1 div $c
   return
     fold-left(
       function($z,$i) {
         $z,
         $z[last()] + $c div math:pow(xs:double($i), $α)
       },
       0,
       1 to $n
     )[position() gt 1] (: skip initial 0 :)
};
        

Higher-order functions come into play with the generic randomizer function. It provides for function callback hooks for each parameter, which depends on the ability to have function values in the algorithm map and the ability to invoke such functions. The execution framework also relies on function callbacks to generate metadata and content.

Maps

Maps are used to hold randomizer specifications, as we have already seen. The execution framework uses maps to hold algorithm and rendering parameter values and pass these bundles of values in a consistent way. XML could be used for these purposes, but it ends up being messier especially with respect to function callbacks. Maps also come into play a great deal for various data structures because implementations optimize the "update" operations on them so that high-count iterative algorithms can perform reasonably.

Shapes, Paths, Systems, and Components

Libraries containing methods for creating various interesting shapes and paths evolve as building blocks for future work. For example, the path library has methods to construct a set of points around a circle, in a spiral, along a meandering line, in an array of lines, and so on. There are optional randomizer parameters to jitter the placement. Other libraries have methods for creating various interesting shapes. Base shapes can be modified in various ways: another library has methods for this. Laying out modified base shapes along different modified base paths creates distinct variations on a base work.

More specific and complex kinds of components get their own libraries: particular systems for generating asemic glyphs, for example, or particularly interesting Lindenmeyer systems and their interpretations that produce interesting branchings. Standard methods can execute stochastic and non-stochastic rewrite systems of various kinds.

Figure 12: Spiral murmurations

declare function this:content()
{
  let $density := $ACTIVE-PARAMETERS=>map:get("density")
  let $generations := $ACTIVE-PARAMETERS=>map:get("generations")
  let $scale := $ACTIVE-PARAMETERS=>map:get("scale")
  let $spiral-in := path:golden-spiral($density,$generations,$scale)
  let $width := rand:randomize($WIDTH)
  let $spiral-out := geom:translate(reverse($spiral-in),$width,$width)
  let $base-shape := ($spiral-in, $spiral-out, $spiral-in[1]) (: close loop :)
  for $i in 1 to rand:randomize($SEEDS)
  let $shape :=
    if (rand:randomize($REFLECT))
    then 
      geom:reflect($base-shape, 
        geom:point(0,0), 
        geom:point($CANVAS=>map:get("width"), $CANVAS=>map:get("height")))
    else $base-shape
  let $shape := geom:rotate($shape, rand:randomize($ANGLE))
  let $point := path:random-point($CANVAS)
  for $i in 1 to rand:randomize($ECHOES)
  let $mutant := geom:scale(geom:shear($shape, $i, $i), 1 - ($i - 1) div 10)
  let $shift := geom:translate($point,($i - 1)*2,($i - 1)*2)
  return (
    <art:spiral x="{geom:x($shift)}" y="{geom:x($shift)}">{
      art:points($mutant)
    }</art:spiral>
  )
};
        

Using a standard Fibonacci spiral path, with reflection and iteration

This is an area of active and continual development.

Experimental Framework

The general process for running tests is the same for each algorithm, to the point where I have abstracted a lot of mechanics into a standard template and set of support functions. A set of external variables define whether I am performing a new experiment or rendering a previous one, how many trials to generate, what customization layer to use, what changes to the default parameters to apply, and so on. A standard experiment driver is invoked, passing in the appropriate variables and two function arguments that create the core content and the metadata block, respectively. Outputs are tagged with a date and time stamp, a project label, and a variant label for alternative renderings.

A project generator then boils down to a set of standardized variables, a couple of functions that will be used as callbacks by the driver, and an invocation of the driver itself. Where the algorithm is reusing component shapes, paths, or systems from a previous project, it can become quite simple.

In order to allow maximum flexibility in running tweaks without having to edit the specific XQuery algorithm, both algorithm parameters and rendering parameters can be passed into generator as external variables. These are merged with the default set of parameters, overriding existing values with the same key, and preserving any non-shared keys, with the merged sets being passed on to the driver.

Colours, Gradients, and Visual Effects

It is always easier to track and manage parameterized and named design elements.

SVG provides for 150 named colours. That's nice, but I want more, including all the Emacs colour names. I created scripts to merge the base SVG colour names with the colours in the Emacs rgb.txt file to create an XSLT stylesheet with a colour table and a lookup function for each colour name. As a small bit of overkill, there is a named parameter for each colour name whose value is the RGB value of that colour or SVG native colour name. Other rendering stylesheets can reference colours via parameter names directly or via the lookup function. For example, the parameter named RoyalBlue3 has the value #3A5FCD. Passing a value of RoyalBlue3 as the background-fill value will invoke the lookup function to set the background to that particular shade of blue.

Automatic generation of simple gradients and styles by name is also provided. The stylesheet parameter palettes drives this. It is a space delimited set of names. A palette named simple-X generates a CSS class of the same name that produces strokes in the colour X. A palette named white-to-X generates a definition for a simple gradient from white to the colour X and a style to go with it. A palette named black-to-X generates a definition for a simple gradient from black to the colour X and a style to go with that. Any of the colour names can be used. So black-to-RoyalBlue3 creates a simple gradient definition from #000000 (black) to #3A5FCD (RoyalBlue3) and a CSS style of the same name. Elements in the DSL conventionally take a class attribute to attach such styling to the rendering of the component.

I make great use of the gradients created by Crameri. His purpose was to make gradients for scientific use that are perceptually ordered and uniform, while maintaining these properties in the face of colour-vision deficiency or even in black-and-white print. The perceptual uniformity and ordering make them pleasing in artistic works also. A couple dozen gradients are provided in a variety of formats, including SVG. I created stylesheets for each gradient which wrap the SVG gradient definition in an XSLT parameter with the same name. Each of the Scientific Colour Map gradients is quite large, with 512 gradient stops, so including them all in every generated SVG would be unwieldy. When the palettes parameter includes the given name, the corresponding definition is added to the SVG along with a corresponding CSS class, but not otherwise.

Several variations of all gradients are possible using naming conventions to reverse the sense of the gradient, to put the gradient against the y axis instead of the x axis, or to sweep both at the same time, or to create a circular gradient instead of a linear one. These simple variations are sufficient to capture most of the use cases, but it is always possible to use the project-style-defs stylesheet parameter, SVG passthrough, or the template override for the defs mode as an escape hatch. There is also a convention for naming each colour stop in a gradient.

<!-- gradients.xsl -->
  <!-- Each of these stylesheets contains one gradient definition: -->
...
  <xsl:include href="COLOURS/tokyo.xsl"/>
  <xsl:include href="COLOURS/turku.xsl"/>
  <xsl:include href="COLOURS/vik.xsl"/>
...
  <!-- Look up or generate SVG gradient definition -->
  <xsl:function name="art:gradient-definition">
    <xsl:param name="name"/>
    <xsl:choose>
      <!-- Named gradients -->
      <xsl:when test="$name='acton'"><xsl:copy-of select="$acton"/></xsl:when>
      <xsl:when test="$name='bamako'"><xsl:copy-of select="$bamako"/></xsl:when>
      ...
      <!-- Convention for simple gradients -->
      <xsl:when test="starts-with($name,'black-to-')">
        <xsl:variable name="stop-colour">
          <xsl:value-of 
            select="art:colour(substring-after($name,'black-to-'))"/>
        </xsl:variable>
        <svg:linearGradient id="{$name}"
          gradientUnits="objectBoundingBox" spreadMethod="pad"
          x1="0%" x2="100%" y1="0%" y2="0%"
        >
          <svg:stop offset="0%" stop-color="#000000"/>
          <svg:stop offset="100%" stop-color="{$stop-colour}"/>
        </svg:linearGradient>
      </xsl:when>
      <xsl:otherwise/>
    </xsl:choose>
  </xsl:function>
  ...
  <!-- Modify linear gradient (across x) to inverted gradient across x -->
  <xsl:template name="reverse">
    <xsl:param name="def"/>
    <svg:linearGradient id="{$def/*/@id}-reverse" 
      gradientUnits="objectBoundingBox" spreadMethod="pad"
      x1="100%" x2="0%" y1="0%" y2="0%"
    >
      <xsl:copy-of select="$def/*/*"/>
    </svg:linearGradient>
  </xsl:template>
  ...
  <!-- Modifying linear gradient to an inverted circular gradient -->
  <xsl:template name="inflow">
    <xsl:param name="def"/> 
    <svg:radialGradient id="{$def/*/@id}-inflow"
      gradientUnits="objectBoundingBox" spreadMethod="pad"
      cx="50%" cy="50%" r="50%"
    >
      <xsl:variable name="offsets" as="xs:string*">
        <xsl:sequence as="xs:string*" select="$def/*/*/@offset"/>
      </xsl:variable>
      <xsl:variable name="colors" as="xs:string*">
        <xsl:sequence as="xs:string*" select="reverse($def/*/*/@stop-color)"/>
      </xsl:variable>
      <xsl:variable name="opacities" as="xs:string*">
        <xsl:sequence as="xs:string*" select="reverse($def/*/*/@stop-opacity)"/>
      </xsl:variable>
      <xsl:for-each select="1 to count($offsets)">
        <xsl:variable name="i" as="xs:integer" select="."/>
        <svg:stop 
          offset="{$offsets[$i]}" 
          stop-color="{$colors[$i]}" 
          stop-opacity="{$opacities[$i]}"/>
      </xsl:for-each>
    </svg:radialGradient>
  </xsl:template>

<!-- param.xsl -->
...
  <!-- Pulled into the defs part of the SVG file -->
  <xsl:param name="global-style-defs">
    <xsl:variable name="gradients" 
      select="distinct-values(
        tokenize(concat($palettes,' ',$stroke-class),' ')[. ne ''])"
    />
    <xsl:for-each select="$gradients">
      <xsl:variable name="name" select="."/>
      <xsl:variable name="root" 
        select="replace($name,
          '(-reverse|-flip|-invert|-full|-anti|-outflow|-inflow)','')"
      />
      <xsl:choose> 
        <!-- Gradient across decreasing x -->
        <xsl:when test="ends-with($name,'-reverse')">
          <xsl:call-template name="reverse">
            <xsl:with-param name="def">
              <xsl:copy-of select="art:gradient-definition($root)"/>
            </xsl:with-param>
          </xsl:call-template>
        </xsl:when>
        <!-- Gradient across increasing y -->
        <xsl:when test="ends-with($name,'-flip')">
          <xsl:call-template name="flip">
            <xsl:with-param name="def">
              <xsl:copy-of select="art:gradient-definition($root)"/>
            </xsl:with-param>
          </xsl:call-template>
        </xsl:when>
        ...
        <xsl:otherwise>
          <xsl:copy-of select="art:gradient-definition($root)"/>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:for-each>
    ...
  </xsl:param>

  <!-- Pulled into the CSS style definitions part of SVG output: -->
  <xsl:param name="global-styles">
    ...
    <xsl:variable name="gradients"
      select="distinct-values(
        (tokenize($palettes,' '),$stroke-class)[. ne ''])"/>
    <xsl:for-each select="$gradients">
      <xsl:variable name="name" select="."/>
      <xsl:choose>
        <xsl:when test="starts-with($name,'basic-')">
          .<xsl:value-of select="$name"/> {
          stroke:<xsl:value-of
            select="art:fill(substring-after($name,'basic-'))"/>;
          stroke-linecap:<xsl:value-of select="$stroke-cap"/>;
          stroke-linejoin:<xsl:value-of select="$stroke-join"/>;
          stroke-opacity:<xsl:value-of select="$stroke-opacity"/>;
          <xsl:if test="$stroke-fill ne ''">fill:<xsl:value-of
            select="art:fill($stroke-fill)"/></xsl:if>
          }
        </xsl:when>
        ...
        <xsl:otherwise>
          .<xsl:value-of select="$name"/> { 
          stroke:url(#<xsl:value-of select="$name"/>);
          stroke-linecap:<xsl:value-of select="$stroke-cap"/>;
          stroke-linejoin:<xsl:value-of select="$stroke-join"/>;
          stroke-opacity:<xsl:value-of select="$stroke-opacity"/>;
          <xsl:if test="$stroke-fill ne ''">fill:<xsl:value-of
            select="art:fill($stroke-fill)"/></xsl:if>
          }
        </xsl:otherwise>
      </xsl:choose>
    </xsl:for-each>
  </xsl:param>
  

A similar, but less systematic scheme, is available for defined filters to provide various visual effects. In this case it is the stylesheet parameter effects that drives the inclusion of the various filter definitions and styles. Here the set of available effects is a growing ad hoc collection of interesting effects using SVG filters, such as drop shadows, glows, 3D lighting effects, splotchification, and so on.

Figure 14: Incised characters

Using colour-parameterized stone effect for background, incised effect on glyph strokes

Improving the tooling, the set of available effects, and standardizing on more of the key parameters is ongoing work. The tooling for filters is somewhat weak at the moment.

Embedded Metadata

One of the nice things about targeting SVG is that you can embed XML in other namespaces into it. I take advantage of this to embed metadata about the parameters and algorithms used to create the works as well as timestamping the various parts of the process.

One of the features of the layered stylesheets described in Domain-Specific Languages is the embedding of parameters into the final result. Recall the metadata mode base stylesheet template for art:canvas:

  <xsl:template match="art:canvas" mode="metadata">
    <svg:metadata>
      <xsl:apply-templates select="art:metadata"/>
      <xsl:if test="empty(art:metadata)">
        <art:metadata style="display:none">
          <xsl:call-template name="dump-parameters"/>
        </art:metadata>
      </xsl:if>
    </svg:metadata>
  </xsl:template>
        

The element art:metadata contains tracking information to be copied into the SVG output and augmented with a dump of the stylesheet parameter values. A named template called dump-parameters is defined in param.xsl. It copies the standard parameter values in a structured way. The template dump-parameters calls project-dump-parameters to dump project-specific information. Figure 16 shows the pieces.

<!-- render.xsl -->
...
<!-- Templates to copy metadata to output -->
  <xsl:template match="art:canvas" mode="metadata">
    <xsl:apply-templates select="art:metadata"/>
    <xsl:if test="empty(art:metadata)">
      <art:metadata style="display:none">
        <xsl:call-template name="dump-parameters"/>
      </art:metadata>
    </xsl:if>
  </xsl:template>

  <xsl:template match="art:metadata">
    <art:metadata style="display:none">
      <xsl:copy-of select="node()"/>
      <xsl:call-template name="dump-parameters"/>
    </art:metadata>
  </xsl:template>
...

<!-- param.xsl -->
...
<!-- Placeholder: specific project overrides -->
<xsl:template name="dump-project-parameters">
</xsl:template>

<!-- Called by main template for art:metadata -->
<xsl:template name="dump-parameters">
  <art:processed><xsl:value-of select="current-dateTime()"/></art:processed>
  <art:description><xsl:value-of select="$meta-description"/></art:description>
  <art:stylesheet-parameters>
    <xsl:call-template name="dump-project-parameters"/>
    <art:parameter name="stroke-class"><xsl:value-of select="$stroke-class"/></art:parameter>
    <art:parameter name="stroke-cap"><xsl:value-of select="$stroke-cap"/></art:parameter>
    <art:parameter name="stroke-join"><xsl:value-of select="$stroke-join"/></art:parameter>
    <art:parameter name="default-stroke-width"><xsl:value-of select="$default-stroke-width"/></art:parameter>
    ... 
  </art:stylesheet-parameters>
</xsl:template>
...

<!-- render-thread.xsl -->
...
<xsl:template name="dump-project-parameters">
    <art:parameter name="gap"><xsl:value-of select="$gap"/></art:parameter>
    <art:parameter name="drop-shape"><xsl:value-of select="$drop-shape"/></art:parameter>
    <art:parameter name="drop-fill"><xsl:value-of select="$drop-fill"/></art:parameter>
    <art:parameter name="drop-opacity"><xsl:value-of select="$drop-opacity"/></art:parameter>
</xsl:template>
...
        

What the XQuery algorithms put into the art:metadata element in the first place is a little less structured, because what counts as useful depends on the nature of the algorithm. The driver will dump out active algorithm parameters and current timestamp, and a library provides some common hooks for certain kinds of metadata:

In addition, complex components also provide methods to dump their metadata. For example, the glyph component used in the examples in section “Example: Lifecycle of a project” includes a method that dumps all its randomizers and settings.

declare function this:metadata()
{
  <art:metadata>
    {art:dump-randomizer("drops", $DROPS),
     art:dump-randomizer("drop-height", $DROP-HEIGHT),
     art:dump-randomizer("slot-jitter", $SLOT-JITTER),
     art:dump-randomizer("length-initial", $LENGTH-INITIAL),
     art:dump-randomizer("length-continuation", $LENGTH-CONTINUATION)}
  </art:metadata>
};
        

When the algorithmic metadata is combined with the stylesheet parameters metadata, we have, if not a complete picture of how a particular work was created, enough combined with the checkpointing of the code and the lab notebook to be able to reconstruct any particular effect. Figure 18 shows an example of the kind of information available.

  <art:metadata style="display:none">
    <art:description>drops: hanging drop threads</art:description>
    <art:created>2020-03-10T11:37:13.919025-07:00</art:created>
    <art:parameter name="slot-width">10</art:parameter>
    <art:parameter name="max-slots">71</art:parameter>
    <art:algorithm name="drops" distribution="uniform" min="2" max="20" cast="integer"/>
    <art:algorithm name="drop-height" distribution="uniform" min="5" max="30" cast="integer"/>
    <art:algorithm name="slot-jitter" distribution="uniform" min="-5" max="5" cast="integer"/>
    <art:algorithm name="length-initial" distribution="uniform" min="50" max="700" cast="integer"/>
    <art:algorithm name="length-continuation" distribution="normal" min="50" max="700" cast="integer" mean="rand:get-last" std="10"/>
    <art:description>ice: ice gradient background</art:background>
    <art:processed>2020-03-12T09:21:54.125418-07:00</art:processed>
    <art:stylesheet-parameters>
      <art:parameter name="gap">5</art:parameter>
      <art:parameter name="drop-shape">circle</art:parameter>
      <art:parameter name="drop-fill">url(#BlueGradient2)</art:parameter>
      <art:parameter name="drop-opacity">0.5</art:parameter>
      <art:parameter name="stroke-class">BlueSwoosh</art:parameter>
      <art:parameter name="stroke-cap">round</art:parameter>
      <art:parameter name="stroke-join">round</art:parameter>
      <art:parameter name="default-stroke-width">2</art:parameter>
      <art:parameter name="max-stroke-width">2</art:parameter>
      <art:parameter name="background-fill">url(#IceGradient)</art:parameter>
      <art:parameter name="background-opacity">0.3</art:parameter>
    </art:stylesheet-parameters>
  </art:metadata>
        

Having tracking metadata available also creates a virtuous cycle of refactoring. It encourages turning magic numbers in the algorithm into defined parameters and bothering to encapsulate components so that aspects of the design can be parameterized. In addition, the declarative intermediate representation of a particular work is much more searchable than either the target SVG rendering or a computer program. The fact that all parameters can be overridden without editing code reinforces this virtuous cycle, as well as making it easier to engage in fast cycles of experimentation. Automatic tracking of algorithmic parameters encourages preserving algorithmic variants, which makes recovering them likely.

Search

With this tracking in place, we can easily answer the question "Ooh, that's interesting, what were the parameters again?" Look at the source, see the tracked parameters.

Once you have accumulated a mass of works, the question sometimes shifts to "What works used this set of parameters?" or "What was I doing the first week of March?" or "What are the works involving asemic characters using a spiral layout?" Answering such questions requires the ability to search across a set of works using complex criteria and adding descriptive metadata as well as the parametric metadata. I use the XQuery metadata function hooks to add descriptive metadata, and store the source XML and rendered SVG in a database with XQuery and comprehensive search capabilities.

...
let $month-ago := current-dateTime() - xs:yearMonthDuration("P1M")
return 
  cts:search(collection("xml"),
    cts:and-query((
      "asemic character",
      cts:element-query(xs:QName("art:spiral"), cts:true-query()),
      cts:element-range-query(xs:QName("art:created"), "<", $month-ago)
    ))
  )[.//art:parameter[@name="resolution"]="medium"]
        

Figure 19 shows an example of a complex search mixed with XPath to fetch a set of source works. Notice how using a specific element (art:spiral) improves searchability over what raw SVG would provide. This search also shows the trade-offs with using a generic art:parameter element. If there were an art:resolution element, everything could be folded into the search directly without much fuss. On the other hand, then it would be harder to do things like Figure 20 where we fetch all the parameters at once.

...
doc("/experiments/20200314/20200314T215958_10_staves.xml")//art:parameter
        

Figuring out the right data model for navigating these tradeoffs is definitely a work in progress, as is the tooling and organizational systems to make it generally easier.