SVG Export object

[Richard Knapp]

After exporting a line plot to SVG, I checked the file. It is interesting the format uses the "path" instead of the "polyline". According W3 SVG, "path" is for shapes instead of lines. Used for a line, it still sometimes imports as a zero width shape instead of a line.

More an informational issue unless W3 changes how shapes are handled in an upcoming version.

[Olly Betts]

It's been like that since first added nearly 15 years ago in bef66af356424806cb818f7b96839d69ee412ca6. It would be fairly simple to change, but would make exported SVG files a bit larger.

However, looking at the SVG 1.1 spec I'm not sure this is an invalid way to use path - it seems to me that we're drawing "open shapes", and there's actually an example in the spec showing a line drawn using path:

​https://www.w3.org/TR/SVG11/images/paths/arcs01.svg

(I don't see how you can draw a line containing curves like that example does without using path.)

Used for a line, it still sometimes imports as a zero width shape instead of a line.

We should be wrapping the centre-line data with a g element which specifies a non-zero stroke-width and that should be inherited by elements within the g that don't override this.

If that's not happening maybe it isn't actually use of path that's the problem. Can you provide an example file and application which fails to import it suitably?

[Richard Knapp]

That all makes sense. I was having a lot of trouble importing and rotating the SVG from survex into OmniGraffle?. However, this may be an issue with an open ticket in OG and rotating lines. Noticed most with small SVG (one survey trip worth of data) the SVG would break apart. I think I saw this in InkScape? too but I didn't use it long enough to troubleshoot to see what I was doing incorrectly.

With more survey data, the problem seems to have gone away.

I agree that curved lines require a shape element; just though the survey line would be simpler with a poly. If not, not big deal.

Seems the spec started uwing the path, then they added the poly line later.

Thank you for looking into this and, again, thank you for an excellent app; it has saved my but at least once already with the robust data encasuplation.

[Olly Betts]

OmniGraffle seems to be proprietary. If you can explain how to reproduce with Inkscape I can easily take a look though.

just thought the survey line would be simpler with a poly

It's actually not - for a single leg path vs polyline looks like:

<path d="M11505.840 -9461.200L11509.940 -9445.300"/>
<polyline points="11505.840,-9461.200 11509.940,-9445.300"/>

Also currently we can pack multiple disconnected pieces of survey together into one path:

<path d="M11505.840 -9461.200L11509.940 -9445.300M11502.200 -9071.880L11494.960 -9070.980"/>
<polyline points="11505.840,-9461.200 11509.940,-9445.300"/><polyline points="11502.200,-9071.880 11494.960,-9070.980"/>

[Olly Betts]

It seems the conclusion here might be that this is down to a known Omnigraffle bug.

If that's been fixed, is it working in Omnigraffle now?

And/or can you reproduce in inkscape?

[Olly Betts]

Pasting email reply here to keep the discussion in one place:

I have not had this problem in a long time but both Survex and OmniGraffle have gone through revisions. I think OG was at version 7.13 and I am now at 7.18. I had reported the issue to OmniGroup but there are so many outstanding issues with OG, my focus has been on other things that aren’t working.

I was playing with InkScape (and CorelDRAW) to see what app I was going to use for the map. I haven’t used InkScape for anything since 2019. For me, OG is much faster and easier to use.

Can this one be put in a “hold” state in case it pops back up?

Just imported SVG into OG and rotated it with no problems.

We don't have a "hold" state as such, so I'll resolve as "worksforme" - the ticket will still turn up in searches, and we can reopen it if you or someone else sees a recurrence.