martinthomson
commented
1 day ago This tool works on a bunch of detection rules. In particular, lines are detected as a sequence of three characters. These problems can be fixed by making the line segment longer, for instance, text --| turns into text ---|. It is also possible in some of these cases to tweak things in other ways, like changing text --| to text --+. You will find that --| has a small gap, whereas --+ joins the lines seamlessly, so that might be the best choice.
One of the key things to understand about this tool is that its imperfections. Each represents a balance between detecting features and text. Altering that balance can have an effect on existing figures.
In general, I recommend trying to work around these. Most of these instances are pretty easy to work around. Like many things, authors really need to preview the output and adjust.
minor issue where the SVG is not as expected: "--" (in SVG) vs. a solid line (in SVG elsewhere, with the same input chars) for part of a horizontal arrow.
Examples from RFC 9594: Figure 7 on the right side, Figure 16, Figure 18, Figure 21, Figure 23 on the left side. (This difference is not significant within these figures; however, whether a line is dashed or solid could have an associated meaning in a different context. Maybe this just needs documentation, i.e., the input should be at least 3 chars if a solid line is the desired output.)
Background: Presumably the authors ran aasvg in order to provide SVG in the submitted XML. However, seems that the .md file in the repo was not the one used, as it doesn't invoke 'aasvg' for this artwork.