Jump to content
You must now use your email address to sign in [click for more info] ×

Now you clip, now you don't...


Recommended Posts

Nesting/clipping/parenting is behaving strangely in regard to the artboard. Moving objects outside artboard breaks nesting order, ruins clipping arrangements.

See the image, try the file included.

My expectation is that the objects within a shape MUST stay within that shape and not be taken out of it just because they have left the artboard area.

image.png.de58441f2e7efd3d7f5878f5e3da736f.png

breaking parent relationship.afdesign

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

Thank you @tudor for reply and explanation. I understand what you are saying, but 🤔 wonder what would be the purpose of this approach, what benefit it brings for User? IMHO, explicit, user-set parent-child relationship must be preserved. If parent is on the artboard children are, too. If parent is off the artboard children will be also, with preserved nesting. If User sets that relationship, app must observe it on the account that the User wanted them there.

Consider a scenario where a User is adding shapes to a parent object as to make a pattern. Maybe a carefully arranged, reusable pattern. Constellations, for example. Each time the User moves the constellations some stars that exit artboard fall out. So user puts the stars back in, nudges them, and they fall out again... and again... Losing user time effort and possibly the arrangement.

Grouping children helps a bit here, but again, if objects are manipulated by direct selection... stars will fall from the artboard. So I feel explicit grouping rules are not observed either.

An example illustrating this silliness that is below (most likely the worst constellation you will ever see)

image.png.52c72226873eee1910d74214cfde60e1.png

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

I believe this happens so we can easily move layers from one artboard to another artboard without needing to move the layer and then manually clip to the ‘recipient’ artboard; the moved layer automatically becomes a child of the ‘recipient’ artboard.

Because of this, the pasteboard acts as a ‘temporary way-station’ for the layer when the layer is moved outside of all artboards. Moving the layer from the pasteboard to an artboard then automatically makes the layer a child of the artboard. This couldn't happen if the layer was still a child of the original parent.

I haven’t been able to replicate the situation in the last image and the screenshot doesn’t show the Layers Panel so it’s difficult to see what’s happening. (Full-screen screenshots are generally more helpful than partial-screen-grabs.)

Link to comment
Share on other sites

Hi @GarryP, thank you for your thinking and sorry for incomplete information above. A screenshot incl. layer palette + example file this time. Window screenshot not used for conciseness. It would be great if you have the time to try.

A hypothetical Constellations graphics scenario. There is a map of sky inside a viewport. The task: select the constellations and move the sky within the viewport so that the star labelled Alba is right in the center of the artboard, preserving the spatial relationships and integrity of the constellation groups.

My workflow is: select the nested content and move as needed. The problem is that constellations South and Southwest keep falling out of my clipping shape. Of course, putting them back fixes that, but I wonder whether this is how the workflow should go?

User makes grouping and nesting relationships precisely to create coherent constructs in order to use them as-one. Mere positioning of such constructs must not break them apart. The user makes them and only the user can break them. Therefore, I opine that user's explicit nesting of objects within a shape must be protected and preserved rather than let Designer assume that, by manipulating their position some of the objects should leave the parent-child relationship.

...

One could group the groups within parents. In more complex situations that approach could make the problem more complex. Groups-within-groups-within-groups increase vertical hierarchical complexity, which slows down work (finding, managing...) and still the problem remains: some objects or subgroups will fall out due to this feature.

I encountered this problem when:

  • Using a complex project drawing and wanting to show only a part of it.
  • Working with a large abstract vector graphics to fill a shape...

Maybe I am fundametally wrong in my approach? Could be.

image.png.ecf30e67145fb5d55859d1a5c613102b.png

Put Alba to the center.afdesign

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

Thanks for the extra information and file; that makes it much clearer.

I’m not sure what should happen here.

As I said above, moving an individual layer out of the boundary of an artboard should put the layer onto the pasteboard, but, this is a bit of a strange situation as you are moving individual layers in tandem. It sort of looks right and wrong at the same time.

I think the current solution would be to group the groups, as you say, but I don’t know if that’s a good solution or not.
Maybe someone else has a better solution, or a better way for you to organise things so the problem doesn’t happen.

I think this needs staff involvement to say whether this is expected behaviour or not.

Link to comment
Share on other sites

You described it so well: "right and wrong at the same time". And yes, I think so too, someone should look into it.

For future consideration by staff, my arguments against the current status would be:

  • User is the king. Application must not assume and not commit destructive operations without user's permission.
  • User data (graphics arrangements in this case) integrity must be preserved.
  • Loosing objects when in creative flow does not feel nice.

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

How would we ever be able to drag a layer out of / off of an artboard and onto / into another artboard? I like being able to drag content from one artboard to another.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

8 hours ago, Aleksandar Kovač said:

I understand what you are saying, but 🤔 wonder what would be the purpose of this approach, what benefit it brings for User?

Let me give you an example: nesting the layers inside the artboard in a strict parent/child relationship allows us to move the artboards freely on the canvas, without worrying that some objects might end up on another artboard. (That happens in Illustrator, where an artboard will automatically grab any object that touches it. It's extremely annoying.)

Link to comment
Share on other sites

Hi @tudor, I see your point and I do remember Illustrator issue you are mentioning. Oh, old wounds. :)

Unfortunately, Designer displays the same extremely annoying behavior coming from the other end. Let me illustrate (no pun intended). (Please see the image below and attached Designer file.)

There are red and blue artboards. Red Artboard contains green clipping path with four stars inside. Select four stars via Layer panel and reposition them just a smidgen. Oh! Blue Artboard just stole two stars! ... The same stealing artboard issue as in Illustrator, but coming from the other end.

My expectation would be: Since green path is on red artboard, it's content must inherit that. When green clipping path moves to blue artboard, stars go with it and inherit that they are a part of blue artboard now. A proper hierarchical cascade of inheritance.

image.thumb.png.8c7644b8f4a1f626fc97597134c0bca4.png

 

Artboard is a thief.afdesign

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

 

Hi @Old Bruce, we move layers between artboards by moving them. :)

if you have the time, try the above file, select 4 stars and move them a little. Maybe towards left, so that the leftmost star sits in the center of clipping path. Perhaps you will see how blue artboard stealing stars can be problematic if your design depends on composition within clipping path.

In the example with red and blue artboards, moving green clipping path to blue artboard behaves IMO perfectly. Drag to blue artboard and the stars follow. Stars are subordinate (children) to clipping path and that relationship is preserved perfectly.

The problem IMO arises when moving nested objects. Moving yellow stars might result in a broken parent-child relationship.

From top of my head, in some other applications with nesting/grouping concept moving a nested object within its parent does not break parent-child relationship. I think I remember moving with a modifier key would override parent-child relationship.

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

For what it is worth I have no problem moving the stars, the one star or all of the sky anywhere on the artboard named page without loosing anything.

982139193_ScreenShot2022-12-13at11_55_10AM.png.cff581c12bbd5579d5325ecbccb59cb7.png The name is off the artboard

790404686_ScreenShot2022-12-13at11_54_47AM.png.a55cd48dd42b06928c89696eff93b13d.png  All the stars are moved

205568190_ScreenShot2022-12-13at11_54_19AM.png.60203210a7c4265dd8cd44ead27b2900.png  The whole thing is moved

2111485998_ScreenShot2022-12-13at11_54_04AM.png.d0320aa3c928c1d366bced236e1adf7f.png

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

I love the attention to detail you are giving UX behavior in your posts. Keep them coming.

I do agree with @tudor, I prefer we can toss things from artboard to artboard quickly as if they were physical objects. This seems to be the intention. Organizing elements can be very time-consuming when they have to be dragged artboard to artboard as in AI. The clipping behavior is a terrible side effect. Maybe we want to move chunks off the art board while we rearrange things. In some ways I like this UX approach, in other ways, not what I am always looking for when moving things outside the artboard if they have tangible relationships with the board they were in... but do appreciate also it is working like it takes up physical space and things can "fall out" of it in some sense. There's drawbacks there, but have to admit this approach on average is more intuitive. It's also nice that the Layers panel actually shows what is orphaned.

Link to comment
Share on other sites

2 hours ago, Old Bruce said:

For what it is worth I have no problem moving the stars, the one star or all of the sky anywhere on the artboard named page without loosing anything.

Thank you so much @Old Bruce for trying this out!

Cases 1, 3 and 4 are expected. Case on img 2 is interesting. Your image is clipped and it is not clear what happened to lower groups. E.g. Look at the result I get here when I select and move all 5 groups nested in "The Sky" clipping path. East, Southwest and South groups "fall out". Orphaned, yes, much better word. Thank you @debraspicher.

image.png.957ff76510d457bd35a668f6f1b033a8.png

 

...

And, when selecting and moving yellow stars in Red/Blue artboard file...

BEFORE moving. Notice one star is not on Red artboard but still is part of Red artboard, right? Logical and correct.

image.png.643417ae667e14db1ab91684af037eaa.png

AFTER moving: Two orphaned stars. Rats! That sneaky blue artboard stole 2 stars! Leave my stars alone! :)Logical? Not IMO, because User modified objects' position only and not its hierarchical relation. Here is perhaps where Designer assumes too much. They should remain a part of Clipping path which is not anywhere near blue artboard.

image.png.9da4f1b943cf3d446cf438331dadd7a9.png

EXPECTED after moving: Objects moved, Parent-child relation intact. Just like in BEFORE pic.

image.png.9ec5b8d147ac87e9604596a451cea757.png

 

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

2 hours ago, debraspicher said:

I do agree with @tudor, I prefer we can toss things from artboard to artboard quickly as if they were physical objects. This seems to be the intention. Organizing elements can be very time-consuming when they have to be dragged artboard to artboard as in AI.

Hi @debraspicher, yes, me too! Just don't like Designer tossing them out for me. :)

In practice, for design purposes, sometimes I make and use some kind of large non-repeating vector wallpaper and nest it in a shape. Then, to improve visual balance, or just eliminate repetitiveness, I futz around with that wallpaper. I move it, scale, add, remove, rearrange parts inside that parent shape... and that's when the things start to fall out and apart. The same when dealing with a large geographical vector map or an architectural drawing and you'd like to focus on some detail using cropping shape. Stuff falls out and apart. Hence this thread.

I did try to use nested groups which eliminates this problem to a degree, but not completely + introduces complexity in Layers palette (empty groups, effort to name groups...) and forces user to read Layers palette instead of looking at objects on the board. Oh, it also takes more time, measured. (sorry, that's what UX/UI phd does to weakminded).

My AI adventure lasted from v7 to CS3 so I cannot recollect this problem there anymore. Still have AI flashbacks and an incidental sentimentality (calligraphic pen, vector effects, blending... mmm)

IMHO, perhaps using modifier key while moving an object could be a way to explicitly override parent-child relation here? Or dragging them out of the relation via Layers palette?

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

On 12/13/2022 at 1:14 AM, Aleksandar Kovač said:

Moving objects outside artboard breaks nesting order, ruins clipping arrangements.

At bottom-left of Layers panel is the Edit All Layers button. It actually has an effect on Artboards, not just Layers (note the uppercase L). 
The default state of Edit All Layers is 'enabled', as seen in your screenshots. 
When it is 'disabled', objects will not jump out of an Artboard.

Link to comment
Share on other sites

@,,, , you Master! Thank you for teaching me (us?) this.

Moreover, it is documented in Help, too. Straightforwardly...🤦‍♂️ (and I thought I did my homework)☺️

Quote

Objects created within artboards are clipped inside the artboard by default.

With Edit All Layers enabled, you can easily move objects between artboards, and also between pasteboards and artboards. This is called reparenting.

In the layer stack, the object will be repositioned to be within the target artboard object.

Thank you for this solution! Thanks everyone for discussion + XL excuses for wasting time of those who knew.

I'm tagging this 'solved'.

Alex

Mac Mini M1, mac OS Ventura

Affiñititos, how about a roadmap? (but with v2.1 efforts ... massive, tremendous improvement!)

Link to comment
Share on other sites

4 hours ago, N.P.M. said:

But Owen, one can also use the released objects to sit either above or beneath the (transparent)artboard and become a visible item of the exported file.
Not that this is the request in this case here though.

Not sure why your comment starts with "but".

Link to comment
Share on other sites

  • 1 year later...

I also want to complain about the crop function. My experience is that it fails 99% of the time, even on simple pictures. See the attached file.
Affinity doesn't do anything. Gimp produces the 2nd picture.

2nd observation is that when it works, and you copy + paste to another program OR export it as e.g. PNG and load it in another program,
it looks like the clipped part is hidden and still present in the file.

 

Screenshot 2024-01-28 at 14.45.03.png

xxx.png

Edited by loekf
Crop and clip mixed up
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.