After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769022 - Improve text along path when path is short
Improve text along path when path is short
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal enhancement
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2016-07-21 08:27 UTC by Massimo
Modified: 2016-12-27 15:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
text along path: truncate excessive text (3.73 KB, patch)
2016-07-21 08:27 UTC, Massimo
rejected Details | Review
text along path: extend guiding path (3.21 KB, patch)
2016-07-21 08:28 UTC, Massimo
none Details | Review
text along path: extend guiding path (3.11 KB, patch)
2016-07-21 08:35 UTC, Massimo
committed Details | Review

Description Massimo 2016-07-21 08:27:34 UTC
Created attachment 331855 [details] [review]
text along path: truncate excessive text

When the length of the path along which the text layer
content is warped is shorter than the width of the text
the excessive text is somewhat mapped to the origin (0,0).

This behavior is often confusing users
(see http://gimpforums.com/thread-weird-line-when-creating-paths or
 http://gimpforums.com/thread-text-along-path-error)
and hardly something to be usable.

I think it would be better to either truncate the excessive text
or warping it along the tangent of the last path stroke, probably
this is not what the user is going to use (she'll probably reduce
the font-size or extend the guiding path), but it should help
not considering it a bug and look for help on forums.



Attached a patch to truncate the text and to the next comment a
patch to extend the guiding path.
Comment 1 Massimo 2016-07-21 08:28:42 UTC
Created attachment 331856 [details] [review]
text along path: extend guiding path

Alternative approach
Comment 2 Massimo 2016-07-21 08:35:15 UTC
Created attachment 331857 [details] [review]
text along path: extend guiding path

Alternative approach. (fixed version)
Comment 3 Jehan 2016-07-23 13:14:39 UTC
Both versions have their interest in my opinion. Truncation is more a way to tell the user "something is not right: fix your text or your path, then try again". Therefore it should be accompanied with an error/warning or something to make sure the user noticed the end of the text is missing, the risk being that one fails to see the missing text immediately, thinks everything is good and continue editing.

On the other hand, I like the extending the text along the tangent and it makes some sense too. It may actually even be what the user wants. Let's say I want some text to finish straight, I could just warp the part I want warped and expect the rest of the text to be aligned with the finale tangent.

So I'd say extending along tangent is my favorite approach right now.
Comment 4 Jehan 2016-07-23 13:19:56 UTC
By the way, both patches tested and reviewed. Works well and all.
Comment 5 Jorg K 2016-12-11 08:44:39 UTC
Would you mind shipping this eventually. I think extending on a tangent is best. That means that if the path is just a little too short, the result will still be usable, the user might not even notice the condition.

I'm not sure why this is classified as an enhancement. I ran into this problem again yesterday and it's just highly annoying that lines are drawn from the text to some off position.
Comment 6 Jorg K 2016-12-11 09:31:22 UTC
(Sorry, I never received the bug mail, so testing again.)
Comment 7 Jehan 2016-12-14 00:35:53 UTC
I agree with comment 5 that it is worth committing, and as I said in comment 3, I also prefer the extending along tangent approach.

Massimo > were you unhappy with something in your patch which explains you don't push it? :-)
I will ask Mitch if he is ok on his side, and will push your patch when I get some time to test it again, so if you want me to hold this, tell me in the next few days.
Thanks!
Comment 8 Jehan 2016-12-21 21:41:11 UTC
Review of attachment 331857 [details] [review]:

Ok so as I was saying, this looks like the best approach to me. Mitch was not responding, but I know that end of year is particularly busy for him, so I'll just take the decision and push. The code looks simple enough, which is a good thing, and it does what it says.

commit 99050ecee6a8240125d511496fd6f9a7f44165e7
Author: Massimo Valentini <mvalentini@src.gnome.org>
Date:   Thu Jul 21 10:31:53 2016 +0200

    Bug 769022 - Improve text along path when path is short.
    
    Extend the text along the tangent of the last path stroke.

 app/vectors/gimpvectors-warp.c | 49 +++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 45 insertions(+), 4 deletions(-)
Comment 9 Jehan 2016-12-21 21:42:37 UTC
Review of attachment 331855 [details] [review]:

This patch is rejected in favor of the alternative which I find much more artist-friendly. If anyone has comments and won't to come back on this behavior, feel free to comment or reopen.
Comment 10 Øyvind Kolås (pippin) 2016-12-27 14:02:52 UTC
Is bug #169616 (still open) a duplicate of this one?
Comment 11 Jehan 2016-12-27 14:19:05 UTC
So I had a look at bug 169616. They kept it open apparently for a nicer non-destructive approach to the text along path feature.

They explain it in bug 169616, comment 4: attaching a vector to each text layer, you can warp the text layer. Editing the text would re-render the warped text (oppositely to now where if you change the text, you have to run a new "text along path" since the feature basically generates a path reproducing the text.
Comment 12 Øyvind Kolås (pippin) 2016-12-27 14:42:18 UTC
The the title of bug 169616 should be changed - or IMHO a new one focused on the specific improvement should be opened; making it easier to navigate the gimp bug collection.
Comment 13 Jehan 2016-12-27 15:00:29 UTC
I just did an update. But you are right that maybe we should open a separate report.