Parametrized stroke outlining / expanding / offsetting

[strandedcity]

I've been following the library for some time, and have started a spare-time project based on it. I've been eagerly interested in the functionality to expand strokes into paths, particularly for bezier curves (where I know the problem is mathematically complex). Has a strategy / timeline for implementation been discussed? I may be able to contribute if new contributors are welcome.

I wasn't sure if the "outline" feature was separate from what I would describe in a CAD world as "offset". Is there some way to get equations for the position of the stroke edge that is not as complex as a full bezier-offset solution? See http://pomax.github.io/bezierinfo/#offsetting for a very detailed explanation of the math involved.

Thanks!

[christophknoth]

@pseaton

The Roadmap says it is planned: "Parametrizable path offsetting / stroking, to expand strokes to outlines and optionally produce all kinds of expressive strokes easily." @lehni probably has already some ideas for it and I am also interested in that topic. But more from a calligraphic point of view.

When smoothing will work sufficiently outlining would be the next thing I would concentrate on. Until then you are a bit on your own I guess. But I think contributions are always welcome anyways!

[christophknoth]

A friend pointed me to a pdf that could maybe be a useful starting point in this topic:
Variable width splines: a possible font representation? by R. Victor Klassen

[strandedcity]

Very interesting approach. I have always thought of the two edges of font characters to be somewhat independent of each other, though I suppose there's always a centerline that could be reverse-engineered.

It sounds like the question of how this is done programmatically is still up for some debate. In the world of offsets there are lots of problems in the forms of singularities, loops, corners, etc, all of which are compounded by the lack of a clear and consistent mathematical formula connecting a given curve and its offset, except in rare degenerate cases.

I'll see if I can work up something useful when I get a moment. I'm a little underwater with lots of projects right now, but I'll get back to it soon. Thanks for the reference, and the replies!

[christophknoth]

@lehni @pseaton
I found a paper called Vector Graphics Stylized Stroke Fonts by Philip J�agenstedt. Look especially at chapter 5: Extended Stroke Model where he describes his ideas. He writes in his blog that he implemented a stroking algorithm for canvas in opera in 2008. But I am not sure if it was ever out in the open. He works for chrome now, so maybe they open source the code one day ;)

But he also did not solve some problems that appear with his implementation like shown in chapter 10.

[christophknoth]

@pseaton I just found two other example made by Pomax where he put his math into action:

Here you can click to generate a random curve and see his outline algorithm. It works quite ok but fails in some edge cases:

And he made a nice little stroke-based CJK character builder that also works quite nice if you don't trick it too much:

It also supports changing the thickness and different stroke endings:

[christophknoth]

Quadratic bezier offsetting with selective subdivision! by Gabriel Suchowolski, Jul 10, 2012

[microbians]

Thanks a lot @christophknoth

UPDATE: Ported from SWF to Canvas 😉 and added variable offsetting

Here is a dirty demo in flash (is an old demo): http://microbians.com/?page=code&id=code-bezieroffsetingplayground

And a drawing application on I use the paper bu with variable offseting.
http://microbians.com/?page=code&id=code-theelectronicsketchbook

I will release the code soon ;)

[lehni]

@hkrish is working on a precise implementation of this that works better than the approach described by Pomax. I'm not sure how far away it still is.

[hkrish]

This has been in the works for some time. One of our main references was the paper http://visualcomputing.yonsei.ac.kr/papers/1997/compare.pdf, comparing different methods for offsetting planar bezier curves. And we chose the adaptive least squares method by J. Hoschek.
The method is detailed in https://dl.acm.org/citation.cfm?id=55191 (behind a paywall)

I had made this demo/test page some time ago. The method is actually quite simple, general (least-sqrs and subdivision) and naturally extends to variable offsetting etc. You can check it out at,
http://hkrish.com/playground/paperjs/offset/offsetStudy.html Warning: the script may freeze your browser in some cases. The curve intersection and boolean code has since been rewritten in paperjs, so most of it's problems are solved, but the demo is still using an old build of paperjs.

As long as we are working on just one cubic bezier segment most of these methods perform well, and definitely Hoschek's is one of the most performant and precise. However everything is downhill from there onwards —I am talking about linking up individual curves while making sure we are not breaking continuity between adjacent curves and discarding invalid parts when we offset a piecewise bezier curve; and in paperjs, we need to have a method that is robust and fast enough to handle most of, if not all, the corner cases.

Hoschek's method has another advantage that it allows us to keep the tangent continuity between two adjacent paths. The methods outlined by Pomax (seems to me that it is an extension of Cobb's method "Design of Sculptured Surfaces Using The B-spline Representation", I may very well be wrong here!), although simple, may not suit our purpose well (see the comparison paper for details).

I am hoping to finish this up in a week or two.

P.S. @lehni I think I can send some code your way before Easter. :)

[christophknoth]

@hkrish Exciting!

[LukeAskew]

+1 for this functionality

[lehni]

Yes we're working on it. It'll take more time.

[davelab6]

@hkrish did you publish the code anywhere? :)

@lehni any news? :)

[iconexperience]

I have been working separately on this issue using a different approach than Hari. Instead of creating the outer offset and inner offset path, I cut the path into curves. Then I subdivide each curve into several parts and apply an offset algorithm to each subcurve. Finally the offsets of all subcurves must be combined.

The code for the subdivision of a cubic curve and the offset algorithm for the subcurves is more or less finished. After cleaning it up a bit I will post it here, so we have a second starting point for implementing the path offset feature. So far it looks like the implementation works for an arbitrary cubic bezier curve and IMHO the result is quite satisfying. The whole algorithm is rather simple, which on the other hand makes it quite fast. Here are two examples:

But there is one remaining obstacle:
In order to have a clean result for the offset operation, the offset paths for the subcurves need to be combined to one single path. But unfortunately the current implementation of the boolean path operations do not produce the expected results.

@lehni or @hkrish, do you see any chance that the boolean operations can be improved, so they can handle overlapping paths, self intersecting paths, and in general produce more predictable results (the usage of a random number seems to produce, well, random results :-))? I think if the issues with the boolean operations can be solved, there is nothing that can stop Paper.js from getting a very nice path offset feature.

Thanks,

Jan

[hkrish]

Your code seem to work pretty well for single curves; how does it work for paths?

Anyway, I need to focus a bit on the boolean code. We have the basics in place to remove the dependency on random (a new cubic solver etc.). I will hopefully get some time these coming weeks, and keep you guys updated.

/hari

On 2014Oct16, at 07:50 pm, Jan notifications@github.com wrote:

I have been working separately on this issue using a different approach than Hari. Instead of creating the outer offset and inner offset path, I cut the path into curves. Then I subdivide each curve into several parts and apply an offset algorithm to each subcurve. Finally the offsets of all subcurves must be combined.

The code for the subdivision of a cubic curve and the offset algorithm for the subcurves is more or less finished. After cleaning it up a bit I will post it here, so we have a second starting point for implementing the path offset feature. So far it looks like the implementation works for an arbitrary cubic bezier curve and IMHO the result is quite satisfying. The whole algorithm is rather simple, which on the other hand makes it quite fast. Here are two examples:

But there is one remaining obstacle:
In order to have a clean result for the offset operation, the offset paths for the subcurves need to be combined to one single path. But unfortunately the current implementation of the boolean path operations do not produce the expected results.

@lehni or @hkrish, do you see any chance that the boolean operations can be improved, so they can handle overlapping paths, self intersecting paths, and in general produce more predictable results (the usage of a random number seems to produce, well, random results :-))? I think if the issues with the boolean operations can be solved, there is nothing that can stop Paper.js from getting a very nice path offset feature.

Thanks,

Jan

—
Reply to this email directly or view it on GitHub.

[iconexperience]

@hkrish The code only produces outlines for single curves. But since a path is simply a chain of curves, the offsets for the path can be created with applying the boolean unite on the curves' offsets.

The only problem are the corners at the path segments. When iterating through the curves of a path, handling the corners could be done like this:

• After creating the offset for the subcurves, check if the handle-in and handle-out of the original end segment are parallel.
• If parallel, nothing needs to ne done, the ends of the adjacent curve offsets will match.
• If not parallel, add a little triangle to the last subcurve's offset to fill the gap to the next curve's offset. The line between the open ends can either be straight (bevel corners), an arc (rounded corners) or a straight extrapolation of the tangents (mitered corners). Creating this triangle should be relatively easy.
• The boolean operation (that we need to apply anyway to unite the offsets of all curves) should then be able to unite the curve offsets seamlessly, as the end of the curve offset will match the beginning of the next curve's offset.

Here is a (not very good) illustration on where the triangle needs to be:

Actually, I think the really difficult part is to resolve the issues with the boolean operations. I would love to help, but I fear that this goes beyond my capabilities. One thing that I can do is trying to implement the corner handling described above to see if it works.

Jan

[davelab6]

Maybe @frank-trampe can help with the boolean; he worked on FontForge's this year for me, and there's also http://www.angusj.com/delphi/clipper.php which is used in RoboFont

[lehni]

@iconexperience, very interesting! I look forward to seeing it all in action. Your plan how to merge the curves sounds good. We'll have to see how the two approaches perform and how precise their results will be. Boolean operations will also be required to handle strokeCap, for either solution. And the mentioned issues with the boolean code are well known, it's just a question of available time at the moment to fix them.

@davelab6, @frank-trampe, help is always welcome! But as far as I understand, Clipper only handles polygons, not bezier curves, so it won't be of much use here.

[davelab6]

On 17 October 2014 00:28, Jürg Lehni notifications@github.com wrote:

@davelab6 https://github.com/davelab6, @frank-trampe
https://github.com/frank-trampe, help is always welcome! But Clipper
handles polygons, not bezier curves, so it won't be of much use here.

Its used in RoboFont on Bezier paths, via
https://github.com/typemytype/booleanOperations

[lehni]

@davelab6 yeah but it looks like the paths are flattened beforehand, which is far from ideal, no?
(with flattening I mean conversion to line segments through sub-division: https://github.com/typemytype/booleanOperations/blob/master/Lib/booleanOperations/flatten.py)

[kuribas]

I have written code for calculating an offset curve from a bezier curve in haskell:
https://github.com/kuribas/cubicbezier/blob/master/Geom2D/CubicBezier/Approximate.hs
My code takes a discrete number of samples from the offset curve, and approximates a bezier curve through them. If the tolerance of the curve is larger than a given tolerance, I subdivide where the error is largest. To approximate, I calculate a least squares approximation, using the chord lengths as parameters, then improve the parameters by making a new guess of the parameters. I repeat this process until it converges. I have found a way to make it converge much faster by improving the guess of the parameters. It will give the best least squares approximation of the curve. For subdivision I just take the point with the largest error, by checking discrete number of samples.
The offset curve has a singularity when the radius of curvature and the offset distance are equal, so I find these points by solving an equation numerically, and use them as endpoints for the bezier curves.
I have not made a comparison with other algorithms, but it seems to work fine. Alternatively you could calculate a hermite spline interpolation from the offset curve. It may give more subdivisions, but is possibly faster than my algorithm. I haven't tested this yet... It seems that the lib2geom library, used by inkscape, uses this approach by converting to the symmetric power basis.

For boolean operations I am working on a line sweep algorithm, which will work in (n+m)log(n+m) for n points and m intersections. It's an adaptation of Bentley Ottman (http://en.wikipedia.org/wiki/Bentley%E2%80%93Ottmann_algorithm), and uses the bezier clipping algorithm for finding intersections (http://tom.cs.byu.edu/~557/text/cagd.pdf).

[kuribas]

I forgot to mention that Chebychev polynomials also are a good candidate for interpolation. They have the good property of keeping the maximum error minimal (rather than the mean error when using least squares). It may be interesting to compare these different approximations for speed and accuracy. For real-time use, a faster algorithm that generates many bezier curves may be better, while for generating an output file, a slower algorithm that has better accuracy may be desirable.

[kuribas]

A rough outline of my boolean operations algorithm can be found here: http://kuribas.github.io/omegafont/algorithms/overlap.html

[hkrish]

Hello @kristof, for offset curves, we chose the method due to Hoschek et.al.
after the comparison done at http://dl.acm.org/citation.cfm?id=618434.
Hoschek's method is conceptually simple and quite performant. Thanks for
the input (Hoschek's method is quite close to what you described above). I
guess we can benchmark it eventually on local offsets. Although, the most
difficult part was the global offset.

All those edge cases!

Our presently-unfinished implementation in paper.js is complete and quite
fast while doing local offsets. Most of the work has to be done at the path
level. So I am really looking forward to see how we can solve some of the
issues related to global offset. I will write a post here with specifics.
All suggestions are welcome. I am almost out of ideas here :)

Again, @kristof, the sweep-line boolean ops sounds awesome. I am really
excited to know that you are working on it. That seems to be the right
approach. I have been outlining a similar approach for using a sweepline to
do boolean operations, just like they do for polygons. Bentley–Ottmann's or
Balaban's are great references. I am trying to implement an efficient
multiresolution curve datastructure to support the algorithm, since in this
case the curves has to be split so that they are monotonous in x and y.
(curious to see that in your case you are splitting only in one direction.
We should exchange notes, I think I can learn a lot from you progress so
far. :))

Although as a first priority I am committed to solving the problems in
paperjs' current boolean implementation. If any of you are interested in
joining me, that would be really nice. Please ping me, I will explain how
it works, and what are the issues we have found so far.

I have a question related to this, any information regarding this is
welcome. Many of the "surprises' in our boolean implementation are due to
loss of precision in the floating point arithmetic involved. Specifically
so when really odd sized curves are created as part of splitting etc. Many
CAD and illustrator like softwares seem to include a "precision" parameter
for boolean ops. And we know that the polygon implementations use "snap
rounding". So, have anyone tried snap rounding beziers? Are there any good
algorithms or case studies?

Thank you.

/hari

On Fri, Oct 17, 2014 at 3:38 AM, Kristof Bastiaensen <
notifications@github.com> wrote:

A rough outline of my boolean operations algorithm can be found here:
http://kuribas.github.io/omegafont/algorithms/overlap.html

—
Reply to this email directly or view it on GitHub
#371 (comment).

[kuribas]

hi @hkrish. If I am not mistaken, the Hosheks method is similar to mine, except that I try to improve the guesses of the sample points for calculating the least squares solution. This is slower, but gives a more accurate curve. This matters for me, because I want to calculate the least amount of subcurves, and speed is secondary for my application.

I think snap rounding may work for bezier curves. In my algorithm I used snapping to other points, but the algorithm gets very complicated, so it may be worthwhile to look at snap rounding instead. The important thing when rounding is to look out for changes in topology, because they may cause errors in the output.

If I can help with your current issues, let me know.

[lehni]

@hkrish, @kuribas do you think both methods could perhaps be combined, with a optional argument that decides weather the algorithm should be optimizing either for speed or quality of the resulting curves?

When experimenting with the code that @hkrish has already written, one of the remaining concerns I had was the production of too many sub-curves under certain circumstances. If the two approaches could be combined, that would be ideal! @hkrish, is it too early to share code? Would a collaboration make sense here?

(Not intending to step on anyone's toes here, just really excited about the activity in this thread : )

[iconexperience]

I have created a Plunker for my code on offsetting a single cubic bezier curve.

You can drag the end points and handles of the curve, zoom in and out (+ and - key), pan (arrow keys), and change the offset distance. I found playing around with it to be quite addictive.

You can find the plunker here: http://embed.plnkr.co/jkNGoe8fD0li9DmY7u76/

(note that there seem to be problems with Safari and Internet Explorer)

My aim was to have a starting point for creating curve offsets that are visually "good enough" with breaking the curve into as few sections as possible. My aim was not to create mathematically precise offset curves, so please do not use any of this code for technical applications.

The result is far from perfect, parts of the code are rather clumsy and the mathematics are not very sophisticates, but it allows changing parts of the algorithm quite easily, so if you like to tinker around a little bit you may find this useful as a simple base application.

Some details about my algorithm:

• First I break the curve into segment curves at the inflection points and the points that I call "peaks". These peaks are the roots of the cross product of the first and second derivative of the curve. They are especially usefull if the curve has a loop. Finally I break all sections that have an angle larger than 60° into smaller sections. There is no specific reason why I chose 60°, it just seems to work well.
• For each section I create two offset curves, one with positive and one with negative offset. I am using an algorithm that keeps the angles at the end points and the distance at t=0.5. I tried some other algorithms (like Tiller-Hanson), but this seems to give me the best overall results.
• The two offset curves are connected with straight lines at the ends.
• Finally, I can merge the section offsets into one single path, which may have self intersections.

What I cannot do at the moment is to take the merged offset path and remove all the self interesections. If someone can point me to a document that shows how this can be done, I would be very thankful.

That's all for now, I hope you enjoy playing around with it.

Jan

[davelab6]

What I cannot do at the moment is to take the merged offset path and remove all the self interesections. If someone can point me to a document that shows how this can be done, I would be very thankful.

@kuribas wrote above on this topic,

For boolean operations I am working on a line sweep algorithm, which will work in (n+m)log(n+m) for n points and m intersections. It's an adaptation of Bentley Ottman (http://en.wikipedia.org/wiki/Bentley%E2%80%93Ottmann_algorithm), and uses the bezier clipping algorithm for finding intersections (http://tom.cs.byu.edu/~557/text/cagd.pdf).

and he also did http://kuribas.github.io/omegafont/algorithms/overlap.html :)

[glenzli]

It seems this feature is still missing officially. I was design an animation editing tool and ran into this problem. I found that by the offset algorithm, there are some unwanted self-intersections. I was intend to implement same funtionalities as Adobe Illustrator's offset path and expand stroke.
I managed to cover most of the cases, and I write it as a small extend library for paper.js. I just want to share it here in case someone needs it.
The package name is paperjs-offset. It append two methods for Path & CompoundPath: offset and offsetStroke. Here is the running result of the lib.

[lehni]

@luz-alphacode this looks great! After looking at your code, I am wondering though: Did you consider using the work I posted above as a starting point? You can see it at http://bl.ocks.org/lehni/raw/9aa7d593235f04a3915ac4cef92def02/

The actual code you can see here: http://bl.ocks.org/lehni/raw/9aa7d593235f04a3915ac4cef92def02/offset.js
This includes code that handles joins and ends, through Paper's own already existing internal functions, such as Path._addBevelJoin(), Path._addSquareCap(), etc.

The offsetting code itself works really well and is based on A New Shape Control and Classification for Cubic Bezier Curves by Shi-Nine Yang and Ming-Liang Huang.

The only reason why I haven't added this to paper.js yet is issues with self intersection when expanding the offset to outlines. These issues are in the boolean operations code, and I so far have not managed to find more time to try and resolve them.

Could you explain how you addressed the issues with self-intersection in your code? Can we merge these two efforts into something that can be integrated in the library officially?

[glenzli]

I've test my code again and found that my solution of finding self intersections performs reasonable for closed path but will fail on some type of open paths, and I've got some ideas about improving it. I'll check these ideas and come back later for dicussion. @lehni

...
I've tried to imporve the solution but not really successful, and it's too late in my zone and I'll try for another idea tomorrow, the issues of self-intersection detection is somehow can be related to a clockwise or counterclockwise comparision. Self-itersected path will create a a loop reverse to the direction of the original curve. But complex curves can be partial clockwise, partial counterclockwise; I think maybe I should break the curve to do it. I'll come back later to explain my idea in detail, after I get some sleep.

[melchiar]

Great to see progress on this feature! If it's of any help, I've run a few tests using the latest code from @lehni and found a bit of weirdness in certain cases where a point's handles are aligned perfectly (example below)

var pathData = "M288 216H0V44.514c21.206 0 32.848-.841 62.371-16.358C81.174 18.271 107.746 0 143.999 0c36.255 0 62.827 18.271 81.629 28.155C255.15 43.673 266.794 44.514 288 44.514V216z";

[shagarah]

Any updates / release times please?

[lehni]

@shagarah I've worked some more on it recently, but am again swamped with work currently, so can't give a timeline. I want to release this soon as part of a final v1.0.0, but it needs more tweaking to be reliable enough.

[hujiulong]

Hey guys, is there any progress on this?

[northamerican]

i can offer a financial bounty to anyone able to iron out the remaining issues with the offset code.

@lehni @glenzli @sapics

[thexperiments]

Wow I did not realize how complicated that is. Started some project with paper.js assuming this would be a nobrainer and now I‘m stuck.

What is the current status here?

Are there any workarounds via external libraries?

Thanks

[lehni]

@northamerican I should have time to start working on this again in about 6 weeks. Please get in touch at juerg@lehni.org so we can discuss this further. Thanks!

[lehni]

@northamerican did you try to get in touch? I didn't receive anything :)

[northamerican]

@lehni e-mail has been sent. ready to discuss when you are.

[martin19]

@lehni: Thanks very much for your work on this. I've got a question/comment about your offset code posted above: If I understand correctly the connect method works by connecting offset segments using the join-type set through the paths stroke style (round, bevel). Is there an exact definition on how the outline feature should work in this regard ? Is there a way to connect segments by "elongating" them and computing their intersections - this works for straight lines - I'm not sure about bezier curves? About your statement above: "These issues are in the boolean operations code" - can you give some more hints on what is going wrong? I haven't found a reference to the boolean op code in your snippet. Thanks!

[NoZ4]

I have written code for paper.js for offsetting, please find it here : https://github.com/NoZ4/paper.js-offsets
Im not good with javascript or mathamatics and its taken me 6 months to produce this. Its for procedual generation of cad designs for laser cutting

I found offsetting curves and paths are easy, its the self intersections that are the real problem along with floating point errors
so in my code I work out where self intersections will occur first and trim curves before offsetting them

Also even if curves dissapper becouse of offsetting the points where curves originally touched must be taken into account I have code creating paths along these points, with arcs.

it works with compound paths, using winding rules, so doughnut shapes can be shrunk/expandid.

I know my code has better accuracy than inkscape, i haven't tested against others.

Im quite cheery that if you expand enough the paths become a circle, or if shrunk turns into a point

it takes into account where paths totally disapper becouse they cant be offset that much and curves/paths inverseing

I got examples on github that show what i mean.

I really hope this can be of use otherwise ive wasted alot of time on nothing

[michaeltford]

Hi, first I wanted to say that I recently started using paper.js and I am amazed. I am porting a tool that renders shapes from Java to Javascript and paper.js is making this very easy. There is one problem that I am am not able to figure out.

I need to be able to render complex paths and find the bounds of these paths. It looks like I can use offset (if it's ready?) but is there a way to render double strokes or other styles? (Similar to below?).

http://www.jhlabs.com/java/java2d/strokes/

My most basic use case is to draw and capture the bounding rect of a double/triple dashed line (Similar to what PowerPoint calls a Compound Line)

https://www.officetohelp.com/powerpoint/how-to-make-compound-line-in-ppt.html

In Java2D these can be done by create a 'Brush' that walks path segments and allows for the ability to render something at each segment. (The work involved is very complicated because of rotations, miter sizes, drawing joins and all the other complicated things that people here understand better than me.

[NoZ4]

hiya,
with proper working offsets double strokes should be really easy, 5 offsets would be needid. so you have your path which would be the center of your line, you offset it + and - then you have two new lines you just need to cap off, then if you want a double line you offset the original path + or - , just more than you did before and repeat what you did for the original

dashed line should be easy just create gaps in the inital path.

brushing is something we dont have at the moment i think, but shouldnt be too hard to impliment, get even points along a path and just clone whatever you want onto that posistion.

Im currently working on my code, Im not doing double/triple line but am doing lines with variable thickness etc i'll be updating in about a week if thats any use

[michaeltford]

NoZ4. Thank you for the response. I will wait for your updates and then try to build a double/triple stroke using your technique. During my research I didn't find any JavaScript implementations of brushing. (I assume because of off the hidden complexity, google slides has an internal one they use) but paper.js seems to be very close.

I thought I would also add a picture from Powerpoint to show you the effect that I am trying to achieve.

Looking forward to trying this out!

[NoZ4]

Hiya everyone

Just thought i would give a update, my code now allows to stroke a path
example images :
https://github.com/NoZ4/paper.js-offsets/blob/master/VariableWidthstroke.SVG
https://github.com/NoZ4/paper.js-offsets/blob/master/Stroke.SVG
https://github.com/NoZ4/paper.js-offsets/blob/master/InverseStroke.SVG

theres a few known issues, shown on the page

@lehni do you think it would ever be a idea to add this to the main code? also I used a bit of your code for offsetting single curves

I think this might be a bit quicker than lehni's approach, since i got some escape early functions, but for things like square caps etc I think lehni's approach is much better.

Thanks for all the thumbs up etc before :)

Thanks everyone Noz

[northamerican]

hey, seekers of path offsets.
i have yet another option, paper-clipper to share with you. as @lehni wrote above in 2014, the Clipper library handles polygons only. however, it is very accurate in creating offsets for paths without segment handles. this library harnesses Clipper's performant boolean operations (see clipperUnite) as well as its offset functionality. it flattens Paper Paths, offsets them then applies a specialized simplify to restore curves, with good results.

with this external dependency, it isn't viable for inclusion in Paper of course but it's performant and reliable enough for my artistic uses. maybe it will come in use until we have native functionality working and approved.

if you are curious as to how it applies smoothing to the path after offsetting, refer to paper-clipper/paperClipperSimplify.ts. it uses Paper's Path#simplify method on split up pieces of the resulting offset path. this helps retain sharper corners on which simplify overcompensates.