Publisher SUPER slow -> Unusable file after new Update [file included]

[budaloco]

I've been working on a menu for a restaurant and I tried to open it in the newest version (1.9.1) of publisher and is basically useless. 

I've tested it in the previous version (1.8.6) and works perfectly. 

Here is a link to the file to benchmark. Never mind the fonts or images...the error is still there.

Hope this is of any help.

[AlWinRgbg]

I downloaded your file. While opening it in AP 1.9.1. (MBP15 2019; i9 with 16 cores; 32gb Ram; from Mojave upgraded BigSur 11.2.2 System) i got a message of missing resources (fonts) after about 30 seconds. And it took another 2 minutes until i could see the second page. Trying to edit something was next to impossible because i got the waterball every time i tried. So i think it's almost the same as on your system. 

While opening the file some objects were misplaced too for some time. After about another 30 seconds AP placed them in the right place. See screenshots.

Edited February 28, 2021 by AlWinRgbg

[carl123]

It's true that 1.8.5 opens the document super quick and 1.9.1 is really slow to open the document.

But the original 1.8.5 document seems corrupted somehow.

In 1.8.5 try deleting the layer ("group") I have shown below and watch what happens to the rest of the document.

Also, if I try to copy/paste, say, one of the Main Course "groups" to a new document I always get the "Breads" group in the new document.

It's like every text layer group in the document has some sort of symbiotic link to the "Breads" group.

Be afraid, be very afraid, this document is possessed! I would not trust it even in 1.8.5

 

[thomaso]

On 3/1/2021 at 6:56 AM, carl123 said:

Be afraid, be very afraid, this document is possessed!

If this .afpub worked without the extreme delay I get in v1.9.1 then there is at least a chance that Affinity is able to handle this situation. Maybe in v1.9.1 it is not only an app overload but also influenced by the workflow. It seems also the creator was possessed in a way by an idea of max. flexibility + max. resolution + max. automation.

I experience the delay as being caused by a combination of various layout features:

Within the text frames, linked across the entire document,
+ are illustrations with hundreds of editable vector objects
+ set to be pinned within the text (float inside)
+ and have text wrapping activated
+ with their detailed shapes a quite complex wrapping outlines

The attached .afpub, unpinned & not-wrapping, reacts a lot faster in v1.9.1.    The_Spotted_Cow_Menu_Unpinned&unwrapped.afpub

As a workaround I personally would make sure that the wrapping outlines would be a lot simpler, with less nodes, possibly via separate wrapping objects.
And I would avoid to place the illustrations as editable objects (or .eps) but maybe PDF or PNG (incl. transp.) or even non-transparent JPG (+ multiply blend mode) instead. – Then I guess also pinning wouldn't harm any more.

I wonder whether APub v1.8.x worked faster for you because it interpreted these curves for text wrapping as rectangular boxes only? In v1.9.1 their complexity appears to slow the app heavily.

   

   

 

The_Spotted_Cow_Menu_Unpinned&unwrapped.afpub

[Dave Harris]

Thanks for reporting this. The slow-down is indeed due to wrapping the text around the complex vector graphics. We used to calculate the default wrap outline a different way, which was fast but sometimes wrong where shapes overlapped. It is now correct, but much slower. To make matters worse, because the graphics are pinned, editing the text moves them and causes the wrap to be recalculated. I've logged this, and hopefully we'll have a fix for the next version.