Compile issue: every line but first is half-page indented

Scrivener Scrivener for iOS
,
1

I’ve been trying to sort this out for the last hour and it’s killing my creativity.

I went to export a portion of a project to share with a beta reader, and they prefer Word. I set the compile flag on all the parts I want to share and clear it on all the parts I don’t (and wished not for the first time a cohesive place to do this enmasse) and let Scrivener work.

I started with this:

IMG_0533
IMG_05331646×939 225 KB

But it exports to this:

IMG_0532
IMG_05322388×1668 191 KB

What is the trick setting fluffing things up? Where is it on the iPad? Can it be fixed or will I have to tell my beta reader that they will have to wait until I get back to my ‘real’ computer next week?

2

Note: this ‘formatting’ appears on most every combination I have tried. Plain text works, but then I have to import that into Pages to make a word file that isn’t just plain text.

3

Create a collection for the parts you want to compile. You can then save the collection, set collections to be visible in your binder and add/delete items to each collection as you wish. Collections can also be created with searches, so maybe add a beta reader tag to those parts. Then search by the tag and save. This will auto update when you tag more parts with the searched-for tag. There are more specific details in the manual and/or tutorial under your help menu in Scrivener. I hope this helps!

Re: your compiled (apparently hanging?) indents - I’ll wait for someone more experienced in compile settings to chime in.

In the meantime, it will certainly be helpful to know if you apply custom styles to these errant parts, or if they are all “no style”. Also, check to be sure the correct style is applied in the compile window. A screen shot of your compile window would be helpful.

4

Collection? Never heard of this feature. Where can I find it?

5

I just realized this is posted under Scrivener for iOS. :person_facepalming:I know nothing about iOS - I’m so sorry!

On windows, if you select items in your binder then Documents > Add to Collection > New Collection.
To then view collections in your binder, it’s View > then check Collections

Also, on mac or pc, if you type “collection”( no quotes) in the top center search bar, you should find the menu commands. I have no idea if iOS has similar functionality.

6

@kewms can you help Dain with iOS iPad and his compile indents?

7

I took at look at my iOS Scrivener (iPad) and from what you show, it seems to be something going on with first line indent. But without poking around your project, I can’t yet see what to say to help, but I’m curious.

That being said, your problem is to get a Word DOCX file you can send soonest to your beta reader. Perhaps “cut to the chase” now and open that DOCX file in Microsoft Word or Pages, select all, and set the first line indent as you want.

Then work the Scrivener questions. It’s the weekend and i’m guessing response by moderators or others will be slower.

PS. Your bottom screen showing what you call “export” does not look like my preview of compile output to Word. Different icons at top. I have iOS Scrivener 1.2.4 on iOS 17.4.1

2 Likes
8

For something like this, it’s very difficult to diagnose what is going on from descriptions of it, without days or weeks of back and forth (now check this, no wait check that over there, what about this checkbox, what happens if you hold the device upside down?) as it is not a normal or common result. You’d have better luck sending an excerpt of the project, or however much it takes to demonstrate the issue, to tech support. There we can go through all of the “now check this” questions in a matter of minutes and either send you a fixed copy or tell you what to do.

2 Likes
9

While I appreciate the scope of the places to look for the ‘trick setting’ (and this is indeed part of the deeper problem) the effort it would take to cull all of my work that isn’t ready to see the light of day from the project files is probably a larger ask. I ended up with the ‘switch to the editor window for every scene then, cmd-A, cmd-C, switch to LibreOffice, open new document, and cmd-V, rinse&repeat’ method to get around the issue, so the original timeliness is moot, but the issue of malformed settings in the project persists.

Having climbed into the XML of projects before, I wonder where such settings live normally?

As an alternative, is there a way to get Scrivener to export EVERYTHING in the binder to some format (XML, CVS, plaintext, markdown) that preserves all DATA and abandons all Formatting, Styles, and project specific Settings? Yes, I’m a dinosaur that remembers with some fondness working in 80 char x 25 line monospaced plain text in the 8/16 bit era. I also remember the pains of pre-WYSIWYG typesetting, where you’d end up spending almost all the time you saved from correcting typed errors getting the [explicative redacted] printer to output what you wanted.

Because if it were, I could export the current working project, then import it into a newly created project and leave behind all of the issues that are hiding in the weeds.

12

Oh I’m not interested in any of the text as content, just the formatting of any one single paragraph that shows the error. There is no need to get critical about what to remove, remove everything from the sample copy except for the paragraph(s) in the screenshot you already showed.

Or if that’s not working for some reason, you can always scramble a project beyond any ability to recover it.

Having climbed into the XML of projects before, I wonder where such settings live normally?

That’s impossible to say without knowing the nature of the problem, it might not even be in the XML at all, but the result of a weird RTF formatting command that got pasted in years ago and never manifested itself until now.

As an alternative, is there a way to get Scrivener to export EVERYTHING in the binder to some format (XML, CVS, plaintext, markdown) that preserves all DATA and abandons all Formatting, Styles, and project specific Settings?

There is no command that would export the entirety of what a project is (keywords, snapshots, bookmark lists, compile settings, etc.), without the formatting coming along for the ride. But honestly I wouldn’t waste time on such endeavours until knowing more. I can think of very few problems that would necessitate so much manual labour to fix them.

That said, you can of course back up your text, as text: see File ▸ Export ▸ Files..., which can batch export to both plain TXT and will do some minor Markdown conversion (as in, it will convert unambiguous things that have no other purpose in the editor, only, like footnotes or images—it’s for backing up Markdown writings, not generating Markdown from rich text).

1 Like
13

Looks like a simple hanging indent problem with the First Line Indent set to maybe 1 inch and the Left Indent set to somewhere at the centre of the page.
Turn on your Ruler and check it out.
Highlight everything and drag the Left Indent to zero.

2 Likes
14

That’s the perplexing thing though. There is no ruler in the iOS version. And there is no GUI in the compiler for designing how things look (as we can see in the first screenshot, the paragraphs themselves appear normal).

It is I would say effectively impossible to accidentally end up with formatting like this. You would have to tap on four separate buttons to get all the way into the compile appearance editor, and then be faced with an empty YAML file that you need to fill out with at least as much as the following:

Title: Hanging Indent
Text Format Overrides:
  Font Family: Courier
  Font Size: 12
  Line Height: 2.0
  First Line Indent: 1cm
  Indent: 8cm

But it’s also unclear how a binder item named “Prologue – Buying Eggs” ends up printing “Prologue” in the output. Overall there seems to be some missing ingredients.

15

Admittedly, I don’t know Scrivener iOS.
But the original post talks of exporting to Word—to appease a beta reader.
Copilot tells me:

image
image1232×467 18.4 KB

I interpret the misaligned result to be in Word where a peek at the Ruler for a few lines can show what’s happening.

The “export” may be a cut and paste to Word, where the problem lies, especially since the experience is not that of other users.

1 Like
16

I don’t have Word on my iPad. I use third party tools to generate Micro$oft formats.

I misspoke in that I run LibreOffice on my full computers, but don’t have it on my iPad, I use Pages on my iPad.

Placating a Beta Reader that both reads and answers a writer is worth more than a modicum of respect for their preferences. I have offered more than once to outright buy them a Scrivener license to make my life easier, but they insist on using Micro$oft Office (and keep trying to convert me). My struggles and battles with the derivatives of the OS wars notwithstanding, it usually is a surmountable difficulty.

I spent a fair bit of time this morning, first by opening the offending project on my windows machine (Scrivener Version: 3.1.5.1 (2073405) 64-bit - 06 Jul 2023) and saved the project as a copy, which I switched to and started culling content. I dropped almost everything except the portion of the prologue that could be seen in the example screenshots at the start of this thread.

I attempted to compile this, and it worked as anyone might expect, and not as it did on my iPad earlier. If it matters, I opened the resulting file in LibreOffice Writer Version: 24.2.3.2 (X86_64) and it wanted to translate to the ODF format from Word2007.

I then copied the first flawed export from my iPad and tried to trim it down to just the first page or two of 102 pages. Trying to delete 99 selected pages crashed LibreOffice Writer. After reloading and recovering, I manged to verify that the resulting document was only three pages and I saved it in Word2007 format.

While working on this, I discovered the flaw had cured itself on my iPad. I can no longer get the indent issue to trigger, and more than that, on the copies of documents compiled with the flaw, it was only from a specific folder in the binder, as when the document moved on to the next chapter, it was formatted as desired. This strikes me as some sort of orphan title page formatting that go applied to top item and then recursively down the tree from that folder.

This is looking more and more like kruft in the cracks fluffing up the index. I think for now I’m going to SaveAs to a new filename for the working version, if I see other oddities, I may have to go to the extreme of migrating the contents of the many binder items into a newly created blank project.

@AmberV I will email trimmed copies of this project and most of the examples I have made to the iOS support email box later today. Perhaps they will still have enough clues hiding in them to get to the bottom of the question no one has asked yet – have I run across a hitherto unseen bug? Regardless, I am preserving originals at this point if for some reason they might be needed.

Further background: The working version of these files, are themselves a copy that was made about 18 months ago at this point. The original was generated from a NaNo template (2021 I think), and was first worked on with the Mac version of that era, exact digital genealogy of specific files is not something I track. After starting the project file on MacOS, I swapped off writing on my MacBook Pro and iPad throughout NaNo '21 and after that November went back to the same project file to keep working on it through to present, though I have a Windows 10 laptop now I didn’t have then which gets used sometimes as well. The project uses Dropbox to coordinate between machines, and I’m adept at the pitfalls of the service.

2 Likes
17

“Prologue” is a folder in the binder with sub-elements, the first of which is “Prologue – Buying Eggs”. In the working version there four sub-elements in that folder. Note: it is just the Prologue folder that generated the errant indents.

trimmed tree

1 Like
18

Thanks for the update. I do agree that it seems more like some kind of bug than anything else. As I noted above, it’s pretty hard to get to a result like that on purpose, at least on the iPad.

If the stripped down example does exhibit the behaviour, I could probably figure out what is going on, if indeed it shows up for me as well. It sounds like it may have been at least somewhat transient, in that you are no longer seeing it? If so, only send a sample at your own convenience. We might get lucky, but chances are if it went away on its own on your own setup, we’ll never see it.

1 Like
19

Thanks, @Dain! I got the sample files you sent, and I can reproduce the problem. I had to change the settings a bit—perhaps that is why you were no longer seeing it—back to “Manuscript (Courier)”, which the first screenshot looks like, and then I disabled the First Item is Title Page setting, as that treats the first item as-is and doesn’t reformat it.

From what I have uncovered, the good news is that you should be able to clear any sections where this problem comes up, by selecting all of the text in each affected section, and using the format brush tool, under “Formatting Options”, select “Use Default Formatting”. On the iPad this is a slower one-by-one fix.

However once you have access to a full computer again, you can fix the whole thing much more quickly since it allows you to select many binder items at once and use the Documents ▸ Convert ▸ Text to Default Formatting... menu command.

Either way, that will be considerably simpler and less time-consuming than rebuilding your project from scratch!

Given how this problem does appear to originate in the formatting itself, I would advise replicating your preferred settings from scratch in an empty document, and using that to set your default formatting.

This is what I did to confirm that this would solve your problem. I created a new blank item in the Research folder and typed in a few words. Tapped the format brush, then used its tabs to set the formatting to Georgia-Regular 13pt, 18pt first-line indent, 1.3x line-height, with everything else left default. I then set that as my defaults, and then updated your sample text with them, and got a clean compile.

As for what is wrong, well I’m not 100% sure, as I am not an RTF expert, but I have discovered where the problem is anyway, and it seems to have to do with some unorthodox tab stop settings (at least I know enough to point the developer to the spot of significant difference between A/B samples that work and don’t work). You can’t even see tab stops in the iOS version of course, so we probably never would have figured this out without some raw data to work with. So thanks again for that.

So this does look like a bug of sorts that we can take a look at, though it may turn out there isn’t much we can do about it, as the weird formatting may have at some point—as I speculated earlier—come from another source entirely and we can’t control what other programs paste into Scrivener too much.

4 Likes
20

First off, a massive THANK YOU for figuring out how to get it to misbehave again. I’m not going nuts! I loathe with a passion having a problem, asking for help, only to have an issue that is not reproducible. Worse, I was starting to feel like I was inducing the error somehow because of the way I typically compile for beta readers. “First Item is Title Page” good grief… I usually have an “This is an ARC made for [beta-reader]” template that lives in the front matter section of the binder that I put on the front of these things.

Okay, before I leave home again I’ll see about doing this. FWIW: My ‘day job’ is driving a big truck hauling food and I don’t bring all the computers with me. I love the interoperability of Scrivener that allows for this, my iPhone gets in on the act too, as I can use it to generate a plain text compile of the working section to kick over to Dream Reader to act as a Text-To-Speech agent.

Your most welcome. I’m hoping that the dev team can make best use of this and fix the underlying issue one way or another. Let me know if I can be of additional help.

2 Likes