Hi. I cannot seem to add additional fonts to both an iPad iPadOS 14 and iPhone iOS 14.
This is a new problem. Previously, I’ve had a Fonts subfolder within the folder that synced to my iPhone and worked seamlessly. The iPad is new to the mix. But i think the issue is iOS 14 as the fonts I had added to my phone pre-14 are still there.
I’ve removed the Fonts subfolder. And then put it back.
I’m having the same issue. I write exclusively on my iPad Pro and running iOS 14. Didn’t have this problem up until a couple days ago. Everything worked awesome, but then I added a new font and it didn’t show up in the list. What I discovered was the issue is the font manager I installed so I can use my favorite fonts system wide. If I install the fonts there, they will not show up in Scrivener. If I don’t install in my font manager, the fonts show up in Scrivener just fine. I use Font Case just in case that make a difference.
I am now having issues with the font showing up in Scrivener’s list, it uses the correct font, but on the very next line it reverts to Helvetica (I hate this font more than anything) and it doesn’t matter how many times I change it back to the correct font and save as default formatting, it continues to revert back to Helvetica. Sometimes right in the middle of the word I’m typing. I don’t sync back and forth my Scrivener files. Everything stays on my iPad so that’s not the issue. And it does this for all of my custom fonts. They all work, I write in that font, but every line reverts to that hideous font. . Hoping iOS version gets an update soon.
katlovergilpin - thanks for the info. So, are you saying this is an iOS bug? Because I’ve been having this issue from iOS 14 through 14.3. Dumb question but how do you distinguish between the problem being Scrivener or the OS? You can tell far from my area of expertise.
I do jump back and forth from ipad to computer, if that plays into this. Though since buying a keyboard, more and more work on the iPad Pro.
I’m not sure if this is a problem with iOS 14 or with Scrivener itself. Although, I have not had this issue happen in any other writing program I have used to see if I like it enough to switch over. I hate to be unfaithful to Scrivener as I love the program, but it has been a frustrated experience at times. I have noticed that as the iOS continues to get updated, issues such as this pops up in Scrivener and since Scrivener for iOS has not been updated in over a year, even longer since it gotten a substantial update. Unfortunately, until we can get an update to Scrivener on iOS, the bugs will continue to pop up and more often. I love working strictly on my iPad, as I feel I get more done, but it has been a real challenge lately with the font issue, the onscreen keyboard taking a third to a half of the editor (even with typewriter mode off), the font issues, and the constant crashes. Scrivener has hinted an update is in the works, just hoping it happens sooner rather than later as it has caused a huge ripple in my daily writing.
Thanks Devinganger - after removing the fonts from settings → general → profiles they appeared in Scrivener (properly installed in fonts folder). Hopefully, Scrivener will ultimately be able to access fonts in accord with iOS 14.
Hmm. In spite of comments above, I’ve had several custom fonts even though I use only one, and they are all working fine in Scrivener on the very latest iPadOS 15.5.1 – and have through lots of 14 and 15 versions.
I’m aware of the officially described method, and it works for most fonts. The issue here is that fonts installed system-wide by a font manager app (in my case, FontCase) seems to mask fonts imported by Scrivener. It’s a bug—though it’s unclear if this bug is in iPadOS/iOS or in Scrivener.
It would be very convenient if Scrivener were updated to know about and use system-wide fonts installed by other applications.
(Incidentally, I can’t find any evidence of an iPadOS 15.5.1 version existing. Only 15.5. I double-checked for available updates last night.)
Well, you’re correct about iPadOS 15.5. I was probably remembering 15.4.1, In any case, nothing recent seems to have made a change, and Scrivener’s custom font feature works.
You didn’t mention your actual problem, which is apparently with the add-on FontCase. I’d be a bit careful of just assigning ‘it’s a bug’ to anyone. There is almost certainly a hierarchy needed, as only one copy of a font can actually be used, and who gets to go first will just be in the necessary rules.
FontCase, though, looks to be not keeping up - without quite suggesting it’s yet abandonware. There hasn’t been an update in a year, according to the store, which is a long time in Apple versions. As it’s open source, or even from many apps in general, that’s perhaps to be expected after a while.
I suspect that you’re pretty well on your own with this, then, unless Keith knows a way to assert Scrivener’s choices of fonts over anything presented by the os or add-on layers, and might be able to fit that into the coming update.
Thinking a little further, I’m not sure what you mean by mask. I was musing that if FontCase wins, then you could put your desired font there. But maybe you mean that using FontCase just prevents Scrivener’s ability in general.
Possibly there’s a compromise in placements where you get enough of the fonts that you prefer?
To be clear, nothing recent has changed. This problem is (based on the clues in this thread) a couple of years old. I’m asking if there are updates on this problem.
I suggest you do not fixate on FontCase as the issue—based on earlier comments, it’s likely other applications are triggering a kind of conflict as well.
You’re speculating that some kind of hierarchy of fonts in iOS/iPadOS exists. I am not sure this is accurate or relevant.
There is certainly a bug of some kind. Scrivener is the only application with which I have experienced this sort of font conflict. iOS/iPadOS introduced the ability to modify the system’s fonts using apps, and for any other apps to see those fonts. For comparison, Ulysses similarly is able to use custom fonts, and it’s capable of installing them itself or using system fonts.
Therefore, Scrivener appears to have two issues: it cannot show/use newly added system fonts, and it cannot show/use its own fonts which happen to have also been installed as system fonts.
FontCase does its job well, even if it has not seen an update (on the store) in a couple of years. I have used it to make new fonts available in several other applications. It has worked so well that I had forgotten about it until I saw this thread.
I am not sure there is any need to “assert” Scrivener’s fonts “over” the OS. From reading how you describe this, it sounds like you’re speculating that some feature of iOS/iPadOS is responsible for preventing Scrivener from using the system’s fonts or its own. I doubt this is the case, but I cannot be certain, since I have neither the source code for Scrivener nor for iPadOS.
I used “mask” to describe the actual behavior I’m seeing. This gets into what is precisely happening. I did not describe it in detail because I assumed you had carefully read the comments above (and those on the other linked thread).
To recap, here’s the sequence of events that reproduce the issue where Scrivener cannot use system-installed fonts. Note that I am assuming a fully-up-to-date iPad Pro.
Begin with the default OS installation.
Install both Fontcase, Scrivener, and Pages from the App Store.
Open Pages. Observe the available fonts it makes available from the system in its formatting options.
Open Scrivener. Observe the available fonts it makes available from the system in its formatting options.
Use Fontcase to install a new font system-wide. (Let’s call this font “Century” in this example.)
Open Pages. Observe that the font “Century” becomes newly available from the system in its formatting options.
Open Scrivener. Observe that the font “Century” does not become available in its formatting options.
So this is the first issue. Scrivener is unaware of fonts installed system-wide. It does not show Century.
A subtlety: Scrivener can in fact use Century if it happens to open a file (such as an existing Scrivener project, or an RTF file) which references Century. This means the font works, but it is not visible in the formatting options. This behavior is mentioned in the linked discussion thread.
To reproduce the second issue:
Begin with the OS after performing the above steps to reproduce the first issue.
Open Scrivener. Observe that the font “Century” does not become available in the formatting options.
In this instance, the font appears to be “masked”—it has been installed, which can be confirmed by attempting to reinstall it. It can be used using the hack described above. But it is not visible in the formatting options.
To work around:
Begin with the OS after performing the above steps to reproduce the second issue.
Uninstall the device profile installed by Fontcase in the first set of steps.
Open Scrivener. Observe that the font “Century” does become available in the formatting options.
I hope the above describes the issue precisely enough for you (or anyone else). It means there are two workarounds for the problem:
I can avoid installing a font system-wide altogether (using, e.g., Fontcase) and use it normally in Scrivener. This has the disadvantage that no other applications can use that font.
I can install the font system-wide and use some other system (like macOS) to set the font I want in a project before opening it in iPadOS.
My goodness. Emily, it’s no secret that software issues can be complex, while the orders that would solve them exist, and are in themselves as machinery, sometimes straightforward – sometimes not – once you find them.
The note (and follow-ups) from @Silverdragon, second in the thread you mention, says right up-front where the problem begins: with Apple, and then the font apps not being happy to align themselves. Silverdragon is always sharp.
And yes, it’s a little less clear how this relates to how Scrivener’s response to the environment appears to have altered.
All the insistence in the world is not going to alter such a collision by itself, and you have the idea from Sparrowhawk already on a way to proceed.
Can Scrivener do anything about this? What you describe finally about ‘masking’ seems to suggest that the font is still present by Scrivener’s folder method, no matter what the external situation is. However, it’s then not giving you the menu option to select it.
I would think that if this is accurate, it is probably something that Keith could fix.
I’m glad you could finally describe the problem so that there’s a chance at insight from the outside. This is not at all always possible, and that’s why the influence or protocols needed to be mentioned. The tone? That’s something you could think about, when you want to ask persons to attend to what is a personal desire for you, in a small and perhaps quite taxing detail of something very complicated.
Understanding what software persons of particular ability go through to create something like Scrivener, would be a lot like understanding what a gifted writer experiences in the long effort of a novel, I think we can safely say.
Perhaps that will properly recognize and compliment @KB Keith, so that he could look at this with a comfortable eye.
It’s true that I am speculating about how Scrivener works, but I should mention I have been a professional programmer for over a decade and have some degree of expertise when I speculate about what a program or a programmer can achieve.
At the time of their post, @Silverdragon was correct. Note that the post dates from September of 2020—very close to when iOS 14 was released.
At that time, iOS 14 made significant changes to its font functionality. It redesigned its APIs to accommodate new and improved typography. Not just the ability to install new fonts, but many other subtle differences. You can read about some of those here.
Because of this change, that means that Scrivener works differently on iOS 14. That does not mean that Apple caused the problem, nor is it necessarily Apple’s responsibility to fix it. It is, rather, a compatibility issue. Applications often need maintenance to continue to be compatible with new operating systems. This is normal and expected.
My original question on this topic was brief and meant to ask whether this maintenance had taken place.
I believe you correctly understand the issue.
This is fixable. It requires implementing the newer APIs. This would need to be done in a way that maintains compatibility with previous OSs before iOS 14. It is not necessarily trivial work, but it is not an extraordinary feature, and it is most certainly possible.
I had assumed that the previous descriptions of the issue were adequate to understand, and that you had read those carefully, so I didn’t feel the need to retread in my original comment. I was only asking for an update.
You point out my tone, and I think that’s uncalled for. I have to confess I’ve lost patience with you.
To be clear, you appeared in this thread and posted an initial response which:
presented no new information;
misunderstood the original issue;
dismissed the original issue; and
disregarded my actual question (about updates).
I wasn’t asking for troubleshooting. I wasn’t asking for a link to the documentation. Saying that it works for you, that it’s “simple,” and “it’s a short list of steps” is deeply condescending because it makes the prior assumptions that I didn’t share the issue mentioned above or wouldn’t take the time to attempt to use the software’s own manual. These are unwarranted assumptions based on the brief comment I added.
I felt the need to follow up with more detail so that others observing would not come to the belief that you had resolved the issue.
You have made a number of additional assumptions about my position, my ability, my expertise, my situation, and what I was asking. Just to rephrase this as simply as I can, I was asking: IS THIS STILL AN ISSUE?
I held (and continue to hold) no expectations on my part regarding obligations on the part of any developer to cater to my individual needs (although I don’t think that would necessarily be indefensible, given how much I have paid for this suite of applications). With my technical background, I’m very cognizant of the kind of effort that application maintenance entails, and I have every sympathy with the developers for the problems this situation poses.
I don’t think it would be constructive for either of us to continue to post here, and I intend to disregard this topic entirely in the future. While I appreciate your attempt to help, I strongly wish you to consider in the future if you have something meaningful to contribute to an existing topic before posting generic troubleshooting steps.
Scrivener for iOS 1.2.2 is currently sitting with Apple waiting to go through the review process. This includes the necessary updates to support fonts added to the system using apps such as Font Diner and Creative Cloud. It also uses Apple’s new font picker UI rather than using our own, which should in theory be better at detecting all fonts, however installed.
Unfortunately we have never been able to reproduce the issue of fonts installed in Scrivener not showing up, however, so I can only hope that moving to Apples’s standard picker hopes with that. In testing the new picker works with system-installed fonts and fonts added to e.g. Scrivener’s Dropbox folder.
This new update should be out sometime this week - depending on when Apple gets around to reviewing it (it will probably take longer than usual, being WWDC week) and assuming it isn’t rejected for some unforeseen reason.