The “e” is also the only letter there with an “island”. Not sure if that has any thing to do with it, but it might be an interesting test to modify the e so the loop didn’t fully close, or try other letters in its place, like p, a, d, b.
Obviously you don’t want a sign that says Kitchbn, but the test might reveal something.
Thanks for the suggestion. That had occured to me, but I had another word that had an “a” in it, same font, same size, and that rendered fine (I also replaced the “e” with an “a”, as you suggested, and that did create a path for it). That other word also contained a “B” and that also rendered OK, but the same word, in a slightly different font did not create a path, though the other letters did. I tried other fonts and they seemed to work. I do believe this is a bug.
Can you use a program like FontForge to check if the font has a problem? There are many fonts out there having issues. I rather assume a problem from that side.
I played with this for a while. It seems that the problem is the “e” is too close to the “h”. If I added a space before the “e” the V-carve worked fine.
It also works if the font is bigger.
I do not know if this is a bug or some basic limitation.
(I had to find and download the font to do this test. It would be useful to include the font in the posting when ShapeString problems occur.)
When I replace in the e the B-splines with arcs, i get some sort of a result. Alas, at the right upper corner I see very fancy paths. I tried increasing the tool diameter, but didn’t succeed. Kitchen_cb.FCStd (33 KB)
I have opened the font with FontForge; I don’t see any indication of a problem. I have also tried a different program for V-carving, F-Engrave; It has no problem generating a V-carve path, but the inter-character spacing it generates is quite a bit larger than what FreeCAD generates.
Interestingly when I try it the ‘e’ gets carved but the ‘h’ is missing. From what I can tell is somehow the voronoi algorithm discards all edges as being “exterior”, which means infinite in length.
Once an issue is added to the tracker, let’s try to keep the discussion over there. It’s easier to relate the discussion to specific code and eventually a PR for a fix.
mlampert
Thanks for the pointer to the Voronoi algorithm. Will look into it in the FreeCAD source, but I assume the developers will make a fix before I do.
Agreed. I posted the issue to the forum on the request of luzpaz in an email:
" @mhindi2 can you please zip the .FCStd file and attach it to the ticket. Can you x-post this to the Path forum.freecadweb.org to make sure this isn’t a 3rd party dependency or user-error ?"
That’s how it used to be: discuss in the forum first, add a ticket then. I thought that to be beneficial for the developers, because user errors could be filtered.
But shouldn’t we accept if the developers find something different to be better for them? That’s the new process, where the whole discussion takes place on Github.
