RM f/g

When I openend the beta 1.9.1.967 I was asked to ‘Select the folder containing the shared property collection files’. Not having a clue, I clicked ‘cancel’ and proceded without problems. Does anyone have clue what these files are?

Thanks, Walt. Where would we be without you – and John Rostron? Downloaded John’s macros and tried them. They work as expected, but only if document units are set to pixels. So I tried a new macro: set unit to pixels – run John’s macro – set units to millimeters. Happy to see we can use a macro wihtin another macro.

If not a bug, then unexpected behaviour. What I wanted to do: use batch process to change only the resolution of images, not their size in pixels. What I did: Opened image. Recorded macro: – Opened ‘Resize Document’ (from Menu > Document); – set DPI: (from 72) to 300; – unchecked ‘Resample’ – clicked ‘Resize’ button Ended recording, saved macro. When batch processing files using this macro, all processed files were resampled to the pixel size (at 300 ppi) of the original image, the image open when recording this macro. This resampling happened without maintaining the aspect ratio. The original image was a square image, rectangular images were resampled to square images. Ended changing the resolution of 215 images one by one.

On startup it crashes unless I switch off the internet connection. Having started up without internet connection, it crashes as soon as I connect to internet again. MacOS Mojave

I, too, would welcome the ability to actually see which (tool) button is pressed in dark mode.

Selecting the Freehand Selection Tool doesn't change the cursor to a lasso. The cursor of the previously used tool stays active. FS Tool works, though. Same in Designer's Pixel Persona. Photo 1.9 + MacOS Mojave

About the afphotofile: it's something that happened the week before. I can't find the file and have not been able to reproduce it. For as far as I can tell now, I was probably wrong.

Opened your file in Indesign (CS6), saved as new idml. This second idml openend in Publisher as expected. Changed the extention of both idml-files to .zip and extracted both files. The second zip-file contained the following files/folders: – Resources – designmap.xml – META-INF – mimetype – XML – Stories – Spreads – MasterSpreads Your file only contained – designmap.xml – mimetype I hope this helps to find a solution.

The same goes for Aff Photo files. Understandable since it is the same file format, but I didn't expect this after performing ‘Rasterise & Trim’. I understood Rastise & Trim is an old school crop action, removing all pixels outside the cropping frame, unlike Aff Photo's crop tool.

Affected files attached. Thanks. Archief.zip

Hi Sean I didn't recognise this as same phenomenon. Sorry for the inconvenience.

I have several Aff Designer files made in 1.9 beta, artboard/page sizes about 100 x 50 mm. Placed inside a Publisher file (1.9 beta), they are placed at A4 size, with the art (at artboard size) in the upper left corner of these A4 frames. Switching to another page box has no effect. I have to switch to ‘minimum content’ to reduce the frames to artboard size. A4 is the starting size of these Designer files (before insering the artboard). Designer files made in 1.8 are placed as expected: at artboard size.

@SPaceBar I recorded a video of replacing a placed jpeg with an AfPhoto file twice. The first time using the Resource Manager, the second time using the ‘Replace’ button in the context tool bar. This time in AfPub 1.8.4 retail. Thanks for looking into this. ReplaceImage.m4v

By the way: same thing happens when this Designer document is placed in a Publisher document. OK in 1.8, not in 1.9 beta.

Here it is.