Aligned objects not actually aligned

[konstantnnn]

When I perfectly align one image next to another, a tiny gap appears between them, a tiny seem appears.

Example 1: Let's put these three images one next to another

When exported, the final result has a tiny gap between each photo. When zoomed in, this is pretty visible. This is also visible while editing in the program.

Yes. I have perfectly aligned it. Yes. I am not a two year old. Yes. This is actually, how, it, works.

Example 2: Drop shadows not aligned, Case study: masterclass logo . png

Example 4: No, this is not just an issue with exported PNG files.

Even tho the objects are perfectly next to one another, its the same path just flipped, the background bleeds in not only on the center, but also on the sides where the orange flap is peaking through — even tho, technically, the orange flap is behind both objects.

[konstantnnn]

Objects in clipping masks have colors bleeding from portions that BY DEFINITION should not be visible.

This is ok on this high resolution document, but on lower res content like more than 2% of the whole object is just this red bleeding that shouldnt be there. Its virtually unusable.

My workaround was for YEARS to just match the color of the circle to the image, or to set opacity to 0, but this is NOT a solution! This is a temporary bandaid to a core rendering problem so many apps have.

Please find a way to fix this. Please! This is not just a rendering in the app, it affects EXPORTS!

[konstantnnn]

This happens cross platform, on macOS, iOS, Windows, Linux, in exported JPGs and PNGs, in printed PDFs from my printer, everywhere.

No, they are propertly aligned in the program. 

No, shifting everything "closer" or adding a stroke or doing anything else as a quick patch is not a real solution.

[Hangman]

On 8/7/2021 at 5:01 PM, konstantnnn said:

Objects in clipping masks have colors bleeding from portions that BY DEFINITION should not be visible.

This is ok on this high resolution document, but on lower res content like more than 2% of the whole object is just this red bleeding that shouldnt be there. Its virtually unusable.

 

[konstantnnn]

11 hours ago, Hangman said:

Thanks a lot!

Is this available on iPad?

Still not solving this very huge issue, but its so much better now

 

Do you happen to know why isnt this on deafult?

[Hangman]

That checkbox won't fix the other issue you have... these are two different 'issues' I think. There are numerous threads about the thin line 'issue' e.g., here...

Regarding whether the option for the 'use precise clipping' is available on iPad, this is the response from the Affinity moderator team...

Quote

"Precise clipping is just a display option. When you export, it will always export with "precise clipping", regardless of the tickbox being ticked or not. On the iPad, there is no tickbox, but when you export it should export with that option on by default. "

I've not tested this as I don't have the iPad version of Designer but hopefully you can confirm if it works for you?

No idea why it's not on by default though it sounds as though it's just a screen rendering, 'visual' issue if it exports correctly.

[konstantnnn]

37 minutes ago, Hangman said:

That checkbox won't fix the other issue you have... these are two different 'issues' I think. There are numerous threads about the thin line 'issue' e.g., here...

Regarding whether the option for the 'use precise clipping' is available on iPad, this is the response from the Affinity moderator team...

I've not tested this as I don't have the iPad version of Designer but hopefully you can confirm if it works for you?

No idea why it's not on by default though it sounds as though it's just a screen rendering, 'visual' issue if it exports correctly.

See…it doesnt export with precise clipping for me…unless that checkbox is ticked

[Hangman]

Which file format are you exporting to, on Desktop, both JPG and PNG export with zero bleed regardless of whether the precise clipping checkbox is ticked, PDF has a thin keyline but equally if you set the circle to no fill then the PDF is fine too.

Did you check it on the iPad as well?

[konstantnnn]

7 minutes ago, Hangman said:

Which file format are you exporting to, on Desktop, both JPG and PNG export with zero bleed regardless of whether the precise clipping checkbox is ticked, PDF has a thin keyline but equally if you set the circle to no fill then the PDF is fine too.

Did you check it on the iPad as well?

With any raster there is a gap, and with vector file formats the infinite zoom paradox is happening. Rasters include JPG PNG TIFF ETC and vectors PDF SVG and other stuff. Tried and true for years now, on all platforms, Windows Mac and iPad.

[konstantnnn]

3 hours ago, BofG said:

I understand where you are coming from with these things - it would be nice if the antialising was able to determine objects are next to ones of the same colour and so blend the two together. However that's just not how things work, so you need to approach things differently. I've not looked at all your examples, but the one of the orange bleeding through can be handled easily:

Of course it can and of course I did approach it and finish my job a few months ago, but if you use symbols for example to do easy symmetry, like in my case that inset flap in the white paper wrap, i duplicated the object as a symbol so i need to only adjust one side of that cutout, and the other mirrors it (to have an easier symetry workflow). I need the objects to be print size, i cant reduce them for display purposes. Adding a white box at the top of the area isnt a solution because now theres a white bump visible because of an another antialiasing issue, and now the top and bottom edge arent flat anymore. Joining the two shapes together isnt a solution, I need to only adjust the left half and the right to update symetrically and automatically. Like, as I said I finished my work but it was such a pain in my rear that I actually gave a thought about going to this forum to write about it. This needs to be solved and this is nuts.

[konstantnnn]

5 minutes ago, BofG said:

See attached. It exports to png fine, the line only shows within the Designer document. As I say, I understand your point however the issue is fairly easily avoided. Another user pointed out in the other thread that Illustrator gets around this by supersampling the output - which is something you can do. I very much doubt Serif will log any of this as a bug (although adding in automatic supersampling would be a great addition), so knowing how to efficiently work within the limitations is always a good thing.

symbol.afdesign 1.33 MB · 0 downloads

but it shouldn’t work like that… objects next to one another should be next to one another...

 

when an iphone 4 loses signal due to the way you’re holding the phone (covering the antenna lines), the proper respose is not “you’re holding it wrong”, its “lets fix it”

[konstantnnn]

3 minutes ago, BofG said:

Do you mean that in the Designer display it shouldn't show the gap?

Everywhere there are any objects in any format at any scale at any resolution at any device at any program in any document under any circumstances, if snapped right next to one another, should be right next to one another… Import export raster pdf svg vector, anywhere there are two things next to one another, even in the real world, they should be next to one another. I don’t realize how can anything otherwise be acceptable, especially as crutial as this

[konstantnnn]

Can you also figure out why did my “iOS 7” images at the top have a gap as well? All images had the same dimensions, I created a new document by opening one image, and then extending the crop 3X until it snapped to the third image. I also did it via new document and put a 3X scale to a round number inside width, and I also did it via artboards, in all cases, there was a gap between three perfectly aligned images in a whole pixel document with no “mm” or other stuff.

 

This is something I shouldn’t be worrying about.

 

And how the heck is this not applied to drop shadows as in the masterclass icon i worked on?!!!

[konstantnnn]

28 minutes ago, BofG said:

If you can post the source images I'll be happy to give it a try.

 

[konstantnnn]

2 minutes ago, BofG said:

Just a thought - are you using artboards and exporting via the export persona?

Here's how I'm doing it and it's kinda showing up

[konstantnnn]

5 minutes ago, BofG said:

 I can only assume either your artboard is not on an exact pixel or the images are not.

[konstantnnn]

4 minutes ago, BofG said:

How many decimal places is your UI set to show? (I'm grasping at straws). I've got all the same values here and it looks fine in Designer and exports without any issue so I'm baffled. Maybe post your afdesign file, I am running an older version so I cannot check it but hopefully someone else will be able to take a look.

I even now rounded the sizes up to a nice whole number and the issue is still here. Providing the file now

TEST.afdesign

[konstantnnn]

7 minutes ago, BofG said:

The sizes are already whole pixels as it's raster images. What I am referring to is the artboard/image positions in the document. The screenshot I showed before of the UI preferences is the important part - I think by default it doesn't show decimal places for pixels, so if your artboard/image is say a x/y: 0.02px your transform panel shows 0px and you are none the wiser.

I'm afraid your version of Designer is newer than mine so I cannot open your file.

Just open the file It's just artboards and images and nothing else that's in newer versions. It's pretty much backwards compatible with versions from 2017.

I changed that decimal setting when you told me, there are four decimal places visible and I saw that the width was "1331,5" or some not complete number like that so I squished and transformed the images to all be an even whole number and I aligned them and the "X", and "Y", and "Width" and "Height" positions are whole numbers now. The issue is still happening. Aldo be it, it's not anymore when exporting.

But still, let's say we started at the left side, and the image width was 254,543 pixels. And lets say I aligned a next image, SNAPPED it, and the next image STARTS at the coordinates 254,543PX and ends at 354,543PX. The program should have no gaps between the two, yet it has.

And the snapping tool should automatically snap objects together to literally the same position, like the magnet icon implies. This is so wonderful! This is a combination of a faulty magnet tool, faulty snapping, faulty number rounding, faulty decimal display, faulty antialiasing, they all sing in harmony!

Check the file if you can.

[konstantnnn]

Just now, konstantnnn said:

It's pretty much backwards compatible with versions from 2017.

I mean funny thing, from all the issues I already encountered, it would be just so brilliantly funny if somebody at Affinity even decided files shouldn't be backwards compatible now so there's an another voice to this harmonious choir

[konstantnnn]

I imported the two images into APPLE KEYNOTE and aligned them within 2 seconds with their guides. No gap.

Exported into PDF.

No gap.

I really didn't want to bring my opinions on why Apple develops superior software and why I desperately want them to design a desktop publishing app, but here we come. 

This is so easy. Import images. Align them. No gap.

That should be it! 

Seriously.

Is this that hard to grasp somehow?

So an end user has to worry about decimal places now?

This is just faulty engineering and lazy bandaid patches to cover up a flawed architecture beneath.

 

[konstantnnn]

Just now, BofG said:

I did try to, it states it's from a newer version and cannot be opened.

Hahahahahah, I cant believe it! Its just artboards and images, been there since the beginning. Thanks much mate anyways!! I can always jump hoops and get around this but, you know, why not just have them fix it

[Hangman]

2 hours ago, konstantnnn said:

I changed that decimal setting when you told me, there are four decimal places visible and I saw that the width was "1331,5" or some not complete number like that so I squished and transformed the images to all be an even whole number and I aligned them and the "X", and "Y", and "Width" and "Height" positions are whole numbers now. The issue is still happening. Aldo be it, it's not anymore when exporting.

This is key and the reason you are seeing the hairline, sizes need to be whole pixels, otherwise you are seeing the result of antialiasing on a non-whole pixel which is a side-effect of the way the rasterisation routine works... as you've now seen when the elements are both placed at whole pixel values and are using whole pixel dimensions there is no hairline on raster exports.

2 hours ago, konstantnnn said:

But still, let's say we started at the left side, and the image width was 254,543 pixels. And lets say I aligned a next image, SNAPPED it, and the next image STARTS at the coordinates 254,543PX and ends at 354,543PX. The program should have no gaps between the two, yet it has.

It will have a gap/hairline for the reason cited above...

2 hours ago, konstantnnn said:

And the snapping tool should automatically snap objects together to literally the same position, like the magnet icon implies. This is so wonderful! This is a combination of a faulty magnet tool, faulty snapping, faulty number rounding, faulty decimal display, faulty antialiasing, they all sing in harmony!

It does, there are no issues with the magnet/snapping tool in this respect...

 

Image on the left showing pixel aligned images - image on the right showing the subsequent JPG export with no visible hairline

 

 

Image on the left showing non-pixel aligned images - image on the right showing the subsequent JPG export which still has the visible hairline

 

Where there is an issue however, one which has still not been fixed despite being highlighted several times with support, is PDF export. PDFs are not exprting at the exact size of the source file...

If you take a look at the widths for each of your three source elements and then compare this to the widths of the same three elements once exported to PDF then you can see the issue...

They should be 1,330 px, 1,440 px and 1,330 px respectively however, the widths on PDF export are 1330.999668 px, 1439.999946 px and 1330.000419 px. All three images are correctly positioned but at the same time they no longer butt up with each other but overlap each other and because they are no longer whole pixel widths, the hairline is visible for the same reason.

The issue is even worse with SVG exports in that both the image width and image positions are incorrect on export, resulting in non whole pixel values for both.

PDF Exported Image Widths

 

It is possible to remove the visible hairline onscreen by adjusting the Coverage Map in the Blend Options, however, this is not necessary for raster export assuming everything is perfectly whole pixel aligned and it is ignored on vector export but at least it helps from a purely visual standpoint when creating artwork.

 

Visible Hairline Onscreen Using Default Coverage Map

 

 

Visible Hairline Onscreen No Longer Visible When Coverage Map Setting Adjusted

One thing I was going to point out with the file you uploaded is that the three elements are not perfectly aligned between themselves so you can effectively see the joins so to speak. I don't mean they are not pixel aligned, they are but you can see the small issue below...

 

 

[Hangman]

The example you posted relating to Clipping Paths is a different 'issue', although it's not really an issue as such because it has a remedy as mentioned previously. Use Precise Clipping is purely used to improve the on-screen appearance by eliminating the red bleed you are seeing with your clipped circle.

Exporting with or without this checked makes no difference, the exported file will not show the bleed.

[konstantnnn]

4 hours ago, Hangman said:

Use Precise Clipping is purely used to improve the on-screen appearance by eliminating the red bleed you are seeing with your clipped circle

Do you happen to know why this isnt on by default?

[Hangman]

I don’t, I can only assume that because it doesn’t influence the exported file that it’s not considered an issue. Like most things I guess it’s optional and either you decide to have it on by default or you don’t. I see no obvious reason for it not to be on by default but equally you can make that the default setting...