I am using Scrivener on a MacBook Pro 15" Early 2011 running Mac OS 10.7.1.
I’m not sure how to reliably duplicate this bug as it sometimes happens and sometimes doesn’t (nothing peculiar appears in the console), but I have attached images to demonstrate the strange behavior.
Start or open a project.
Begin editing a text document.
Enable full-screen mode.
Continue typing in the document.
At this point, a few lines of the text displayed on the screen will suddenly be substituted with nonsense characters, i.e. not the ones I typed. I expect to see the characters I typed and not others.
Entering the composition mode or returning to app mode fixes the problem, though it returns once I go back to full-screen.
If I copy the affected text (in full-screen mode) and then paste it in TextEdit, the text I originally typed appears—not the nonsense text.
This behavior makes Scrivener difficult (and annoying) to use in full-screen mode, but doesn’t seem to affect the application otherwise.
To rule out font problems, have you tried replicating this in a test project using a different font? Might be best to save as many variables as possible. From your WIP project, use [b]File/Save As...[/b] to create a testing duplicate and start working in it immediately. Verify the bug reproduces. Then leave full screen; change the font to Optima and try to reproduce it again.
Some common troublemakers that it are hard to determine if they are engaged from your screenshot:
[b]View/Page View/Show (Hide) Page View[/b] on or off?
Editor zoom set to anything other than 100% in footer bar?
Preferences : Editor tab: is either Wrap to Editor mode’s “Center” or Wrap to Page’s mode “Center pages” enabled?
Thanks for your reply. Let me answer some of the questions you posted first.
View/Page View/Show (Hide) Page View was off.
The editor zoom was set to 200%
The “center” option was selected in the preferences (I believe that’s the default).
With Warnock Pro, I tried to altering some of these variables while in full screen mode. Turning on Page View in Full Screen fixed the problem, and it remained fixed in app mode. Changing the zoom level had no effect. Changing the “center” option also had no effect.
I then tried different fonts—Minion Pro and Optima—and things started to get stranger. I had no problems in full screen mode with Minion Pro, but I did in the app mode. The same strange text appeared but it affected a different part of the text. Changing the zoom level fixed the problem, but changing the other variables didn’t.
The other variable you didn’t ask about but that appears to affect this problem is the optical size of the font. I was using Warnock Pro Regular when the problem appeared in full screen mode, but if I changed the optical size to caption, display, subhead, or light, the problem vanished. The same happened with Minion Pro in app mode. The problem appeared in the regular size but not in caption, display, or subheading.
I had no problems in app more or full screen with Optima.
Minion and Warnock are both open type fonts from Adobe, and Optima is a true type font, so I decided to try another True Type font. Palatino had no problems in either mode, but Hoefler Text had the problem in full-screen mode (though it wasn’t as bad as Minion or Warnock).
I’ve used Minion, Warnock, and Hoefler Text with other text editing programs with no problem. Those include applications that use the Mac OS text rendering engine, like Nisus Writer Pro and TextEdit. LaTeX also hasn’t problems with any of those fonts, so I can’t imagine it’s a problem with the fonts themselves.
Okay, thanks for thoroughly checking all of that out. From what you report, it sounds like you might benefit from clearing out your font cache. OS X caches font tables so that they can be more rapidly accessed while you work, and since these caches are volatile, they can sometimes get corrupted with ordinary use; or it could be that in the upgrade to Lion something got damaged. There is a free tool called Onyx (you’ll want to make sure and download the version appropriate for your OS, don’t grab it from an aggregation site like MacUpdate) which has a host of system maintenance, cleaning, and repair utilities. There is a font cache reset tool in there which will take a reboot once it is done. Hopefully that clears up the problem.
I cleared all the font caches with atsutil (sudo atsutil databases -remove) and then restarted so that the type server could rebuild the databases. The problem, however, continues. It’s either a bug in Scrivener or in ATSUI (I hope scrivener isn’t still using MLTE). Given that I haven’t had problems in Nisus and TextEdit, which use ATSUI, I suspect the problem is with Scrivener.
Keith would have to answer that; I’ll let him know of this thread. But it might be using ATSUI for Tiger support instead of Core Text. I doubt it ever used MLTE. There might still be an underlying problem but it is only evident in Scrivener because of its dynamic view resizing. There are some pieces that are subclassed and have always been on the edge of glitchy in rare cases. Keith put together alternate system for sizing and centring text views. The fixes will be released in 2.1.1, but there is a public beta version with these methods, here. Give that a shot and see if it reproduces.
Frankly, I’ll be a little surprised if this is the root of the problem. The fact that it responded to switching the view mode though does give me hope. It just does seem more like a font system issue—those weird kerning results and character swaps, especially, shouldn’t be the result of a screwy view. Worth a shot though.
Scrivener uses exactly the same text system as TextEdit and Nisus (the NSText system), so this is strange indeed. I can’t reproduce it, and I’ve never heard of this issue occurring before, but the one thing that might be different in Scrivener is that fine kerning is turned on by default. I’m wondering if that is causing the issue (although it’s a stab in the dark). Try deselecting “Use fine kerning” in the Editor pane of the Preferences and see if that makes a difference.
Okay, so I tried turning the “Fine Kerning” option off, but that didn’t affect the problem.
When I tried using the beta in full-screen mode, it wouldn’t let me scroll the main text either with the scroll bar or with the arrow keys (i.e. moving the cursor with the arrow keys). Because the problem has mainly appeared in the full-screen mode, I couldn’t really test it much with the beta.
The scrolling problem should only be a problem in the regular version - changes were made to the beta in the beta testing forum to fix this, and everyone who had the problem has reported it fixed. Could you please double-check the version number in which this is occurring (by choosing “About Scrivener” from the Scrivener menu)?
I just posted a new version the other day, so try re-downloading - there was, I noticed, a scrolling problem whereby the centred view wouldn’t actually extend to contain all the text, so that may have been the issue.
And the initial post is only edited, not removed and re-created, so yeah it dates all the way back to the first public 2.x beta in February. The correct date of post will be the last post in the thread.
I just posted a separate thread on what I believe is the same bug. I didn’t notice this thread until later when I happened on it and examined the screenshot.
I believe this is due to auto hyphenation splitting a ligature (the ff in differential in this case). So you will only get it when:
Using a font with ligatures.
Using full hyphenation (probably in conjunction with full justification).
On a line where the hyphenation algorithm wants to split the ligature.
This is why you see it go away and come back with different widths.
My testing in TextEdit seems to show that TextEdit avoids this issue by simply refusing to hyphenate at a ligature. Which is odd since the correct behavior (turning the ligature into two separate fs and splitting them) occurs in Snow Leopard.
An easy (but temporary) fix is to select your whole text and go to Format>Font>Ligature>Use None. Of course you lose your pretty ligatures, but this is probably preferable to losing hyphenation.
Sorry for the duplicated reports. There is a bit of additional information, including some console bug chatter in my other post.
