Custom font not working properly (Windows <-> iOS sync)

I’m trying to install Cambria font on iOS. I’ve tried both old methods (Fonts subfolder on Dropbox) and system-wide font installation (using FontCase app). The font itself seems to work fine, but after I edit project on my PC, then sync Windows → iOS, Cambria Regular turns to either Cambria Bold or Cambria Bold Italic.

For example, I edit a project on my PC, save it, close it, wait until Dropbox uploads files:

This is what I get when I sync and open this project on my iPhone:

I’ve tried a couple versions of Cambria, but all of them behave in the same manner. Is this a bug or am I doing something wrong? I’d appreciate any help.

Are you able to create text in the desired font directly in iOS Scrivener?

Yes, and it even syncs iOS → Win as it should, but if I then edit it on PC, Regular font switches back to Bold Italic during Win → iOS sync.

I’ve had similar compatibility issues here and there in the past between Windows fonts and iOS fonts, in that a font specified in Scriv on one platform would not be retained on the other platform.

In some cases, I noticed that the font had a slightly different name on Windows then it did on iOS. It was the oddest thing. I installed the same font on both platforms from the same source, but somehow iOS and Windows OS pulled in different names. This happened with the NK57 family of monospace fonts, as well as a few others. The font worked fine on each platform, but wouldn’t work when syncing cross-platform–the font would change to a variation of the font–similar to what you’re experiencing.

My assumption is that there is something in how the font was implemented that makes Windows & iOS treat it differently.

You may want to confirm that the font name is specified exactly the same on both platforms. If it’s not, that would explain the issue, although I don’t how you’d go about fixing it–I was never able to, and ultimately moved on to other fonts that did work cross-platform.


I believe I’m experiencing exactly what you’ve described above. Font’s name is exactly the same everywhere - Cambria.

Is it that you are anxious to do your composing in Cambria in the Scriv editor?

If it is just that you want your compiled output to be in Cambria, then (as I’m sure you know), you might just work in some untroubled font and leave the final font specification to Compile.

A lot of these problems come down to how different text engines address font names. Even if you are using the exact same font, installed correctly on both operating systems or software, it won’t matter because one tool refers to the font by “Cambria-Regular” and another by “Cambria-TS-Regular” or whatever, internally. It’s not something that is easy to work around, since the result is unpredictable and can vary from one font to another. We have added some manual overrides to the iOS version to try and detect variations with very common fonts, like Times New Roman, but since these require very specific adjustments to font detection, it isn’t something we can fix in a universal fashion.

In short, it’s one of those things rich text isn’t particularly good at. Even on the very same computer you can lose fonts between different word processors. It’s something you have to live with if you use more than one tool.

1 Like

Thanks for detailed info! Knowing this internal stuff, maybe you can help me adapt Cambria to iOS Scrivener? I have the tools needed (both TransType and FontLab). The problem concerns only Cambria Regular it seems.

How would you change names in these field to adapt this font to iOS Scrivener?

I work mostly on Windows and Cambria is a font that was created specifically for ClearType, so it looks much better on my screen than any other font, helps to minimize eye strain.

Firstly, yes, in theory modifying the font’s metadata so that both RTF engines are working with the same identifier would work. I’ve never actually tried it, but I can’t think why it wouldn’t. That said, I don’t think it’s going to help you out in this specific case.

Okay, so this is weird, and I’m not sure if there is actually anything you can do about it short of giving up the use of boldface entirely and disabling the variant on both systems (and I have no idea if that is wise at all in Windows since Cambria is a core MS font).

For some reason the Windows version of Scrivener is addressing this font as “Cambria-Bold” in the font table header, and then when using it, uses the \b0 switch to force regular weight rendering, and \b1 when there is actually bold. That’s an odd way of going about things, and the iOS RTF reader isn’t prepared to work that way—it’s wanting a separate font declaration for each variant where each variant is distinct, rather than forcing normal weight switching from a bold font base.

Gritty technical details...

Basically here is what the iPad produces (in excerpt and cleaned up a bit for legibility):

  \f0\fnil\fcharset0 Cambria;
  \f1\fnil\fcharset0 Cambria-Bold;

\f0\fs24 \cf0 test font setting\
\f1\b BOLD: test font setting

Now here is what the Windows version is writing:

  {\f0\fnil\fcharset0\fprq2 Cambria-Bold;}
  {\f1\fnil\fcharset0\fprq2 Cambria-Bold;}

{\f0\fs24\b0\i0 PC: this is a font test}
{\f1\fs24\b1\i0 BOLD: this is a font test}

So first of all, you can see why RTF is an archaic monstrosity that we’re only using because the Mac/iOS text engines do (and support nothing else more modern or sane). What a mess. :slight_smile: But you don’t have to be an sorcerer to see the problems.

In short, iOS uses the \b switch by itself on bold text, and uses the bold font variant as the font setting for the text. The Windows version uses \b0 and \b1 to indicate whether text is bold as well as different font identifier declarations. In theory neither method is right nor wrong, and that is one of the reasons why RTF is a nightmare for coders, but in this case the fact that Windows is writing both fonts as Cambria-Bold is the real culprit.

I don’t understand how or why it would be doing that, and in my testing it doesn’t do that with other fonts in general. Maybe there are others that have this quirk, but here for instance is another Microsoft font, Calibri, being addressed correctly in the RTF header:

  {\f0\fnil\fcharset0\fprq2 Calibri;}
  {\f1\fnil\fcharset0\fprq2 Calibri-Bold;}

So this is some kind of bug worth looking into, and checking our records, we have done some tinkering with how the engine works with font names in the past, to get around some of the most common iOS/Mac/PC issues, so this might be something we can fix.

Yeeeah, now I understand your challenge! I guess I’ll have to stick with Charter for now — it’s rendered slightly worse than Cambria on my screen, but much better than Times New Roman and the likes. But more importantly it causes zero problems on Windows, MacOS and iOS. Still, I hope this will be fixed somehow, someday. Thanks again for an elaborate explanation!

1 Like