Is there a script or plugin out there that can automatically merge/intersect overlapping paths?
When it's a text path I can sometimes get away with
ofn-path-edits > Break text path apart then
ofn-paths-to-selection, but the mileage varies depending on the font and it's still a few steps to get done.
I know inkscape is always an option as well, but it has its own issues.
I just wondered if it was even possible to script a true
merge paths in gimp, or even a way to break apart and add all to selection in one go?
[
attachment=4328]
You could be lucky (or not) using ofn-text-along-path and asking for one path per character (and then using ofn-paths-to-selection), though OTAP works better with more "rectangular" fonts.
(05-08-2020, 04:07 PM)Ofnuts Wrote: [ -> ]You could be lucky (or not) using ofn-text-along-path and asking for one path per character (and then using ofn-paths-to-selection), though OTAP works better with more "rectangular" fonts.
Thanks for the reply.
I'm guessing that it must not be possible to do any kind of union of paths in gimp then. I've always just worked around the issue on a per project basis and wielded inkscape if needed, but didn't think I've ever actually asked. I guess I should make an official feature request then, or upvote an existing if already asked for.
Cheers!
ofn-paths-to-selection does it for paths. But what you have is a jumble of strokes. Hence my suggestion to see if OTAP works well enough with your font since you can make it produce one path per character.
One solution (the solution?) to your problem is to have oriented strokes, where for instance clockwise strokes select the inside and counter-clockwise strokes select the outside (so the two strokes of an "O" would be opposite for instance). Then the final selection is the union of all the selections from CW strokes intersected with the union of all the selections from the CCW strokes. But this requires strokes to be closed, have no loops; and makes hand-made paths harder to use because you now need to be able to control the direction of a stroke.
(05-08-2020, 10:26 PM)Ofnuts Wrote: [ -> ]ofn-paths-to-selection does it for paths. But what you have is a jumble of strokes. Hence my suggestion to see if OTAP works well enough with your font since you can make it produce one path per character.
One solution (the solution?) to your problem is to have oriented strokes, where for instance clockwise strokes select the inside and counter-clockwise strokes select the outside (so the two strokes of an "O" would be opposite for instance). Then the final selection is the union of all the selections from CW strokes intersected with the union of all the selections from the CCW strokes. But this requires strokes to be closed, have no loops; and makes hand-made paths harder to use because you now need to be able to control the direction of a stroke.
I see what you mean now with OTAP but I could just adjust the kerning in the text dialog to achieve the same thing so the letters are not touching before using text to path, unless I am missing something. Directional strokes are certainly more than I want to tackle for a normal project.
I usually run into this while recreating a logo. Most logos are not just straight text and they will squish, skew, tweak, or otherwise manipulate the text in one way or another. So once I identify the font or something close, I will size and adjust the kerning to match it as close as possible before turning it into a path for further manipulation. So it's at this point where is would be nice to merge/union the resulting path for filling and stroking if needed.
I don't understand how inkscape is able to union a collection of strokes properly. It can take the same path that looks garbled in gimp and make it render properly. Unfortunately when you copy it back to gimp it acts as if it was put in a clipboard blender.
I guess I'm wondering why gimp can't do a union on the actual path/strokes. Is it fundamentally not possible with the way paths were developed in gimp from the get-go?
InkScape possibly uses the stroke orientatiion. Experiment:
- Create text with letters having inner loops
- Layer>Text to path
- Break path part with my script (which AFAIK keeps the stroke orientation)
- Stroke each path with Fade>Color dynamics, with a two-colors gradient and a short fade length
Result:
It is easy to see in which direction each stroke is stroked (the red to green fade). Coincidentally all outlines (including the dot on the
i) are clockwise and all the holes are counter-clockwise.
Experimenting further using a character with a dot inside a hole (the zero in some fixed-width programming fonts), this rule is confirmed:
Conclusion: hang on. If I find a way to determine the orientation of a stroke, I could have a solution before the end of the weekend. Can you post an XCF with your text path?
(05-09-2020, 10:12 AM)Ofnuts Wrote: [ -> ]Conclusion: hang on. If I find a way to determine the orientation of a stroke, I could have a solution before the end of the weekend. Can you post an XCF with your text path?
Absolutely.
Thanks for investigating this.
Plot twist: I found that your path was exactly the opposite of my text paths, outlines are CCW and holes are CW... so I tried with more fonts and this is font-dependent, some fonts have CCW outlines, others are CW. Could depend on the font type (OTF or TTF), and this could explain why Gimp doesn't rely on that (Gimp doesn't know the font type). Makes things a bit harder, I have to add an option
Yikes!
Is it possible just to look for the difference between the inner and outer, regardless of direction?
In the general case, no, because you can have silly special cases like diacritics (the dot of a "i") that get included in a nearby character.
However, as far as my tests go if there are CW and CCW fonts, both types use opposite directions for outlines and holes. And it is likely poissible to determine the CW or CCW nature of the font by looking at the direction of the longest stroke (which should be an outline).