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.

Interesting, indeed. Speaking of a browser that can execute arbitrary JavaScript code, Firefox should fall in this category, but it's not the case. Regarding embedded browsers and much more "dangerous" code, I use Jetbrains's software for development / engineering and these products are not facing these problems either. They have connected welcome screens, plugins update mechanisms, online code and tools installers, remote debuggers, and so on... If you look in the forums, Win users are experiencing performance problems, too. At this stage, what's more disturbing for me is the lack of visibility on what they are working on. As I said, a public bug tracker would help both the users to know what they're doing and the devs to receive more detailed and specific information to help. This is disturbing because the users started to experience these problems more or less 8-9 months ago (we are almost in June) and the communication is inexistant, like if there is no problem at all. You have to actively dig into the forums and search for similar problems and this is not OK. It would be in an open source community project, but here we have commercial products aimed at professional users. Moreover, the software QA is apparently not catching regression bugs in both performance and functional aspects. I totally understand that the staff is doing its best, but it's not what's most important : get bugs fixed first, and check for every possible regressions before adding new functions. And give all users a warning on web site in the style "We have currently a problem with X, that was not present in version X -1, so don't update for now if this is important for you". Or more simply don't publish a buggy version. As I said, having customers to accept non Adobe deliverable files is difficult enough. Even if they are open to support a smaller company like Serif, in the end they want a deliverable at the deadline, not excuses because something that was working previously is not working anymore.

Well... This problem is still not solved, and we are months later... There are serious software QA issues as performance regressions are becoming more and more common on all Affinity apps on Mac (apparently on Win, too). In fact, I enjoy less and less using Affinity apps, particularly when I have to tell my customers to wait a little bit more because of bugs in Publisher while merging data, for example. Having to make them accept deliverables using Affinity formats instead of industry standards is already difficult enough. I use other resource intensive apps for engineering, and none of them are subject to the performance problems mentioned here. So, what is Serif doing wrong ? Would it be hard to keep your users informed on a specific development blog for example, so it would possible to know on what you're working instead of just hoping for these bugs to be solved ? Do you have a public bug tracking system ? Would you publish a roadmap so we know what to expect and when ? This black box style of development is so outdated... As new versions were published, I installed them hoping for better performance. But new bugs appeared and I can't downgrade to previous versions that used to work better (App Store versions). In short, I am not sure where my honeymoon with Affinity products is going...

The CSV file is built using R and RStudio (Data Science stuff) on raw data. It's purely computational. I also produced thousands of plots, exported as PNG files, and they all display correctly the strings. No problem to read the CSV file in other applications.

Thanks Bruce ! I didn't mention that I am currently on MacOS 11.1 Big Sur. The font used is Fira Sans and I've already made a bunch of multilingual documents with it without any problems. This appears during the merge preview/process only (while importing the data from the CSV file). Not when the text is manually entered.

Thank you ! I agree that it totally make sense. So I stripped the CSV file to a minimum. You can find it attached here. Don't hesitate if more information is needed from your side. data_extract.csv

Hello ! I am working on reports and merging data from a UTF-8 CSV file. As you can see in the screenshot, the data contains the string "Côte d'Ivoire" but the result in Publisher is incorrect. I tried the following without success : Write the string manually : it works perfectly well using the same font (Fira Sans), but it is of course not a merge anymore. Open the data in another software : Numbers, Excel, EasyCSV Editor, CotEditor : they all display the string correctly. Double check the data, in the case of an invalid character. Change the encoding (UTF-16, iso 8859-1, etc.) Does someone have the same issue ? Is there a workaround ? Is it a bug ? Also, while on the merge operation, how to export files independently instead of one huge file ? I cannot provide the CSV file as it contains sensitive information. But I can follow instructions to provide you with more information. Thanks a lot !

Thank you Walt ! Unfortunately I cannot provide the CSV file, as it contains sensitive data. Nonetheless I can confirm that MacOS and other applications decode correctly this file using UTF-8. Following your remark, I'll post this in the Beta forums ! Sorry for the inconvenience. How to delete this thread ?

Hello ! I am working on reports and merging data from a UTF-8 CSV file. As you can see, the data contains the string "Côte d'Ivoire" but the result in Publisher is incorrect. I tried the following without success : Write the string manually : it works perfectly well using the same font (Fira Sans), but it is of course not a merge anymore. Open the data in another software : Numbers, Excel, EasyCSV Editor, CotEditor : they all display the string correctly. Double check the data, in the case of an invalid character. Change the encoding (UTF-16, iso 8859-1, etc.) Do someone has the same issue ? Is there a workaround ? Is it a bug ? Also, while on the merge operation, how to export files independently instead of one huge file ? Thanks a lot !