Stan.B

Thanks. Maybe this is the case. I checked the sizes of the embedded pictures and differences between the AFPUB files - and they more or less correspond. Key thing - it eventually writes file down. cheers and thanks, Stan

Thanks Catshill. It is nice you found a workaround. But would you agree, that this is exactly that - a workaround around a thing that should not be? Frankly, as these ghosts were not critical I would not even report them, but as I noticed also other anomalies in area of master pages, I reported all of them altogether. If anyone analyses incident density per module this might be a signal of some quality problem in the master module, and - hopefully - a trigger for some more checks and improvements. Publisher is such a nice tool, it would be perfect if it does not expose these flaws :).

Hi, I use spread master pages heavily for my photo book. I have there picture frames and text frames using custom defined text styles. Also, I apply a master pages containing just numbers in the footer, to other master pages, that I apply to the book spreads. When working on actual content pages quite often I apply different master pages to change the layout OR apply the master page to just one page (half of the spread), *replacing* the previous master page. I noticed several issues, that are bugs to me: 1. content pages did not react to changes in formatting within text fields (text style, adjustment, margins within text frame, etc.) Having changed the master page I expected all the content pages depending on it to update. Did not work. Text fields, text styles in them were not updated. Dragging the master page AND choosing a new master page from the page context menu to REPLACE the master 2. edit content page detached from the master page I noticed a vertical shift of objects and their frames, by - more or less half em, as if page being edited had slid off the master lying below (if I may try to describe it like that) 3. "Ghost object frames" visible on the content page in the spread, after applying a spread master page to the OTHER page on the spread. This though is already addressed in a different thread, where I just confirmed having observed the behaviour. Cheers, Stan

Hi, I was to write about the problem as well. I am seeing "ghost objects" (coloured frames) from the spread template applied to just one page of the spread. Cheers, Stan

Hi Gabe, thanks for the welcome. As for the trouble - since my first report it happened to me at least once, maybe twice. But in between - all was fine. What I also noticed later on is that periodically size of the subsequent file versions jump up from 100-110MB to approx. 170MB. Re reclaiming redundant space in the file: could it be possible that the size of the files varies that much? By almost 50% instead of 20% you refer to? Also - one hint for your developers: when the Saving progress bar appears, it shows no progress at all for quite some time (minutes?), then when actual save begins it is very swift (fraction of a second). I do not see how this could be relevant, but who knows: every day or so, I create a copy of the AFPUB with an incremented version number - my own personal versioning and disaster recovery mechanism. Would changing name of the file have any impact onto the first save operation afterwards? Cannot imagine that. I need to correct myself on my earlier description of the external resources: I wrote that all the files are linked and gave size thereof. Actually it appears I have three maps copied as pictures, that are embedded. Cheers, Stan

Hi and thanks for welcome words. My answers below: 1. Are the resources stored locally or an network volume? Local SSD drive, like before an upgrade. 2. What file formats are the resources? Just pictures, JPGs. 3. Are they linked or embedded? Linked. At least so they were before upgrade. 4. What file size are the resources all together, what file size is the .afpub? As an estimate: I use ~150 pictures, of 5-24MBs each, lets say on average 15MB, so in total ~2GB+. The total size of the pictures folder is 6GB, but not all of them are used. 5. What macOS version? Catalina with the latest upgrade: 10.15.4 6.Is your mac poor on free disk space or RAM? It is more or less as it was before upgrade. 217GB disk free, 32 GB of total RAM. Should be enough. 7. Did it work during layout without such a delay? During layout it works swiftly and without any delays. No difference compared to previous version. 8. Did the fan running faster while working with Affinity? No, it did not. 9. Can you notice reduced free disk space on your system volume when working in this .afpub (compared to when the app is closed)? Good question. I did not check. But - given the size of RAM - is this something to check? 10. Did you get your Affinity app(s) from the mac App Store or from the Serif Store? Ha! From the Serif Store (I had to check...) I opened the file right now, deleted one character and saved. It was definitely faster than my first case I reported here, BUT the pattern was similar: Saving progress bar appears and shows no progress for some time, and then starts moving forwards and does it very quickly (in less than a second for sure). So.. it is not that critical, it works. Maybe the first time when I opened a file in 1.8.3, that was written in 1.8.2 there was some kind of conversion? No, this does not make much sense actually. I would assume the whole file structure resides in the memory already when I select "save"... If any, first conversion should have happened by opening. Cheers, Stan

No, i am saving to the local drive

Hi, just installed and launched Publisher 1.8.3 to work on my photo book. Unfortunately neither Save As... nor Save .... .... one moment... "Save" just competed, but it took extremely long time to complete without any visible change to the progress bar for a long time. cheers, Stan