When using iOS Scrivener in split view mode with iBooks on a 10.5" iPad Pro, I have noticed that, at the end of a document, there is a lot of weird behavior with respect to the font/style of the text entered. I don’t think this only happens in split view mode, but I don’t recall seeing it while running Scrivener alone.
Examples:
Sometimes, in the middle of a line, while typing, the font/style changes from “none” or “body” to something else, usually a variant (sometimes italic, for example) of the Heading 1 style, but always something pretty large. If I bring up the paintbrush menu, “body” style has a checkmark, but if I type, a different font/style is used. Highlighting and changing the larger, non-body font and selecting “body” changes what it looks like, but then typing again types in the incorrect font/style.
Usually, if I go to the end of the text (cmd-down arrow) the cursor is very large (like for a heading font), but when I type, I get body/none.
These artifacts only happen at the end of a document, I don’t see them when adding or changing in the middle of the document.
My workaround for the problem is to type some body text, back the cursor up a word, hit return to create a new line, then go back to the previous line and do my additions. This effectively adds a dummy line to the bottom of the document and then I don’t see the problem. But the problem consistently appears if there is nothing, or only blank lines at the end of the document.
Have you tried updating to the latest version of Scrivener (an update was released on Tuesday)? There is an incredibly serious and stupid bug in the iOS 11 text system whereby, when you type at the end of the text, the typing keeps reverting to the formatting of the first letter in the document. In the latest Scrivener update, I have done my best to work around this bug using a raft of kludges until Apple fixes it.
I updated to the Scrivener version that says it was “Updated for iOS 11 Support” on Sept 19. In Settings it says that the Scrivener version number is 1.1.2(1158).
As far as I can tell, the behavior hasn’t really changed in the past few days.
That’s hugely frustrating because I worked hard to work around this ridiculous Apple bug and thought I’d got it mostly fixed. As I can’t reproduce the problem on my end since my “fix”, could you please provide me with the steps I need to follow to reproduce the problem? (Apple is aware of the bug, and it’s so internal to the text system that it is almost impossible for me to fix myself, but I would like to see what I can do.)
EDIT: Wait, you’re on the macOS 3.0 beta team, and you’re talking about styles. Is this in a 3.0 project? I can now reproduce the problem when I open a 3.0 project in the iOS version and I have text using a style at the start of the document. 2.x projects are working fine. The styles are throwing off my workaround to Apple’s nasty bug (ironically, the workaround is being thrown off by another Apple bug… ).
Sorry, I have been using Scrivener3 for too long and forgot about it being a possible factor. Yes, all my projects are Scrivener3 projects.
FYI, I am amazed at the number of Apple bugs that you have to deal with. Long ago, I worked for a small high-tech firm (hardware design) and I remember having to work hard to prove to folks that some bugs were caused by peripherals we purchased from large companies. The standard refrain became “That can’t be their (the large company’s) problem, they are a real company.”
).