P.S.

I had a typo in my previous comment from July 15th, sorry for that:
"- work flow 1: one-way import from SVG, all subsequent editing will be done in ILLUSTRATOR:
try to convert most of Inkscapes primitives, strip of annotations"
My group (would like to) use both work flow 1 and 2.

Best Ben

This is encouraging, Dirk!

I understand the predicament here. As a low-hanging fruit, I suppose a warning alert ("Are you sure you want to trample onwards" with a "don't show this again" checkbox) might appear if you do something in AI which destroys some incompatible third-party structures.

"most-minimal-destructive" sounds great in the long term!

Hi Friedrich,

Thanks a lot for your feedback. We definitely have the 2nd workflow and especially the most-minimal-destructive preservation part on our long term roadmap. And we will consider keeping the document structure, author data, meta data and styling information as untouched as possible. (A truly round-tripping experience.) This may take us some more time though.

If there is any low hanging fruit that we can do in the short term that would have an immediate impact to your workflow we would be very interested in that.

I wonder what benefits you see with workflow 1, the pure import workflow. What information would you like us to keep? How is it different from workflow 2?

Greetings,
Dirk

Dear Dirk,

I am replying to your comment from July 15th.
While I do not feel competent to give my final answer to your design question, I think it is important to ask the user about its work flow, i.e.
- work flow 1: one-way import from SVG, all subsequent editing will be done in Inkscape:
try to convert most of Inkscapes primitives, strip of annotations
- work flow 2: two-way import from/to SVG, only minor editing will be done in Illustrator, most subsequent editor shall be done in Inkscape again: try to modify SVG as little as possible
I commonly encounter both work flows when I collaborate with colleagues.

Hello Benjamin,

I share your frustration and we are constantly improving the import of SVG into Illustrator.

A question to you: As mentioned, InkScape preserves its own primitives in the SVG file while providing a fallback for non-InkScape viewers and authoring tools. What would be your expectation to Illustrator when you modify an element that has InkScape primitives that might no longer be valid with the changes from Illustrator? Should Illustrator remove those annotations actively? What if the annotations from InkScape are still valid even with the change from Illustrator? Is it still ok to remove the annotations/primitives?

Greetings,
Dirk

Dear Dirk,

Thanks for your detailed answer.
For users it is always confusing if essentially different file formats (here "SVG compatible fallback" and "InkScape enriched SVG ") have the file ending ("svg").

Illustrator could offer different import/export options for these different versions of SVG.
I wish developers would pay more attention to the fact that users do not use one single monolithic application to get a job done: I am importing SVGs from Matlab, mathematica, codecogs, ... into Illustrator, collaborate with colleagues using only InkScape, to create one single figure in the end. Import/export is crucial.

Best wishes
Benjamin

Hi Benjamin,

I understand the issue that you are facing and I understand the request to support "a simple round-trip" experience for SVG.

However, there are a lot of things to consider:
* SVG has a very limited set of features considering the complexity of most illustration applications even beyond Adobe Illustrator. Every authoring tool has a different way to handle the limitations.
* InkScape uses its own namespace to enrich SVG documents with the features that go beyond the capabilities of InkScape and provides a fallback for SVG compatible implementations.
* Illustrator, as any other SVG consuming application but InkScape itself, is only able to understand the SVG compatible fallback.

Even if Illustrator would try to keep more metadata from the originally imported SVG document and you do edits to the SVG document in Illustrator, those would not play nicely with InkScape since Illustrator would really only modify the fallback but not InkScapes enhancements.

As said, InkScape enriches the SVG document with its own capabilities. However, this really just makes the SVG document an InkScape specific file format like Illustrator's own .ai file format. Since the feature set of both applications are very different, a fulfilling round-trip experience won't be possible.

Just like InkScape, you can preserve Illustrator's capabilities in SVG as well and Illustrator provides a fallback rendering for all SVG compatible implementations. InkScape runs into the same issue when opening such an SVG files from Illustrator as it is the other way around.

Therefore, Illustrator considers SVG more of an export format than a native file format. To clarify, this is not a reason of Illustrator being older than SVG but a way to handle the limitations of SVG.

I hope that clarifies the issue and explains why keeping more metadata on round-tripping wouldn't actually solve the issue you are facing.

Greetings,
Dirk

Illustrator seems to wreck a lot of things when importing SVG, regardless of where it originated. Its habit of changing css, classnames etc. is infuriating.

I fully understand there are legacy reasons why this has happened, since Illustrator predates SVG, but it begins to look like poor strategy in the post Flash, responsive-design century.

Illustrator is currently a liability for the integrity of any SVG roundtrip work. It's fine for originating markup, but falls very short if that markup is going to be tweaked or manipulated by other tools.