SVG support still very poor

[macfreek]

I just downloaded OmniGraffle 7 beta, just to check the level of SVG support. I just picked the first public SVG file that came to my mind, the OpenStreetMap logo. I was extremely pleased that it was imported as multiple editable objects. Unfortunately, it seems that the level of sophistication is still very poort. http://imgur.com/Sjo3zPO says it all.

I’m no expert in this field, but perhaps there is some “Acid” test available somewhere (like there was when CSS was created for webbrowsers).

[GraffleGuru]

Unit testing by the developer would be a good idea.

[kcase]

I’m no expert in this field, but perhaps there is some “Acid” test available somewhere

The reason we refer to the feature as “Basic SVG Import” is because we know it doesn’t support everything. The complete SVG standard is surprisingly complex, with a whole raft of completely different unrelated ways of parsing things. For example, the basic structure is XML, and you can apply styles as XML tags. But you can also apply styles using CSS, which is its own hugely complex standard involving tags, inheritance, etc. And to parse a custom path, you have to write a custom parser for yet another language that has its own idiosyncratic rules like letting you skip any punctuation or verbs that you could determine from context.

And, of course, the SVG standard is in the process of changing. Some of this helps simplify things, except that you still have to read stuff written in the old standard also so really it just makes things even more complex.

Which is not to say that we’re not continuing to work on it: we are. Just to let you know that our goal isn’t to have perfect support for all possible SVG files in 7.0. (For example, we currently don’t try to read text at all.)

Please do let us know where the current limitations are getting in your way, so we know what work to prioritize!

[macfreek]

Thanks @kcase for your detailed response.

I’m a network expert, so I am mostly interested in sharing network drawings in a common format. For Windows users, there is Visio, and Linux users typically use Dia or OpenOffice Draw. So for me, it would be even better if OG would support .dia or .sxd format. However, I rather have see that OG has proper support for one format, than broken support for many formats (of course, proper support for many formats would be sheer heaven in my universe).

The features I’m looking for are simple shapes (rectangles), embedded images (of network equipment and the like), and line drawings between these images, where the lines should closely follow the specified path (with multiple corners). also support for multiple text labels is essential. I don’t expect SVG to support the concept of anchors – that a line would ‘snap’ to a image or shape. (If it does, and OG would support that, I would be filled with joy and start dancing in the streets – wait, skip that last part. Given my dancing skills, that would be a Bad Idea). So lacking such a ‘magnet’ function, it would already be great if OG would honour existing groupings in the SVG file.

[GraffleGuru]

The reason we refer to the feature as “Basic SVG Import” is because we know it doesn’t support everything. The complete SVG standard is surprisingly complex, with a whole raft of completely different unrelated ways of parsing things. For example, the basic structure is XML, and you can apply styles as XML tags. But you can also apply styles using CSS, which is its own hugely complex standard involving tags, inheritance, etc. And to parse a custom path, you have to write a custom parser for yet another language that has its own idiosyncratic rules like letting you skip any punctuation or verbs that you could determine from context.

And, of course, the SVG standard is in the process of changing. Some of this helps simplify things, except that you still have to read stuff written in the old standard also so really it just makes things even more complex.[/quote]

All that is well and good.

The main problem is that XML, UML, SVG are not Standards. They are fraudulently labelled as “standards”, but they have none of the power or properties of a Standard. Your detailed explanation stands as evidence that SVG is not a Standard.

• For comparison, do look at genuine Standards. They have not changed, and they do not need to change. OLTP, OpenArchitecture, IDEF1X, have not changed since they were each published. They do not allow stupid things like, gee, you can do that 42 different ways. No, there is just one way.

• Truth does not change, it is permanent. Falsity is forever changing. And they need more falsity just to prop up the previous falsity. A cancerous monster, that demands your blood.

• SQL was a genuine Standard when it first came out, but the Committee is fighting each other, and over time, it has regressed to a non-standard. A free-for-all somewhat like XML, but not quite as bad.

• At best, XML and SVG are merely tag-value pairs, and the set of tags keep growing. Worse, they have not defined an Hierarchy (all data in the universe exists in an hierarchy). Therefore particular tags can be be placed in several different branches of the tree, and obtain the same result. And the tre is not stable.

• It is sickening that these freaks are allowed to get away with it. They are criminals.

Which is not to say that we’re not continuing to work on it: we are. Just to let you know that our goal isn’t to have perfect support for all possible SVG files in 7.0. (For example, we currently don’t try to read text at all.)

Good to hear. But that is on the Import side.

[quote]Please do let us know where the current limitations are getting in your way, so we know what work to prioritize!

The above applies to Imports. Macfreek has provided some direction and priorities.

My problem, the reason I can’t use OG-SVG, is on the Export side. The above does not apply to Exports. Export simply requires a developer who understands SVG tag-value pairs, and has the science to organise himself for the task: define an Hierarchy (once !); eliminate duplicates; etc.

• On the Export side, one simply needs to determine the subset of SVG, that is required for a drawing, and elevate that to an in-house Standard.

• For heavens sake, it can’t be that hard, the data.plist file is XML already !

• The problem is, as evidenced, that the OG developers each do their own thing, and there is no corporate-level or product-level standard for anything. The GUI interaction, the plist file, or the SVG Export.

  • I know this, because I have parsed the plist file (you guys have no idea re the real value of OG, but let’s not get distracted). It has exactly, precisely, the problems that you have detailed re why parsing an SVG file is an ever-changing nightmare.

• Your detailed explanation, when applied to the plist file, which has the exact same problem, stands as evidence that the XML in it is not a Standard. Likewise the SVG Export.

• (Actually there is a deeper problem: you do not have a Relational Database for the OG drawing, it is a pre-relational, pre-1970 record filing system. Or even a Relational mindset. But I won’t get into that here.)

All my diagrams are in OG. Some are complex, but most are simple (very technical, but simple, in terms of a drawing). So I need SVG for that, only. Nothing serious.

First, let me say that the SVG Export works, in the simple, core sense. But it does silly things …

1. SVG images
   When viewed in a browser, allow Hover. That is supposed to work like the Notes in PDFs before it was removed (it is not OG’s fault that Notes do not display in PDFs any longer). Therefore the Notes in each shape in the OG diagram, should show up as Notes when hovering over each shape in the SVG image in the browser.

• They don’t.

• What does show up in the Hover, is the LayerName. So every shape provides a Hover, whoopee, but the content is the same for every shape: LayerName. Ridiculous.

• As far as I am concerned, that is a bug, which demands fixing, it is not a new feature request.

Cheers