vonBusing

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.

By default the Gradient tool on a text box is activated for the text itself. You can adjust the text box background gradient by changing the context in the gradient tool's contextual toolbar: Just switch "Text" to "Frame" as above. But these are the only two available options. Serif would need to add a "Rules" context to make it work on the column rules as well.

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

I thought it might be so, but I could not find it in the 1.8.0.502 update listing at first. Now I see that the text frame improvements I was reading were limited to the IDML import, and that this one was further down on the list...

I do not have it in the retail version 1.7.3, but it is there in the beta 1.8.0.502. MPB 2013, MacOS Mojave 10.14.6, Metal enabled for APub but OpenGL for APubBeta

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?

I uploaded them to your link. Please handle as confidential information.

Hi Pauls, Yes, the assets I had in place during the 1.7.x beta cycle. A 8.5 MB file: They did not show up in the Assets pane in the new beta. It was empty, so I tried to add them again from exported files, but it did not work. I looked at the read/write access rights to the new file (that works) compared to the one that was included in the folder I removed, and they were the same (644).

Hi, When trying to import existing assets' library, I get "Import failed - Unable to import file". Same error with a freshly exported library from APub 1.7.3. Actually: I can't add any new assets to the assets pane or create any new category. Factory reset from the Edit menu (or any other reset from the settings pane) did not help. What actually helped: closed down APub and deleted the (from the user home folder) Library/Application Support/Affinity Publisher Beta/ folder, and restarted. Maybe there are some less drastic solution to suggest?

"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