These are chat archives for caryll/otfcc

13th
Aug 2016
Belleve Invis
@be5invis
Aug 13 2016 02:09
Perhaps I should write a library that creates a curve fit from a function that generates arbitrary precision polygon approximation of it...
So the Minkowski Sum (which is stroke expansion), boolean and algebric curves can be supported in a uniform way.
Georg Seifert
@schriftgestalt
Aug 13 2016 05:58
I didn’t like to convert to poly but went with an approximation of bezier intersection instead.
Belleve Invis
@be5invis
Aug 13 2016 06:00
No, my idea is that use poly only in intermediate representation.
Georg Seifert
@schriftgestalt
Aug 13 2016 06:00
The poly to bezier conversion needs to make sure that segments that didn’t have intersections should be unchanged. So you need to fit the poly with the previous curves.
Belleve Invis
@be5invis
Aug 13 2016 06:01
For boolean, yes, my lib preserves existing curves.
But for something more complex like Minkowski Sum, using poly as intermediate data and rebuild the curve is a good idea.
in the shape rebuilding substep
for any poly segment, if the rebuilder find that it is converted from a curve segment, than it will use the original curve
Belleve Invis
@be5invis
Aug 13 2016 06:07
And all intersections' position are preserved.
Georg Seifert
@schriftgestalt
Aug 13 2016 06:08
when I looked into possible libraries, all working solutions where using poly lines but they never cared about converting back to curves. They only needed it for drawing and then the lines would be better. The implementation in RoboFont uses an implementation similar to what you suggest.
Belleve Invis
@be5invis
Aug 13 2016 06:09
there are boolean libs that deals with curves directly, using data structures like DCEL. very 高端 (high-level) data structure.
But things like Minkowski Sum (stroke expansion) is much harder...
Georg Seifert
@schriftgestalt
Aug 13 2016 06:13
Yes, boolean. Do you have an example for a DCEL implementation?
Belleve Invis
@be5invis
Aug 13 2016 06:13
Sorry no.
there was one but deciding each facet's winding number is harder than expected, so I moved to clipper.
Georg Seifert
@schriftgestalt
Aug 13 2016 06:16
my implementation works quite well but there are some edge cases and it needs optimization for big segment numbers.
Belleve Invis
@be5invis
Aug 13 2016 06:17
yeah edge cases are really annoying.
I choose clipper because it can handle edge cases well.
And I profiled my lib, it takes most time in the step of calculating intersections.
Clipper itself is very fast