Export size bug (1.5 and back)

[smallreflection]

Perhaps I'm doing something wrong, but pixel-snapping and export size to me is one of the biggest outstanding issues that takes up a lot of time.

 

Essentially, even when keeping Force Pixel Alignment and Move By Whole Pixels turned on and making sure a shape is a whole pixel measurement, moving a shape, group, or whole artboard often still positions the shape on a partial pixel, resulting in an additional pixel on export.

 

The only workaround I've found for this is to go back to the Draw Persona, manually input an even pixel coordinate into the transform panel, then reattempt to export. That's fine for a few items, but if you're dealing with setting up numerous layers or artboards for export, that can be quite time-consuming.

[Ben]

If you have Move by Whole Pixels turned on - it'll move in whole pixel increments.  If your object wasn't on a pixel before you moved it, it'll still not be on a pixel - so, from 15.3 to 16.3, etc.  It won't snap it to 16.0.  Turn off Move by Whole pixels to correct you object, or enter a whole value in the transform panel.  Once you have it on a pixel position (including a whole pixel height and width), then your move will stay cleanly snapped to pixel positions.

 

Also - if you have other objects in your doc that are off-pixel, and you snap/align against them, then your object will be off-pixel.  It won't snap, then correct onto the nearest pixel.  A snap is a snap - it is precisely aligned to the snapping target, regardless of whether the target is pixel aligned.

[smallreflection]

Correct, and that's what I thought I'd done. I went back to do another test and it seems to be working as it should, so I think I realized what might've been doing it—when option-dragging a layer to duplicate it, because Opt allows you to break off of the pixel grid, I think that's what was causing certain layers and artboards to get off by a pixel even with Align to Pixel and Move by Whole Pixel on. Hadn't realized that before.

 

Edit: I just went and tested again, and in addition to snapping to other objects potentially jumping it off a pixel, Shift + Dragging also seems to always bump an object off the pixel grid. I'm sure that's a tricky thing to solve, but that seems to be going a bit too far in allowing objects to get off.

[Ben]

Yes - the conflict between Alt and Cmd dragging - we provided Cmd also to allow duplication on drag to allow for people to duplicate and snap at the same time.  Both duplicate, but Cmd doesn't interfere with snapping.

 

Shift drag should still conform to pixel snapping.  Again, pixel snapping is applied if there is no other snap.  Again, if you start off pixel, the constrained direction snapping will stagger across pixel boundaries.  I should perhaps draw some diagrams of how we apply the snapping logic - it was carefully thought out to allow for arbitrary axis of snapping while still conforming to the pixel grid, and allow for snapping to other objects.  I was not convinced by the method of snapping to objects then quantising to a pixel position - it seems to fight against all other snapping.  And, you effectively don't snap directly to other objects, which seems counter intuitive to me.

 

If you identify an error, can you upload an example document and steps to recreate the problem, then I can see what's happening. Other than that, I'm reasonably confident that the precision we apply to snapping should be way in excess of pixel tolerances.

[smallreflection]

Ah, that makes a bit more sense now I think. I had completely forgotten that Cmd+dragging also duplicated, I'd been so used to using Alt/Opt instead. That does indeed keep pixel-snapping going, however I'm pretty used to Opt/Alt (now Cmd) + Shift dragging when duplicating elements, and adding Shift does tend to almost always bump an item off the pixel grid, apparently because it's switching to primarily snapping to the preview shape being cloned.

 

That makes sense in theory, however for UI design and the like it would be nice if that was perhaps a setting to turn off/on, so that when doing precise work with a lot of shapes, we could still use Shift to keep elements in alignment with each other and roughly snap them to other objects, but ensure that everything still stays snapped to the pixel grid. It seems like if you wanted objects to primarily switch to snapping in relation to another shape instead of the pixel grid, you'd just turn the Force Pixel Alignment option off. I suppose alternatively though, if object snapping is keeping my elements in alignment, I don't really have a need to use Shift so much, and perhaps I should just break that habit. ;) Thanks!

[Ben]

That doesn't sound quite right... If your object start on pixel and you Shift-constrain, if you move in X or Y it should still be pixel aligned, unless you make a snap alignment with an object on the other axis - then you would find that the constrained his is still on pixel, but the other axis might have been aligned to another object off pixel.

 

If you constrain to a diagonal, then it should stay on pixel still, but there is greater opportunity for other snaps to send you off pixel, due to the way the pixel snapping is applied with a non X or Y constrain.

[smallreflection]

Right, that's what I had expected as well. However for me, Shift+dragging an object on the X and Y immediately takes it off the pixel grid, every time, at least it's seeming to. I'll try to drop a screencapture into Dropbox to show what I'm seeing.

[smallreflection]

Take a look—I've recorded a clip including modifier keys: am I doing something wrong here?

 

https://www.dropbox.com/s/wgso02vaxlnie7t/affinity-snapping-test.mp4?dl=0

[Ben]

Is this only happening when clone dragging? What about when just dragging?

[smallreflection]

I just tested again to be sure—it's happening all the time when just Shift + dragging, not only when Clone + Shift + dragging. The problem doesn't occur when just clone + dragging or dragging alone). So Shift seems to always be acting as an off-pixel-grid modifier key instead of just keeping the shape on the pixel grid and moving locked on an axis.

 

Since Opt/Alt seems to be an off-pixel modifier already, it seems strange that Shift would be doing the same thing.

 

I noticed if I keep the grid turned on with snap to grid, it definitely helps this problem a bit, but it seems like it shouldn't be going off-pixel even without the grid.

[Ben]

Ok - I've found the problem.  It'll be fixed in the next Beta.

[smallreflection]

Bless you! :D You're awesome.

[Ben]

Thanks for finding this - it was a single totally isolated bug.  Good spot.

[paolo.limoncelli]

Ok - I've found the problem.  It'll be fixed in the next Beta.

 

One more little point Ben!  :)

 

When you have a resolution different from 72DPI the "Force/Move pixels" keeps on snapping to "real" pixels.

For example:

 

• @144DPI - AD snaps to  .5pt increments (that are full pixels)
• @216DPI - AD snaps to .3pt and .7pt increments

 

Is it by design?

Pixels are not points, so it makes sense logically. 

 

As a user such a feature would suggest me to find "integers" in the inspectors/transform inputs/measures etc, regardless of the DPI I'm using.

It is a personal observation, I solved with grids, and I'm sure you discussed this point, but I'm still curious about you imagined it to work.

 

:)

[Ben]

Yes - the "pixels" are the internal document pixels.  It makes most sense in pixel based document.  In a non pixel document, if you turn on pixel preview mode - it is those pixels that you are snapping to.  Of course, that is affected by DPI.

The feature was primarily added for pixel based designs (web, UI, etc) rather than print.

[paolo.limoncelli]

 

 

The feature was primarily added for pixel based designs (web, UI, etc) rather than print.

 

Ok it makes perfectly sense, and this is how I work for web.

UI design is getting closer to "print" paradigm than in the past, so for these specific tasks I tend to use points rather than pixels, this is the reason why I asked.

[Ben]

Is this something we need to consider then?

 

I'm already going to look at pixel snapping to add sub-pixel, so perhaps we could have a "points" option.

[paolo.limoncelli]

I can expose you this scenario I had to manage recently, so you can value if it is worthy:

 

I started a UI project for a touch control panel.

The customer decided for a 4" touch screen, then (UI for prototype done and approved as usual...) switched to a 5"@1.5x (so wider and more dense).

I started this project in points @72dpi (1px = 1pt) so I had to up-sample and re-arrange anything in order to match the new production requisites.

The "snap to pixels" works no more in this case, but it is not a "real" problem since I've managed this with grids.

 

Obviously a "Move by whole points" and "Force Points alignment" should have been handy.

[Ben]

It would be fairly trivial to have an option to conform to pixels or points - I'll look into it when I'm back on snapping.  Obviously, using pixel preview mode becomes redundant in anything other than a pixel based or 72dpi document.  Back in the early snapping, I actually had an arbitrary invisible grid which later became the pixel snapping mode - so you could snap to mm, for example - but I wanted to reduce the number of snapping options as it was becoming over complicated.

 

If anyone else uses this approach, then I think it will be a reasonable change to make.

[smallreflection]

Wow, new beta out already with the fix! That was fast!  :D

[paolo.limoncelli]

 

 

If anyone else uses this approach, then I think it will be a reasonable change to make.

 

We are going to get a customisable multiplier in Export Persona.

So my use case in the future could be perfectly covered by a simple 1.5x for assets.

 

On the other side, if you're use the Apple Devices presets, these follow my approach (so you have the points/dpi combo) and the "move by whole pixels" is no more useful. 

 

PS. Wow! Blazing fast fix for ths SHIFT thing!  :ph34r:

[Ben]

Probably the best approach is for you to create some example files, and I can see what can be done to improve on snapping options to fit.