Andy05

Ok, I obviously have to jump in a final time as you just create new scenarios to your liking in order to find at least a tiny "proof" for your abstruse arguments. This is where you failed (yet again): Firstly, this discussion was not about saving into a native export. Secondly, even if it would have been about saving into a native export—of course, the objects out of bounds have to be saved as well. But that doesn't mean that the dimension of the artboards or canvas should get extended to make them fit in a native file format either, does it? I just marked the important part in your quote, where you basically confirmed that the apps should not override the user's settings. That's what I said and you denied since you tried to jump into this thread! That's what all the discussion was about—and now you're "trying to win" the discussion by changing sides and join my initial argumentation? LOL Seriously, you should just admit that your "resize on export is a feature"-statement was simply nonsense. Because it is, no matter what obscure new scenarios you need to create now. Seriously done with this discussion now, I guess I proved my point clearly for any other person than you and latter would be a mission impossible.

You are really, really stretching your arguments very thin now in your desperate attempt to have the final say, don't you? NO WAY any app should extend an image to all objects, strokes or whatever which are outside of the canvas. This is utterly nonsense, really. Oh wait! I know your next reply! »Designing and placing (parts of) objects outside of the canvas or an artboard is something, which almost never happens! Only a handful of users ever do that in very rare circumstances.« Yes, you're right. No one ever places anything beyond the canvas' borders and of course, no one ever cares about automatically resized images during the export. Also, with your last reply about artboards as children of other artboards you even contradicted yourself in so many ways, I really wonder why you didn't notice this yourself. As you couldn't nest artboards into each other if the app would always extend each of them to the outer dimensions of any object, genius! All nested artboards would always have the minimum size of all objects if the app would follow your "resize is wanted by design"-logic... BTW: Feel free to reply once more so you'll have your final say in this discussion (which seems to be so overly important to you) as you reached a point now, where it becomes ridiculous to me to waste a single more word on this issue.

If it's something like this: You can paint with those rainbow-cycling brushes, setting the hue jitter to cycling and amount you need. As an example, I attached the simple brush I created for the image. rainbow.afbrushes Edit: @Ron P. - this is my horrible revenge for your colourful blind-making image you posted today!

I hope you don't mind me adding one small critique about something which instantly came into my mind when seeing your images. The "UNIQUE DESIGN" at the bottom of the images shouldn't be in all caps. This font is not meant to be used in all caps—it decreases the legibility massively (and my old typographer's heart is bleeding! LOL). As a rule of thumb, never use fonts which are very complex (handwritten fonts, German/gothic fonts etc.) in full caps. As an example, see your comic-style font to the left, in contrast to the text at the bottom, it's perfectly readable in all caps. EDIT: And you might have to check your files for the second and the third image. The piggy banks at both sides are way more blurred than in the first image.

That's not achievable with my suggestion in this thread. But I provided some good starting point for that in your other thread.

The black filled parts might be a problem though. I'm not sure if the OP want those without fill, too.

Nice, that you didn't try to explain, why expanding the image to show your strictly needed 1px oversized objects is far more important than my 501px. Probably because you've notice the hole in your logic eventually? The app is not supposed to decide how far it should extend an image. That's what I said from the very beginning. And which you obviously still don't get.

And that's where you're wrong. The solution is simple, I stated the options already. Crop the image (and objects) and pick one of the options for the "semi-covered" pixel row(s), because: Yes, they would get cropped off. And you'll notice that immediately when you work with the exported images. So, you'll see that something was off in your work. But a resized image might go unnoticed and could cause trouble later on in the layouts. It's way better if the exported image looks weird and off rather than "looking good", but it's (maybe unnoticed) of a different size. Neither crop nor resize might give the result you want, but you'll notice the problems with a cropped image more easily than with a slightly resized one. That's not rocket science to understand, is it? EDIT: BTW, great example, you gave! What if I use 501px stroke width in your example? By your logic, the app has to take those off-canvas pixels into account, too. (Why stop at 1px? Either the app is supposed to crop to objects' outer limits or not.)

If you want to recolour it only to shades of one single colour, you could add a rectangle above the image and set the blend mode to "hue". The colour of the rectangle can still get changed to whatever colour you want.

If you need only the lines, put a white rectangle below the image and apply Blend Options like mine to your image layer (just a rough example here): You might have to tweak it a bit and also work on multiple copies with Gaussian Blur and re-sharpening for smoothing out the lines.

Seriously now? Ok, if your really important 1px object is missing, you'll notice that immediately when looking at your image. Whereas you might not notice that you work with an image in your layouts, which isn't 100% the size you expected it to be. Say what you want, auto-resizing an image on export is an absolute no-go.

Not at all. As for the "off-pixel" row (which isn't "fully covered due to the fraction of a pixel placement"), here's where the app might decide what to do (not on the absolute dimensions)! The app has several options here: It could fill the pixel row with canvas background colour (if set) transparency (if set for canvas) semi-transparent (on canvas colour or without canvas colour) depending on the fraction of content on that pixel row. The pixel row which exceeds the canvas' dimensions needs to get cut off (cropped). Again: Placing something beyond the canvas' dimensions, is something which might have been done on purpose. The auto-resize of the canvas "by design" is simply not the correct solution. Just because pixels is the lowest possible unit in this scenario, it doesn't mean that the software should override the user's settings.

Nice video! But what's a "TOYKO"? ;-D

See my quote and you'll see what I meant by "this". You showed two solutions, crop or resize. We're on the same level that far. But those are two different solutions actually: crop = correct and resize = wrong. A resized export can never be the correct solution. That's what I meant since the very beginning.

Hey, if you want to earn millions with such an artwork, you should invest at least some work into it! Place every single image by hand, damnit! 😄

Doesn't help OP with his current issue, but might be useful information nonetheless if an upgrade is something worth being thought about: Current FF 10 version runs without any problems in Affinity Photo (win 10).

Uh! For security reasons, you should probably warn people about looking at such an image! Being an old fart, I almost went blind accidentally looking at all that shinyness.

... this. Changing the dimensions is a no-go. Out-of-border artboards or objects could be done on purpose. An (automatic?) resize of the output can't be wanted.

Yes, agreed. This info is pretty pointless (who really wants to know those stats actually). At least the horizontal version is less annoying than the vertical one which completely changed the layout of the forum.

No, that's not what you said. You mocked about my statement that exact dimensions is one of the most important details in design. You disagreed and that's where you were wrong, not me. I said, a software should never override the dimensions, which you claimed as not important. Actually, 1 pixel can matter even in print. B/W highres art prints can cause unwanted ragged edges, if not printed at 100% of their size. Further, you claimed it would be "by design". Reading MEB's comments sound different, don't they? If it would be "by design" and hence, a wanted feature - why would he ask for OS and app version in use to investigate? If nothing would be off, there wouldn't be anything to investigate at all. And exactly because the user has control over where to put what object, the resizing issue is a bug, not a feature. What, if that object was meant to be a fraction of pixels off? Why should the app override my settings rather than croping the out-of-bounds objects? Get over it, the community will still love you, even if you're wrong for the first time in this forum. 😉

Maybe it got reset for you when the forum got upgraded.

True, but it might get a bit confusing, if you try that with 100 or 1000 labels.

What app/OS? I can't confirm the issue on my system (AP, Win 10). Elliptical marquee tool works as intended here.

Sometimes even transparent areas of an overlapping PNG can cause the same unwanted effects.

Well, I didn't mention my "pre digital" era. For about 1 year I still had to work with lead letters and clichés in our family business (advertising papers in Hamburg). Edit: On a positive note, all that taught me reading texts mirrored and/or rotated at any angle as quickly as any non-mirrorred, non-rotated text.