-
-
Notifications
You must be signed in to change notification settings - Fork 101
Description
I came across a .gds file that contains some degenerate paths that traces back over itself, such as: path.curve = {{0, 0}, {100, 0}, {0, 0}}.
Gdstk loads these without any error, and converts these to polygons, but in a manner which in my point of view seems problematic, since a path with manhattan orientation is converted to a non manhattan polygon.
For example, the path (as visualized with klayout) in the left of the below image is converted to the polygon in the right.
I understand that it is not well-defined how gds readers should handle such cases so each reader may follow a different approach. Also, I've seen that gdstk provides several approaches to handle joins (Natural, Bevel, Miter, Round, Smooth) and even allows using custom Functions.
Currently, in order to avoid problems in my application, I have slightly modified the Natural approach as follows:
segments_intersection(r1, tr0, r2, tr1, u0, u1);
const double half_width = half_widths[2 * i];
u1 = -u1;
if ( u0*u1 != 0 && u0 <= half_width && u1 <= half_width) {
const Vec2 ri = 0.5 * (r1 + u0 * tr0 + r2 - u1 * tr1);
right_curve.append(ri);
} else {
const Vec2 ri0 = r1 + (u0 > half_width ? half_width : u0) * tr0;
right_curve.append(ri0);
const Vec2 ri1 = r2 - (u1 > half_width ? half_width : u1) * tr1;
right_curve.append(ri1);
}
The only difference here is that I've added the term u0*u1 != 0 in the first condition and this seems to work without problems for all cases I've encountered. Do you think this is a reasonable approach and if so, would it make sense to revise the Natural algorithm?
Thank you
