abra100pro

It might occur only when there's a PSD file linked – not sure. That's why: I worked about 1-2hrs with the file having a JPG linked. Then replaced the JPG with a PSD and exported > crash. I repoened the AD-file and found the PSD-image to be of bad quality (pixelated – maybe a bug on its own). I then replaced it again with the very same PSD to find it high quality again. I exported and it worked. But I'm pretty sure as I continue to work in the AD-Doc this crash will come again... Maybe I'm wrong about the PSD...

Every now and then AD crashes when I want to export. See screenshot – not sure whether it is the nasty Monterey (ever since 12, now 12.4) or AD. Please see screenshot. It happenend in many files, so I cannot send you a particular one. But I could pm crash logs, of course.

Yes, sure: it is attached. ADColourpicker.afdesign

I found the colour picker being inaccurate when chosing an existing colour. see movie. ADcolourpicker.mp4

Just get out of my way. Leave your non helping feedback out of my topics.

You miss the point of a forum like that - it is about bugs and suggestions. Would be really empty in here if we all thought like you: "It is as it is". BTW: I guess the wheel would not have been invented, yet, with that mindset. I will continue making suggestions and reporting bugs. If you don't agree with them - you're heartly invited to keep it for yourself. What crosses your mind to tell me not to ask for something or report something in a user forum???

Wow, strong words. So besides you criticizing my mind you suggest that we should learn weird muscle memory tricks before having the impertinence to ask Serif to think it over? Man, I made 678 web-banners with AD in three days - believe me I wasn't thinking of coffee in the sun! These are the kind of jobs your are superglad when software does not come you in the way but gets the butter on the bread smoothly. The way you argue makes me assume you use AD once in a while to design a birthday card. What is it that you counter my topics with "no need for that"? Just because YOU don't need it, does not mean others do. And please stop telling me what to do. You can ask me or suggest, but that sound of yours does not work with me.

If it is intentional I kindly ask if that's the most userfriendly way. As a designer I'd prefer not to think about whether to use artistic text or frame text in order to have all the resize possibilities. If the best user experience is a major goal for Serif (and I'm sure it is, the apps are great in many way and a highly welcome alternative to the mexican mudbrick ;-)) this is exactly a point I'd review. Another funny thing is: The bottomline of the compounding rectangle when selected is different between art text and frame text. I personally prefer the frame text method - it leads to much nicer results when aligning text towards other objects: See a sample of a button - at the bottom you see what difference the selection makes at the top: right (frame text) is just centered better vertically: Since AD does not yet allow warping/free transform of text ( ) there is not really a need for a comounding box like that with art text, no?... And at last : PLEASE add a feature to change an art text to frame text and verse visa.

This one is about resizing a group from any other handle than the additional "resize-me" handle in the lower right. Pleas check video to see what I mean: ADresizeGroup.mp4

Thank you a ton for your confirmation. Please let the devs know, that this is really urgent/important for producers like me - it makes a huge difference.

That's exactly it - the export should not be affected by the position of the artboard in any way. This is the only remedy for this bug. I really couldn't care less about the position of artboards on the canvas - Why would anyone, other than for the personal satisfaction of "hey, mom, look how aligned they are!"

I am astonished - in which App (I) ever used is CMD + drag = copy? And why does Alt/Option + drag the same but... somehow not the same? This is an inconsistency and by no means a standard. I defined the bug in several posts, made videos about it, etc. @Alfred also made it very clear; maybe his definition is easier to understand than mine: "Since exporting to a raster format means you can only export whole pixels, it doesn’t matter whether the output is intended for web use or not. The dimensions of an object exported at 100% scaling should always precisely match the dimensions of the object in the document, regardless of the position of the object relative to the canvas or the artboard, and regardless of the position of the artboard." Nothing to add.... oh, but: It is a bug by all means. Serif, why don't you just fix it? There is no reason for leaving it as it is. BTW: I have no intention to bite one's leg here in the forum for helping me with explanations, so, @walt.farrell, @Old Bruce and everyone around: thank you really for your help and tips to find a fix to this desaster. But doing so many jobs with many artboards this issue is a longterm PITA and after hours of designing I struggle another hour or so to get my work out, this is where I really start throwing darkgrey pixels onto the artboards ;-).

Can we agree on this to be a bug?

to the artboard? no. You can check that on my image.

This doesn't work on a daily basis, because: You always have to check whether you have the snapping off (which is useful in other steps of the process) You cannot copydrag 4 artboards quickly upwards unless you follow the exact and ridiculous procedure of Alt + Shift and drag and then in the drag release the alt but keep the shift Everyone who has not worked with dozens of artboards does not know how tedious this becomes in no time.

We're talking about the size of the export, not the x/y of the canvas. The y/x are (for instance) 1080px x 1920px no matter what is set in the prefs.

Wow - Thanks I did that and realized that there are decimals everywhere - but this is still a bad joke! What comes after 6 Pixels? 2660.99892332? Come on! As @Alfred posted: It MUST not play a role where on the canvas a integer sized artboard lies - this really must be fixed

You mean these ones?:

Thank you, @Alfred! This is absolutely right.

Please, Walt, it's not done by the settings - check my video and you will see that everthing is correct. There is another prove: see these two images: the big one shows the position and size of the artboard; the small image shows the size of the very same artboard after switching to Export persona - it _is_ a bug, period.

No, no, and no! We've had this before - it is ridiculous! I invite you to work with 34 artboards and be aware of them all being placed on integer values. You will very quickly swear on this, believe me. This is a bug and if Serif and the whole community tells me it's not I will have to quit using AD. But seriously: how can anyone think this is a proper behaviour? This is so extremely annoyingly false that I lack of words.

(Being constructive... ) Two of the artboards were positioned with decimals in their x/y-values (however that happened). I repositioned them to integers and nothing changed. I saved the file and quit AD, reopened it and now all the exports are correct except one (which is of cours placed with integer x/y-values on the canvas - I already have developed a serious paranoia on this). Please take notice that I saved and reopened the file before without success.

I export banner-artboards of common sizes and they end up being one pixel taller or wider than the artboard in AD - I reported that a lot and sent files and got recognized but it didn't change in over a year - this is a major bug and I cannot understand how (web-)people are using AD with it. This is the final post I'm doing about this topic. I don't want to annoy anyone and I have no will to continue nagging about it if no one else seems to be affected (enough) to care. I'd consider this bug solved as soon as I can place my artboards anywhere on the canvas - even with decimal x/y-values and they get exported at the exact size they also have in AD. Here's the video: AD-ExportDimensions.mp4

see movie. After it I could manually change the blur value back to the state before dragging - so: not a leg breaker but still a bug. ADShapeMaskFx.mp4

@Bryan Rieger Oh, you mean the "Fraction-of-a-Pixel"-Gate? Thanks for your feedback - seems to be a visual render bug.