I have run into a bug in a diagram created on diagrams.net. When the file is opened in Inkscape, text is truncated and this error message is embedded in the file: "Viewer does not support full SVG 1.1"

I'm not the only one to encounter this bug. diagrams.net explains the bug here https://www.diagrams.net/doc/faq/svg-export-text-problems 

According to diagrams.net, the bug is due to its use of the ForeignObject coding for text in diagrams.net svg.

Why does Inkscape not implement the full SVG 1.1 specification? This limitation affects compatibility of file exchange with other applications.

The full spec is large and not all features will be supported by Inkscape. 

There may be workarounds, or follow the guidance by the diagrams.net team:

...disable formatted text and word wrapping for all labels in your diagram before you export it to SVG by following the steps below.

1. Right click on a blank area of the drawing canvas, then choose Select All from the context menu.
2. In the Text tab of the format panel, uncheck the Word Wrap and Formatted Text.

Note: When you disable these formatting options, you can still style the label text as a whole. You can not apply different formatting to parts of the label. When you disable word wrap you may have to add manual linebreaks to match the previous output.

The the guidance by the diagrams.net team does not always work.

It seems to me that since text is pretty common in graphics, Inkscape might make implementing the complete text-related spec a priority.

This is not about text as much it is about foreignObject support.

Depending on your design, it might be straightforward to use Inkscape/SVG text instead of embedding xhtml just to get text.

Why is this being imported into Inkscape, instead of finishing in diagrams.net? 

Similarly, have you tried importing into Illustrator, Corel or Affinity?

As @TylerDurden says, this is about <foreignObject> rather than just text. In theory foreignObject allows any XML content to be embedded in an SVG file, not just XHTML text content - but you can't expect Inkscape to support every possible language. Even if we just restrict the scope to XHTML that basically means implementing the core rendering engine of a browser inside Inkscape, and also implies a full CSS parser and engine. But HTML & CSS now is vastly more complex than it was 20 years ago - and getting more complex every year (at least in the case of CSS). Web browsers are huge applications, well beyond anything the small Inkscape team could possibly implement.

20+ years ago there was a push towards compound documents, whereby a single document could be created by combining multiple different document types. Microsoft's Object Linking and Embedding (OLE) or Apple's OpenDoc format epitomised the idea: instead of having a single monolithic program that would do everything, you would have lots of smaller programs, each focusing on a specific file type, which could be combined to form the final output. It's a powerful approach in theory, but not without its problems (e.g. what happens if the user doesn't have the required application to view one part of the file, or if they are using a different viewer program than the author did?). As such, this approach never really took off outside of specific closed cases, such as OLE between applications within the MS Office suite.

<foreignObject> was an attempt to make this sort of functionality available to SVG, but it only works if your viewer understands not only SVG itself but also the content of the foreignObject tag. So, in practice, it only works in web browsers - and that's just an odd side-effect of them supporting SVG natively. In a browser, ironically, the SVG is really the foreign content, whereas XHTML in a <foreignObject> tag is actually the native content!

In theory the Inkscape developers could perhaps use an OLE type approach to pass the foreignObject content out to an HTML library, and render the result in the page. But that's complex, and glosses over the difficult questions around how the content should relate to the SVG around it. If there was a huge amount of XHTML in <foreignObject> on the web then perhaps it would be worth the effort, but there's not. For most users the (limited) text formatting offered by SVG itself is sufficient.

Thanks, Xav. It makes sense that diagrams.net has optimized for the Web, as it is primarily browser-based.

Are there any svg editors that can open and edit files with the <foreignObject> attribute, other than diagrams.net, or is this peculiar to diagrams.net/draw.io?

Please share an example diagrams.net svg file and we can check it out.

This one was created in diagrams.net, could not edit it in Inkscape because the text in the text boxes became truncated ("Viewer does not support full SVG 1.1" error).

(It's a technical diagram for a medical journal.)

tigrisoculus

It makes sense that diagrams.net has optimized for the Web, as it is primarily browser-based.

Call me a cynic, but I don't think they've optimised for the web at all. I think they've optimised for the web that the W3C dreamed of in 2001, that never really came to pass - and just never updated their code for the web we've actually got.

There's nothing in the file you've shared that couldn't have been implemented in pure SVG, without requiring <foreignObject> content at all. And even the foreignObject code that is there doesn't look terribly web-friendly to modern eyes: it uses obsolete parts of XHTML (e.g. the <font> tag), rather than content that would be expected in a modern web page. While the rest of the web world has moved on, the file you've provided is clearly - and unnecessarily - based on the state-of-the-art back in the early 2000s. The fact that it works in a web browser is due to browsers maintaining backwards compatibility for old standards, not because the file is "optimised for the web".

Someone with sufficient knowledge of XSLT (a standard used for mapping one XML language to another) could probably throw together an XSLT file that could convert the <foreignObject> blocks into plain old SVG <text> elements - but that's reasonably obscure knowledge that isn't common amongst developers now. Even with such a file you would need a suitable toolchain to apply the transformations to the original document and spit out something new.

Realistically I can't see any way to get the text to be editable in Inkscape without either recreating it, or without someone putting some serious programming time into a method of converting the <foreignObject> content. That could be via XSLT or some other external process, as an import filter, or via an extension, but all of them would need significant work to implement.

Neither diagrams.net nor Inkscape are to blame for this incompatibility - they're both using the XML standards in the right way, it's just that their capabilities don't overlap enough to be able to cross-edit each other's files. I do think the onus is on the former to perhaps look at offering a pure SVG export option, though.

My testing with software to open the file from diagrams.net, with all text intact:

• Illustrator - no
• Corel - no
• Affinity - no
• Inkscape - no
• Scribus - no
• SK1 - no
• LibreOffice - no
• Gimp - no
• Google Draw - no

tigrisoculus

The the guidance by the diagrams.net team does not always work.

I would let them know and ask if any more can be done on their end.

Thanks so much for your help. Xav's explanation seems very plausible.

I contacted support@draw.io, which forwards all its mail to jira@drawio.atlassian.net (the free app's corporate owner) and got nowhere. I had no idea draw.io svg was universally incompatible.

If anyone has the energy to let them know of the extensive testing done by the fine people here on the svg their app produces, please feel free to inform them, you'd be helping users and improving the app ecosystem.

Ah, I didn't realise this was an Atlassian thing. Originally I wrote:

Xav

Call me a cynic, but I don't think they've optimised for the web at all. I think they've optimised for locking the files up in their own ecosystem while still being able to claim that they're using an open format.

I changed my wording after looking briefly at the site and realising you didn't need to set up an account to use it, so I mistakenly thought it was a completely non-commercial operation. But my (limited) experience with Atlassian software is that they very much want to lock you into their ecosystem and get you to buy more of their tools. Of course, as is the way these days, it's on a subscription basis: a few dollars per user per month quickly grows to a lot of money as a business expands and they have little choice but to opt new users in to a whole suite of tools they don't need in order to be able to share content with the rest of the company.

I'm not suggesting that Atlassian are doing anything wrong or immoral. They're just following the current "Software As A Service" trend in enterprise software deployment; it's just a trend I'm not very keen on. But I suspect that making files easier to get out of their ecosystem won't be a high priority for them.

Edit: One thing I really don't like is their claim that the "viewer does not support full SVG 1.1". I think this is deliberately misleading, if not downright dishonest, and a clear effort to try to shift the blame to Inkscape and other SVG programs for deficiencies in their own files. Yes, <foreignObject> is part of SVG 1.1 - but as I mentioned above, it's basically a way to embed any other XML language into SVG.

There are XML languages for many, many things - the LibreOffice/OpenOffice formats are XML documents, for example, as are the more recent Microsoft Office formats. There's MusicXML for describing Western music. If I was to embed a complex LibreOffice spreadsheet into an SVG file, I wouldn't expect any program - not even a web browser - to magically be able to work with it and allow it to be edited. If I embedded some MusicXML content I wouldn't expect to hear sound coming out of my speakers when I load the file into Firefox. Atlassian blaming other programs for not supporting "full SVG 1.1" is no more honest than if I made that claim of a web browser that won't edit my spreadsheet-in-a-vector-image document.

draw.io Google Group says

 

You can disable the use of foreignObject by clicking here: https://app.diagrams.net/#_CONFIG_UzV3UjUyyk0tSk8F0qrGjqpggeLM3IKcVJ/EpNScYoh4SVFpqqq5CxABAA==

My impression is that the diagrams.net developers have little interest in improving the compatibility with other editing programs. The online app serves as a reasonably good addition to the online collaboration tools that Jira supplies. They might be more interested in adding the functionality that users might be seeking from programs like Inkscape, but the program is a sidecar to the collaboration tools that make the big corporate dollar, so "good enough" is where diagrams.net will aspire to be. 

Not that different from Google Draw or Slides... they are passable, and contribute to the value-add of the Google workspace, but don't expect them to be Illustrator or PowerPoint killers.

Despite the code being open, the development is closed.

Open-source, not open-contribution

Similar to SQLite, diagrams.net is open source but closed to contributions.

The level of complexity of this project means that even simple changes can break a lot of other moving parts. The amount of testing required is far more than it first seems. If we were to receive a PR, we'd have to basically throw it away and write it how we want it to be implemented.

We are grateful for community involvement, bug reports, & feature requests. We do not wish to come off as anything but welcoming, however, we've made the decision to keep this project closed to contributions for the long term viability of the project.

https://github.com/jgraph/drawio

I agree with Xav that the message about not supporting the full spec is a dick move... they don't support the full spec either (nobody does), and are distracting from their export deficiency.

My guess is the diagrams.net developers do not know why an export to svg has been enabled. Maybe somebody added it a long time ago and moved on. Meanwhile, nobody thought very deeply about the function of the export and why users might want svg compatibility with graphics programs -- though the truncated text box issue has come up in their forums (and elsewhere) before. So clearly diagrams.net users are going off the reservation with the svg.

There's also this when starting a new diagram

diagrams.net will edit its own svgs when the XML embed is enabled in the export.

I would not have delved into this except one of my colleagues created a diagram (not a flowchart) important to our project in diagrams.net and we wanted to shade an overlapping part of it, which we could not do in diagrams.net. So I exported a duplicate svg to Inkscape and found the text to be truncated with the "Viewer does not support full SVG 1.1" message.

The diagrams.net people got mad when I kept on asking about svg. I honestly thought their app created and edited svg and I was encountering bugs.

Still, perhaps in response to my questions, a developer provided this kludge:

 

You can disable the use of foreignObject by clicking here: https://app.diagrams.net/#_CONFIG_UzV3UjUyyk0tSk8F0qrGjqpggeLM3IKcVJ/EpNScYoh4SVFpqqq5CxABAA==

Apologies for the implication of the fallback text. We've changed it to "Text is not SVG - cannot display" from the next release.

davidjgraph

Apologies for the implication of the fallback text. We've changed it to "Text is not SVG - cannot display" from the next release.

That's a great outcome, thank you for doing this.

(Of course, even better would be to use native SVG text where possible, but I appreciate the vast amount of work that would entail compared to just changing a string, so I applaud you for at least doing something, rather than ignoring this altogether)

It's not possible, no. We've a huge historical set of shapes that use HTML for complex labels.

draw.io isn't an SVG editor and didn't have an SVG export for many years. It just happens to render using SVG DOM and it seemed like a cheap export to add.

What we are looking at is an option to convert text to paths by exporting to PDF and importing that to Inkscape server-side. It's a pain to build always available and secure server-side functionality on a free app, which is why we resisted. But users don't really care about excuses, they want it to just do everything (TM) :).

Well... on a positive note... when there would be enough community wanting to implement lacking features in draw.io - the whole philosophy of open source software is that you also have the right to fork the project. This is not an aggressive move is a project is not open to contributions. It also relieves the burden from Atlassian developers, who can choose to integrate the fork if they saw this as the better product (or even merge the fork back into their own product). The Apache license is clear about this.

Note though that this is a pretty big challenge - taking something like this up lightheadedly may result in hurting the open source movement ("you see: a bunch of amateurs took over, and now it's dead in the water").

I am glad though that Atlassian took over this project, as it otherwise would probably have been abandoned - and certainly wouldn't have gotten the popularity it gained by being part of Confluence and JIRA.

JurgenG

implement lacking features in draw.io

This depends on your viewpoint. The scope of draw.io isn't intended to be an SVG editor. If someone wants to fork the project and create an SVG editor, please do.

JurgenG

I am glad though that Atlassian took over this project, as it otherwise would probably have been abandoned - and certainly wouldn't have gotten the popularity it gained by being part of Confluence and JIRA.

Let's just clarify the draw.io project has always been a 1.5/2 person open source project and has nothing to do with Atlassian. Atlassian does not own it, nor have they ever contributed anything towards it.

davidjgraph

This depends on your viewpoint. The scope of draw.io isn't intended to be an SVG editor. If someone wants to fork the project and create an SVG editor, please do.

I fully agree... often forks are born out of new desires/use cases for existing projects. I don't think replacing the XHTML with sVG alternatives would turn it into an SVG editor... I would rather compare with someone moving from Python2 to Python3 to futureproof a project.

davidjgraph

Let's just clarify the draw.io project has always been a 1.5/2 person open source project and has nothing to do with Atlassian. Atlassian does not own it, nor have they ever contributed anything towards it.

Ouch... my apologies. I wrongly deduced from this thread that the project was taken over by Atlassian. I'm guessing I won't be the only one then. Thanks for setting that straight. I just wanted to express gratitude to the people (or company) maintaining the current project. I've seen too many nice projects ending up in github-desert because the original developers didn't have the incentive to maintain it anymore. Then I'd rather see it being picked up by a company over it dying.

Thanks to the 1.5 to 2 persons for putting your love and sweat in the program. It's highly respected.

davidjgraph

Apologies for the implication of the fallback text. We've changed it to "Text is not SVG - cannot display" from the next release.

Thanks, davidjgraph. That will save some confusion.

I don't understand the relationship between Atlassian and draw.io. Any mail to draw.io goes to Atlassian, and is answered by Jira support, who don't want to bother answering questions about draw.io. Because I was confused and kept asking about compatibility, I got blocked by them in draw.io forums, too. 

So draw.io is a standalone app with its own 1.5--2-person development team, to which Atlassian refers its customers for diagramming? If anyone has an avenue to the developers, you might ask them to enable whatever this is as a default:

tigrisoculus

draw.io Google Group says

You can disable the use of foreignObject by clicking here: https://app.diagrams.net/#_CONFIG_UzV3UjUyyk0tSk8F0qrGjqpggeLM3IKcVJ/EpNScYoh4SVFpqqq5CxABAA==

That will make their useful app much more useful. Thanks, everyone, for your help.

tigrisoculus

I don't understand the relationship between Atlassian and draw.io. Any mail to draw.io goes to Atlassian, and is answered by Jira support, who don't want to bother answering questions about draw.io. Because I was confused and kept asking about compatibility, I got blocked by them in draw.io forums, too. 

The company that runs the draw.io integration client for Atlassian Confluence use Jira as their service desk. You emailed the alias of their service desk and it replied from an atlassian.net email. This domain is the one used by Jira cloud, it does not imply any relationship between the company using Jira and Atlassian. There are tens of thousands of email accounts, one per Jira Service Desk on cloud. You asked them a question about the core project, which they are not responsible for, they will have directed to the core project. They are correct to do so.

tigrisoculus

So draw.io is a standalone app with its own 1.5--2-person development team, to which Atlassian refers its customers for diagramming? If anyone has an avenue to the developers, you might ask them to enable whatever this is as a default:

No, Atlassian and the draw.io open source project have no relationship. I'm going to now unsubscribe from this thread.

Well, if anyone has a way to communicate to the diagrams.net (draw.io core application) developers, please ask them to enable this as a default:

tigrisoculus

You can disable the use of foreignObject by clicking here: https://app.diagrams.net/#_CONFIG_UzV3UjUyyk0tSk8F0qrGjqpggeLM3IKcVJ/EpNScYoh4SVFpqqq5CxABAA==

The question about truncated text when draw.io is edited by other apps is a frequent one in their support forum https://groups.google.com/g/drawio (from which I have been barred from posting).