ofn-path-edits

[Ofnuts]

(05-17-2021, 07:06 AM)teapot Wrote: Hi,

I've been using ofn-path-edits for ages and it's extremely useful.

However having recently changed it from v0.9 to v0.10 I'm getting some odd results in the way paths are displayed after doing break path apart.

Starting with the original path visible, I did break path apart.

Then when clicking on and moving anchors in the new paths they look like lone anchors when they are not.

Opening a new view of the image all is fine in the new view. The paths are fine if exported and imported. So it's something odd about the display of the lines.

Here's two views of the same file after I've moved some of the anchors in the left one, none of them are lone anchors. The blue line is in the old position.  The right view is correct reflecting the moves.



When the visibility of the active path is switched off the blue line in the left view remains and the correct active path line appears reflecting the moves I made.  The right view is correct with no path line visible.



The behaviour is different if the original path wasn't visible before doing break path apart. The visibility of the generated paths is on but there are no path lines visible.

So it looks like the visibility of the original path and the generated paths isn't working.

I reverted to ofn-path-edits v0.9 and for the same path I cannot get the problem to occur, so that works fine.

Eventually I tried commenting out these two new lines in v0.10 and that seems OK:

'gimp_image_freeze_vectors' in dir(pdb) and pdb.gimp_image_freeze_vectors(image)
'gimp_image_freeze_vectors' in dir(pdb) and pdb.gimp_image_thaw_vectors(image)

Thank you for any help to resolve this.

The freeze/thaw instructions are meant to disable display updates that may take significant processing time.if you leave them in but add pdb.gimp_displays_flush() after the thaw, does it work better?

[teapot]

(05-17-2021, 11:06 AM)Ofnuts Wrote: The freeze/thaw instructions are meant to disable display updates that may take significant processing time.if you leave them in but add pdb.gimp_displays_flush() after the thaw, does it work better?

Thanks Ofnuts. I didn't try adding a display flush as there's already one within protected() soon after the thaw:

   'gimp_image_freeze_vectors' in dir(pdb) and pdb.gimp_image_thaw_vectors(image)
   pdb.gimp_image_undo_group_end(image)
   pdb.gimp_displays_flush()

I've access to two machines with different versions of gimp and have seen the fault on both:

Machine one:

   gimp 2.10.10

Machine two:

   gimp 2.10.24
   python2-gimp 2.10.24

The workaround of commenting out the freeze and thaw works on both.

[Ofnuts]

That would be a Gimp bug then... Will check this out.

[teapot]

Thanks Ofnuts.

On further testing similar issues apply to break text path apart and break path apart by nesting order.

Also thinking that maybe gimp doesn't like break path apart changing the visibility of the paths during the freeze I tried another workaround, I reinstated the freeze/thaw and commented out these lines in break path apart:

strokePath.visible=True
path.visible=False

The display was then OK. So that's an alternative workaround although it was handy to have the script turn on the visibility of the generated paths.

[Krikor]

My English is poor, so I couldn't understand the problem reported by Teapot.

But I tried to check if there was anything abnormal with the plugin, and in fact now that I was able to reproduce the problem I started to understand what Teapot had discovered.
I confirm that the same is true with my version 2.10.21 Samj's portable.

The palliative solution I found was:
Close and open the path view before trying to edit it.

If before editing the path resulting from the 'Break path apart' operation, its visibility is closed and then reopened, the editing view becomes in real time.

[teapot]

Hi Ofnuts,

Thank you again for your extreemly useful path edits, I use many of them frequently.

I just noticed an anomaly with Join Strokes.  The example below has two stokes the first with anchors 1 and 2, the second with anchors 3 and 4.  Before running join strokes the handle of anchor 3 was dragged out to the same location as point 4. Here is the before and after join:

   

   

[Krikor]

Hi teapot,

I tried to reproduce your report, but I didn't find a difference between the before and after joining the strokes.

In the image below; from top to bottom:

The 'before', without the union of the strokes. You can see 4 markers displaying the position of the anchors for each stroke.

The 'after', after joining the strokes, only 3 markers showing the existence of anchors. (Final anchor marker becomes middle marker)

   

[Ofnuts]

(10-03-2022, 05:54 PM)teapot Wrote: Hi Ofnuts,

Thank you again for your extreemly useful path edits, I use many of them frequently.

I just noticed an anomaly with Join Strokes.  The example below has two stokes the first with anchors 1 and 2, the second with anchors 3 and 4.  Before running join strokes the handle of anchor 3 was dragged out to the same location as point 4. Here is the before and after join:

I suspect some shenanigan with anchors that have only one tangent. To quote a code comment:

Code:

    # If there is no backward handle on the first anchor of s2, use the coordinates
    # of the last anchor of s1 instead.

Can you attach the XCF with the strokes before the join?

[teapot]

Hi Ofnuts, Here's the before join .xcf which is the same as I described earlier:


  beforejoin.xcf (Size: 2.59 KB / Downloads: 159)

[Ofnuts]

OK, uploaded a hopefully fixed version. Tell me how it goes.