nwhit

All 3 Affinity apps are showing duplicate fonts/styles. In all 3 of the Affinity 1.10.x betas, if you select any Font Book collection, it shows numerous duplicate styles for many of the fonts. If you then select one of those collections, then subsequently go back to the All Fonts listing, it will now show even more duplicate font styles, thus making it a bit impossible to select a font and style, not knowing if you've selected a real one or some corruption of the list. This first began with either v1.9.x and/or my switch to Big Sur. Can't be sure which caused it since both happened at about the same time for me. Prior to this, I used Font Book collections routinely/daily in all Affinity apps without any issues. I have tried clicking the Reset Fonts in prefs numerous times, and restarting the app(s). As per the pics, still get a ton of duplicate font styles showing for several fonts. In the examples showing, it's Futura and Futura Condensed. These are from a new Futura family package. In Font Book, I ran Font Book's duplicates find and eliminated a handful of unrelated duplicates (not related to Futura), validated all fonts, and restarted the computer in Safe Mode. But no matter what I do, I still get a whole bunch of duplicate font styles for quite a few fonts. Even Impact (randomly shows 3-4). How in the world do you get a correct font list in Affinity, or is this a bug where the Reset Fonts isn't working? I'm at a loss and trying to get client work done, but don't know which font style I can or cannot use.

I was having issues with fonts in Big Sur, so tried a Control-Open for Publisher (Affinity Store version) to let the first 3 items reset including prefs. Made a copy of ~/Library/Application Support/Affinity Publisher first. That didn't resolve the fonts problem, so wanted to restore my prefs/presets. etc., so moved the original Affinity Publisher folder back into the App Support folder, replacing the new one. But all my pref setting are gone. Lost my Studio preset, all my regular pref settings, etc. I even tried grabbing a copy from a day ago Time Machine backup, and that didn't bring back the prefs or presets. I even renamed it and restarted Pub to create a new virgin prefs folder, then copied over items from the original one, but still my prefs/presets were gone. Has something changed in Big Sur as far as storing the prefs and presets? I thought everything was in that folder in App Support. The Publisher folder I now have in there has a "presets" folder with what appears to be my Studio preset named com.seriflabs.Studio.Preset.Data2Layout-tab.Basic Startup 1.preset, but it neither is there upon opening nor in the Studio Preset menu. And none of my other presets are there. The assets and keyboard shortcuts seem to be there, however. HELP! How can I get my prefs back so that I can go back to work?? UPDATE: Found there was a com.seriflabs.affinitypublisher.plist in the ~/Library/Preferences. I had been under the impression all was within the Application Support folder, but I assumed wrong!

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! 😵

Just upgraded to a new iMac with Big Sur (came from Catalina) and have now opened an existing client APub doc (v1.9.3). I noticed that one of the Text Styles looked wrong. The font used was Futura Light, but it now shows it with a "?" next to Futura (pic attached). Nowadays I simply use Font Book for font management and do have fonts from as far back as the 80s, so a bit of a mess, but it has worked just fine until Big Sur (with minor straightening out along the way over the years). In looking at Font Book, it is showing Futura now has duplicates, and reading further about Big Sur, I understand that they now install a bunch of fonts into the System/Library/Fonts/Supplemental folder that apparently aren't supposed to be disturbed. So I see that I now have those fonts, plus the Library/Fonts and my user ~/Library Fonts folders. In looking at the newer version of Font Book in Big Sur, I see the dialog for duplicate fonts (pic attached). However, I have not used this newer duplicate resolution, so am not 100% sure how to best proceed so as to not mess up my existing Affinity documents. I have to get the client's document finished quickly, so don't want to have to tie up my computer for days trying to sort out this new font issue with Big Sur. And I also found out that if I simply try to change the font within the document, whether by editing the Style or simply changing the font, it destroys the entire paragraph (pic attached) or even the entire text frame. So, I'm hoping that someone who had had to resolve this issue with Big Sur and APub (and other Affinity apps) can guide me on the CORRECT way to get back to business. If I resolve duplicates in Font Book, do I just use the automatic button? Can I simply deactivate the duplicate Futura font set located in the System/Library/Fonts/Supplemental folder and not mess up my existing files? Once I correct for duplicates, what do I need to do within Affinity to get my fonts working again? I do see the Pref for Reset Fonts, but I didn't want to click that until I understand the implications of doing that. I don't want to destroy the typesetting in all my previous Affinity files! We do use Futura a lot, so would have a HUGE impact if I do it wrong! And speaking of Impact, I also see that the Impact font now also has duplicates! And it is also used heavily. Hoping someone can provide me a correct step-by-step to get me back to having the right fonts showing/available. Not worried about sorting out old or corrupt fonts since everything I've been using has worked for as far back as I can remember until I switched to Big Sur, so it appears it is just an issue of resolving duplicates and making sure Affinity documents retain their correct formatting. Thanks in advance! I've read some of the other threads and websites related to OS11 and fonts, but none had a clear resolution to the issue. Thus I thought I would ask the great, experienced Affinity users for guidance in order to get my client's work done ASAP.

Yes, in fact it did crash when I did a CMD-Z while editing some text. And, no, not aware of any debugging software installed. I've never seen this type of crash myself on any software in Mac history! I was quite surprised to see Terminal open and that it had run something.

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

Just tried and seems to be working fine on the new beta 243.

Thanks. Yes, I can't remember EC not working with CMYK previously since we have produced items for print before and I don't remember having had to do the RGB first. Seems odd. And you're right, I just looked at their web page and it does say, "Eye Candy can handle images in CMYK mode and 16-bits/channel, which are needed for professional print work."

Aha! Interesting! Playing around with it, I found that in the upgraded 1.9.3 I accidentally created the new test document in CMYK. The results as seen in the pics were that EC failed, whereas in the betas and previous versions (1.8.x) I was creating in RGB. Works when created in RGB but not in CMYK. Interestingly, I can create the items with the EC effects in RGB, the convert them to CMYK and still export in 300DPI PDF just fine. Apparently just have to create and filter in RGB first. Thus don't know if this is a bug in APh or by design (or a limitation). At least part of the mystery resolved (sort of)!

Just upgraded to 1.9.3 and Eye Candy (Update: See my reply on what happened) no longer works. Worked fine in 1.8 and the 1.9 betas including the newest 1.9.4.242. Not only is the preview in EC not working in 1.9.3 release, the final result no longer works. I had been testing it with several 1.9 betas and it has always worked, so disappointed that it stopped working in the 1.9.3 release since I use this plugin frequently. And as I said, it was working fine in 1.8.x before upgrading today to 1.9.3. Not sure why the release version is not working when the betas do. It has been in the past a problem with the MAS versions not working due to sandboxing, etc., so that's why I bought an extra/new copy from the Affinity Store in order to be able to use EC. Settings are the same in both app versions (Metal on), same as tests in past versions. Attached pics show EC preview and final in APh 1.9.3 release and 1.9.4.242b.

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.

Also doesn't happen for me on Catalina in APub 1.9.2.1024 beta. F&R works fine.

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.

I'm still using beta 1.9.2.1024 and macOS 10.15.7, but it works fine for me.

I just tried my G**gle Nik filters using the 1.9GM beta and they seem to work fine on Catalina. I am using the Affinity Store version. Had to switch from MAS version and buy the Affinity version awhile back in order to get Eye Candy filter to work.

This feature is in APhoto 1.9 beta that is pretty close to coming out. They're working out the last few bugs, but you can try it yourself by installing the beta from the beta thread. Installs side-by-side with the release version, so nothing harmed by trying it. I also need this feature VERY badly, so am pleased it is finally here. This is the Mac beta: https://forum.affinity.serif.com/index.php?/forum/19-photo-beta-on-mac/

Thanks for this! I just last week started playing with the new beta and was perplexed on how to work with a merge, even after reading the Help file! Hopefully the release will have much clearer instructions similar to what you've presented!

What I eventually found out from exhaustive testing was that the Mac App store version simply could not get around Apple's sandboxing security to run Eye Candy. In my testing, the beta versions always ran it fine, but that is not using Apple's sandboxing since it comes from Affinity directly. In the end, I bought a new copy of Photo from the Affinity Store and it has worked well. Didn't like having to spend an additional $50, but for the amount of work it saves me using Eye Candy for client work, it was pretty danged cheap! It's not like competitive products where it might be several hundred dollars to buy an additional copy, so it fixed my problem and I'm happy. And with all of the major upgrades/improvements/new features Affinity has provided to date with no upgrade charges, well worth supporting them as much as possible!

Okay, I just tried opening multiple times with the 5 embedded-version docs open and it opened every time. I then switched to multiple opens of the original linked-version 5 docs and no crashes. The only "difference" that I can think of before this morning's crash was that the computer had been in Sleep prior to opening APub (woke up about about 20 minutes before opening APub). Not sure if that would be a cause of any issues, especially with the linked resources, but that's all I can think of that was different. And as originally reported, when it did crash and upon reopen asked if I wanted to reopen the previously open docs, it did not open them (as was the case with all previous crashes). Not sure why that has not been working as it should. Anyway, the docs and crash report are uploaded.

Sadly, had another crash on Open. I have uploaded the 5 files that were open plus the newest crash report. I changed the APub docs to have embedded resources, so everything should be there (hopefully!), although I normally work with mostly linked resources for the most part. On creating a new Prefs folder, can try that for an opening or two but can't do it for a longer time since I have work to get done and need my workspace layout and other defaults, etc. And since this has been an intermittent problem, not sure if that will do much, but can give it a temporary try.

Jon, since upgrading to 1.8.6 and then subsequently closing and reopening, I haven't had a crash. That said, I was working on several similar docs this last few weeks, so can't really remember which ones were open when the crashes were happening (typically have 4-6 open). Can you tell which docs were trying to open from the crash reports? I could save them as resource-embedded and send to you just to see if maybe I'm not currently working on one of those that were previously causing the crash. Thankfully I may not need to start with a new App Support folder since, if I recall correctly, I would lose my prefs, workspace, defaults, etc., which would be a real pain to try to reconstruct. I'm VERY pleased to see that the 1.9 beta will have savable workspaces/Studio layout. Takes some time to develop a "friendly" workspace, so in the past was always a huge PITA to lose it from a crash, etc. Also will be extremely nice to be able to switch to various workspaces based on what a person might be doing in a project. But as of today, opening APub 1.8.6 with 5 docs has not caused a crash, so either I am not opening the "faulty" doc any longer, or the problem has gone away with my recent upgrade.

Been having this issue for a few weeks using previous version of APub, so after finishing a project upgraded to 1.86 this morning to see if it would fix it. Didn't. Routinely get a crash (fails to open and get the Report dialog) with a cold start. Additionally, if I click to reopen the previously open docs, it never does. Have not had this occur through many versions of APub including numerous betas. Not sure what it causing it. None of the open docs are complex, etc., so doubt they are to blame. Also, never have this happen with APhoto, so just APub is doing this. 2019 iMac with internal SSD, Catalina latest. Last 2 crash reports attached. Affinity Publisher_2020-12-08-100020_TRAC-Main17.crash Affinity Publisher_2020-12-09-120542_TRAC-Main17.crash

I moved the main text frame off the page, created a new text frame on the main page, then copied and pasted all the text from the single, old, stretched text frame. Once pasted into the new text frame on page 1, I could then click and flow to a new frame on page 2 without the issue. Apparently at some point the original main text frame became corrupted, thus not allowing a flow to a new frame. Not sure when or how that happened since I have been using this "template" for a while now without that issue. And for 2+-column main text frames, never use the scale handle. But in the end, now can say it's fixed.

Yes, I read the thread on the IDML import, but this was a created from scratch back a couple versions. Text was a copy/paste (unformatted) from a text document for other media, but each paragraph copied/pasted from various other text sources (web, html email versions, etc.), but as normal for much of our past work, all brought in as plain text (unformatted) and into paragraphs setup with Styles. Unlike in past versions, the formatting/font size stays correct if the text flows within the same frame. But as soon as you flow it to a new frame, the remainder of the interrupted paragraph in the new frame is the wrong size. The following paragraphs remain correct within the new frame. And, you are correct. The original frame was not scaled. I did find one workaround, but it is not a workable solution. If I copy the initial text frame with the entire text, paste it on the new or same page, delete the text within that pasted frame, then flow from the original into this now blank frame, things work. Very strange. And the odd thing that suggests a bug is that when you roll-up the original text frame, thus pushing more text into the new linked frame, the text that moves into the new frame is likewise enlarged/wrong size. The "split" paragraph simply can't make it across the link without changing font size in the new text frame for the balance of the split paragraph.

Not sure if this is the same as a couple other threads that report similar issues, but I can't seem to work around this issue. In 1.8.4 when I try to flow text to a new frame, the font size jumps significantly FOR THE REMAINING PART OF THE PARAGRAPH THAT FLOWS TO THE NEXT FRAME. I've tried using the loaded cursor (from the flow icon) to drag out the new text frame, tried creating a new, blank frame, and either way, the first few lines of the overlapping paragrpah have the wrong font size (Text Style was applied to the paragraph). And, no, I did not stretch the text frame using the "scale" handle. I dragged out a new text frame, either from scratch/new or with the loaded flow cursor. I can upload the file with embedded assets with a private link. I don't recall having this issue in previous versions. I also have read that there is a reported bug if the text frame has been scaled with the bottom-right extended scaling handle, but I didn't do that in this case. Has made it very difficult to edit and finish the last couple of these docs where this problem cropped up. Has required creating a line break and then changing the incorrect font sized lines. Thanks.