Paste SVG text into Designer as a new SVG?

[v_kyr]

1 hour ago, lacerto said:

Whether an omission or not, I do not think that it takes a lot to improve the code on Windows versions so that behavior will become identical with the macOS versions.

Probably shouldn't be a big deal here. - Though under those apps I use under macOS, Affinity is the only one which offers a "File -> New from Clipboard" function at all. The rest of apps I use can paste as text into docs only, without any further help of some of my own workaround scripts here.

[Peter Panino]

I am not talking about Mime types, an entirely different discourse. I am talking about simple Text format in the clipboard semantically representing SVG XML.

[walt.farrell]

4 minutes ago, Peter Panino said:

I am not talking about Mime types, an entirely different discourse. I am talking about simple Text format in the clipboard semantically representing SVG XML.

I don't think it would be appropriate for an Affinity app to simply say "oh, the text on the clipboard looks like it's SVG code, I'll assume that I should create an SVG". There may be times when a user wants to paste the code, not an SVG object.

Using the MIME type is safer, in my opinion, though I suppose for File > New from Clipboard there could be a new option to assume an SVG file is wanted if the clipboard text looks like SVG (especially as Affinity won't create Text documents that way), or the application could prompt for a user decision.

[Peter Panino]

This is an app I have built (not yet published) that can exactly do that: Creating an SVG rendering from SVG XML in the clipboard:

 

[v_kyr]

35 minutes ago, Peter Panino said:

Creating an SVG rendering from SVG XML in the clipboard

And how does it indicate to other common apps, which make use of the MS Cliboard API, that it is an XML/SVG based text file inside the clipboard, so that it is handled the right SVG drawn way by those other apps when pasted into them? - What you've shown above is just the SVG editor & preview portion (aka SVG based xml text), which don't tell much about how it's format is written into and identified as being a SVG code and then also handled that way from pasting from the clipboard.

[Peter Panino]

17 minutes ago, v_kyr said:

And how does it indicate to other common apps, which make use of the MS Cliboard API, that it is an XML/SVG based text file inside the clipboard, so that it is handled the right SVG drawn way by those other apps when pasted into them? - What you've shown above is just the SVG editor & preview portion (aka SVG based xml text), which don't tell much about how it's format is written into and identified as being a SVG code and then also handled that way from pasting from the clipboard.

I am not sure I understand your question. If you have an SVG XML text in the clipboard, you can paste it into my app, edit it, and save it again as an SVG file. My app also allows you to render the SVG as a raster graphic in different formats and sizes, and then export it (just as Affinity Designer does - but to more formats than Designer - even to .ICO).

[v_kyr]

33 minutes ago, Peter Panino said:

I am not sure I understand your question. If you have an SVG XML text in the clipboard, you can paste it into my app, edit it, and save it again as an SVG file. My app also allows you to render the SVG as a raster graphic in different formats and sizes, and then export it (just as Affinity Designer does - but to more formats than Designer - even to .ICO).

Well your app just does SVG wise what I do here ...

... so it just places the UTF-8 text into the clipboard. - But this thread title "Paste SVG text into Designer as a new SVG" suggerated (at least to me) that Designer would need to draw the SVG from the SVG code and therefor it has to identify in some foolprove manner that the plain UTF-8 text from/in the clipboard is SVG/XML code. So it either checks (parses) the UTF-8 text from the clipboard in order to find out if it is SVG/XML based contents, or (probably for Windows) it would need some mime type indicator for it's clipboard contents. As either way it has to know what it gets from there format wise (the clipboard) in order to being able to handle it correctly.

On macOS it does that, the above shown when inserted into the clipboard is shown here when pasted over to ADe v1.

[Peter Panino]

9 hours ago, v_kyr said:

it has to identify in some foolprove manner that the plain UTF-8 text from/in the clipboard is SVG/XML code

The software can automatically detect that because I have programmed it to do so: If a valid SVG XML text is in the clipboard, the "Paste and render SVG from Clipboard Text" command is automatically enabled - otherwise, it is automatically disabled. In my screenshot above, the "Validate" button can also do this check after you manually edit the text in the editor.

[Peter Panino]

To make it more clear, here is the functional flow of the rendering process in my app:

[v_kyr]

12 minutes ago, Peter Panino said:

To make it more clear, here is the functional flow of the rendering process in my app

That was already clear to me, since as a developer I just need to see it's UI and used widgets there. - The overall important point is more this here ...

28 minutes ago, Peter Panino said:

... If a valid SVG XML text is in the clipboard, the "Paste and render SVG from Clipboard Text" command is automatically enabled - otherwise, it is automatically disabled. ...

... which means that you explicitely check/parse for valid defined SVG-XML code, and that's what the ADe Mac version IMO does too. Aka if the clipboard doesn't contain a fully defined SVG header, so let's say just some SVG circle element, then it will be copied just as plain text into ADe. But if it contains a fully specified SVG contents file (SVG version, XML dialect, xmlns, ... etc.) it will try to render it.

Just pasting over the SVG circle element portion from the before shown example:

[Peter Panino]

4 hours ago, v_kyr said:

Just pasting over the SVG circle element portion from the before shown example:

That should depend on the context: If the current tab contains an SVG document, then in your case, it should insert a circle element (and not a text element) into the current SVG document.

[lacerto]

3 hours ago, Peter Panino said:

If the current tab contains an SVG document

If you mean a document tab within Designer, then SVG elements that are pasted do not create a document of type SVG, nor do SVG elements pasted on to an existing Designer document (even empty one) make it a document of type SVG. There is no SVG document format that Affinity apps can save back to, so when Affinity apps produce SVG code, it is always an explicit result of exporting to that format, also when "copying back" SVG code by virtue of a preference setting. So even if the menu command says "New From Clipboard", it means "new Designer document from Clipboard". The Clipboard can contain also e.g. a bitmap, yet the document created will be a Designer document, not a bitmap of the format that is pasted.

Also, if you paste SVG code within a text frame, the code will be pasted as text instead of rendering it to graphics (even if inline graphics is supported). This will happen also if you paste single object elements from Clipboard, so the current code requires something more than just object tags to make a decision of trying to render the code rather than just pasting it as text.

It is nice if the developers make Windows and macOS apps behave identically in context of this feature, but as mentioned, comparing with other 2D graphic design apps (especially on Windows platform), this is not a big omission. I do not think that there is a "right" way to do this kind of data exchange so it is good that the user can basically make a decision by placing SVG as code or objects based on the target container (page vs. text frame), or use Paste Special (on Windows). At some point Serif made a change that allowed font designers to paste object content from Designer in format that behaves meaningfully (e.g., in proper size) in FontLab so often when exchanging information via Clipboard (I do not recall if it was specifically related to developing SVG fonts), there needs to be some target or application in mind, and therefore need to tag content in a way that the targeted app can use. It does not need to be MIME based but planned to behave in a way that can be processed as planned in specific data exchange considering the needs of users who have requested a feature. For coders previewer plugins might be more straightforward method to check that coding works, but that probably depends on complexity of code.

 

[Affinity Info Bot]

The issue "[Win] 'New from Clipboard' fails with SVG code on the clipboard" (REF: AF-854) has been fixed by the developers in internal build "2.5.0.2317".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Affinity Info Bot to notify us.