nwhit

INTERESTING!!! So you have the same issue with Affinity's listing of Font Book user font collections?!? As I've said in previous posts, I'm not seeing the duplication of fonts in any other app other than Affinity apps, and all Affinity apps are showing the same duplicates within the font collections, which if viewed, then corrupts the All Fonts list as well! 
Yeah, in the old days, I used to use Suitcase (years ago, and even before OSX), etc. to only have my main fonts showing in my main apps. But with Big Sur/OS11 especially, it is no longer possible to do that. OS11 puts 355 mandatory fonts into the System/Library/Fonts and Supplemental folders that can't be deactivated. Makes for a very congested fonts menu! 
I have for a few years used Font Book's user-designated Collections, and with no problems. I was using them routinely in Affinity apps as well and was not aware of the problem I'm now seeing. For me it started with what appears to be OS11 and/or Affinity 1.9.x. But interesting that you see the same thing! 
I haven't used a font management app in years, so am not aware if using one can overcome this issue. Might be worth the very hefty price they now ask for one of those previously inexpensive utilities if it could fix this problem. Maybe someone who uses a font management utility could answer that. The way it is right now with OS11, scrolling through several hundred mostly useless fonts to try to set type in client docs/images is really not pleasant at all. 
Thanks for the input, Bruce! At least I now know that I'm not alone in seeing this issue (and totally cursed!!). And it does raise the question, where is Affinity getting its Font Collection listing from? Or why is it "corrupting" Apple's Font Book's user Collections? 

I did just try to use Reset Fonts in APub prefs, then restarted APub. I modified the "faulty" text style, and tried to reapply that, but it messed up the entire paragraph, then the entire text frame. I then copied all text from the frame, pasted into Text Edit as plain text, then back in APub, created a new text frame, pasted the plain text into that, then applied the main para text style to the first few paragraphs and the edited character style to a sentence within. That worked, thus leading me to believe that the entire existing text frame is "contaminated" or something. That doesn't look good if all our existing docs will need all text reset once I resolve the duplicate fonts issues! 😵

I was working with some text in a small banner ad when Photo 1.9.3 crashed. The odd thing is that with the crash it opened Terminal and created the following:
TRAC-xxxxxxxxxx$ /Applications/Affinity\ Photo.app/Contents/MacOS/Affinity\ Photo ; exit;
2021-06-17 13:35:04.816 Affinity Photo[2599:98660] CoreText note: Client requested name ".SFNS-RegularItalic", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2021-06-17 13:35:04.816 Affinity Photo[2599:98660] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions...58 completed.
 
[Process completed]
----------------------
Never seen anything like this before! Hopefully that Terminal session hasn't messed with anything. Crash report attached.
Affinity Photo_2021-06-17-133455_TRAC-Main20.crash

Thanks for checking. I haven't been upgrading (still on 1.8.6 for actual production), waiting for the dust to settle on 1.9.x. But I did just try this on my beta of 1.9.2.1024 and it seems to work fine. But thanks for the follow-up. Hopefully with 1.9.4 I can upgrade and start enjoying the new features. 

Just as an FYI, I'm still using AP beta 1.9.2.236 and Unsplash works fine for me on Mac Catalina. While my "regular"/working version is still Affinity Store 1.8.6, I've been upgrading the betas through the 1.9 series and now using the last one. Doesn't provide a solution for your issue, but at least a reference point.

SOLVED! Stumbled across the Layer/New Live Filter/Depth of Field Filter. This is, essentially, the typical and common blur vignette, but also has the option for the "Tiny Town"/Tilt-Shift effect. 
 
IMPORTANT: Took me a while to figure out why I was getting a white border around my picture after applying the filter. Apparently you need to check the Preserve Alpha option in the adjustment pane. Not covered in the Help, but found a reference to it in the forum.

Thanks for your encouragement. Based on your PM, I did the screenshots for virtually everything just in case some things didn't transfer. Was a bit of a pain, but for my needs with Eye Candy, it was well worth it. Was simply getting a little nervous about having to rely on using betas, especially with my intent to soon upgrade from Mojave to Catalina, thus requiring me to use my CS5 PS within a Parallels Sierra virtual volume. That works, but it is slower and has a couple minor bugs that don't help everyday productivity. 

UPDATE
I pulled the trigger.
I created a new Affinity Photo folder in the Library/Application Support directory.  I then copied the all the pref folders from the beta prefs EXCEPT the user folder. That I copied from the 1.8.3 MAS Containers pref folder.  I then opened the new 1.8.4 from Affinity Store, entered my key, etc.  The Workspace was NOT retained (sadly!). On the other hand, the Brushes, Styles, keyboard shortcuts, color palettes were retained. The macros had to be re-imported. And when trying to add the Assets Studio Panel, it  caused continuous crashes. Thus I had to delete that pref and create a new, blank Asset panel.  My several Tone Mapping presets didn't come over, so needed to export from 1.8.3 and re-import. All in all, it seems to have worked, although I've not really tried very much in the new setup. Took about an hour to get it straightened out. But in the end, it did fix my main issue -- getting Eye Candy plugin to work in a release version!!! 

Thanks, yes, I have been doing just that as a backstop in case things need reconstructing. Thanks for the help!

Looks like this is fixed in beta 1.8.4.663. Thanks!

Looks like this is fixed in beta 1.8.4.663. Thanks!

I can appreciate what you're saying. On the other hand, EC has never had an issue in most all of the betas. Works fine. That does lead me to believe that the issue lies in the Mac App Store version and, as you say, sandboxing. In the release version Mac Bugs forum, a poster did report that EC works in 1.8.3. As was the case in 1.8.2 and 1.8.1.
So I guess I am now spoiled enough using Affinity apps as opposed to my antique CS5 apps, it would be worth the extra $50 to be able to regularly use EC within APh. Also hoping that you can support EC in the future. It is a very useful tool and greatly reduces time/costs for our clients.

Sorry, just tried it and it isn't fixed. I opened the APhoto file in the newest beta/rc, then did a save as. Tried to place in the latest APub beta just now and get the same issue. The bounding box is still a full A4 size. 

Thank you!!! It's back to working (mostly) in the new beta. It does, however, have a glitch or two in the preview of certain effects. It appears to be related to bevels I think. But at least EC can now be opened within APh and there is at least a reasonable preview! So a BIG thank you for that! 
PS. I did notice that every so often, I could get the preview to work if I resized the window, but not always.
 

Have had this issue in the last few betas and still there. Using APhoto beta 168, have a graphic that is only roughly 7x3" and is a cmyk doc. When I place it in APub b584, the bounding box is essentially an A4 size, thereby requiring either a lot of overhang of the empty bounding box or using a frame or other method to crop. Cannot understand why it comes in with the strange bounding box. I also have an RGB version of this same APhoto graphic created at the same time and it places just fine. Don't know if the error is in APub or APhoto, other than it opens and looks fine in APhoto. I did just try Placing it in a 1.7.3 ADes new doc and it also places with an A4 bounding box, so maybe this is a problem with APhoto???


Gurney_Logo_Footer_-_Literature-1cmykv18.afphoto

Yes, I have been trying it for the last hour or so and so far, so good. Still have a pdf-x4 issue, but the Digital Small seems to be fixed! Keep my fingers crossed as I keep trying a variety of exports. But also encourages by your results!

AHA!!! I thought I had seen it before but a search didn't show it! Thanks! Maybe it'll get fixed!!!

It's nice that both windows can be resized, but I've noticed in trying in this latest beta that neither widow's size stays set after a restart. Especially important in the Resource Manager window where the names of the resources are very often much longer than the "default" field spacing. If either window is resized, should be sticky between app starts. Thanks.

Tracked down both issues (missing font and X4 export). The doc had a linked pdf graphic element (a site plan) that had that missing font within that pdf. That not only caused the mysterious Missing Font warning (but Preflight could not show it was in that item), but also caused the failure of the X4 export. I'm guessing because of the missing font. 
Seems this could be an issue. I'm sure many people get pdf graphics sent to them where the fonts used might not be 100% matching to theirs. If including them within an APub doc causes this much grief (can't easily find the problems), might it not be better to handle the export error better? Or at least with Preflight have the ability locate the item/resource with the missing font? Both the Affinity team and I have been scratching our heads as to why this doc created in APub would not export. Preflight ALMOST found the problem, but maybe needs a little better capability to actually track down the problem item -- if that's at all possible.
My workaround for that doc has been to open that pdf in Designer (which converted the missing font to curves, I'm assuming), then exporting it back out as an eps for inclusion in the APub doc. Perhaps it might be better to just link to the now converted Designer file??? That's assuming liniked Designer files are not presenting any issues within an APub doc.
At least this mystery has be solved, assuming Preflight can be improved to find this type of error. We routinely use placed pdf graphics in our page layout docs, so it would be nice to catch this problem before it becomes a time-consuming output error. Never had this problem in ID, which I understand is an issue with pdfs with missing fonts opening or being used in Affinity apps. 
 

Just checked my 5k iMac and I'm not seeing a significant diff when the windows are overlapped. I do agree that much of the interface is (and has been) a bit too small to comfortably see on a 27" iMac. 

If it's not in the IDML, then, yes, be great to have an Pref to set for IDML imports. I've learned to reset the option, but other users may not be aware of this and start adding a bunch of resources to an imported IDML without realizing they are being embedded.
Thanks.

Really hate to get into this "fight", but I just tried doing a Photos pic: duplicated it, Edit, Edit In Affinity Photo. Made changes (did a colour halftone), saved in APh, then closed the pic in APh. The changes were saved back to Photos, did a Done there and the changes were reflected in the pic in Photos. 
I also tried the APh extension Haze Removal from within Photos and it worked and saved just fine. I will readily concede that this performance might not be universal for everyone's configuration, but for my fairly "normal" Mac, works fine here.
I do have to say that as a pro photographer, I don't use Photos as a DAM since I need all my master files readily available in client folders/directories, not in a "library" file. (Been a pro for decades and have used numerous apps for DAM, but today do not like the current options. Liked Aperture a bit since I could store originals/masters in their original locations and not within a "library" file.) But I would likely welcome an Affinity DAM since I am generally pleased with what they are doing with the other apps. 
Just my 2-pence.

Just checked my 5k iMac and I'm not seeing a significant diff when the windows are overlapped. I do agree that much of the interface is (and has been) a bit too small to comfortably see on a 27" iMac. 

Also notice that after a restart of the app, the New doc window expands full-size, which on a 27" screen is waaaaaaaaaaay too large. I would think that once the window is resized by the user, that size should be retained/sticky even after a restart. 

Just found the general area in the thread.
Unfortunately, in a skimmed reading, it looks like it might require having ID, but not needing to actually open it to run the script. But I could be wrong since it's been a while since I've read it or used the script.