nwhit

Opened fine in the betas but does not launch in the final Mac App Store version.

Interestingly, after going from the latest beta to the Affinity Store final 1.7.2 update, I also lost the text rulers on new and old documents. I quit the app and restarted which gave me back the text rulers, but odd they disappeared with the final version update. I'll have to watch if they disappear again.

As per the thread below, many are concerned that even in the latest Affinity betas any changes made in APub via SL to a linked file, the changes made within SL are not saved to the original APh or AD file, nor is the newly modified graphic changed to an embedded file. Just curious when/if this will be addressed so that we can really start to use this potentially great feature. I was hoping to see this in 1.7.2 but in testing today, still not working.

In v151 crashes both Nik and APh beta after selecting about the 4th "Recipe". Crashes when clicking on the notification dialog for losing previous settings. No crash report generated. Can select normal presets but the "Recipes" are what cause it to crash. Update: If I click the Do Not Show Again in the dialog, no crashes. Tried about 8 Recipes and saved the final one successfully. Thus probably related to handling that pop-up dialog.

...using the Recipes. After clicking on the Accept (regarding getting rid of previous filters), always crashes. Metal on.

Was replying to OP that there was no problem with text wrap for me in the new beta.

Same here. Just tried it on an existing and a new doc.

Just noticed an issue in the Hyperlinks panel where in the dark mode when double-clicking on the name to edit it, cannot read what is in the field much less what you're typing. The display is white text and white background. Minor thing but does make it tough to edit link names.

Still the same in v458

Sorry, forgot to add that. High Sierra. Metal on. iMac 27 2017 i5 Radeon Pro 580 8192 MB.

Normally if you change a file name of an open doc in the Finder, the app automatically gets the new file name for the open file. Tried it on two open files. One that did not have any changes/modifications got the updated file name. The other open file that had not been recently saved did not update the file name. Thus when closing that file, APub asked if I wanted to save it, but it saved it as a new file with the old name.

The latest beta is 1.7.2.442. Be sure that is the app version you are reporting on.

I kind of assumed that. Really wished it worked like so many other Mac apps. The reason for this "desire" is that it is not uncommon to mistype (or even misthink!!) a file name when originally saving, thus requiring a file name change. Hate to have to close the file, go to the Finder to change the name, then manually reopen the file with the new name (since the Recent Files dialog won't work after a file name change. Also saves having to do a Save As, then remembering to trash the old file later. Over the years, have had to do these Finder file name changes many, many times, and for a few other reasons as well. Always been simple on a Mac with apps automatically updating with the changed file name. The other worry I have is that if a person is not aware of this "limitation", and they do change the Finder file name, they may not be aware that changes made to the open file from then on will be a a newly created file using the original name, which may be quite different than the original name. And while I cannot say for sure, that might possibly lose Undos and History in the process. And it could create confusion when later looking for the correct and latest version of the file if the file name change is significant, thus putting it out of sequence in the Finder and Open dialogs. Don't know how tough it is to get this to work, but seems other apps do it reliably, so perhaps worth thinking about. Or at least providing some type of warning dialog if someone does this, and before the app "secretly" creates a new file with the old name (you won't know this until much later when you try to open the new file name and discover it's not the latest version). Thanks.

Has been happening fairly often. An export of a JPEG in APub results in a switch from APub to Preview after the export. The resulting JPEG is not, however, opened in Preview. Had been using that option in APub for PDFs but that option is not there for JPEGs. I've found that I need to quit APub in order to get it to stop switching to Preview.

Works correctly! Thanks!

I read that in the beta notes, so will give it a try today. Thanks!

Crashing again with Recipes again in v150. It crashed after about the third Recipe selection was made. It didn't generate a Photo Beta crash report but the one attached has a time stamp at the same time, so may be the results. quicklookd_2019-08-05-144429_TRAC-Main17.crash

Have not had this happen before. Had a mutli-layer small advert and was going to place a couple art elements on top. However, when I selected the items individually to place (psd files), before clicking and dragging to place it, the main pic layer below it disappeared completely and a large, stretched version of the file to be placed appeared instead (see pics). Once I placed the 2 psd items, the display went back to normal, but this would, of course, preclude precise positioning when placing if a person were relying on the main picture layer. Very strange and can't say I've had this happen before in any of the versions. Can upload various files but would need a link.

I did that for sending the file to you so that you'd have the images that are normally linked (as per a common instruction prior to uploading a problem file). Have been doing some more work this weekend with the new beta and have not had a reoccurrence of the crash when opening other files, so maybe a one-off for whatever reason.

Crash report attached. High Sierra. Affinity Publisher Beta_2019-08-01-124602_TRAC-Main17.crash

Aha! Now I see what's happening! When the "place" cursor is hovering over an existing picture frame, it seems to automatically preview the placed item in that frame! That may be "by design", but it does make it hard to place new items on top of existing frames. Perhaps I am doing something the wrong way??? Update: I tried adding two new picture frames on top of the main picture frame to contain the two new psd files and seems to work better. Slower way to add minor graphics, but at least doesn't cause the issue reported in first post.

With both Metal display and compute on. Previously did not work properly but the latest betas work much better with metal now. Still might be a few glitches with metal but not with my common workflows.

As per my other post on the newest beta speed improvements, with the new 1.7.2 betas, my speed is massively faster than 1.6.x or 1.7.1. And that's processing 24MP RAW 3-bracket HDR merging, tone mapping, plus other touch-up tools, then custom export. High Sierra, iMac 2017 i5, Radeon Pro 580 8192 MB, Metal display and compute. Cleared up the slowness with the 1.7.2 betas and made it significantly faster than 1.6.7. In fact, too fast for me to even get some coffee drinking done while I work! (I typically do several hundred of these RAW develop/merge/tone map/touch up/exports a day, so am very familiar with typical speeds.)

I've uploaded the file. However, it only crashed the one time after updating the beta. Since then it opens fine and I haven't had issues opening others so far, although I haven't had time to test a lot of previously created files. I also had to go into the file and embed the images and re-save in the new beta, so not 100% the same file. Don't know if the crash report showed anything strange but thought I should report it.

I agree that this needs to get sorted out better. Really a remarkable capability, but has some very rough edges that make using it a bit dangerous as bergdesign said. I'm just now testing the newest beta 442 and was wondering iof this has been resolved, but it hasn't. Using Studio Link to edit a linked APh file does not change the original APh file, nor does it create a new, embedded version for "safety". I would think this should have a preference where you could select (maybe per document) if edits in SL update the original file. But if it doesn't update the original file, it does need to embed a new version so that edits don't get lost.