(SVG) Missing fills / Fill tool not working properly

[jeffwallin]

I did a screencapture video to show exactly whats going on. That is here : https://youtu.be/BzjvsnS1BzY
And you can see from my reaction in the video that it is random each time you import something if a fill is going to work or not. Before recording the video the tires in the vector drawn van would not let me fill, but in the video they do. There are still other parts of the van that do not let me fill for no particular reason.
Hopefully this is something that can be fixed with a new release

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[odysseywestra]

Thanks for the bug report.

Is anybody experiencing this on OSX as well? I just want to double check.

[jeffwallin]

Has anything been done about this is in the new Nightly Build? My OpenToonz install works great otherwise so I dont want to update and risk losing what I have, but i would be willing to if that has been fixed

[skitaoka]

We have been able to reproduce this bug on Windows 7; the bug is caused that Toonz does not accurately support paths which have holes and self-intersections. We plan to fix this issue in later version than 1.1.

[btr0005]

Problem exists on Windows 10 as well.

[ideasman42]

Please attach a simple SVG that causes the error.

[mcjadski]

Here is a simple example: (I created the SVG file in Inkscape.)
svg_fill_test.zip

It should display like this:

But instead it displays like this:

The top brown shape has no stroke; the other three blobs have strokes. You can use the fill bucket to paint the top brown shape a different color, but you can't fill in any of the three below shapes.

Here is a YouTube video in which someone demonstrates how she was able to get around this issue: https://www.youtube.com/watch?v=wQ8hll0wt1Q

But while the problem I'm experiencing with this file looks quite similar to the problem in this video, I wasn't able to do the thing she does, where she is able to ungroup and separate out multiple lines. I wonder if the program has been changed since then, if my .svg file is just different somehow, or if I'm just doing it wrong...

However, I found that if you manipulate the three bottom shapes in basically any way, they become fillable. I'm thinking this issue (or at least the issue with this particular sample file) is related to #1007.

Obviously, besides not being fillable, the line thickness on the 3 bottom shapes is completely messed up. (And they have a glitch where they have way too many control points.) But since this seems to be a separate glitch, I decided to move it to a separate issue (#1009).

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

By the way, I have a question: Why are imported SVGs considered to be just "Vector Levels" instead of "Toonz Vector Levels"? When you import an .SVG, it's converted to and saved as a .PLI file, and you're able to use palettes and everything. It seems like it's at least trying to be the same thing; the only differences I've found so far are glitches (some of which I'll have to open as separate issues).

[Houkime]

Still an issue in 1.1.3 (Arch x86_64)
Does not import filling unless it's a gradient (fills solid)
Strange stroke thickness.
Seems stable.
Here're examples with an Inkscape 3D-Box.
Interesting: If you enable FillCheck and try to resize one of rectanugular sides in OT you'll see that it becomes fillable (it really becomes) but back/front layering of rectangles is all wrong.
Actually all of the sides can be fillable except for front-right one and an opposite to it.

3dbox.zip

Really ruins workflow since OT doesn't have 3D tooling of its own.

[Houkime]

Output when run from console and trying to load attached example

QString::arg: Argument missing: Always do this action., /home/username/Desktop/drawing.svg create context:0x7f6fb8076900 [thread:0x58959700]

example2.zip

[Houkime]

Ok, I continued investigation into this and found out that it is sth in the structure of d parameter of the Path is what causing it.
Here are two examples that are different only in one SVG command symbol in pathdata:
svgtests.zip

Their pathdatas inside SVG are
`[Unfillable one]
d="M 24.555386,8.556045 C 19.036271,4.4868663 6.3610149,12.859084 6.3610149,15.57187 c 0,2.712785 8.8867111,11.272093 12.8155731,11.131776 C 23.10545,26.56333 28.0633,24.271493 28.48425,23.148961 28.9052,22.026429 29.974523,13.533047 24.555386,8.556045 Z"

[Fillable one - deleted final C command symbol]
d="M 24.555386,8.556045 C 19.036271,4.4868663 6.3610149,12.859084 6.3610149,15.57187 c 0,2.712785 8.8867111,11.272093 12.8155731,11.131776 23.10545,26.56333 28.0633,24.271493 28.48425,23.148961 28.9052,22.026429 29.974523,13.533047 24.555386,8.556045 Z"`

Also it seems like Stroke Thickness bug is independent of Fill bug

I finally was able to have QtCreator debugging sessions and breakpoints going on so maybe I'll be able find out what is causing this internally.
It seems like the sourcefile of interest is image/svg/tiio_svg.cpp
This code seems very old though, looks like hell and with spanish (?) comments... But hope I'll get through.

Interestingly it seems like geometry parsing itself works ok (shapes are just unfillable - not wrongly-shaped or sth). But nevertheless sth in this pathdata makes the difference between unfillable or fillable.
Which is curious enough.

[ghost]

If you manage to get this figured out, I would be so grateful. I would love to be able to consistently import svg files.

[Houkime]

Ok, seems like I somewhat figured out what pathdata is considered bad by OpenToonz.
(and thereby how to fix it quickly by hand if you really want)

Error arises when the final point of the pathdata matches or nearly matches (0/128 precision) the first point.
IMPORTANT: Maybe it's not the only case of bad pathdata but at least sth to begin with.

I manually simplified SVG to the max and did some testing to be sure.

So here is different pathdata that works and pathdata that doesn't
The starting point is 0,0 for convenience. It is right after M (moveto and start) command
Ending point in SVG is before Z (loop command, automatically connects end to start).
Only starting and end points are of importance for this examples.
0.0078125 is exactly 1/128. (however this value can slightly differ when starting point is not near zero because of accuracy)

[X axis]

[subcritical deltaX - unfillable]
d="M 0,0 C -5,-4 -18,4 -18,7 -1,18 4,16 4,15 4,14 5,5 0.0078124,0 Z"
[critical deltaX reached - fillable]
d="M 0,0 C -5,-4 -18,4 -18,7 -1,18 4,16 4,15 4,14 5,5 0.0078125,0 Z"

[Y axis]
[subcritical deltaY - unfillable]
d="M 0,0 C -5,-4 -18,4 -18,7 -1,18 4,16 4,15 4,14 5,5 0,0.0078124 Z"
[critical deltaY reached - fillable]
d="M 0,0 C -5,-4 -18,4 -18,7 -1,18 4,16 4,15 4,14 5,5 0,0.0078125 Z"

[Negative Y axis]
[subcritical deltaY - unfillable]
d="M 0,0 C -5,-4 -18,4 -18,7 -1,18 4,16 4,15 4,14 5,5 0,-0.0078124 Z"
[critical deltaY reached - fillable]
d="M 0,0 C -5,-4 -18,4 -18,7 -1,18 4,16 4,15 4,14 5,5 0,-0.0078125 Z"

However, it looks like there are no real geometry calculations on the distance because:

[subcritical DX and subcritical DY but supercritical Euclid distance - unfillable]
d="M 0,0 C -5,-4 -18,4 -18,7 -1,18 4,16 4,15 4,14 5,5 0.006,0.006 Z"

And here's the folder with exemplary SVGs
svgtests-continued.zip

Will continue tomorrow.

[RodneyBaker]

Is this fill vs non fill problem just a matter of rounding?
At a quick glance that's what it appears to be.

[RodneyBaker]

In looking at the svgtestfiles (in the above attached zip file) the common theme seems to be that of overlaid control points.

I will also note that while it doesn't address the specific import issue the use of the new feature "Replace Vectors with simplified Vectors" does resolve the fill problem for ALL of the exemplary SVGs in the svgtest zipfile. So in some instances that could be an acceptable workaround.

It would be good to revisit this issue and see how much of it still applies to current releases.

[RodneyBaker]

A few SVG related issues were fixed in #2358
Fill, Scaling and Centering issues still persist.

[flurick]

What if tiio_svg.cpp only accepts shorter svg command x,y strings than about 15 characters?
Looking on the example in #3171
The offset paths may be an import issue (parsing mixed m and M svg commands in one path).
But maybe the missing/extra fills are more internal. Filled regions seem to shift around along the path even with small adjustments of the points in that example.

[RodneyBaker]

This is one of many reports that will need to be reviewed after merging #5334. Some issues relate to SVG but others to PLI.
It is important to understand that at this time the only way Opentoonz supports SVG is through conversion to PLI.