These are diagrams I have written in SVG for use on diverse web pages, usually of mathematics or physics. They are all copyright me, of various dates, ©2007–2015.

[ICO]NameLast modifiedSizeDescription
[PARENTDIR]Parent Directory  -  
[IMG]transpyth.svg2024-07-28 12:12 2.2K 
[IMG]tradsqr.png2024-07-28 12:12 1.3K 
[IMG]tradhyp.png2024-07-28 12:12 1.9K 
[IMG]torque.svg2024-07-28 12:12 2.9K 
[IMG]similar.svg2024-07-28 12:12 1.9K 
[IMG]shear.svg2024-07-28 12:12 2.2K 
[IMG]secantofc.svg2024-07-28 12:12 1.2K 
[IMG]scatter.svg2024-07-28 12:12 1.6K 
[IMG]pythint.svg2024-12-12 02:00 7.4K 
[IMG]pythcircles.svg2024-07-28 12:12 17K 
[IMG]pythanim.svg2024-07-28 12:12 3.9K 
[IMG]pythagoras.png2024-07-28 12:12 1.5K 
[IMG]missionstatement.svg2024-07-28 12:12 691  
[IMG]intervals.svg2024-07-28 12:12 4.9K 
[IMG]hexity.svg2024-07-28 12:12 15K 
[IMG]fifty-three.svg2024-07-28 12:12 4.0K 
[IMG]conic-axes.svg2024-07-28 12:12 3.9K 
[IMG]colour-cube.svg2024-07-28 12:12 24K 
[IMG]cocentric.svg2024-07-28 12:12 2.4K 
[IMG]chop.png2024-07-28 12:12 2.7K 
[IMG]best3of4d6.svg2024-07-28 12:12 5.7K 
[IMG]anathem.svg2024-07-28 12:12 1.0K 
[IMG]alternating.svg2024-07-28 12:12 6.4K 
[TXT]README.html2024-07-28 12:12 8.6K 
[IMG]KerrRadius.svg2024-07-28 12:12 1.5K 
[TXT]HEADER.html2024-07-28 12:12 184  
[IMG]Euclid.svg2024-07-28 12:12 1.3K 
[IMG]3d6.svg2024-07-28 12:12 5.7K 

Cricicisms of SVG

While I like SVG as an image format, the spec has some gaps in it that I find frustrating. Not quite frustrating enough to define my own XML grammar along with an XSLT and some scripts to JIT-compile it into SVG, but I'm sporadically tempted. I suspect many of my grumbles come down to a common root cause: I write SVG by hand where much of the spec is driven by suppliers of WYSIAYG graphical software, who are far less concerned with duplicative work. Some of these complaints below may be user error, of course: I may simply have failed to find the right way to do the things I want – if you know how to solve the problem I failed to solve, I'd be very happy to hear how !

Individual points

I would have liked a point element (that I can animate to follow a curve, e.g. a circle) together with the means to specify a line, figure or transformation in terms of its current position. Then, in my animated proof of pythagoras I would only have needed to animate the point at which a right-angle triangle has its right angle vertex, ideally by specifying a circular curve (with the hypotenuse as diameter) and an angular speed. All other variable geometry would then be computed from that (and would be necessarily correct). Instead, I was obliged to construct lists of floating-point co-ordinates (suitably rounded) for every part of the whole geometry. Not pretty (and visibly slightly wrong in places, invalidating the proof).

It'd also sometimes be nice to have point elements so that I can share them between diverse figures, e.g. specifying one as start attribute for a line in place of its x1 and y1 or an end in place of x2 and y2. (Speaking of which, I'd have liked the notation better if the start had been 0 and the end 1, rather than 1 and 2; this would fit nicely with the natural parameterisation of a line as an image of the unit interval in {reals}.) I realise that the spec's authors were keen to support compact representations, which attributes handle well, but it would be nice to also have a dual path where the same data as is presently in attributes may instead be specified via content of the element, e.g. a polygon element having point elements as children in place of its points attribute. For a path's data, it would make sense to have a data child element, with a d attribute matching that of the path, and allow the last directive in this to omit a final x y pair, implicitly using a following point for these values. It would likely be necessary to forbid providing both an attribute and the corresponding content for a shape element.

Markers

When I use a triangular marker on the end of a line, as an arrow-head, I want to specify the line as ending where it officially ends and have the tip of the arrow head appear at that point; but then the line's cap (which always reaches to the full width of the line at the end-point, optionally with a shaped extension beyond) protrudes outside the (triangular) tip of the marker. It's only by the line-width, but I can see it. To hide the line's cap, I have to position the marker just a little forward from the line's actual end, so that the triangular tip is as wide as the line at that point; I am then forced to chose between the line formally ending a little way short of where it should (which is both messy to compute, at times, and semantically improper for the geometry I'm so carefully depicting) so that the arrow tip is displayed in the right place, or having the line semantically correct but with the arrow's vertex protruding just a little beyond the point where it should be. Neither of these is a good solution: my diagrams describe geometry, so the line should start and end at the points that mean something for the geometry, not just a little short of there; and the graphical representation (i.e. the arrow head) should end there, not just a little beyond it. I can probably do something funky with clipping, applied separately to each line using the marker; or I can use a stroke-dasharray to skip the relevant short part of the line; but either solution involves ugly repetition of the same work. This could be fixed by having a stroke-linecap value that either makes the line stop (visually) before its (formal) end-point or makes it taper to a triangular tip; either would need a length specifier (at each end) to control that (and we're getting into repetitive work again). It would be better, however, to have some way for the marker itself to specify a clipping region (relative to its own bounding box) that gets applied to the line on which the marker is used. (In principle, this might clip somewhat outside the marker's bounding box, too; e.g. a marker-mid might want to clip the line it's on to shape the line just before and after it.) In the case of an end-arrow, this would simply mask out the line within the arrow's bounding box, so that the last part of the line is replaced by the arrow.

An end-arrow also has the problem that its orient="auto" is specified relative to the direction at the end of the line while its orientation otherwise is specified absolutely as an angle relative to the X-axis. When a circular arc ends in an arrow-head (as happens quite a bit in geometric diagrams), if the arrow-head covers a part of the arc that subtends a non-tiny angle about the circle's centre, the head looks wonky, since the arc isn't perpendicular to the back edge when crossing it; it doesn't even cross at the mid-point of the back edge. I can fix that by setting the marker's orient explicitly (on the marker), requiring a separate marker for each direction that any arc ends in; or I can define the marker at a wonky angle within its viewBox, requiring a separate marker for each ratio of stroke-width to arc radius. I could also fix it by stopping the line short of where I actually want it to stop and using the entry-point of the arrow, instead of its tip, as reference point; but see the line protrudes past the front of its arrow problem, above, for why I don't like the broken semantics (and ugly computation) this implies. I'm not sure what the best solution to this might be; one option would be to specify two reference points, one as at present for where on the marker the line ends, the other for where it enters the marker. Another would be to specify, where the marker is used, a tweak to its orientation, relative to what's specified on the marker itself (so the marker can say orient="auto" and I can tweak that by a few degrees).

If I use an arrow as a marker-mid on a polygon or polyline, its orient="auto" is determined by the angle bisector of the two edges, which is good for some things but makes it tricky to have each edge of the polygon end in an arrow in that edge's direction, ignoring the other edge. I would seem to need to draw each edge as a separate line with a marker-end or have a custom marker for this purpose, that's set skew at half the turning angle of the corner (and then, for an irregular polygon, I'll need one such marker per vertex angle).

I have to set a marker's colour where I define the marker; I can't see a way to do so at the point where it's used. This means I need a different arrow-head for each colour of line on which I want to use one. It would make sense for color="inherit" on a figure within the marker element to mean it inherits from the line to which the marker is applied, but this isn't what I get when I tried it (in Opera, Chromium and Vivaldi). Perhaps I'm doing it wrong or missing something.

I like that a marker scales with the width of the line on which it's used; but it'd be nice to be able to over-ride that, too, at the point of use, e.g. to make one arrow head be twice as big as the rest, without having to define a separate arrow-head just for one use. This, along with some of the parts above, might be better handled by having markers be content of line elements instead of attributes, so as to allow for specifying assorted properties of each marker using the usual properties, transform, fill and so on, instead of needing marker-end-, marker-start- and marker-mid- versions of each. Compare the similar remark, above, about points as content of an element.