Sketching text fails if glyphs overlap

[jwebb]

System information

• SolveSpace version: e07b082eb810d2088c92b97d04e864a4ab95816f
• Operating system: Ubuntu 20.04

Expected behavior

Sketching 'Text in TrueType Font' should create a valid contour.

Actual behavior

The contour may be self-intersecting and therefore unusable if some glyphs overlap e.g. due to kerning. For example, the letters TY in DejaVu Sans Bold.

Additional information

While in general CAD software expects that users should resolve self-intersecting paths manually, this seems an exception: other than picking a different font or text this isn't in the user's control. I think the desired behaviour would always be to take the union of overlapping glyphs in this case.

[ruevs]

Yes, if a particular text in a particular font has overlapping glyphs - either due to kerning or "handwriting" fonts for example - then the sketch will be self intersecting and it will not form a valid solid when extruding/revolving/lathe-ing etc.

I don't think there is a general way to fix this.

[jwebb]

There is certainly general fix: When two or more glyphs overlap, generate a contour which is their union. That's a standard operation in any 2D vector graphics package, and Solvespace already offers it for 3D solid models. And it's the right solution because it's logically equivalent to how every font rasterizer handles the situation.

Whether it's easy or justified within Solvespace's framework is of course another matter.

[ruevs]

I understand. You meant the union of the 2d outlines of the overlapping glyphs. That makes sense. SolveSpace currently does not have this implemented for anything else, so it will be entirely new code. But it is possible.

[phkahler]

Split the curves for each glyph against the curves from the previous glyph. Discard the sections from each curve that are inside the outline of the other glyph. The tricky part is the word "inside", but I wouldn't be surprised if there is a lot of code already there that can be used in making that determination. Curve-curve intersection looks like it will be important for #1091 - second issue.

[ruevs]

In principle it is "simple" we already do all of it in 3d. The inside/outside classification I am VERY familiar with ;-)

But still it will require some thinking planning and "design" where to put it and how to implement it in a nice/flexible/clean way - maybe for future use - e.g. general 2d boolean operations.

[ruevs]

Here is a much older related issue https://github.com/solvespace/solvespace/issues/285 By the way SketchFlat could do this: