cleay

Yes it should — just enter 800 in the H field and leave the W field blank.

So the work around is to run a batch job twice: 1. first batch job to resize only using a width or height value in the W or H column next to 'Save as JPG' (or ''Save as PNG' etc...) 2. second batch job, this time run on your resized images using whatever macros you need.

Appreciate the workaround. I think that simply adhering to the proportion checkbox might be a bit more intuitive though!

FWIW, after a LOT of trial and error I managed to work around this by splitting the macro and exporting twice. The first export with a height (but no width) entered in the 'New Batch Job' window (no resizing in the macro itself), then running the second canvas size macro on the resulting images.

Yep correct. FWIW, after a LOT of trial and error I managed to work around this by splitting the macro and exporting twice. The first export with a height (but no width) entered in the 'New Batch Job' window, then running the second on the resulting images.

This bug still exists in 2022(?!) — when recording a macro and resizing, unless both X and Y fields are set expressly, the proportion based on the single X or Y value entered should be recorded, not simply the calculated end values.

Just saw this topic on a bug that dates from 2018. I ran into the same issue today: Concerning that it hasn't been addressed yet. Looks like I'll have to dust off photoshop...

So, I think found a bug that I can't (yet) work around. I created a macro to batch process a few hundred product images of varying heights and widths (but all portrait). To record the macro, I first resized the document (with proportion locked) to 3200px high and centred, then resized the canvas (with proportion unlocked) to 3500px high by 2800px wide, again centred — with the aim of making all images 4/5 aspect ratio with a consistent 150px space above and below. But the macro does not respect the proportion lock. I've tested half a dozen times, and with separate macros for each step. A macro created using a tall skinny image, will cause all batch processed images using that macro to distort to the pixel width of the original macro image, even though the proportion lock was unchecked when creating the macro. The image after creating the macro looks as correct (unsurprising, as the pixel dimensions are correct for that initial image), but it seems that the macro only records this initial pixel width, applying it to all subsequent images regardless of the proportion setting. (resulting distorted image attached). Oddly, a similar macro — 1. resize doc to 2400 wide, 2. resize canvas to 2800x3500 — when applied to landscape images worked fine. Bug fix required I think.

Thanks for the reply Dan — there are no AD Crash Reports in console app (only 2: Plex from a week ago, and Illustrator from 2020). And no records in diagnostics or logs from the time of the 2 crashes this morning. Odd thing is that the report crash popup that usually appears after restart is absent — it's like the system has no idea it's crashed...

Hi, Starting a few weeks ago, I've been having frequent full systems crashes — cursor becomes unresponsive, fan goes into overdrive, system restart. A full system freeze/crash like this is exceedingly rare on macOS — never had more than a handful in the 20yrs preceding this. I'd not been able to track it down definitively before today, but it is AD causing the crash. I've replicated it half a dozen times today — with and without hardware acceleration turned on. I have no idea what's going wrong, but for now I cannot use AD for more than a few minutes before a system crash. Any ideas?

I had no idea that existed. Neat trick!

what?!

Bump. Seems like there should be a way to extract a curve from text-on-curve. Perhaps the path should be treated like a child later of the text (or vice versa) — so it's possible to drag it out from underneath to release...

Nice thanks!

I second the missing 'c' shortcut. I assume there is some logic to it, but it was disappointing to discover