vonBusing

😳 Not seeing that on MBP 16" and macOS Catalina 10.15.7...

Universal apps! incredibly overweight apps are back in town...

My hardware detection was accurate in both applications. Maybe an article number mismatch/duplicate for your model in the Serif lookup database?

Monthly mailer sound like some newsletter that could probably quite easily be handled by html/css/js. Any browser could make it to a pdf, if required.

Bump: Publisher 1.8.1 is still working the same way. If this is the intended behavior (not a bug but a feature), I would love to hear an explanation of this choice that I do not understand. If not, are there any plans to fix it?

Since it's an image (rather than a vector object) that you are recoloring, you could use the overlay layer effect to fill with an actual color, like white. Not sure how the fill property on an image is actually working, but it is some kind of tinting rather than fill that is occurring. Maybe someone will be able to explain the different color matematics between fill and color overlay on an image. They surely are different.

I tested the provided test file on my MBP 16" with the configuration below and I see the same behavior as @philipmuller97 , both with Metal and OpenGL. Same behavior in APubBeta 1.8.0.523.

Hi @Jon P, I have now tested, as you suggested, to create a new document from the iMac, connected to the laptop via Thunderbold, on the laptop drive. I also included images as linked from the Laptop drive. That worked normally without any access authorisation prompt. Closing and opening that document again does not trigger any warnings, unless I had, in between, opened the file on the laptop, done some changes, and saved again. Then I get this (as with my original working document): : From that dialogue, if I select "Resource Manager" I get the list with all resources with status "Access denied". From here, I have to relink each resource individually, even if they are all in the same folder. If, instead, I select "Yes" in the dialogue above, then I am prompted to relink one of the resources, and nothing more. If I open the Resource Manager now, all the resource links appears as OK. Not sure why we have this difference here, but currently, the "Resource Manager" button in that dialogue is more a kind of trap than of any help. Also the action to "locate" a resource is slightly ambiguous. From this dialogue "locate" is to find the source file on your drive, while "locate" in the Resource Manager is to find where the file is used in the document, only. In the Resource Manager, one may want to do both. Both iMac and MBP are running macOS Mojave 10.14.6 and HFS+ file system. Thanks, /Miro

Hi! In the Affinity Publisher help it is stated that: "It's good practice to keep your linked resources in a subfolder within your document's folder. Not only does it keep your images in one place for easier management, but if you move your project to a new location, the links to your resources will always be maintained." I have all the linked files in a folder that I have together with my APub document, see example screenshot: However, each time I access my project from another computer (and the root path is, of course, different), the links to the images are broken. This is not what I would expect since the relative path is unchanged, and that situation must be similar to moving your project to a new location, stated in the help it should be possible to do. The files are on my laptop and I access the files from an iMac connected to the laptop via thunderbolt. The status for the files in the resource manager is "Access denied". If I replace the missing files with themself again, then status is OK, even after a document reopen on the iMac. Luckily the link connections when opening the document on the laptop are also still OK even after updating them from the iMac. But they reset to "access denied" each time the file is saved again from the laptop. Am I doing something wrong or is it something that can be fixed?

"Funny" that the Affinity Publisher internal update is less than 25 MB while the Affinity Designer and Photo 1.7.3 updates from the Mac App Store are over 400 MB, each. Does this reflect the actual update size for each application or is due to differences between distribution channels (Affinity Store vs Mac App Store)?

I had exactly the same issue recently. Suddenly, any non-letter key (delete, erase forward, arrows) would add various kind of spaces or tabs, making edits quite impossible. I eventually closed down Publisher and restarted, and it went away. I had no similar issues in other opened programs. I cannot say what I was doing just before it started. Probably pasting some text from somewhere else. APub 1.7.2, MacOS 10.14.6

Please, please, please: let Publisher remember the last used Area setting in the export dialogue. The default is set to "All spreads", but I _never_ use that. I want "All pages". I do not know how many times I have to re-export my file because that setting is stuck on spreads by default, independently of all other export settings that are remembered very nicely. This is _so_ annoying...

Thanks @DWright for your reply. As one of the end-users, I'm not very familiar with acronyms like SSCM or GPO. We do have some central system to make software requestable for installation (that how I got AP and AD to be installed on the computer), but somehow, that require quite some preparation of the package to make it available (that I initiated). As far as I understand, the same manual preparation will be needed for each update to distribute. I was hoping this could be avoided if the apps were able to update themselves. Currently, we only have a very few installations (<10), so we are using individual licences. If interest is raising in the company and we get to a higher level, maybe that would justify some kind of multi-user license, but we are not there yet (although I try to be a good ambassador ). At the current level, it should not be a volume issue, that each installation updates itself.

Hi, In a corporate environment, users usually do not have admin rights on their windows 10 machines. With Affinity apps in version 1.6.x, it's not possible to update them once installed by an administrator, because they require a separate download and to run the new installation program with admin rights. My question is, if a 1.7.1 is installed, is the update procedure for future updates different and can be expected to be able to run on the app without an admin intervention?

I agree that locked items should not move in that situation. The behaviour you describe was already happening in Designer 1.6