konstantnnn

Please Affinity Team

its not on par and not of acceptable quality.

PLEASE! PLEASE ! PLEASE !!!!! P L E A S E !!!!!!!!!!

https://github.com/yanone/speedpunk It's open source.

Screen Recording 2021-08-27 at 07.12.13.mov

Thank you so much, the tips helped me. I certainly wish this will be fixed, asap. I hate how the small issues are ignored. They are really important.

Alongside Apple color picker, please let us have the Apple Font picker instead of the built in app's ones. fonts.mp4

A single color change should leave a single history entry. ColorMeCrazy.mp4

Cmd+click to select layers is hiding transform handles, even when you let go of the key. Click.mp4

So hot

During my orange phase

I think I may be the only one using Affinity for my note-taking in school… Looks like a poster.

Thank you for highlighting this. This actually may be added to my list of workarounds, merging curves.

I mean I must admit I was using these workarounds, like increasing the size, overlapping, or in some cases multi-layered overlapped divided extracted strokes to achieve an inside-stroke-look I wanted, I was extending images, where there was a "gap" I would duplicate the original shape, and center it and put it behind the two shapes, I was constantly doing so much for years now that I just felt enough compelled to write some feedback about it. It would be really, really nice to just not think about it. I agree I may sound to a technical engineer, a bit, arrogantly blonde.

Thanks for the great response!

Take a look at the jointing curve in the "Artboard 2" of the document! Enter pixel view, or even make the insides of the clock hand darker. It's pretty jarring. Could you provide me a solution to thatDocument.zip

We are talking about images that are not rasterized now. Un rasterized images. We are talking about how does a vector program interpret and pixel-display raster objects. An outside frame of every image imported into Affinity can be looked as a vector rectangle. We're talking about adjacent OBJECTS having arbitrary GAPS. The question is awfully simple, should there be a gap between two adjacent objects? To make it simpler for us to understand, I googled the definition of adjacent, "next to or adjoining something else". Next to. It's next to. Should there be an arbitrary gap to something that's magnetically snapped together? It's awfully simple. It's so, amazingly simple. Should there be a gap between gapless snapped objects? I don't care if they are at Retina resolution, 20X resolution, Infinite vector resolution, on Mars, on Jupiter, on my or my sister's computer, in milimiters, inches, meters set to seventy decimal places, half pixels, quadpixels or seventy bilionth-part of a pixel. Should there be a gap between gapless snapped objects? To objects that are ending and starting on the same physical number. The same number. The answer is obviously no! I think this is common sense. This isn't anything crazy, to think two supposedly gaplessly adjacent objects — implied both by the "magnet" icon of the snapping tool and the literal position numbers ending in one place and at the same place beginning the other — and implied by the "infinite zoom" paradox of the program where it's obvious that this is a rendering glitch and the logical outline - literal position information is pretty clear about this. There's no place for the background to peep through. They are adjacent. Wikidictionary again? Or? And it shouldn't. Because I seriously thought you were britishly sarcastic. All of my images and graphics will start to look like bad Windows 95 graphics? What kind of question is …that………….. At this point, a much more relevant question would be "why use this program" again Keynote comes to mind, there are no gaps with all straight-aligned images and halfpixel/.3333 pixel stuff and freehand and etc and etc. When you do a degree turn and rotate it then that's the only time it ever shows this. Which means that the problem partially or completely is solvable in the first place, like Keynote already did non-rotated objects (which my main issue is about). Keynote already solved it (look above). When you rotate it, there is an issue in Keynote, but I do know if those engineers cared enough they would fix that as well. It is solvable. Technical limitations are meant to be broken. That's how you make better software. That's what feedback forums are all about and all for. That is the purpose of filing feedback. I see no point in utterly defending a technical limitation instead of saying "yup, hope they fix it". You're using it wrong is not a proper answer. I still think this is a joke. You can't possibly say that you agree that gaps should appear on perfectly adjacent objects. You're the man! Shifting gears Correct me if I'm wrong, but a part of the confusion maybe also comes from the thought "how should the dispalay engine treat snapped sub-opacity antialiased edges". Isn't it? Let's have an example. I have an object (could be a square image, or a literal square, doesn't really matter — to the "outline view", it's just a square so that's why I use the term object/square/image interchangeably throughout this post). 1) My image is mostly pixel aligned, but there's a single vertical line of pixels on the right which the image doesn't fill fully. In fact, the image covers just about 0,000002% of those pixels. 2) When I bring a second image and snap it to the first one, logically (the program, PDF engine, outline view and snapping engine) know that they are one next to another. The display engine, however, almost acts to ignore this. The display engine is looking at that single vertical line of pixels, and literally it's like it's saying "well, these pixels are filled by an image, so let me start rendering from the next line where there are no pixels filled"! The display engine almost seems to fail to understand that, yes, these pixels are filled by an image, but there is still more room to be filled. In fact, there is 99,9999998% of room left empty, but the display engine seems to ignore that and to count this very binary — either its full or empty. This is a flaw of the engine. And when you keep zooming in, it's almost as if you're shaking the program to wake up from a hangover; it's reducing and reducing and reducing the gap as you keep zooming in and zooming in and zooming in — but it's an infinite cat and mouse game. My issue is with all of this, and the way I'm proposing it is to let the logical way win. If the developers started going from that, upwards, from the core idea to the technology, they would make a superior display engine. I don't care if it's a huge leap or (or for) a small insignificant thing. That's what I would do if I knew how to code. If I had a team. That's what Steve Jobs's core vision was when he made the first mac. That's the right thing to do. That's how I approach all of my design work. Document.zip

Its working wrong. Yes that is how it works…If i have a single shape and a background. Not when I have two shapes next to one another and no logical way of the background color peeping through. If two objects are one next to another taking up 30% of a pixel and 60% of a pixel, the semitransparency of one should be added to the semi transparency of the other altogether, because there's no background VISIBLE THERE to contribute to the pixel's final color output!!! Just as how there's no background visible WHEN YOU DO perfectly pixel align —because they are ALIGNED!!! one next to another! with m a g n e t s Let me draw this in an another way, if I perfectly-force-pixel-align two shapes (and there's no gap), I then GROUP THEM, RASTERIZE THEM, and start moving them without force-pixel-alignment, NO gaps would EVER show because there isn't any space for the background to peep through because they were perfectly magnetically snapped in the first place!! This is how it should work if they werent rasterized in the first place. I don't care! how all of it works, and I don't care about any more explanations that just explain to me how something works..that's WRONG! I haven't checked affinity forums and was working on a project and again encountered gaps now with STROKES, the underlying color of the stroke is peeping at the edge. It took me again here. This is unbelievable! I should apply a stroke and GO. I don't care! why I can't, I should, and anyone who gives two cents about developing great software would care too. Imagine where would the computer world be right now if all the way back people snarked suggestions of fixing technical limitations and literal bugs in how software works. I can't imagine a more depressing thought.

https://forum.affinity.serif.com/index.php?/topic/147196-aligned-objects-not-actually-aligned/&do=findComment&comment=822722

Can this be implemented with anchor points as well?

33.3333333333333% size shape in Keynote — no gaps. The same exported PDF with identical dimensions when viewed in Affinity — welcome gaps! Do I seriously need to go on… #gapGate #endTheGap2024

Then change it.

There's no background color peeping through. There's no PLACE for it to peep through. The objects are one next to another. Their colors are the only colors a pixel should ever be allowed to see and the only colors a pixel should be allowed to display.

I just spelled it cockscrew..

Me neither. I just want Affinity to build great software. That’s the only reason I’m here. I don’t think I’m wrong in thinking that, a great cockscrew that is at the same time is a great potato peeler is actually amazing? And if Affinity is letting you have a pixel view and pixel options in their vector-based-vector-priority application, they’re already choosing to play a game of a cockscrew and a potato peeler… Just, they’re leaving ting bits and gaps unpeeled