Scriptwriting mode reverts to Courier Prime

I’ve been a longtime, happy user of Scrivener on both Mac and iOS. Recently I’ve tried the scriptwriting capabilities of the desktop version and found it a great help. I’d like to work on my iPad as well, but one thing is holding me back.
As soon as I toggle the scriptwriting mode for the project in the iPad app (latest version on iOS 11.2), any new script element I create reverts to Courier Prime.

I know Scrivener will revert to a default font on iOS if the chosen custom font isn’t present, but all my text is formatted using the Palatino typeface, which is a default font in iOS I believe. I’ve also explicitly defined the typeface for all the elements in the Script Settings dialog in Scrivener for Mac (v3.0.3). I’ve also created a blank project with the Stage Play (UK) applied to it and changed the font settings, after syncing with my iPad the app still reverts to the Courier. The desktop version of Scrivener still respects my changes in Script Settings.

Does anybody know if this behaviour is intended or if there’s something else I could do?

EDIT: Just updated to iOS 11.4, but the problem still persists.

You probably already know this, but screenplays are supposed to be written in mono-spaced typefaces. Palatino is not. It’s pretty much an industry standard. Perhaps the iOS version only allows scriptwriting in mono typefaces. I couldn’t find anything definitive in the iOS tutorial.

Yup, but I’m not writing an official script or screenplay, just using the handy functionality. It seems weird that you’re able to create all these style options on the desktop, just to have them completely overwritten without warning on iOS in scriptwriting mode.

Thanks for the report. I’m able to reproduce this with a simple test project, by creating a new screenplay project, then adjusting its Script Settings to use Palatino on all elements and importing a little sample content. When copied to iOS, the existing material is formatted correctly, and I can edit that text without losing the font assignment. However if I add a new line or change an element designation on an existing line, then the font switches to monospace.

There is a fallback behaviour here that will do that, if the font being requested by Script Settings is not found on the iOS device. However it seems to be triggering even when the font does indeed exist.

We’ve got it filed to look at for the next iOS patch.

Great to hear that it’s probably a bug and that you’re looking in to it.

Hi,

I’ve just come to the forums to hopefully find a solution to the above issue. I thought I would comment on this thread, rather than start a new.

It looks like it’s been an issue for a while and wondered if there was any hope of it being fixed? I really love the script writing on the Mac app but when I have to use my iPad it does cause issues.

Further to this, when importing back into Mac it looks like any dialogue isn’t formatted as such but is instead labelled as “General text” meaning each line has to be reformatted individually.

Would be great to hear where you’re up to as I use my iPad more than ever and Scrivener is the one app that ties me to my old mac.

Thanks,

Lewis

The iOS version of Scrivener hasn’t been updated for over a year and there seem to be some other scriptwriting bugs plaguing the current version.

Is an iOS update still in the works?

What they said.

If I am working on a script and want to prepare it as a “typeset script”, I would not change the scriptwriting font I worked in, but simply have compile change the font at compile time. That would be a natural and certainly the simplest approach on the Mac version,* and I believe the same approach could be taken in the iOS version.

In that way, the genuine bug uncovered here would not get in the way of getting the work done.

gr

  • It seems to me OP went to a great deal of work (in their Mac Scriv set up) to accomplish something that could have been done with a single click in compile! I mean, maybe they just adore looking at Palatino when they work. I don’t know.

This issue seems to have been resolved in Scrivener 1.2.0 for iOS, released in September.