Post by Anton SherwoodHeh, well, I had in mind to fit each stroke separately,
then bring them into FF and deal with overlaps by hand.
That works too. Fontforge already has several bells and whistles ready, so
don't need to reinvent that wheel either. Good idea.
Post by Anton SherwoodPost by Jose Da SilvaSee if LibSpiro can help you, this way you can avoid re-inventing the
same wheel. [...]
Is there a Python wrapper? My C is very rusty.
I have not had time to look through fontforge/python.c, so not sure what it
has already. I know I would have to add 'a' and 'h' handling in any case.
Checking google, seems someone already created a python wrapper.
I'd be interested to hear feedback if you do want to try it out.
https://github.com/perey/PySpiro
Post by Anton SherwoodCan LibSpiro tell me, for a given spiral and a point not on that spiral,
where it comes nearest?
The way you use spiro, is by creating 'knot' points where you want curves
to cross through, for example, if you want spiro to cross through:
{x0=0.0,y0=0.0}, {x1=2.0,y1=3.0}, {x2=3.0,y2=7.0}
spiro will attempt to find the best curve fits to cross through those points.
Sometimes, some curves are just not possible, and libspiro will let you
know it tried, but was not able to find a solution to fit your choice of
points.
This example doesn't have straight lines, but it's a short example.
Using a test input pattern (tests/call-test1):
80, 738, '{'
749, 540, 'o'
671, 309, 'o'
521, 396, 'o'
377, 333, 'o'
467, 231, '}'
spiro makes six attempts and comes out with a solution like:
moveto(80,738)_1
mark_knot()_0
curveto(172.314,664.426, 287.04,622.654, 403.914,606.06)
curveto(462.352,597.763, 521.42,594.908, 580.064,588.226)
curveto(638.708,581.543, 698.554,570.643, 749,540)
mark_knot()_1
curveto(776.321,523.404, 800.431,500.639, 815.305,472.344)
curveto(830.178,444.049, 835.075,410.104, 826.082,379.43)
curveto(817.089,348.755, 793.992,322.521, 764.639,309.862)
curveto(735.286,297.204, 701.137,298.343, 671,309)
mark_knot()_2
curveto(643.661,318.667, 619.475,335.4, 595.839,352.199)
curveto(572.203,368.998, 548.225,386.017, 521,396)
mark_knot()_3
curveto(493.059,406.245, 461.39,408.353, 433.721,397.395)
curveto(419.886,391.915, 407.262,383.305, 397.36,372.199)
curveto(387.457,361.092, 380.322,347.504, 377,333)
mark_knot()_4
curveto(371.073,307.121, 378.034,278.522, 395.545,258.566)
curveto(413.056,238.61, 440.626,227.952, 467,231)
end
If you do:
./configure --enable-verbose_lib
make check
then run:
tests/call-test1
you'll see the info shown above.
Post by Anton SherwoodPost by Jose Da SilvaI also suggest sticking with G2 curves 'c' to keep the results simple [...]
Yes; though I would like to see what happens if the program runs until
it converges with G2, and then runs to improve that solution with G3 and
so on.
Libspiro starts out with an assumed expansion, but then expands it further
for best fit. For example, it will start out by giving space for 2 more
points to make a G2 curve, and will start-out with an array expansion of an
extra 4 points to make a G4 curve, but as it tries to fit a solution, the
array can/will expand in some places
Post by Anton SherwoodPost by Jose Da SilvaDo you have a planned license? GPL3+? Other?
yah, GPL, I guess.
...
https://bendwavy.org/wp/?p=1986
https://bendwavy.org/wp/?p=3529
https://bendwavy.org/wp/?p=3554
Interesting.