Jump to content
AFeyt

Snapped objects still have a pixel gap between them (2020)

Recommended Posts

I've probably read all the posts on the forums about this topic. Even the ones from almost 3 year ago. Yet the issue still remains. Is there a way to snap objects together without having a gap between the objects? I have tried the force pixel alignment and move by whole pixels. I also find that this does not only happen when snapping shapes to shapes, but also having a shape on top of another shape. It is also visible when a shape is on the side of the art board and exported to PDF format. I also tested this in Adobe Illustrator CS6, which is old, and I don't see this issue when putting shapes next to each other and exporting the file to other formats(jpg, png). The strange part is, while writing this post, I tested it in two documents. In the one I see the gaps and then in another the gap between the two shapes are gone. Please see the documents attached with examples. snapping_test.afdesign shows the gaps and snapping_test_successful.afdesign exports correctly without showing any gaps in the exported file, only in Designer itself. Please explain this, or I would really appreciate if this can be fixed or improved with an update. 

snapping_test_successful.afdesign snapping_test.afdesign

Share this post


Link to post
Share on other sites

Welcome to the forums.
Some notes:
* Your page is not whole pixels in size.
* Some of your layers are not aligned to pixel boundaries – do you have “Snap to Grid” set to ON?
* Try zooming to 100% - does that look better?
See my attached image (open and zoom in), where the lines have gone after some tweaking of positions and sizes.
I can’t help with the ‘edge of the page’ problem but maybe someone else can.

Annotation 2020-05-02 123044.png

Share this post


Link to post
Share on other sites
24 minutes ago, AFeyt said:

I've probably read all the posts on the forums about this topic. Even the ones from almost 3 year ago. (...) Please explain this,

  It was explained, e.g. by @MEB, to be related to the way Affinity renders the screen view. It can also affect the appearance of e.g. a selection marquee.

You might have noticed that this gap is "not real": it does not increase with zoom level. Here for instance a  200000 % and a 145 Mio % zoom view:

1074286407_zoomviewrenderissue1.jpg.ea7614b92c903e054371ad6299cccdce.jpg  876235326_zoomviewrenderissue2.jpg.23401d8484a4c49e42e6ad7742be21d4.jpg

34 minutes ago, AFeyt said:

It is also visible when (...) exported to PDF format.

There it's quite similar and particularly in PDF generally an occurrence since ages, depending on e.g. the PDF version, its transparency and flattening settings, the viewer app and the zoom level. (not to confuse with a similar PDF occurrence which appears on print, too.)


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24", Affinity in Separated Mode (documents merged)

Share this post


Link to post
Share on other sites

Thank you @GarryP and @thomaso for your explanations and advice. 

I did some further testing now, applying all the information given by you. I changed my document to be whole pixel sizes and aligned the shapes on the "Pixel Grid". This resolved the issue. In other words, if I choose any of the paper presets that measure in millimeters, I need to change the Document units to pixels and remove the decimal digits e.g. A4 preset(210mm x 297mm) which is 2480,3px X 3507,9px when changed to pixels, should be rounded to 2480px X 3508px. This removes the lines or gaps between the snapped shapes since exporting the image rounds the dimensions to whole pixels(2480px X 3508px) and not paper size(210mm x 297mm)

In summary:

1. Make sure document is whole pixels.

2. Make sure shapes are aligned on the pixel grid ( Made visible from View -> Show Grid or Ctrl + ' )

Share this post


Link to post
Share on other sites

There may be some confusion between different terms.
Snapping is not the same as Aligning. You can align one, or more, things to another thing but this may or may not involve snapping.
The wording of “Force Pixel Alignment” confuses this a bit more as that makes sure that the X and Y coordinates of a layer coincide with the whole pixels of the document (unless, sometimes, “Move By Whole Pixels” is also ON).
Using snapping to grid can also make things go a bit strange as it can override the Force Pixel Alignment in some cases.
If you are not using the grid then don’t set “Snap To Grid” to ON, but there's  no such thing as a 'pixel grid' (unless you specifically create one).
Now I’m starting to confuse myself.
Maybe someone else can come up with a better explanation.

Share this post


Link to post
Share on other sites
1 hour ago, GarryP said:

The wording of “Force Pixel Alignment” confuses this a bit more as that makes sure that the X and Y coordinates of a layer coincide with the whole pixels of the document (unless, sometimes, “Move By Whole Pixels” is also ON).

Just in case you might know: I never could get a clear experience with these two buttons. For instance in this screencast: why aren't only whole pixels but still decimals available, with either one or both buttons? As if the first would not cause any "force" and the second would not make a difference either ...


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24", Affinity in Separated Mode (documents merged)

Share this post


Link to post
Share on other sites
6 minutes ago, thomaso said:

For instance in this screencast: why aren't only whole pixels but still decimals available, with either one or both buttons? As if the first would not cause any "force" and the second would not make a difference either ...

Because snapping takes precedence over pixel alignment, and some snapping locations are at fractions of pixels.

Share this post


Link to post
Share on other sites
15 minutes ago, anon2 said:

Because snapping takes precedence over pixel alignment, and some snapping locations are at fractions of pixels.

Ah, yes, when I deactivate snapping entirely then pixels are whole only. – But again: Why?, since I have activated "Force..." in the snapping prefs, too:

902654594_pixelalignment-snapprefforce.jpg.28f62fb37166ff8fb29816954c8f5c35.jpg

 


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24", Affinity in Separated Mode (documents merged)

Share this post


Link to post
Share on other sites
48 minutes ago, thomaso said:

Ah, yes, when I deactivate snapping entirely then pixels are whole only. – But again: Why?, since I have activated "Force..." in the snapping prefs, too:

902654594_pixelalignment-snapprefforce.jpg.28f62fb37166ff8fb29816954c8f5c35.jpg

 

My answer is the same as before - snapping takes precedence over pixel alignment. (The checkbox inside the Snapping Manager and the button on the toolbar are two locations for the one toggle.)

Share this post


Link to post
Share on other sites
10 minutes ago, anon2 said:

My answer is the same as before - snapping takes precedence over pixel alignment. (The checkbox inside the Snapping Manager and the button on the toolbar are two locations for the one toggle.)

Does it mean, there just can't be a setting for snapping which 100% prevents any decimal use of pixels? Because snapping can be caused by more aspects than an object's border and position (e.g. by a single node on a curve)? – Correct?

Is this snapping also the reason that enables me to draw an object with 1/2 pixel height (as in my video above) ? Because every object can cause a snapping by its 50% height which caused the 1x1 px object to enable the 0,5 px height for the new objects drawn next to it?


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24", Affinity in Separated Mode (documents merged)

Share this post


Link to post
Share on other sites
11 minutes ago, thomaso said:

Does it mean, there just can't be a setting for snapping which 100% prevents any decimal use of pixels? Because snapping can be caused by more aspects than an object's border and position (e.g. by a single node on a curve)? – Correct?

Here is the best solution for snapping on pixels and only pixels. Consider the midpoint of a 301 pixel wide object, that is object geometry. Any line not 90 or 180 degrees is going to have most of it's length not on pixels.

1022643508_ScreenShot2020-05-02at9_57_53AM.png.97eb8db0978f6600595eae18f51a12ff.png


MacBook Pro (13-inch, Mid 2012) Mac OS 10.12.6 || Mac Pro (Late 2013) Mac OS 10.14.6

Affinity Designer 1.8.4 | Affinity Photo 1.8.4 | Affinity Publisher 1.8.4 | Affinity Designer Beta 1.8.x | Affinity Photo Beta 1.8.x | Affinity Publisher Beta 1.8.x

Share this post


Link to post
Share on other sites

I’ve spent two hours on this issue and here’s my insight:

  1. canvas size (width, height) should be in pixel, integer, and most importantly EVEN NUMBER
  2. canvas position (x, y values) should be in pixel and integer
  3. all of above apply for shapes too
  4. For precision, move shapes by their xy values instead of snapping 
  5. no gap

another route: 

  1. create shapes
  2. manually move each shape so that they overlap by 1 px
  3. no gap
  4. Outline precision be damned

tl;dr

you can get rid of the gap but at what cost? Time? Precision? Ugliness (add a same colour background to disguise the gap)?

Everyday I doubt the reliability of affinity products in a professional setting and yet I still work with them. Guess the frustration is just part of the process.

Share this post


Link to post
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

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.