Known Issues - iOS
After upgrading to Scrivener 1.2.2, it is no longer possible to load any projects, including newly created ones or the tutorial.
Those using modified default formatting with certain fonts may experience this crash. The problem appears more common with custom installed fonts, but has been noted with some system fonts as well (American Typewriter and Hiragino verified).
Fonts do not need to be reset, nor does using them cause instability. It is purely a matter of whether certain fonts have been applied to the application's default formatting for new documents.
To get back into your projects:
- Load the iOS Settings app and scroll down to the Scrivener section.
- Under "Reset Scrivener", enable the Reset Default Formatting toggle.
- Bring up the multitasking screen and swipe up on Scrivener to close it, if applicable.
When you reopen Scrivener, you should now be able to load your projects and work normally. If you wish to try changing the default formatting back to using another font, some have found that different fonts work better than others. If the software starts crashing again, you can easily follow the above checklist to get back in, and try again with another similar font.
Images that have been fully embedded into the text editor (which is the default mode of operation, unless one specifically uses image links to the disk or binder) can lose their DPI setting when the binder item they are embedded within has been edited. The most likely effect of this will be the visible image size changing, as DPI is the only tool Scrivener uses to change the visible size of an image in the editor.
The underlying image itself remains untouched, with regards to its pixel dimensions. This only impacts the metadata that declares how large the image should display itself.
This is currently done intentionally in order to display the image sensibly. A large print-size graphic when displayed in the iOS text editor would be so large that it might take several seconds to scroll past on an iPhone and would severely disrupt the flow of editing your text. Given the fact that the iOS text engine does not have a mechanism for displaying these large images sensibly, the choice was made to scale the image to its intended size, as printed, and in doing so dropping the DPI of the image down to what is native for iOS, 72 DPI.
Images that are set to Mac-native screen resolution (72 DPI) will not see this resizing effect, since its nature is to reset the DPI to 72. If you are not using Scrivener to store print-ready graphics, then you should consider using 72 DPI graphics that have been resampled to the size you wish them to appear. Not only will that save disk space and keep your project from bloating with unnecessary pixels, but it will ensure maximum compatibility across all platforms.
Otherwise, for those that need print-sized graphics, this problem impacts images that are displayed on iOS, meaning the best workaround is to ensure that images are not displayed in this simpler editing environment. The most effective and easiest way of doing this on the desktop version of Scrivener will be to make use of the
Insert ▸ Image Linked to Document ▸ submenu, whilst storing the images themselves in the binder. Alternatively, leave images outside of the Scrivener project and use the
Insert ▸ Image Linked to File… command. See our article on Embedding vs. Linking Images for more information on the difference between these methods.
Mac users who make use of a great number of images may prefer setting Link to images dragged from binder into editor in the Behaviors: Dragging & Dropping preference pane, so that this is done automatically.
Linked images of all sorts will be displayed as an icon in the iOS editor, indicating where the image will be placed, but the original image will never be loaded or processed (indeed, in the case of images linked to the disk, the original image would not even be accessible from another device).