Delden

M. Connor, By spending 4000+ USD on an 8-core 5 Ghz machine, I expect a substantial speed-up of my workflow. You can’t just tell people that « there is no need to bump this thread » and call it a day. This problem was introduced by Serif when Serif decided that it was a good idea the change the welcome screen. So, there is a solution, but Serif doesn’t want to acknowledge it. And this thread is almost 2 years old. You might think that the problem is just happening when people open your applications, say once a day, which is acceptable. But it’s not and here is why. I use all Affinity products mainly for corporate publication. I produce periodical complex reports with Publisher involving data merge. Here is one use case. The reports are produced using a 10 pages layout for 200+ entities. Each record has circa 250 linked fields pointing to SVG icons and plots. As Publisher always crashes after 15 records (apparently the number of open files exceeds a limit somewhere), I have to manually create batches of 15 records, manually export the PDF, then close Publisher, open it again, then set the new batch for the next records, on so on. So, I have to manually do it myself instead of taking one step (that would already last almost 2 hours just to generate the merge). And as Publisher has no scripting capabilities, it must be done by taking the time of a real human that has to click everywhere for hours because of your bugs. Of course, this has to be repeated every time the customer asks for a modification. It doesn’t stop here. These reports are produced in 6 languages. And all this $hit has to be repeated. In your opinion, how many unchargeable hours are wasted because of this, M. Connor? In this case, the total number of Publisher reboots and manual interventions is 214!!! How ridiculous does it sound to you? That's almost 1.5 hours of waiting time, not including the manual interventions. So now, M. Connor, stop insulting your customers by: saying that there is no solution (because the problem was created by Serif itself), minimizing the problem (because you apparently are unaware that some customers don’t produce only basic documents) Ruining the performance of expensive machines with poor software development decisions. SO YES HAVING TO WAIT 30+ SECONDS EVERY TIME YOUR APP CRASHES HAS AN IMPACT. In the use case I mentioned, there are several bugs (usability, performance, and plain bug old bugs😞 There is no reason that the merge process is not fully multithreaded. My CPU is used at max 20-25% during the whole process (8 cores, 16 threads available). Why is there a limitation in the number of opened files on a 64 GB RAM configured machine having more than 3.5 TB free disk space (which can be used for swap)? Why do you want us to wait 30+ seconds every time your app crashes ??? As I was considering upgrading to Affinity 2.0, I also read another thread regarding the new software packaging policy (using apps on Windows). People are not so happy with that. So far, I bought all your apps 3 times: for macOS, for Windows, and iPad. I also bought your books. That tells you how involved I am in your products. But the Serif attitude is ruining the Affinity experience in professional use cases. The time for excuses is now over, as it becomes more and more painful to use your apps in a corporate environment. I also had to convince management and colleagues to use Affinity instead of Adobe products. That wasn't easy, but at that time I was convinced that it was a good idea to support Serif instead of the same big techs. They won't make the same mistake, and Serif's attitude is largely contributing to this. Listen to your customers.

Thanks again, Bruce! Indeed, I already formatted the fields in Publisher. The text to link has a varying number of paragraphs, some in italic, some in another colour... My data source is a CSV file. The document should also be produced in 6 different languages. Do you think that there is an auto height adjustment for text boxes allowing to move automatically other text boxes located below ? In that case, I could format a number of fields, bind them to individual paragraphs in the data source, and have an adjustable layout... So tricky... Or... Render individual pages then insert them to the document ? 😔

Thanks, Bruce! That's 20 files to maintain... If the customer asks for a modification, I'll have 20 files to modify. It will take time and be hard to track changes. The template contains almost 300 items linked to the data.. And it is periodic. To be clear, what I need is to display or not contextualised texts for each record. Normally it would just be correct to bind a text box to the data, and it's trivial for a merge. But the said text is rich text (with different number of paragraphs, different typographies, etc.). If I bind the text as is, I lose its format. If a bind a rich text, I got garbage in my final documents (expected). Nevertheless, I get your point and find it useful only if it can be automated. For now, I am trying to find solutions. Creating all 20 text variants in a template, and displaying only what's needed was just an idea.

Thanks, Joe! Yes, that will work as a kind of switch to display or not one textbox. Let's say that I have about 20 different formatted text versions in separate textboxes, and only one should be displayed at once. I have to arrange them on top of each other to maintain consistency in the page layout. Placing an opaque image will only mask all or none as I cannot dynamically rearrange the z-orders (can't we?). Am I correct ?

Some input, anyone? 😉

Hello, I am currently producing a 2'000+ pages report using Publisher and successfully merged text and images. The merging process is not multithreaded and thus very slow, but let this aside for now. Here is the problem. I have some variable 2-columns formatted text, generated from data analytics, that must be displayed on demand. So far, I see 2 different methods: Embed the custom formatted text in the Publisher template and just display it according to a flag in the data. That would be a clean solution as it would be completely set up before the merge process. In this case, how to bind the visibility to the text? Insert the text from the data in a text field, but in this case I need to embed the formatting as well (font size, style, etc varying from paragraph to paragraph, the number of paragraph being not fixed). How to set paragraph formatting externally? I don't know which would be the best solution and how to implement them (is it at least doable?). Furthermore, there is maybe another way to do it, so all suggestions are welcome! Thanks.

Hello, No it didn't.

Of course, I am only referring to Mac users. Glad that it works well on Catalina (it was my case, too), but one cannot require the users to stay on an outdated operating system. Even if it still receive maintenance updates. It is clearly made to be replaced. Some Big Sur functionalities are useful to me (I preferred Catalina).

Not sure if I understood correctly what you said. Can you confirm that users having bought these apps directly from Serif are not experiencing this bug ? If so, is it possible to transfer the licences, uninstall the versions installed from the AppStore and reinstall these apps directly from Serif ? Using that new log in thing (that precisely slows down the apps) offers authentication and license management, right ? This would be a fully satisfactory, definitive and solid workaround.

Good points, indeed. Still a nice to have rather a must have, but this is just my personal opinion. The fact is that this "nice to have" stuff comes a the cost of a huge performance hit (including people that don't need it) and having spend good money on powerful hardware, is still debatable though. Example : working on Publisher, having to open Designer to create a diagram and Photo to adjust settings of an image creates a triple penalty in this scenario. On a 8 cores machine, 64 gigs of RAM it is not acceptable. Sure, once open everything is smooth, but it still remain an avoidable and annoying hiccup. No matter its usefulness or slowness acceptance, it still is a bug affecting all users.

Yeah, devs are sometimes living in an obscure world, dealing with complicated dragons and wizards related stuff. For some, it's even a magical dimension... 😂 Thank you again for your time, I appreciated it !

Thank you, Dan. At least, now it is safe to assume that: Serif will not swap to another web framework despite the welcome screen and the log in page being mostly useless for the vast majority of users. In a pure Apple's "You're holding it wrong" fashion, there will be little chance that Yara & co it won't ever be fixed. So I understand that passing annoyances to the end user is totally acceptable and that Serif doesn't mind to alter its good reputation by delivering unsatisfactory products. I admit that I'm being a bit harsh, but these apps were working perfectly before adding these connected things. What are you planning ? Yet another market ? Yet another cloud storage ? Yet another subscription model ? No, thanks. It was precisely why I've chosen Serif products in the first place. Honestly, I was rather happy to stop using Adobe products, but it seems that Serif is taking the same road.

Thanks Dan C, it's good to know that you're not ignoring it. More heavy apps currently installed on my Mac don't behave this way. Do you have more information on the root cause, technically speaking ? Why are Affinity apps in particular affected by this ?

Apparently, it would have been more honest to say "We won't fix it", but they didn't do that. At this stage, it is a real disappointment.

End users should not be the beta testers. As Serif releases beta versions, I already installed some in the past. Just using a beta version is not enough to find bugs, because it's impossible to test every possible usage patterns and the available time is surely not infinite (and not free). Automatic tests are made just for this purpose, even if they can't test every possible code paths, either. But at least they can test for thousands or millions paths overnight and it is generally enough to spot bugs or regressions. What's frustrating in this specific case, it's that all products are affected by a bug on a completely non-essential functionality (regarding only the slow startup case). In the end, how can you know that a specific bug has been corrected before updating ? If at least there was a public bug tracking system to allow users to know if a specific problem is solved.