Feature request - proper arc support

[rr-]

Right now SVG arcs appear to result in segmented lines, and unfortunately this is what Illustrator is often generating for curved paths. It makes stuff look pretty bad.

(AI2ASS isn't working for me for some obscure reason, which is why I turned to this project instead).

[irrwahn]

Unfortunately this is not as trivial as one would wish. Since ASS does not support a native arc drawing command there are basically two ways to approximate elliptical arcs: line segments and cubic Bézier curves. SVG2ASS already uses the latter approach to approximate full circles, ellipses and rounded rectangles, as calculating the control points is pretty straightforward in those cases. For arcs with arbitrary sweep angles however the calculations are substantially more involved. I will look into it, but please don't hold your breath, as I cannot promise to get round to implement this anytime soon, or implement it at all.

Meanwhile a potential workaround might comprise to somehow coerce the SVG generator into using Bézier curves instead of elliptical arcs in paths, as these should carry over reasonably well to ASS.

[rr-]

Thanks for the response. I understand that the calculations are very complex - I tried to look into the code and it was very difficult to follow. One thing of interest might be that when I tried to increase the count of the line segments:

     double step = M_PI / ( 0.36 * ( r.x + r.y ) );
+    if (step > fabsf(dt) / 10)
+        step = fabsf(dt) / 10;

it produced much better results, naturally at the expense of the output size:

Before

After

I think that improving the heuristics for the optimal number of the line segments would be enough, at least for me.

FWIW the file in question can be found here: https://0x0.st/zw2Y.svg I had to do some other patches related to parsing unknown style attributes and recognition of translate(x y) (without comma) for it to convert, LMK if you'd be interested in a pull request.

[irrwahn]

Yep, looks way better with limited step size / increased segment count. I actually thought of something like that before but forgot to mention it in my previous comment. The step calculation has always been questionable to say the least, so I'd say there's no harm in tweaking it further. (Or even make it configurable, I'll give that some thought.)

Please feel free to send me any patches or pull requests you deem worthy. I will happily accept any fixes and sensible improvements, your efforts are certainly appreciated! And don't hesitate to open issues about stuff you'd rather not touch yourself, I'll try my best to help.

(And yes, the code isn't exactly easy to grok even for me not having looked at it for years. It is a toy project that got out of hand - and it shows. Sorry for that.)

[irrwahn]

FYI: In 53ab26c I added an (experimental) -z command line option to tweak the angular step width. The higher the argument, the coarser the approximation. The default value of 4.0 should yield a result close to that of the previous hard-coded calculation.

UPDATE: Commit 20ac3b0 should fix the parsing of inline CSS and transform parameter lists.

[rr-]

This is awesome! Thank you. For me, this feature request can be closed, but I'm not sure if you'd prefer to track it seeing how there's still a TODO in the code.

The patches I wanted to send were actually just a much dumber implementation of your https://github.com/irrwahn/svg2ass/commit/20ac3b035d1aa4350cbfb16dc96cec801607c107 so there's not much I can further do to improve it :)

[irrwahn]

You're welcome. Thank you for your input and for reporting the bugs we were able to fix in passing. :) Don't hesitate to let me know if you happen across any further problems, I'm happy to help.

For the time being I'll leave this issue open, as the original request "proper arc support" IMHO remains valid and there is a small but non-zero chance I'll eventually get round to implement the Bézier approximation.

[unixfx]

does it work on windows?

[irrwahn]

It's a simple command line tool with no external dependencies beyond the C library, so I see no compelling reason why it shouldn't be possibly to build and run on Windows, though I never tried myself (and don't intend to). My best guess would be to build it using either MinGW or Cygwin, but in theory it should also be feasible to build with MSVC, with minor modifications.