Dependancies currently reduce portablity, and reduce clarity?

[nanjizal]

Currently dependancies such as Kurdo make it hard to assess how easy it would be to port to another programming language outside the Rust programming ecosystem.
I guess ideal would be if a rust contributor forked dependancies to just include required code as an alternate choice so that porting is more feasible, so dependancies can be replaced or replicated more clearly, I guess if I coded Rust it might be simpler to port, but I think it's rather the problem is the coupling is hard to untangle ( I am already used to looking at less familar languages so I think it's dependancy that is the main tricky part ).

I am unaware of any ports of relevant parts of Kurdo to other languages and it's very large lib to try port just for better curves.

My primary interest in porting to Haxe ( my preferance language ), and to allow cross compile to php, js, c++, python etc..
I have my own geom library 'geom' that could be extended to perhaps provide some Kurdo features ( certainly points and matricies ).

Also unclear from my previous look at the code base how the shader aspect of the curve algorithm works, currently I use line segments for standard Bezier gl/webgl rendering curves which in turn use triangles to create thickness in one of my libraries in the shader ( use an interleaved shader with xyz rgba uv ), it's not clear if spine is setup to allow similar approaches, or is it doing something smarter with the shaders and curves.

I know you intend to write a more detailed technical write up, but probably some of us don't require full details of the maths which may take time ( although if I follow it all definitely interesting ), but rather would love some more detail on the code/structures spline generates and uses so it's clearer how it could be rebuilt for different ecosystems.

My initial gut feeling ( when looked awhile ago ) was the code was rather tightly coupled to Rust ecosystem but the algorithms really did not need to be, but maybe I misunderstood the code base.

Thoughts or suggestions welcome, obviously as you know I ported hxSpiro which I have largely abandoned touching further due to GPL license complications with my unfortunate choice of sources, but keen for better curves MIT licensed code in place of standard Beziers for use with Haxe and excited by the rust font examples seen.

Even with Haxe c++ it's not simple to work out how to wire up rust library so porting seems simpler.

Another question I have made minor contributions to with hxTrueType that provides font curves, but do you have proposal for extended TTF format to include spine type curves. I guess TTF etc.. use rather horrible tables inside, and do not provide more modern features that should be in next generation font use.