PaoloT

Hi, This has been discussed here and there in multiple threads, but I don't think there has been an explicit request. So, here it is: I would like to be able to set 72dpi as the default resolution of my exported images. 72dpi is a traditional way to match printed points and fractions of an inch. It has been (and maybe still is) the standard on the Mac. While this may be irrelevant in some applications, where the size of an image is set by pixels, it is relevant in other cases, where an image is not associated to local measurements, and its size depends on the embedded resolution. Dealing with 96dpi images, while still thinking at 72dpi, means that an image would result too small. This would cause loss of time trying to 'debug' the problem. Paolo

That is: if the context toolbar was free to float, as the other elements of the UI, we would have a standard Mac UI. So, it's a mystery why it doesn't happen. It must be something on a personal level. Paolo

It's what I’m working on now. It's a fascinating and powerful system, but lacking a lot from what a modern page layout program can do. And, obviously, not exactly user-friendly. For example, unless I’m happy with a few templates for scientific articles, I have to build my own template by coding it. Typist is a lot easier than LaTeX, and a lot more modern in allowing system fonts and diacritic marks without heavy patching. Still, it's an arcane way of working. There is no easy way that I’ve found to create object styles. Paragraph and character styles, unless one uses a couple of them, is a hell to type. And multiline cells in tables are still considered something odd. (Thank you to Scrivener for doing mosto of the heavy-lift, here…). Being able to author in Markdown and publishing with Affinity Publisher would be a dream. But there is no easy path. The Word format used for interchange doesn't seem to allow linked images. IDCL is very basic, and then Publisher wouldn't understand it, unless you manually convert it to IDML. And Markdown is totally ignored. What a shame! Paolo

Now, we know that, for some reason, separate mode is not possible even on the Mac. But then, please someone explain me this:

Ok, but those are also those boring parts for which we wouldn't want to pay for! 😁 Paolo

I find incredibly annoying having to continually displace windows to alternate between showing tools and showing the documents behind the foreground one. A really odd way of working. Paolo

If software for people who can't design exists, I hope Serif will continue to make software for those who can.

An impressive release, with very well conceived new features! Thank you for all your work! Paolo

What an incredible work! Congratulation, and thank you! Maybe I’ve found a little mistake when you explain the Lanczos algorithms. In the current text, one is the slowest, but the other one is slower! Paolo

With a single application on the screen, there was no way to talk about document- or application-centric. Obviously, this distinction came later. When developing the application-switching system, Apple could have gone for an application frame or not. Windows 95 chose the app frame, IBM OS/2, if I remember correctly, didn't, and went for a solution similar to the one also developed by Apple. Apple could have been gone even further with the OpenDoc project, where the app was split into the component tools (and this is something that we can find in the Affinity apps, with their Studio Link). The application frame doesn't allow any transparency of the app, and this would have gone against the idea of a virtual desktop, where you document is not confined inside a tool. On your real desk, the tools are acting on the document, and you can have more documents open at the same time . For people like me who have to work at the same time on several parallel documents, the application frame is a really, really bad thing. I hope it's just a matter of time before it is removed again. Paolo

Not only that: if duplicating a book for an alternative version, the duplicated book still points to the original documents, and one will risk to overwrite them instead of the new, duplicated ones. Paolo

Actually, it's the opposite. The Mac has always been document-centric, so much that the tools of the inactive documents disappeared when in the background. And the desktop was not crowded by app frames, but by free-floating documents. Windows framed the documents in the app, that was hierarchically dominant over the documents. And it is what is happening with Affinity V2, where you can't focus on the documents, because they are hostage of the app frame. Paolo

Hi, I'm on Mac Monterey (12.6.9), running the latest beta of Publisher. I opened an IDML file, that only showed a single page. I then Shift-clicked the red triangle, to let Publisher autoflow the remaining text to automatically added pages. Publisher is apparently locked since long minutes. CPU time is 100%, but nothing is changing in it. The app is declared non responsive by Activity Manager. My guess is that a partially embedded SVG file in the IDML file is causing some infinite loop. I sent the IDML file to the main Serif address (not here, since it contains reserved materials), and if needed I can send a spindump. Paolo

Hi, I just interacted with someone to whom I suggested the Affinity Suite. A software engineer with no experience with page layout and design programs. He seems to like it, but find it too complex for a non-specialist. I remember when programs included an Easy mode, where only the most basic commands were included in the menus, and only the most essential palettes and tools were offered to the beginner, or the user with no need to care to the details. Maybe this can be still a good idea. Paolo

Dear Callum, thank you very much for your answer! In my particular case, all the images are delivered together with all the other files of the project, using a File > Package feature or not. - In case I could work only with Affinity apps, this would not be an issues, since everything would be in the native format. - In most cases, I have to comply with file formats standard in the web development. So, images files have to be PNG or SVG. What I can do, in the current state of things, is to save the master Affinity files, and then export the corresponding web-compliant files. This means having to deal with twice the files. It is feasible, but it would be handy to have an option to use the web-savvy formats include all the Affinity features they can support (including linking objects). Releasing projects as a web site is no longer a secondary option, but it is many times the primary one. Affinity Photo and Designer are great tools to make the needed images, but I feel a further degree of integration would be really welcome. Paolo