matisso

@MEB, this is just a Modal Windows.afdesign file from the Grade UI Pack, like I said. For the sake of convenience though – there you go. There's also the screenshot of the Snapping Manager you asked for. And a few more showing moments when it goes “wrong”. However, I don't really think the snapping settings are the key here. It’s the snapping that takes over pixel alignment that appears to be the problem. Cheers, Matt Modal Windows.afdesign

This is pure gold, I must say. Cheers, Matt

Thanks @MEB for the hint on snapping to objects. Indeed this might be likely is the issue, I had my mid-points snapping on while testing this on the Grade UI file (I had all of them ticked, to be exact). It's worth noting that it doesn't always behave like this. I had to make a few attempts to recreate it, because sometimes the object snapped right into the pixel grid – that would actually explain the mechanism you described. However, if it also happens that it doesn’t snap where it’s expected, well, something isn’t right. @arechsteiner pretty much nailed it – it says force, so please actually force. Right. So I actually played with it for a bit longer, trying different snapping options and carefully observing what is happening with the object as it snaps to different candidates. It looks like this behaviour is also caused by snapping to objects that are off-grid. Text is notorious for creating such situations, as it doesn't follow the pixel grid. You might select all the text objects in the layer palette, and choose “Exclude From Snapping” option from the context menu. Then again, that would be extremely tedious to do it for every text object in your design and for every objects that you prefer to stay off the grid, for better antialiasing or whatever different reason. That's where another limitation comes in, namely the lack of selection of objects based on their kind, attributes, or so. Enter Illustrator: Select / Text Objects. Among other selection options, like select similar objects, same opacity, colour, stroke weight, etc. But still it wouldn't address the underlying issue of objects not being pixel aligned, or snapping taking priority over it, if you like. That’s actually easy (from a user’s perspective, ofc) – ideally, give the user a choice in preferences. One option would be to force integer values, another one – allowing fractions in pixel forcing mode. Or make the decision on your own, like Adobe did. For the record, in the described case Illustrator snaps to either smaller or larger integer value, ± 0.5 pixel difference depending on from which side you draw the second, smaller object. It doesn’t make any difference to the eye. When centering objects manually with the help of smart guides, the object stays pixel aligned (technically being 0.5 px off the centre of the one it’s being aligned to). If you use an align feature, and centre them, it aligns perfectly, not pixel-perfect. Then again, Illustrator also has the “Align selected art to pixel grid” feature. Sorry for a slightly harsh tone of my previous post. It’s just that I see a lot of potential in Affinity apps but when I try to use them in a real world environment (aka actual work) I run into various glitches and I end up doing things longer and less comfortably than I would have done it using Adobe apps. Sure, a part of it happens because I’m far (well over ten years) more experienced in the latter, but some features like this clearly work in unpredictable ways (the infamous constraints/ungrouping issue being just another example). Cheers, Matt

Same issue here. This has been around since 2014 (see https://forum.affinity.serif.com/index.php?/topic/452-pixel-snapping/) and still isn't properly implemented. Meanwhile it's 2018 and I'm getting this (this is a part of Grade UI pack, which everyone who has Affinity can grab): Just moved the top box, with with pixel snapping turned on, without snapping override (Alt-key). Fraction coordinates, blurred artwork. When is this going to be fixed? As in: working? When preparing this screenshot I drew an artboard to export this part of the file. Guess what: despite pixel snapping the artboard got a half-pixel height. FFS. I paid for both Affinity apps and even got my company to buy another copy of Designer. I get to read a flurry of posts about yet another platform releases, awards of the year, how Affinity can replace Adobe apps, whereas basic stuff like this still causes trouble. This is extremely frustrating and disappointing. Cheers, Matt

I won't even bother to download this, @dutchshader. Read this carefully: let's say you have twenty layers/objects but sandwiched between each pair of them are other objects that must remain where they are. In this scenario you will still need to select the layers you want to move one by one and keep it that way. If you group them, the sandwiching will be gone. Locking an object within a layer isn't a solution either. You might expect (I did) that if one object is locked, it would remain in place when moving the layer that contains it. However if you move the parent layer, the locked object follows, too. Cheers, Matt

Yes please! I'm amazed, not to say a bit disappointed, that this had gathered so little attention. Linking is essential for the reason mentioned in the above post and groups are not a substitute. Cheers, Matt

The first image in the stack isn't just nested. It's a parent's object mask, to be precise. If I remove it – and there's still another image clipped inside the parent object – all works as expected. For the record, I have also found a workaround for it – if you select the parent object and then use the node tool to select all nodes, you can move the parent object and the problem doesn't occur. Cheers, Matt

The flickering it does made me think of display issues. But the contents of the clipping path actually do get moved around, when you inspect them. Go figure…

Hi, @Sean P, no problem, there you go! It's a bit hefty, probably due to the bitmaps. I wonder what you guys come up with. Please remember to tick the Lock Children setting. Why isn't this persistent? It doesn't quite make sense, IMHO… Cheers, Matt W1_cover_bug_2.zip

Hey guys, I don't really know how I should look for that (basic search didn't come up with anything), so if that's been already reported elsewhere – sorry! Having that out of the way, let's begin. There's an odd stuff going on in Designer when moving a clipping object which also has a mask and Lock Children ticked. Please see the attached video. Basically, when I move the parent clipping path, the objects that are clipped and are supposed to stay in place (because Lock Children setting), hop around and pop into some random places. Also, when undone, the parent object comes back to place but its contents often doesn't. When I repeatedly Redo / Undo it goes back to place eventually, as the end of my clip also shows. The said mask is disabled on my clip but I tested it with the mask back on and exactly the same thing happens. I also tried rasterising the clipped image, changing its blending mode back to Normal, but neither helps. Only removing the mask “fixes” it. Cheers, Matt Affinity-mess.mp4

Oh, right.Yup, sadly, it looks like a bug. When you change colour of the text in a symbol instance (unchecking «Sync» toggle prior to that, of courses), the attributes that get unlinked are «Text, Text Frame», so it basically breaks most of synchronization except the size (even that works only when you resize the text using its bouding box – setting font size directly doesn't work, either). Cheers, Matt

Oh, wow. So great and so nice of you to share it! Thanks a lot, much appreciated! Cheers, Matt

Confirmed. I used that quite recently when I was preparing multiple variants of a responsive website. So, enjoy. Cheers, Matt

It's been a year and a half since this was posted and we're still waiting for it… I'm just working on a logo in AD and need this transformation so badly. It's a shame we need to revert to other apps with such a basic feature, guys! regards, Matt

Did it go completely ignored, I wonder? It's a quite convoluted way to have to export a bitmap just to be able to distribute many repeating objects along a path. Losing size-independent scaleability in the process is a bad thing, too. cheers, Matt

I ran into this just recently. Are you guys planning to fix this, @Sean P? It's still present in the current beta. Constraints certainly shouldn't prevent the user from intentionally arranging objects, do you agree? Cheers, Matt

Could that rather be set as a preference, please? While I agree it's sometimes distracting and unnecessary, it's not always the case! cheers, Matt

It would be so much better if there was a preference for that: insertion mode toggles (I'll leave proper wording to you, alright?). Best of both worlds, no supposed confusion and control for those that need it. Cheers, Matt

Yes, MEB beat me to it. :) I've made a screenshot of the Slices panel for you. You can also add several formats and set different resolutions for each of them if you wish. The last, expanded slice in my example will output two PNG files, the first one will be 640 pixels wide, another one – 480. regards, Matt

+1!

This the first sentence on the Perfect Exposure site: Also – don't all caps at everyone here. :lol: Have a nice day! Matt

Erm, yes, a fat +1 from me on this one. I've been struggling enormously with groups and constraints, too. These random relocations upon grouping/ungrouping are a total efficiency killer. Please, please, fix this. @MEB: Do you still need a sample file or have you been able to replicate the problem? [edit] Gaah, I didn't notice this thread is in Bugs on Mac section. However, this happens on Windows (10, 64 bit) as well. I will post another bug I discovered today, unless it's been already reported. cheers Matt

Bump from me as well. It's been three years since this was requested? :blink: regards, Matt

I see there's already such a request here.

@dutchshader, not quite. Unfortunately, dragging with Alt also changes the adjacent nodes to sharp ones. As stated in the help file: The feature I describe shouldn't break the curve continuity. If the nodes are smooth, they should remain so. regards, Matt