SVG plugin additions

[edb]

I'm going over the code and doing some additions to the SVG plugin (wpc_svg).

So far I've added support for the H, V, S, Q, and T path commands, as well as the relative version of those commands, as sometimes those commands can be used by a drawing program when it saves to SVG. Here's an example file:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<svg width="500" height="500" viewBox="0 0 400 400" version="1.1">
<path style="fill:gray" d="M 10 80 q 42.5 -70 85 0 t 85 0 t 85 20 t 85 10 v 90 H 10 z"/>
</svg>

Things are still a WIP at the moment.

[edb]

I've made a repository for it:
https://codeberg.org/elblake/wings-svg-plugin

[micheus]

Hi edb

This importer is already available in Wings3D - wpc_svg_path.erl
Which different feature are you including on this one?

If it's something missing, maybe it would be interesting you make a PR including these features in the current one.

[edb]

The modifications so far are XML parsing is done with xmerl, a new command tokenizer that can tokenize "shrunk" SVG path strings where spaces that are usually expected are missing (Inkscape optimized SVG), added new path commands (H V Q S T). and possibly a few more things which are WIP atm.

My modifications aren't complete but I will make a PR for wpc_svg_path.erl when it is ready.

[micheus]

My modifications aren't complete but I will make a PR for wpc_svg_path.erl when it is ready.

Nice.
Just have in mind that this stuff can be a nightmare. It's hard to cover all options that came with different software exporting this format. Please have this in mind otherwise we have problems keeping the compatibility of kind of plugin.

These issues were related to a change made to Inkscape that may need to be checked:
- Inkscape .svg path import internal error
- SVG import more broken than before?


and just to illustrate and show you that it's hard to make it work with all exporters take a look at this thread in which the user tkbd helped with the PS/EPS exporter to minimize the issues when getting it from Illustrator, Inkscape and LibreOffice: When Import any ps/eps file,Output error log

So, please try to test your changes to other apps than Inkscape.

[edb]

Thank you for the forum threads, I will have in mind the previous issues.

I will be using tkbd's svg import test files as part of my testing and I'll be testing with libreoffice as well.

[edb]

I've managed to implement one more command: arcto, so now A commands can now be present in the SVG command list.

Code:

<?xml version="1.0" encoding="UTF-8"?>
<svg
   width="320"
   height="320"
   version="1.1">
  <path
     d="M 154.46118,76.188335 A 61.947593,67.495135 0 0 1 103.50532,142.61246 61.947593,67.495135 0 0 1 34.466647,99.760412 61.947593,67.495135 0 0 1 60.92262,18.129251 l 31.590961,58.059084 z"
     stroke="#000000"
     fill="#008000"
     stroke-width="2"
     fill-opacity="0.5"
     id="path2" />
</svg>

I've started testing with libreoffice draw as well and the shapes do get imported. though it adds a bounding box with an invisible rect so I'll have to remove those. I'll be trying with GIMP and scribus eventually.

I'll post beam builds to this thread soon before I get around to a PR, so SVG files made in other other software can be tested in advance if there are any issues too.

[edb]

I'm still making changes for this plugin.
The importer now calculates the scale for the shapes from the SVG document width and height and viewbox. Some software export SVGs with document width and height at "100%" so I still have to come up with a reasonable scale for the shapes for that.

Here are SVG files from different software I've tried compared to EPS 100pt square.


I'll post a branch for wings with this SVG importer soon.

[micheus]

I'm not sure about this way you are handling the elements' size when importing, but try to not make it to much different the way it hands that currently.

The import dialog just provides a Scale factor to help with that. The users are already used to it.

[edb]

Hi micheus,

Thanks for the feedback, I will add an option for the user to use viewbox coordinate system only which will do the scaling the same way as before, giving users a choice. The updated importer will also have checkbox options for the very few changes of behavior so it can be switched to behave the same way as the importer had done previously in case the user needs it.