[Github] Formatting differences when switching between macOS and Windows

Hello,

Apologies if this is a common topic, but I’ve browsed a few threads and haven’t seen it. I keep my writing in a github repo for easy switching between devices. Currently, I’m running the following Windows and macOS versions (desktop and laptop respectively):

Windows - 3.1.5.1
macOS - 3.4.0

I just pulled the repo onto my Windows machine and opened the Scrivener file and the formatting of all my scenes, character sketches, etc. had been clumped together and I had lost all my paragraphs.

The text of one of my other stories was changed. It looked like a larger Times New Roman font but given a filter where the inner lining of the text had been whited out. Needless to say that’s not what it looked like on Mac.

I imagine this has to do with the fact that the two versions are very different, but I do want to continue writing on both devices using my existing solution.

I was wondering if there’s some kind of setting that I need to toggle to make the different versions speak to one another better? I can always switch back to Google Docs, but I’ve liked Scrivener a lot over the years and want to keep supporting it.

Generally speaking, this is not a Scrivener issue between platforms, nor may it necessarily be a Github+Scrivener issue. We do use Git in-house for some of our projects that require collaboration, like the interactive tutorial. Granted we do tend to only ever edit it on one platform, but I have never run into systematic problems with Mac/Win/Git usage either.

Do check this setting though:
https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings

One person did report similar issues on platform swap, and following that config advice cleared it up for them. It’s a bit odd since I would not normally suspect CR/LF issues to be of major impact in RTF (it uses a hard line termination marker, or syntax, to indicate paragraph breaks, not something as incidental as text file newlines). But that’s the best I have to go on, I can’t verify whether it works or not, since I myself have never seen this happen.

Well, one advantage to using Git is that you can fairly easily roll back the damage, but if not there will also be Scrivener’s automatic backups. So you might have to do some recovery in modified sections, but definitely do some baseline testing with settings adjustments on something disposable, like a copy of the interactive tutorial.

By the way, here is our FAQ answer on compatibility. There are a few things to be aware of, but nothing quite so critical as this in general use!

The text of one of my other stories was changed. It looked like a larger Times New Roman font but given a filter where the inner lining of the text had been whited out. Needless to say that’s not what it looked like on Mac.

The FAQ might not address that. I’ve seen that happen now and then (not sure why), but it’s easy to clear. That’s the Format ▸ Font ▸ Outline setting that is rendering that odd look.

1 Like

It looks like it kind of worked! I still need to realign everything in the project manually but it should be okay I think after I’m done… I’ll just spend some time to reformat and see what else I need to change.

Thank you very much.

In my experience, you grow very accustomed to using the Documents ▸ Convert ▸ Text to Default Formatting... command, and will probably put a custom shortcut onto it on both platforms. :slight_smile:

Hmmm, okay actually I went back and did some rearranging in MacOS and once I went back to Windows the line formatting just went back to being clunky again. All my paragraphs just cluttered together and I have to hit return for each respective paragraph. I’ll try playing around with the git settings again but I’m not sure if that’s what’s going to solve it. Maybe there’s some default formatting settings that I’ve missed?

All the templates just clunk together too. I think I’m too much of a new user so I can’t paste images but it’s not just the writing itself that clutters together.

That’s quite all right, I don’t need a screenshot of the result as I think I know exactly what you’re describing at the syntax level, and that would be more useful than a screenshot of a megaparagraph anyway (but you should be past the new user flag at this point).

If you load one of the affected RTF files in the Github website and look at the raw code, are the ends of lines missing a single backslash? That’s what is needed to indicate a paragraph break in an RTF file, like so:

First line.\
Second line.

It might look different, but that’s the sequence of characters you would want to see.

First line.
\
This is fine too.

We found in this report the user made, that quite inexplicably Github was deleting the backslashes from RTF files that were located within subfolders of the project (test RTF files placed at the root level of the project did not suffer this damage). It makes no sense at all for it to take such a drastic hand in modifying data, and is almost certainly something that should be reported to them so they can look at the conditions of your test. Deleting syntax from files upon sync should be considered a major bug.

Again the user reported messing with the config settings and it made that behaviour stop, which is even more confusing to be honest. Changing CRLF settings should have zero impact on whether or not a system mistakenly deletes a backslash character, but that’s what they reported!

1 Like

Hmm, I do see slashes actually at the back of the .rtf file in question. For instance (sorry for the short snippet, it’s just one sentence):

she muttered.\

There are other RTF files where I definitely don’t see any backslashes so that is in fact weird, but the story that does have a backslash also weirdly enough doesn’t have line breaks / paragraph formatting when I load up the software.

I read online that Windows parses new paragraphs as \par instead of \ on macOS. Would this be part of the problem? I made a quick change to the backslashes and added “\par” which fixed the issue, but that probably isn’t a sustainable solution to do this every time I switch between OS/Windows.

Looking at my notes, there is another correct way for RTF to indicate paragraphs, and that will look more like this:

\blah\blah\formatting\codes {Here is the text.}

And yeah, they can be that as well. RTF is such a mess. But no, like I say there is normally no problems with this. We’d be in such a major support nightmare if everyone that ever switched platforms (which includes mobile users) lost their paragraphs (!!).

Well, one sanity test would be to try a copy with a zipped copy of the project, instead of a more complex way of transferring the data.

Yes, I see the \blah\blah\formatting\codes + text pattern as well, mostly just to indicate quotation marks and the like.

Okay, so yea sending over a zipped copy of the file works just fine, actually, so you’re totally right. What is Github doing…? I guess today is one of those days to bug Github about it.

If you have the time to, if you could send me a before and after result, two projects in a zip, I could take a look and see if there is some edge case we are missing, too. We should be parsing for all the forms of paragraphs on both text engines, but who knows. It can be as simple as a single-item binder, and you can DM me the zip, if you can’t reproduce it with sample text.

At the least I can add the case to my notes file on this, even if I can’t come up with a solution.

Sure thing! I can compress a ZIP of the Mac original and zip the Windows version when I pull it from Git. If you need anything else let me know.

In the meantime, I played around with some settings. For people who discover this thread maybe years and years from now, I seem to have the most luck turning core.autocrlf to false instead of true.

git config --global core.autocrlf false

I also made adjustments to my .gitattributes like so:

# Set the default behavior for text files
* text=auto

# Mark .rtf files as binary and disable diff/merge filters
*.rtf binary -text -diff

After renormalizing and cloning the repository, it seems to be okay? I’ll make an update if anything seems to break again.

2 Likes