Open keenancrane opened 2 years ago
Related: #541
For the formatting/prettyprinting, could walk the dom tree with https://developer.mozilla.org/en-US/docs/Web/API/TreeWalker
Related: #1129
Also, as of #864, we use Prettier to format the SVG files.
@samestep that's not bundled right, just the automator? because we really just need indentation and newlines, definitely shouldn't put prettier in the browser.
@maxkrieger Ah yes, you're right.
svgo is a library that optimizes SVG trees. Although it claims to be node-based, looks like other made it work in the browser: https://github.com/jakearchibald/svgomg.
One other note on CSS classes: when you have multiple images on the page, the CSS classes like st0
can conflict with other images. See #1307.
Currently our SVG output is quite a mess:
We can do a lot better! (See especially the final section below for the type of output we might want to aim for.)
There are two distinct ways we can improve it:
The first item is more or less a matter of running the output through some XML formatting package like this one. As for (2), there are several ways to improve the document structure:
These items are elaborated on below.
Clean up the garbage
Currently we emit a lot of SVG code that is unused. For instance, we repeatedly emit code for a Gaussian blur effect applied to (I think?) a path or arrowhead—see below. The idea was probably that this code needs to be available in case the Style program needs it. But we should definitely emit this code only on-demand, i.e., if it's actually used, rather than by default.
Eliminate redundant code
Things like markers are repeatedly written into the SVG file for instance; we should write these once, and then use them by reference (i.e., via instancing), which may still require that we write a per-instance transformation.
Use CSS styles
Currently many shape attributes are repeatedly defined inline, in the shape tags themselves. SVG allows one to include a CSS block at the beginning that defines a collection of styles, then refer to these styles from individual shape tags. Consider for example this illustration, and corresponding SVG code:
Re-using styles becomes more valuable as the styles get more attributes (color, stroke color, stroke width, mitering, etc.).
Moreover, encapsulating styles in CSS enables users to modify many style attributes without recompiling/re-running Penrose.. For instance, in the example above the color of many circles can be updated by changing just a single color string. This ability makes Penrose diagrams even more useful, e.g., in scenarios where re-running Penrose is impossible (say, due to lack of support on a given platform) or infeasible (say, due to real time constraints).
Hierarchically group elements / Give elements meaningful names.
Related to #783, our current SVGs are just a linear dump of shapes, whereas SVG allows hierarchical grouping of shapes via the
<g>
tag.. Both automatically organizing shapes into groups (e.g., grouping shapes that come from a common Style rule) and/or giving Style programmers the ability to specify grouping (a la #783) would go a long way toward improving SVG structure.Likewise, adding meaningful names (derived from things like Domain names and notation, Substance identifiers, Style GPI names, and so on) would make it much easier to inspect and edit files either at the source code level, or in an external tool.
A good example of both nice grouping and nice naming is this file generated by a little home-brewed utility called
obj2svg
(which converts a 3D Wavefront OBJ mesh file into a 2D SVG drawing):Here's what this file looks like when you load it up into Illustrator:
Notice in particular how elements are nicely grouped and nicely named—making it easy to perform high-level edits. Here for example I selected the set of front-facing edges and colored them pink (originally gray in the SVG file).