Known Issues (Archived 2.x)
Important: This is an archived article, documenting known issues in Scrivener 2.x. For an up to date list of issues impacting version 3.x, view the new Known Issues article.
A few known issues have longer articles:
- Low Quality when Compiling to Word or OpenOffice: "Low quality" refers to a loss of formatting features, such as footnotes and images, as well as line-spacing and margin fluctuation.
- ePub and Mobi Books Have Left Aligned Images.
- PDFs in Mac OS X 10.10 (Yosemite) cause editor to become stuck
If applicable, the macOS version number will be printed before the bug title, such as the following, "[10.12]", which means this bug should only appear in macOS 10.12 "Sierra". "[10.9.3+]" would indicate any version since Mac OS X 10.9.3 "Mavericks".
[10.14] Viewing some types of research can corrupt the window
NOTICE: Scrivener 2.x is not tested against macOS 10.14 "Mojave", and it is not supported to run it in this environment. If you depend upon this older version of Scrivener, you are advised to hold back on updating your operating system until you can fully migrate to Scrivener 3.
Symptoms
When viewing certain types of research documents, the editor will briefly flicker and then the binder sidebar will become blank, and nonresponse to any input. We do not know the extent of how many different types of files can cause this bug to occur, but have made positive identification on Microsoft Office files, such as Excel and PowerPoint files.
Cause & Status
The problem likely has to do with Apple's built-in Quick Look display of these file types, which Scrivener depends upon to show a content preview for unsupported files in the main editor.
Workaround
If you end up in a situation where the bug has happened, you can navigate to what you were previously looking at by clicking the Back button in the editor header bar. This will ensure that when you reload the project, it will not reload into a condition where the problematic file is already in the viewing area.
[10.12] Crash when zooming a PDF using the trackpad
Symptoms
Periodically the software crashes while working with PDFs. This may occur directly as a result of trying to change the PDF magnification, or while simply working with a PDF in the background---as accidental triggering of this gesture may be involved, or potentially even simply while the option to zoom with a gesture is enabled system-wide.
Cause & Status
Unfortunately the command that is triggered by an interaction between the trackpad gesture used to adjust the magnification of a PDF and the macOS PDF viewer that Scrivener makes use of. Since the bug exists wholly between two separate Apple features, there is nothing that can be done to fix the problem.
Workarounds
Disabling the Zoom in or out feature of your trackpad in the relevant System Preference pane should cause the crashing to go away.
[10.12] Paragraph spacing applied to lines within a paragraph
Symptoms
Paragraphs with line breaks within them will apply padding to those lines as though they were paragraph breaks. For example if a paragraph has 12pts of spacing after the paragraph, then inserting a line break within that paragraph would space out the lines with 12pts, instead of using the natural line-height model for spacing one line after another within a paragraph.
Cause & Status
The problem appears to originate from within Xcode 6, when used to compile software for macOS 10.12 "Sierra". The bug impacts how the underlying text engine itself displays this combination of formatting, and as such the only way it can be fixed is through an update to Xcode or to 10.12 itself.
Workarounds
There are no known workarounds. It is worth noting that the problem is cosmetic in nature. Nothing is wrong with the underlying formatting, and once the text is displayed in software that has not been compiled in this version of XCode, or in programs that do not rely upon the macOS text engine (like LibreOffice or Word), it will appear as intended.
[10.11.2+] Crashing on Project Load (Full Screen)
Symptoms
Projects attempting to make use of Mac OS X's Full Screen mode upon load can cause Scrivener to crash. Projects on the same machine that were not in Full Screen mode the last time they were closed will open normally.
Crash logs for this type of bug can be identified by searching for the following text:
Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan nan]'
If in the following numbered sequence of lines you see references to NSFullScreenTransitionOverlayWindow or startEnterFullScreenAnimationWithDuration, then your project is subject to this bug.
Cause
The bug appears to be entirely confined within Mac OS X's internal code for animating a window to its a dedicated Full Screen "Space". Why this happens for only some programs and not others, and why it hasn't impacted all 10.11.2 computers is unknown.
The Fix
Upgrade your copy of Scrivener to 2.8 or greater. The ability to open a project directly into Full Screen mode has been disabled in this version, which dodges the crash entirely.
[10.8+] Crashing When Closing a Project
Symptoms
If you get a crash report upon loading Scrivener and don't remember any crashes, or if you've noticed that Scrivener crashes when closing a project, then you might have experienced this minor bug that can in most cases be simply ignored.
Cause
The crash itself involves general low-level macOS code, the sort of stuff that Scrivener depends upon to run. We can't really say for sure what has crashed, but given the nature and timing of it, we are certain it does not crash while the project is still open. More likely it is after the window has been removed from your screen and the Mac is running what maintenance it needs to, after such an event occurs.
The important thing to know is that this is a relatively benign crash, as crashes go. Since the project is closed when the crash occurs, there is very little risk to the project itself.
Workaround
At this time there is no workaround possible or necessary. We hope to eliminate the crashes in a future release of Scrivener.
[10.11+] Audio Playback Impacted by Cursor Navigation in Opposite Split
Symptoms
When viewing any multimedia document (such as an audio file or movie) in one split, while typing in a second split, attempts to use certain keyboard shortcuts that would adjust audio playback (such as Cmd-LeftArrow and RightArrow) will be stolen by the playback view, instead of moving the cursor in the active text editor (Cmd-Arrows would move to the beginning or ending of a line, normally).
Cause
The flaw is in the QuickTime player component itself, and there is nothing Scrivener can do to fix the problem.
Work-around
There are no known work-arounds at this time, short of somehow removing the conditions (such as viewing something else in the split) that cause various shortcuts to be "stolen" by the player.
[10.10+] Composition Mode does not fade other monitors
Symptoms
When using multiple monitors, the option to blank out secondary screens when using Composition Mode does not work properly, causing a flicker and then resumption of normal display on secondary monitors, or no change at all.
Status
The source of the problem has been identified and will be fixed in a future version of Scrivener (though given the scope of the changes, potentially to the 2.x line).
[10.6.8] PDFs in Mac OS X 10.6 (Snow Leopard) do not display properly
Symptoms
The PDF view will only display one page or part of one page, and attempting to scroll will have no effect (though the scrollbar may move), or in some cases the act of scrolling will produce visual garbage in the main viewer area.
Cause
The modern PDF display engine provided by Apple, and used in Scrivener 2.6 and newer, is not compatible with 10.6, and there is no way for us to create a version that has the incompatible PDF viewer replaced. This problem is entirely outside of our control, it is as best we can tell, and oversight in Apple's development tools not taking into account the considerations of older operating systems. Given the age of 10.6 at this point in time, we do not expect this problem to ever be fixed.
Workarounds
- If the ability to reference PDF files in the editor is of critical importance to your usage of Scrivener, then the legacy version of Scrivener, version 2.5, can still be downloaded from our site.
- If you never use PDFs in your projects, then the newer versions should be just fine for regular usage. Plus, if you don't necessarily need to see the PDF in Scrivener but use the project system to store and organise them, you can still open the PDF out of Scrivener using the
Documents/Open/in External Editor(Ctrl-Opt-O) menu command.
Spell Check Stops Working
Symptoms
Misspelled words will not be highlighted in red, straight quotes will not automatically switch to smart quotes, double-hyphens and triple periods will not switch to emdashes and ellipsis (respectively). This may happen immediately after installation, or it may happen after years of the spell-check working correctly.
Cause
This is caused by a timing error where individual elements of the editor window are initialized in the wrong order, resulting in a disconnection with the operating system's spell-checking system. The timing is so sensitive that it impacts very few systems, and when it does, it may not impact them all of the time. For example, a system that was working for years may suddenly experience this problem after a system update or the installation of new software, because the overall timing of the system has shifted just slightly.
Workaround
Although it results due to a timing error, the actual trigger is a specific feature that can be controlled: Page View mode. It can only occur when Page View mode is enabled when the project is opened. To get around the problem, open the project and disable Page View by going to "View > Page View > Hide Page View." Then close and reopen the project. Spell-checking (and its associated replacement features) should now be working. At that point, Page View mode can be re-enabled if needed, although it may need to be disabled before the project is closed, or the problem may re-occur. We are continuing to work on a more permanent solution to this problem.
Typing Lag in Main Editor
Symptoms
Typing speed in the main editor will lag behind actual key presses by a noticeable degree, such that if one types rapidly enough, the display of what they have written will take some seconds to catch up. The severity of the problem may vary from machine to machine. The software will be fine when it is first launched, but during the course of using it, something will happen to cause the lag to appear, once it does it will seemingly stay that way until restarting the software.
It is important to note that there are a few things that can cause typing speed to slow down in Scrivener, so if what you are experiencing does not precisely match the above symptoms then please contact us via support so we can help you with your individual case.
Cause
The bug is caused by a glitch in the Mac text engine and its subsidiary font panel. The bug has been reported to Apple, and we'll be using another method to scan for the font panel's presence that will avoid the most common bug triggers, but you may encounter a few that we cannot fix.
Workaround
To trigger this bug you will need three ingredients:
- In the System Preferences: General pane, scroll bars need to be set to always shown.
- The font panel itself must be resized from its original stock position on the screen, and the font preview feature needs to be enabled (you can hide the preview using the gear menu in the font panel itself).
- One may need to right-click, at any point, into a text editor (there may be other triggers as well, but right-clicking polls the system for the font panel's position in order to set its menu labels, this is the part that will be fixed in Scrivener).
Thus if you can avoid any of those conditions, you should avoid the lag entirely. For most poeple, disabling the font preview feature in the font panel will be the best thing to do without.
Changing Editor Zoom Disrupts Ruler Markers
Description
When altering the zoom level of a text document in the main editors with the indent and tab ruler visible, the markers on the ruler may visually drift by small amounts. The key word is visually; the actual formatting will not be changed, and the visual problem can be fixed by simply toggling the ruler off and back on.
Cause
This bug originates within the Mac text engine's standard ruler supplied to third-party developers like ourselves. At this time we can do nothing to fix it and must wait for Apple to do so.
Work-Around
Simply toggle the visibility of the ruler off and back on to reset the markers to their correct positions. This can be done with the Cmd-R shortcut, or with the Format/Hide Ruler and Show Ruler menu commands.
[10.9+] PDF view acquires white rectangles
Description
When using the "Continuous" PDF display mode (where you can scroll through the entire PDF with the scrollbar or mousewheel), adjusting the view settings (such as zooming), and then using PgUp or PgDn a number of times can cause white rectangles to appear along the top or bottom of the view. This condition will be persistent once it appears, even after restarting Scrivener.
Cause
This problem originates from the PDF viewing engine itself (PDF Kit 32bit), which is being provided by Mac OS X. At this time we can do nothing to fix it and must wait for Apple to do so. We plan to update Scrivener to 64bit in the future, which will dodge the problem.
Work-around
Avoiding the use of "Continuous" mode, and selecting View/Media/PDF Display/Page Breaks so that only one page (or set of pages) is shown at once will avoid the problem entirely. If you are using 10.9, and find your PDF display "corrupting" with usage, you should consider using this alternate method of viewing PDFs.
Scratch Pad Undo Fails to Work
Description
While typing in the Scratch Pad editor, Undo (Cmd-Z) will stop working after pausing for a moment from typing.
Cause
Scratch Pad automatically loads changed files back off of the disk. It works this way so that synchronisation can be used to keep multiple computers using the same scratch pad notes. Unfortunately this check also detects changes made by the scratch pad itself, causing it to reload moments after you pause.
Loading a scratch pad document off of the disk resets the undo history.
Problems with Eastern Scripts in the Scrivener 2.0 Outliner
Description
When synopses are displayed in Scrivener 2.0's outliner, writing in the synopsis area using Eastern scripts such as Korean can sometimes be problematic.
Example
Using "2-Set Korean" and typing "d, k, f, x, p, d, j" should result in "알테어"; in the synopsis area of the outliner, this may sometimes turn out as "알ㅔ테어".
Cause
When synopses are displayed in the outliner, formatted text is used to display the title in bold and the synopsis in a smaller, coloured font. In order to ensure that no other formatting is allowed into the synopsis area - which is unsupported - Scrivener has to ensure the correct font is being used as text is entered. However, some fonts don't support all characters, and many fonts don't support all Eastern script characters. The way the OS X text system handles this is to substitute other fonts that do support the necessary characters, in order to display and enter the text correctly. Unfortunately, there is no mechanism for checking whether font substitution is in progress during typing, so when Scrivener fixes up the font to ensure that no extra formatting has crept in, it can mess up the font substitution, causing certain characters to get entered incorrectly.
Workaround
Given that the issue is caused by Scrivener temporarily swapping back in a font that doesn't support the necessary characters, the workaround is to choose a font for the outliner that fully supports the script you are using. To do this, go to the "'Appearance" pane of the preferences and set the Outliner Font. AppleGothic works well for many Eastern scripts, including the Korean example given above.
Status
We still hope to fix this bug in the future so that the workaround is not necessary, but we have yet to find a satisfactory solution.
Finding Text in an Annotation Can Reset Text Colour
Description
Under certain rare conditions, it is possible for the Find panel to reset the colour of the found phrase within an inline annotation, so that it is no longer a part of that annotation. This is similar in effect to selecting a word inside of an annotation and manually changing its colour to something else.
Reproduction
In order for this bug to appear, the underlying text must have its own colour applied to it, and that colour must be different from the colour of the inline annotation. In addition the entire annotation must be off-coloured this way. To you, the text will not appear coloured because inline annotations override local colour changes to the text. This can most often occur when using revision mode, which automatically colours text as you type it.
- In a test paragraph, create an inline annotation (assuming
default red). - Set revision level to 2.
- Right-click in the annotation and choose "Select Annotation".
(Partial selections will not trigger the bug; manual full-selection is okay.) - Use
Format/Revision Mode/Mark Revised. (Whether you leave
revision mode on, or turn it off at this point, does not matter
for reproduction.) - Place the cursor before the annotation to help search out.
Cmd-F; type in a word that appears within the annotation.- Hit
Enter. (This is important;Cmd-Gand clicking the
button will not work.)
Workaround
If you experience the bug, used Edit/Undo to get rid of the initial problem. The bug is only triggered when the Enter key is used to confirm a search from the Find dialogue box. Using Cmd-G or Shift-Cmd-G to scroll through search hits, or clicking the "Next" and "Previous" buttons in the Find panel will not trigger the bug.
Status
This is unfortunately a bug in the underlying Apple text engine, and not something that can be easily worked around at the level that Scrivener works within.