ofn-text-along-path

[Ofnuts]

   

This is a general upgrade of the text-along-path script. The changes are:

• Removed the Gimp-2.6-specific code
  
• Fixed the positioning of characters (no more residual jitter)
  
• Added "Repeated" layout option
  
• Added "Reverse path direction" option
  
• Added "Boxes" option
  
• Fixed handling of closed strokes
  
• Improved performance (paths not added to image unless necessary)
  
• Repackaged/renamed "ofn-"
  

Enjoy.

Comments, suggestions, and bug reports welcome as usual.

Usual place is here.

[Blighty]

Thanks Ofnuts
Been playing with it. Very good.

[Espermaschine]

Whats 'Spacer' for ?

Is that for the new Repeated mode ?

[rich2005]

(10-16-2017, 08:00 AM)Espermaschine Wrote: Whats 'Spacer' for ?

Is that for the new Repeated mode ?

Yes, It is described in the 'Docs' that come in the zip archive.

The characters to be inserted between each repetition of the text, when using the Repeated layout.

   

[Ofnuts]

As Rich says.

The purpose of having a separate text is that on an open path, the spacer isn't added at the end. On a closed path, you can use the spacer but this should give the same results as putting the spacer as part of the text. In some future version I could add a specific font for the spacer (so you can use dingbats...).

[Espermaschine]

I had a look at the Doc (the images), but missed the link.
Thanks for clearing it up.

Great work ofnuts !

[rich2005]

Not dingbats but some odd characters copied and pasted from a character map.

   

[Ofnuts]

(10-16-2017, 10:48 AM)rich2005 Wrote: Not dingbats but some odd characters copied and pasted from a character map.

Your example makes me think that it would be nice to have an option to separate the paths for  text copies and spacer copies. This would make it easier to apply different post -processing to each category (for instance, colors...).

[Ofnuts]

I notice that t-a-p does something incorrectly: when it lays out the text, it considers the character boxes. This means the character boxes are flush with the beginning/end of the path, but the characters, which usually are a bit inside the box, are not. A picture being worth 2¹⁰ words, you get the blue path below instead of the red one (the guide paths both go from one vertical guide to the other).

   

Now, the big question. Is there any use for the current wrong behavior (margins are of course kept where necessary) and should I leave it as an option (more complex code, more parameters, more doc) or should the code stick to correct behavior (a user can always shorten the path if necessary...)?

[Blighty]

(10-22-2017, 10:58 PM)Ofnuts Wrote: Now, the big question. Is there any use for the current wrong behavior (margins are of course kept where necessary) and should I leave it as an option (more complex code, more parameters, more doc) or should the code stick to correct behavior (a user can always shorten the path if necessary...)?

If you hadn't pointed out the wrong behaviour I don't think anyone would have noticed. Not worth adding the option.