Just noticed this today. About 50% of the ‘character’ templates in my current project have become heavily indented. Other document types (so far) seem fine. Not critical, but CBA fixing them given I should be actually writing… but what gives?
Yup, that is regrettably how Mac OS X works at this point in time. We have it reported as a bug, it was filed as duplicate, so I presume they are aware. For now, all tab alignment = left alignment, except for decimal stops. Keith is working on a fix for it, but it is extremely tricky since it is the fault of the core library itself producing bad RTF code. You can try in TextEdit as well, only left tab alignments will save properly between sessions.
So what you are seeing here are templates that had been formatted to use right-aligned tab stops. When the template was edited at some point, with 10.11 in the mix, the RTF was updated with the incorrect codes, resetting all stops to left aligned. Mess, eh?
Again, decimal works, so you can use that as it will act like a right stop.
Welcome to Apple’s beta program. I mean… the latest stable version.
sigh. El Capitan seems particularly littered with weird UI glitches like this. While the OS seems rock-solid stable, UI polish is definitely lacking… Beta indeed.
Here’s another El Cap glitch that is driving me mad: if I go to the Info on a file, say an .rtf exported by Scrivener, El Cap has TextEdit as the default app for opening it; if I then change the default to NWP and double-click on the file, I get an alert saying “This app can’t be opened because it is from an unknown developer”. The same thing happens if I change the default app for .m4v’s created by exporting slideshows from Photos — they want to open in Amadeus Pro, the audio editing app! — to QuickTime, or .jpeg’s from Preview to Graphic Converter.
I assume it’s overly aggressive sandboxing, but it’s a real PITA.
And if you have auto-capitalisation turned on — and you can’t turn it off without turning off the ‘…’ to ‘…’ or ‘–’ to ‘—’ auto conversion — then if you have a stop after an abbreviation the next word is capitalised and Cmd-Z’ing no longer just removes the capitalisation, it undoes all the typing, and when you retype it re-capitalises! Another real PITA.
It makes me wonder occasionally if I shouldn’t have stuck with Yosemite!
Any progress with this alignment thing? It has effectively made the character sheets useless to me now. Was trying to update character bios and it’s an alignment mess. Even creating a new folder (not based on character templates) & copy pasting and the mess persists. Will have to rely on something other than Scrivener for this now, which is frankly rubbish workflow wise.
Update: Also if you copy paste misaligned text into textEdit, you can then adjust the 2nd-line + wrapping in the ruler at the top, which fixes the issue; so it suggests that it’s not Apple’s code that’s broken as such. Either they changed something, or Scrivener has a bug. It’s ONLY scrivener that exhibit this issue for me. Is there any way to adjust paragraph wrapping?
Have you upgraded to 10.11.2 yet? I recently tested this bug again as I hadn’t since 11.0, and found that both TextEdit and Scrivener were saving tab alignment correctly now. Apple is also showing the original bug reports we submitted as being closed.
Yes all my Macs on 10.11.2 - Interesting, existing character sheets still broken, but if I create a new one, it works. So I guess the corruption must get saved to the individual RTF files. I can recreate those easily enough. (I’m sure I tested this yesterday though… perhaps my head is also buggy).
It was definitely Apple’s code that was broken here - you should have equally been able to fix it in Scrivener since 10.11.2.
yes, this was exactly the issue. You could create right-aligned and centred tab stops, but they weren’t getting saved into the RTF. The original template is fine because it was saved before Apple introduced the bug. But any documents you created from the template while the bug was in place would have lost the right-aligned tab stop when they saved. Given that they aren’t saved in the RTF itself, there’s no way for them to magically reappear now that Apple has fixed the bug, unfortunately, seeing as the bug was in saving not loading. So now that it’s fixed, you have to manually fix up those tab stops in Scrivener. I’m glad Apple fixed this, though, because the workaround I had come up with was pretty ugly and hacky.
I take back any implied criticism of Scrivener Also glad Apple fixed their bug; mind boggles how that got through their QA (surely stuff like this would be covered by their automated tests).
Thanks for taking the time to respond KB. My writing life without Scrivener would be miserable.