Losing indents in iPad .txt sync

I hope this is the right place to post this…

When syncing from Scrivener to Dropbox and opening the files in Plaintext (or indeed Writeroom) on my iPad, I notice that all my indents are lost. I assume this is because the files are being copied as plain text files and lose all formatting? The thing is, I just finished sharing a previous project via Dropbox and could swear that my tabs had carried across. Of course I’ve now removed that project from Dropbox so am doubting my own memory.

Essentially my question boils down to whether I can get dialogue indents showing on my iPad or not?



If the indents are special-case, then yes they could be lost in edited paragraphs. If you just have a universal first-line indent that you are using as an aesthetic preference, then they should persist between sessions. While plain-text round trips do mean stripping formatting, Scrivener does attempt to bring the text back in within the formatting flow of the document around it—and therein is why special-case indenting would get lost. If the paragraphs around it are normal, the edited paragraph will brought it like the ones around it. So that could explain why sometimes it worked, and sometimes it did not.

Check your Snapshots pane, if you need to do some double-checking. Scrivener snaps a document before updating it from Dropbox, so the original indentations will be in the last Snapshot it took. I’d try opening a vertical split and dragging the Snapshot into the second editor so you can get a nice big view (don’t use comparative mode; that temporarily strips formatting from the Snapshot).

I see. Then this is a problem for dialogue-heavy text, as a new line of diakogue is simply a tabbed indent. It does make syncing a bit awkward if you are syncing to a pkain text editor. I take it that rtf files wouldn’t be a problem but I’m assuming there is no such thing as an rtf editor for the iPad that will sync with Dropbox? :frowning:

That is correct, I am not aware of any application on the iPad that can edit RTF files; otherwise there would be no problem. I’m not sure how widespread of a problem this is, though. Certainly it depends on the country/language, but most that I know of just use some form of punctuation to denote dialogue—either enclosed in a matched pair of some sort, or an em-dash in rarer cases. Simply using an indent is something I have never personally encountered. Block quotes, certainly, but I don’t think that is what you mean as those tend to be much more isolated in usage.

Most English fiction will have a new line and an indent when a new person speaks, otherwise it would be difficult to read!

Update: I have just discovered an app called Essay that edits rtf on the iPad and syncs with Dropbox, but not sure if it does folders. Will check it out.

Further update: Hmmm. although Essay is reviewed here techinch.com/2011/03/04/essay-ap … g-on-ipad/ it appears to no longer be in the App store.

Oh, that sort of indent should be fine, right, as it is a global setting? It’s not like the narrative paragraphs around the dialogue are lacking in a first-line indent. Dialogue just has an indent because it is yet another paragraph. I’m not sure why you lost those, then. I just ran a series of tests and editing lines of dialogue remained indented at the same level as all of the other paragraphs in the file. The only time it messed up is when I used a different indent setting for a paragraph—then editing it caused it to go back to the universal first-line indent of all the items around it.

I’m pretty sure Essay used HTML for its underlying format, not RTF, and that they were using the term “rich text” in a liberal sense, not as the first two letters in the “Rich Text Format”. I could be wrong, but I thought that is what they were doing. Interesting that it got yanked, I wonder if they broke the rules and used the mechanisms Pages does. They wouldn’t be the first to disappear for that reason. Most editors with formatting controls have an edit mode vs. a display mode for that reason.

I did test this one out when at its début, and I remember thinking its Dropbox implementation wouldn’t work with Scrivener (either the folder problem, or because it used an import/export cycle rather than just opening straight off the DB system). It’s hard to say, now, but I don’t recall getting it to work, and that’s usually the first thing I check with any new interesting looking editor.

Aha! This is perhaps why it worked before for me and doesn’t now? It does look like my paragraphs have an indent in this project, which I don’t usually have, so I wonder if I’ve used a differrent template or something in Scriv and this is why my manual indents are lost, because they are different ?

That kind of stuff won’t come from the templates. While that would be possible to do, we chose not to have templates override the user’s formatting settings as it would be really confusing otherwise, especially as project-level formatting overrides are a somewhat esoteric feature.

What might be the cause though is that 2.1 switched its default formatting from Optima to Cochin 14pt. So if you’ve been running on defaults this whole time, that could explain a shift. Cochin looks quite a bit different from Optima though, so I’m sure that would have been noticeable.

Whatever the case, I would try using Documents/Convert/Formatting to Default Text Style to get the paragraphs all back on the style, and see if you have further problems after that.