SVG Text Fixes?

[StickmanRed]

Resolves #7084, #7321

Changes

Added "toEditorSVG" function taking the SVG element and returning an adjusted version accounting for some text offset issues.

Reason for changes

This could be useful to those importing SVGs from other programs.

Tests

This was tested on Chrome with SVGs from scratchblocks, the "Save blocks to image" addon, and the Scratch editor. The images' text did appear as they were imported in both the editor and the stage. When editing the image in Scratch, the text stays as it originally appeared; however, when changing the contents of the text, it sometimes becomes displaced, which I believe is a consequence of the "text-anchor" property.

I haven't found any other bugs in the code, but if there are errors or if it can be rewritten, the program loops through the text elements, adds "<tspan>" tags inside each element if there aren't any, and adds "x", "y", and "dominant-baseline" changes to "transform: translate"

[Samq64]

Could the addon's description be updated to mention scratchblocks?

[StickmanRed]

Could the addon's description be updated to mention scratchblocks?

would it be something like this? (edited content in addon.json)

[Samq64]

This still needs some work:

• The green flag and dropdown arrows are missing sometimes
• The text after an input is now to high instead of too low
• The SVG is not centered on the canvas

Screenshot

[StickmanRed]

This still needs some work:

• The green flag and dropdown arrows are missing sometimes
• The text after an input is now to high instead of too low
• The SVG is not centered on the canvas

I'll fix the second bug first, since that shouldn't happen... the other two weren't really my focus, being not text-related, but maybe the first bug could be patched using some code from "blocks2image"...

[StickmanRed]

• The green flag and dropdown arrows are missing sometimes
• The text after an input is now to high instead of too low
• The SVG is not centered on the canvas

For the first bug, a future version could replace the "<use>" elements with their respective references. I'm not sure how to fix the third bug you mentioned, since it has to do with the "transform: scale" property being removed from the top "<g>" element...

Edit: Actually, I added a quick concept that should fix the first problem... I'm still unsure about the last one though

[Samq64]

Scratchblocks import fine except for the offset now. I'll need to do some more testing to make sure it doesn't accidentally mess up other text SVGs

[WorldLanguages]

I'll need to do some more testing to make sure it doesn't accidentally mess up other text SVGs

How can we be sure this won't break existing SVGs that upload just fine? It will be hard to test all cases.

[StickmanRed]

I'll need to do some more testing to make sure it doesn't accidentally mess up other text SVGs

How can we be sure this won't break existing SVGs that upload just fine? It will be hard to test all cases.

Theoretically, the code should only add ignored properties to "transform" (offsets created by "x", "y", and "dominant-baseline"), place text nodes inside "<span>" tags (I'm not sure why Scratch shifts other text down), and substitute for "<use>" tags (added specifically to accommodate scratchblocks). Besides a bad concept execution on my part, I don't know of any new errors it could cause...

[Samq64]

Also would it be easy to fix Scratch 2 block shadows?

[Samq64]

How can we be sure this won't break existing SVGs that upload just fine? It will be hard to test all cases.

Theoretically, the code should only add ignored properties to "transform" (offsets created by "x", "y", and "dominant-baseline"), place text nodes inside "" tags (I'm not sure why Scratch shifts other text down), and substitute for "" tags (added specifically to accommodate scratchblocks). Besides a bad concept execution on my part, I don't know of any new errors it could cause...

Also the addon disabled by default but it would be ironic if it breaks other SVGs.

[StickmanRed]

Also would it be easy to fix Scratch 2 block shadows?

I'm not exactly sure... the only solution that I can think of is to insert every element with the "filter" property into its individual SVG "<image>", which should keep the shadows but will render the blocks uneditable...

[DNin01]

I'll need to do some more testing to make sure it doesn't accidentally mess up other text SVGs

How can we be sure this won't break existing SVGs that upload just fine? It will be hard to test all cases.

One thing we could try is programming a notification that appears when this addon makes changes to an SVG. Just an idea. We could show to users, just so they know the addon is doing something in case it breaks an SVG…?

But even if it's just a console.log(), it could be useful information.

[StickmanRed]

I'll need to do some more testing to make sure it doesn't accidentally mess up other text SVGs

How can we be sure this won't break existing SVGs that upload just fine? It will be hard to test all cases.

One thing we could try is programming a notification that appears when this addon makes changes to an SVG. Just an idea. We could show to users, just so they know the addon is doing something in case it breaks an SVG…?

But even if it's just a console.log(), it could be useful information.

I guess that's an option, but, after reviewing and using the addon a few times, I'm convinced that it shouldn't break anything that isn't already broken...

[WorldLanguages]

For this addon, we can go two ways

1. Keep it NOT enabled-by-default, and keep experimenting with SVG fixes
2. We could enable it for all users, which would benefit the most people, but we would need to be more careful, and consider showing UI notifying the user that the SVG has been altered. Possibly an Undo button to restore it to the original SVG.

A third alternative is enabling the addon by default, but instead of fixing SVGs by default, we add a little tooltip, after one or more SVGs were uploaded, with an "SVG fix" button.

[WorldLanguages]

@StickmanRed You're probably right on the fact this doesn't break any SVGs, but as I usually use SVGs as "just a vector format" (and usually do not read XML sources directly) I'm not familiar with all aspects of the SVG specification. Ideally we could look out for someone else who's somewhat familiar for a second look?

[WorldLanguages]

Just curious, have you considered using window.DOMParser? It's not that important, but maybe you didn't know about it.

[StickmanRed]

No, I haven't... could that be used as an alternative to iframe?

[WorldLanguages]

Probably. Using an iframe and destroying it afterwards is still fine, though.

[StickmanRed]

@StickmanRed You're probably right on the fact this doesn't break any SVGs, but as I usually use SVGs as "just a vector format" (and usually do not read XML sources directly) I'm not familiar with all aspects of the SVG specification. Ideally we could look out for someone else who's somewhat familiar for a second look?

Is there anyone to ask who could evaluate the changes, or should I wait for someone to review them?

[scratchaddons-bot]

Ping! There has been no activity for 7 days.

[scratchaddons-bot]

Ping! There has been no activity for 7 days.

[BroJac5246]

Do we want to be specifically mentioning third-party software? Do we know what platforms' SVGs experience this bug? I know this is somewhat unrelated, but now is a good time to maybe revise this.

[DNin01]

I think it's fine when put certain ways like "such as Affinity Designer", but "such as those created with Affinity Designer" way of wording it makes it feel a little more like free advertising. It's probably a matter of how specifically the product is being mentioned - "such as" is further away from the product names in the proposed description.