vonBusing

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.

Hi Pauls, As far as I remember, I have not met the same problem again, neither in betas nor released versions since that actual version. Thanks, /Miro

Maybe you solved that, but did you try Copy and Paste (cmd-C with the app selected on the dmg and then cmd-V in the Application folder) instead of drag and drop?

Any particular reason why Photo Beta updates are offered through auto-update (much smaller download size) while Designer and Publisher beta updates never are?

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.

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?