Legal self-intersecting input for offset operation

[olologin]

I was reading your sources recently, and it seems I identified couple of input classes which are going to produce good offset results if we have self-intersecting inputs.
I know that normally your recommend resolving self-intersections (via Union) before passing such inputs to offsetter, but in some scenarios we can avoid this it seems, and save some CPU time when we use clipper.

Scenarios:

1. Positive offset of open polylines should not suffer from self-intersections in inputs, because ExecuteInternal will produce all resulting paths (including self-intersecting loops caused by concave joins) in CCW orientation, and this means winding number of any point inside offset is going to be positive. Besides, these self-intersecting loops caused by concave joins have no way of ending up somehwere outside of the offset capsule => they have no way to add false area to the result => Union will form correct output.
   By "self-intersecting loops caused by concave joins" I mean these blue things near point 1, some examples:
   

2. Positive offset of convex polylines that dont have any holes. Of course each convex polyline must not have self-intersections, but multiple convex polylines in the same input can intersect with each other without any harm to the result. ExecuteInternal will produce convex output for each input, which will have CCW direction, and Union will be able to form correct output.

Am I right? Maybe you could add (1) to the documentation. (2) is too specific, and maybe useless to normal people reading documentation.

[olologin]

Other information that I could derive from your code, I hope I am not wrong :)

Examples of problems with self-intersections in closed inputs.
(Below red is CCW curve of a body, green is CW curve of a hole, each picture contains input (leftmost image), ExecuteInternal result (middle image), Union result (rightmost image), as I imagine it.
Hole sticks out of a body - Small positive offset:

Overlapping bodies - negative offset:

Regarding orientation of these "concavity loops":

• With positive offset ExecuteInternal produces result where each body offset has these loops in CCW orientation, holes also have these loops in CCW orientation
• With negative offset ExecuteInternal produces result where each body has these loops in CW orientation, holes also have these loops in CW orientation.

This points me on the following classes of bad inputs that will definitely cause some problems:

• Positive offset of a polyline with concave join can add false area if this join happens to lie over some place where there is no area (hole of another offset, outermost "void")
• Negative offset of a polyline with concave join can falsely substract area if this join happens to lie over some place where there is an area (body of another offset)
• Hole of one body intersects another body

[AngusJohnson]

Positive offset of open polylines should not suffer from self-intersections.

With regard to the documentation here that states "offsetting should not be performed on self-intersecting polygons as doing so will almost always produce unexpected results", this advice does not pertain to open paths (polylines). It's quite OK to offset polylines that self-intersect, though doing so will flatten the resulting polygon generated by the offset.

The following example offsets an open path that self-intersects and demonstrates flattening of the overlap region:

  PathsD subject = PathsD{ MakePathD({10,10, 100,200, 10,200, 100,10}) };
  PathsD solution = InflatePaths(subject, 10, JoinType::Round, EndType::Joined);

Edit: I've now updated the documentation to further clarify this.

[olologin]

Thanks for documentation update!