SVG: Converted strokes have incorrect thickness and too many control points

[mcjadski]

I decided to make this a separate issue from #119, even though it's a glitch that happens with the same file.

Here are the sample files: (I created the SVG file in Inkscape.) svg_fill_test.zip

Again, it should display like this:

But instead it displays like this:

The top brown shape has no stroke; the other three blobs have strokes. The line thickness on the 3 shapes is completely messed up; they're supposed to have a fixed width, but they go from seemingly no thickness to far-too-thick.

If you try to manipulate the control points, things get even stranger. Take the middle bottom shape, which (from the SVG's standpoint) should only have 3 control points:

However, if you start moving around the one control point where the fat end meets the thin end (using the Control Point Editor Tool), you find a great many control points in there:

I can't make sense of where the control points are coming from. Sometimes I'm able to separate out many more:

Since I'm able to move a given control point around as one control point, only to "find out" later that it was actually multiple control points, I think they must be being created somehow.

Also, while the large brown shape doesn't seem to have a wellspring of infinite control points, it still has too many. Here's how it's supposed to be (in Inkscape):

But in OpenToonz, one of the control points is being interpreted as two of them:

I got the same behavior on Win 7 and OSX 10.11.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/41432778-imported-svgs-strokes-have-incorrect-thickness-too-many-control-points?utm_campaign=plugin&utm_content=tracker%2F33713530&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F33713530&utm_medium=issues&utm_source=github).

[artisteacher]

I have the same problem in OS X 10.12.5.

This is a simple svg in Affinity Designer (the anchor points look identical in Illustrator)

The same image in OT - notice significantly more anchor points

[DoomDesigner]

When can they fix it? @shun-iwasawa @turtletooth @manongjohn
This is very necessary for studios. And still need to save in Svg and EPS format.

[adamearle]

How can we get this fixed guys what needs to happen, because we need to really need to hustle on this

[adamearle]

Adoption is one of the largest problems and if studios can't find a way to quickly start adopting OT for current and future work it is going to take a lot longer to pick up steam

Adoption is imperative

So what do you we have to do to get this done?

[artisteacher]

There has been some great work to add some amazing new features and more stability. However OT still has a good deal of instability (maybe more so in OS X than other OS) which is going to minimize adoption. The focus should be on making the program as stable and consistent as possible. What is most important (and is already ongoing) is fixing any issues that result in crashes and memory/performance issues. Then issues that aren’t showstoppers but also don’t work properly should be resolved. I think that with the amount of work to do (250+ issues - though some could likely be closed) more developers would probably be helpful - particularly developers that can work across platforms. Not many people are willing/able to do so much work for free, so money will be necessary.

[Orphanlast]

https://www.bountysource.com/issues/41432778-imported-svgs-strokes-have-incorrect-thickness-too-many-control-points

[RodneyBaker]

Regarding the thickness issue...

Until such a time a this can be fixed a workaround is to make note of the thickness of the line that is displayed in the UI and immediately select the object/lines that have been imported, change the line thickness to 0 or 1 and then back to the thickness desired (the one you made note of at the very beginning. If a standard thickness works best so much the better.

Regarding the extra Control Points.... there is now a feature (at least in OTX and Morevna releases... that allows us to Simply Vectors. I haven't used it a lot but in the times that I did it worked very well.

[RodneyBaker]

In the test that I just ran the SVG test file (posted in the first topic) came in with the start of the line thicker (which was easily corrected via the method I mention above) but the number of CPs generated was quite reasonable. This was from dragging and dropping the SVG file into the xsheet and not from using the convert dialogue via OT's browser.

[RodneyBaker]

I note this issue still persists in current releases.

A known solution exists for the issue of importing SVG images where the line thickness is not uniform. Perhaps the word can get out so that problem can be addressed?

Background When an SVG image is imported into OT it imports fine with regard to shaping However the line thickness is not appropriate/correct/uniform and therefore does not properly represent the original SVG image.

Workaround The workaround for this is to immediately apply three steps after importing:(edited) 1) Select everything imported 2) Change the Line thickness to 0 (zero) 3) Change the Line thickness to a desired thickness (example: 2) Step two is required in order to get OT to achive uniform thickness of the line if omitted the line thickness will change but proportionally (as if everything is just scaled/multiplied). So the line will still not be of uniform thickness. It may be that the code simply overlooks something simple The workaround could be hardwired but is likely not optimal.

[artisteacher]

SVG's could definitely use some attention. Just as important as the line thickness, the number of vertices in an imported SVG should not change from the original.

[RodneyBaker]

the number of vertices in an imported SVG should not change from the original.

I know this will read as being a little nitpicky but I don't fully subscribe to that although recognize that it would be optimal to have that as an option. Someone with a thorough knowledge of SVG should be able to implement a direct loading of SVG as a feature. I can see times where letting the application determine the curvature required would be preferred. (I think it's safe to say we all acknowledge OT tends toward being control point heavy with regard to vector lines... a deeper issue than just SVG)

I use the term 'feature' here for several reasons: 1) The SVG standard is still evolving and improving 2) To my knowledge OT currently doesn't support the SVG 2.0 standard

Given that the new feature would likely be "Support for SVG 2.0". Again, the underlying issue here is that the standard is a bit of a moving target so expertise is required. This is a long list of additions to include color gradient fills and (potentially editable text). The development required full compatibility is substantial. Fully implementing SVG also has some security related overhead and concerns that would need to be addressed.

My consideration here is mostly to address what isn't working in the current implementation that otherwise works as designed. This is a fairly short list with the most obvious being that of the non-uniform line thickness. I'd classify this as a bug although perhaps others would not.

Hope that makes sense.

[RodneyBaker]

Another thought... (that points to further feature development) which I only add here for completeness sake...

OpenToonz never just displays the SVG as is. The SVG file is converted regardless of whether the user opts to Import or Load the file. When Loading this results in a .PLI file being created in the original directory of the SVG file which is then used in OT. When Importing the PLI is generated inside the Project 's file framework.

Another option (for potential development) would be that of allowing OT to reference the SVG as read only and directly place the SVG (or 'imported' copy) onto the canvas. The referenced SVG would then simply be edited in another SVG edit capable program.

[gab3d]

I might be wrong, but I tend to think the different number of vertices when importing is not due to 2.0 spec unsupported. A valid question here would be: Does any sort of SVG file from any SVG version loads proper (same number of vertices, same shape, fills intact)? I tend to think it does not... 🎃

[RodneyBaker]

Agreed that the number of vertices isn't related to the 2.0 spec.... that wasn't my point... only that SVG is a bigger thing than the issue under consideration here. What I'm suggesting is that the broader scope is likely not an SVG issue as much as it is how vector curve precision is handled in OT itself across the board. It seems very clear that a massive number of CPs/vertices are generated with vector lines. That's why the 'simplify vector' feature is so useful. We are in agreement so... I'll just stop there except to say that there are other things that don't work with SVG and the 2.0 spec is important to that larger scope.

Concerning the actual curvature... The SVG importer (and the converter) appears to be working overtime to try to preserve the curvature but it appears to do that by adding more points rather than adjusting the bias of the handles entering and exiting those points to achieve the curvature.

Perhaps @turtletooth can weigh in on this as he was the one that developed that vector simplification feature.

[RodneyBaker]

According to @morelightning (via OT Discord) the problematic line is likely this:

https://github.com/opentoonz/opentoonz/blob/792dc2b6b402d622292efe815bfaa2635c43eeb9/toonz/sources/image/svg/tiio_svg.cpp#L429

[RodneyBaker]

There are also two related lines commented out.

https://github.com/opentoonz/opentoonz/blob/792dc2b6b402d622292efe815bfaa2635c43eeb9/toonz/sources/image/svg/tiio_svg.cpp#L1768

https://github.com/opentoonz/opentoonz/blob/792dc2b6b402d622292efe815bfaa2635c43eeb9/toonz/sources/image/svg/tiio_svg.cpp#L1797

[RodneyBaker]

Watching this as the code is said to be merged but haven't been able to confirm the fix yet in a nightly build.

[RodneyBaker]

With latest nightly release there appears to be at least three issues still remaining with SVG import. I was under the impression these were addressed in recent PRs but those may have addressed other issues.

1. Filename error upon loading in most ways (Using Right Click > Load Level via xsheet seems to work best) Opentoonz looks for a PLI file instead of SVG. There is also the error of ranges being set to a magic number in the 65534 range even when there is only one frame.

Ref: #2231 (Note @manongjohn description of the failure to convert the SVG to PLI that in turn generates the missing PLI error.

2. Color Fills not being maintained. If the SVG has groups assigned fills seem to import much better.

3. Vectors are imported offset and out of scale The top left boundary of shape container appears to be placed in center of the Opentoonz canvas. Shapes appear to be scaled to (at least) twice original size..

[artisteacher]

I still think the number of control points is important. If I can make an SVG shape with 5 control points in Illustrator or Affinity Designer or etc., I don't see any reason for/benefit to OT changing that to 20 control points. Having too many control points can really slow down the performance in OT to an unusable level. While 15+ extra control points on their own may not slow things down, if you import enough complex SVG, it could. I think there may be an issue with cusp points not being recognized or utilized properly in PLI. Since the SVG is converted into PLI upon loading/importing, additional vertices seem to be added to compensate for the lack of cusp points.

In addition to the scale/offset/fill issues, at some point it would be great for basic gradients to be recognized. We can add linear and radial gradients in the vector styles, so most of the underlying function is there.

[RodneyBaker]

We need to break the various SVG issues off into a discussion topic so they all can be attacked in 2020 development cycle. There are some current workaround that demonstrate approaches to resolving each problem to include the underlying issue of control points being added. I want to focus on that aspect for this response but first a suggestion that might at least partially resolve some problems.

Currently, all SVGs are converted to PLI format upon being opened in Opentoonz. In similar fashion... although with new much new code to allow for it... it would be ideal to add direct SVG manipulation (or at least initially read only access) to SVG images. This would not resolve editing issues but would remedy a major issue of simply importing SVGs into Opentoonz. Note: Opentoonz currently does a really good job with creating SVG images from PLI format for use in other programs... the conversion process is just hidden in the Right Click menu of the Browser.

Solving the conversion issue goes deeper into the source of the PLI format and how various tools effect control points. This will need to be addressed but goes beyond the rudiments/purview of the SVG format.

Note that there are many issues with SVG specification and movement toward SVG 2.0. For more on that I recommend keeping a close eye on Inkscape as one of it's developers and writers of documents in on the board for SVG 2.0 along with (at last check a rep from Adobe, etc.) Much of the development of SVG 2.0 has stalled in recent years but there are good signs of life still remaining. My point here is that there is little consensus on the road forward for SVG and this is problematic. In this sense it's good that SVG images are converted to PLI format.

One process that should generally be run immediately after importing SVG into Opentoonz is the 'Reduce Vectors', currently known by the rather unwieldy name of "Replace Vectors with Simplified Vectors" (RVwSV). The RVwSV process does a pretty good job of minimizing/optimizing number of control points and adjusting the biases of curvature handles. RVwSV isn't perfect but and needs to be enhanced but should be used in cases where lines generate too many control points.

Under the hood I'd say there needs to be an option to reduce control points by some tolerance level. As long as the bias handles are able to correctly store magnitude, gamma (and in 3D alpha) orientation there is little need for more than two control point on any line segment. I'm confident this will happen in some form or fashion. Some ground work has already happened (i.e. introduction of RVwSV operation)

A problem arising of course with altering any number of control points in that the change will create new incompatibilities. For instance, with autoinbetweening if we have two vector shapes exactly the same for our extremes and then alter the number of control points on one when we autoinbetween we are much more likely to get a mess in the results.

[RodneyBaker]

Regarding Fill Gradients...

There are currently some issues with the adoption of gradient fills for the 2.0 standard. We could likely resolve those independently of the standard but we need to keep an eye on the standard or risk the 'fix' breaking as others adopt, incorporate and adhere to the SVG standard.

REF: https://dev.w3.org/SVG/modules/advancedgradients/SVGAdvancedGradientReqs.html

We might take a look to see if we could at least implement the v1.1 standard:

Currently the SVG 1.1 specification defines two types of gradient paint servers; Linear and Radial.

Aside: We need to find an SVG expert but I'd think most of them would be focused on working with the actual standard and/or Inkscape as that is where most of the action is.

[RodneyBaker]

I should add that I plan to open a bounty related to SVG in early 2020. I'm doing that for several purposes but mostly to move toward resolution of issues with SVG as that is a popularly expressed area of interest.

Because I don't want to delay any effort to resolve issues, I will commit to paying that bounty forward to anyone that works to resolve the issue (writing the code that is) prior to establishing the bounty. I believe there is (or was) a bounty related to SVG already and that related to the line thickness issue (and the bulb that would appear at the ends of lines. Those fixes were implemented in v1.3. At present I plan to start the bounty with $100, specifically list milestones and then see where we can take it from there.

In addition to the extra Control Points created during conversion from SVG to PLI the following are the basic issues with SVGs imported to PLI in Opentoonz:

• [ ] Scale: Vectors are resolution independent and so cannot use standard raster scaling nor can it use Opentoonz's approach to using DPI to effect resulting scale. Currently manual adjustment of Scale and Position is required to get the vectors properly positioned on canvas.

• [ ] Offset: Conversion of vectors from SVG appears to possibly use the upper left corner of all selected vectors versus the center of select vectors (or perhaps vice versa?). In resolving the scale issue it will be good to verify that where the vectors are being calculated from is consistent. There may in fact not be any offset issue and the creation of large scale offset vectors might fully relate to the issue with Scale.

• [ ] Color Fill: SVG vectors converted to PLI tend to lose their color fills due to incorrect assessment of gaps. Increasing the Gap tolerance (ala other recent improvement) with Color Fill for vectors should resolve this issue.

• [ ] Sequential SVGs: I believe this is still an issue and there should be a report open on it. Will verify. The issue concerns Opentoonz failure to recognize sequences of SVG. This needs to be revalidated now that some filenaming issues have been addressed

• [ ] Reference SVG vs PLI: There is a reported issue with Opentoonz initially referencing SVG file (or import but it apparently doesn't renew that reference after the SVG is converted to PLI so the pointer refers to the PLI file thereafter.

• [ ] Referencing SVG vs PLI: Opentoonz

[MsBlockCat]

@RodneyBaker Hi! I'd like to add $25 to that SVG improvements bounty. What's the best place for me to do so?

[RodneyBaker]

There hasn't been a bounty opened for SVGs as of yet. As such a bounty would need to be opened.

[MsBlockCat]

I'll wait for whenever you're able to begin the bounty before adding my $25, as you have a lot more in depth of a plan!

[RodneyBaker]

The first two steps... the main part of the bounty of personal interest to me... concerns scale and position. With those two resolved SVG can at least be used in a meaningful and reliable way. I should be fairly close to posting a bounty.

On Sun, Apr 19, 2020 at 7:55 PM MrBlockCat notifications@github.com wrote:

I'll wait for whenever you're able to begin the bounty before adding my $25, as you have a lot more in depth of a plan!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opentoonz/opentoonz/issues/1009#issuecomment-616256113, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATVAMHIA4OQIETWZRDCEJ3RNOMRJANCNFSM4C6CU5VA .

[MsBlockCat]

As an update, I've decided it makes more sense for me to use the $25 elsewhere... I apologize for that! I'd still love to see SVGs work better in OpenToonz though, don't get me wrong. :)