jeremysom

Although that being said. I just tried rasterising the three groups which have the blur effect applied. Those pages are no longer rasterised (text is vector) and the bleed exports properly as well. Suuuuper weird. Although I have no idea how it works under the hood, my best guess is the size of that image (that gets blurred) is too much for the export process, and it gives up and dumps memory unexpectedly (and silently).

@Pauls yeah that explains rasterisation of the sub-groups. I don't fully see how that would rasterise siblings (like the text) which are not under a blur effect. I assume that would still be some kind of bug. I also wouldn't expect this to affect the bleed on export either? Weird issue, I know.

@Pauls nah nothing in preflight. I also went through preflight profiles and couldn't find any option for that? I've uploaded the relevant files. Hopefully the same problem will present itself when you try.

I have a 400+ page document that I exported for print (with bleed) included. I have actually printed the book only to discover one of the spreads didn't export it's bleed correctly. Literally only one spread is messed up. I've reopened the document and everything looks fine and normal on that page to me. Every time I export those pages they are getting completely rasterized (even text), and the bleed only gets exported on the inside edge. I can send through the file, I just don't want to make it available publicly. I'm using Publisher 1.9.1 Screenshots below of the page inside Publisher, and then the weirdly exported PDF.

Yeah I agree, the clipping object is definitely unnecessary. I would have had that photo somewhere else (i.e. not in a picture frame) and then later on changed my mind and dragged it onto the picture frame. Still I don't think this should affect resource management in the document. I should still be able to "Replace" or "Collect" images in the "Resource Manager". I had to touch several dozen picture frames in my document and either delete the clipping object, or drag the constraints group out of the picture frame, in order for me to move (the image's file location) or replace it. That's my main problem. Sorry if that wasn't clear to start with.

It took me a little bit to replicate the issue in a new document. It turns out it only happened to some of my Picture Frames. It turns out Master pages have nothing to do with it. To replicate: Add linked image to new document. Crop image Add picture frame to document Drag the Image layer onto the picture frame layer. Behold the magical constraints group appear. This now means the image cannot be replaced, either from the context menu, or through the Resource Manager. I'm guessing the constraints group is a feature and not a bug. But the inability to "collect" or "replace" these images from the Resource Manager is definitely a bug.

I have a 400+ page document with lots of images. Some of these images are embedded in a picture frame (from a master page). Once embedded in the picture frame, the image gets wrapped in a "Constraints Group". Trying to replace the contents of that image with another image (or moving it's location with the "Collect" button in Resource Manager) fails. The only way to change the image, is to drag the "Constraints Group" out of the picture frame layer, change the image, and then drag it back into the picture frame layer.

I've got a large 400+ page document with over 600 large images. The export process is slow (1-2hours) and does occasionally hang. I've found I pretty much have to export to CMYK because exporting to RGB just takes too long. I've learnt to live with the slow export but it's frustrating when I leave it going overnight and it hasn't progressed Anyways, what I'd love to see is a simple label on the export progress bar that shows what page it's trying to export. It would be massively beneficial to be able to pinpoint pages that might be slowing the process down. I've taken to sticking a PostIt on my monitor to track progress and make sure it's still moving. I'm using a Macbook Pro 16inch.

Somewhere around the 16GB mark.

Lots and lots of memory usage. I’d be guessing memory leakage.

I have a document that is 400+ pages full of linked images. When I export to PDF now (since 1.8.4) the export process ends up filling up memory and 600GB+ of SSD space. I'm using a 2019 8-Core 16inch MacBook Pro 16GB RAM. 1TB SSD. The only way to clear the 600GB+ is to force quit Affinity (or restart computer). I assume this is some sort of temp file problem or perhaps memory leaks? I have tried exporting a subset of the document (i.e. first 100 pages). This process completes because my computer doesn't run out of space but it still leaves my SSD with significantly less space until I force quit publisher (normal quit hangs). My plan in the meantime is to maybe export the document in 100 page chunks and then stitch it together but that's obviously not ideal. It's worth noting that performance in 1.8.4 has improved dramatically. So speedy! And saving appears bug free now. Unfortunately the export is now causing me headaches. I'm not able to upload the images but if you need me to perform diagnostics, let me know.