otfried / ipe

The Ipe extensible drawing editor
http://ipe.otfried.org
145 stars 12 forks source link

Check libspiro0 for spiro resolved (or not) #492

Closed JoesCat closed 4 months ago

JoesCat commented 8 months ago

SpiroCPsToBezier0() also returns 1 on pass, or 0 on failure to resolve, therefore it is good if we watch for pass/fail and act accordingly. This helps us avoid assuming good data, which may result in a (possible) segfault.

JoesCat commented 8 months ago

I noticed that the other branch was making use of a function that returns pass/fail, so I just re-organized it to react similarly for both branches. This code modification is not tested, but hopefully what's suggested here helps you improve ipe.

otfried commented 7 months ago

Is there a reason we should still be supporting a version of libspiro that is more than 5 years old? I think I would rather remove that branch of the #ifdef by now.

JoesCat commented 7 months ago

That is a good question. From my point of view,, GIMP/GEGL is the major user of libspiro and it still points to an old API, so it remains flexible using older or latest libspiro.

Fontforge doesn't have as much pull as GIMP, but it is in need of having some updating in this area. It now requires libspiro, but it still hasn't been upgraded to use the latest interface (eg anchors/handles), so it's still sort of okay using one or the other depending on the distro. With the change from autoconf to ninja, I believe the code was modified for only libspiro1, which is a plus in your favour, but I haven't looked at the build system.

So if we look at what it looks like out there.... libspiro versions, the latest version are picked up by Debian, Fedora, Arch, which is good news since other distros tend to follow them.

Watching the video for issue #491, I suspect this user is using the older libspiro (which uses math calculations based on absolute 0,0 while the newer libspiro interface uses a relative 0,0 for doing it's math and therefore would allow for moving curves around like a template).

IPE is your project, so I'd sort of refrain from saying yes/no, but hopefully with this info above, it helps you decide if yes, it's worth retaining backwards compatibility, or yes, let's just move forwards now with latest libspiro and drop older libspiro.

FYI - the old interface goes up to about 2015. The new interface begins in 2019, but I did some errors in implementing it, corrected in 2020. 20221101 I think I've resolved all bugs, and runs about as fast as it can without going overboard on code complexity. I think 20221101 is considered stable/mature, and don't think there's much more that could be added to it at this point.

FYI - This may also be useful to yourself as a gauge of pickup ipe versions - I've used it as a way to measure how easy/hard it is to pickup a project, like ipe, fontforge, etc, or how readily various distros pickup the next versions - but this is a sidebar to your original question.