Convert Text to Default Formatting

In this screenshot, note that both of the documents have been converted to default formatting, yet they are different.

Why is that?

Does one of them have paragraphs using a style? If so the default settings for that tool will ignore styled content. You would need to enable the option to strip out all styles to drop it to default “no style” text.

I’d also check for line breaks instead of paragraph breaks, with View ▸ Text Editing ▸ Show Invisibles. Some of what I see in the screenshot could be explained by that (the rest perhaps by differing zoom levels between splits).

No, everything is “no style.” This is a project converted from a version 2 project (from Windows).

In that project, I think that document was set to “Compile as is.” I haven’t found that option in Scriv 3 mac yet.

Thanks for the quick support, BTW.

So the line endings were fine as well, no “:leftwards_arrow_with_hook:” anywhere and all “”? Because that’s really what it looks like to me—like one very long paragraph with manual line breaks inserted into it, meaning one indent at the very top of the section.

⠂─────── ⟢⟡⟣ ─────── ⠂

The “Compile As-Is” setting would have no affect on the functioning of this command. Even if it did, as you note it doesn’t exist in v3. When the project had its format updated, it would have checked for any documents using that setting, and created a special Section Type (N/A) for you, designating those items to it. Of course the most pragmatic approach for an existing project that is already at the compile phase is to leave those items assigned to the automatically generated Type and make sure in your compile settings that it is assigned to the “As-Is” layout at the very bottom of the layout list (which it should be by default).

Going forward with new projects (or if you wish to get this one in tip top v3 shape), a better approach is to look at why the checkbox was removed: in the older version of the compiler the choice to override formatting was an all-or-nothing affair with one checkbox at the top of the Formatting pane. So to get around the fact that some items might need to express abnormal formatting, the “Compile As-Is” exemption was designed. It worked all right, but was a bit of a pain if the only reason you needed it was because the title shouldn’t be “Chapter One: Prelude”. It meant having to manually mirror the current compile settings for all of these sections, from the heading style on down to the paragraph formatting.

With the new system, you can think of each row in the Formatting pane as almost having its own v1 level of compile settings available to it. It can have its own separators (and hence there is no “Page Break Before” checkbox either), it can choose to override formatting or not, etc. In short: you can create a Layout, as these “rows” have been coined, that is designed to handle front or back matter, as a categorical statement. Maybe part of that design is that they print the text As-Is but have a uniform heading style that matches everything else—maybe not, but either way you don’t need a checkbox in the sidebar to handle these decision with exemptions and overrides on top of overrides. All you need is a dropdown that lets you pick “Front Matter” or whatever the case may be, and then design what “Front Matter” should look like, specifically.

Excuse my butting in, in case I have completely misunderstood things, but…

… “no style” doesn’t mean that the text gets a common “normal style” as it does in Word, does it? As far as I have understood the “no style” text may have any font, spacing, etc, just as it used to have in Scriv 2. If you want all that “no style” text to look the same you simply select it all and change font, size, spacing, etc or apply the standard formatting for the Editor you have defined in Preferences.

The main point in why I asked them to verify the text is “no style” is that styled text (or at least the attributes of the style that it controls) will not be reformatted by the Documents ▸ Convert ▸ Text to Default Formatting… command.

That “no style” can look like anything is entirely the problem in fact: they want to normalise these disparate examples of text, but for some reason one chunk of text is ignoring the command.

Right, it is that latter component, of applying the standard formatting, that we are having troubles getting working on some text in the project but not others, for some reason.

But in thise cases, isn’t the solution to first select all, then make sure that everything has “no style” by setting the style on it all to “no style” and when that is done apply the standard formatting?

So the line endings were fine as well, no “:leftwards_arrow_with_hook:︎” anywhere and all “¶”? Because that’s really what it looks like to me—like one very long paragraph with manual line breaks inserted into it, meaning one indent at the very top of the section.

Yes, everything was fine.

I fixed it by copying formatting from one of the scenes, selecting all in the Acknowledgments document, and pasting the formatting.

Great! That’s similar to what my next question would have been: whether Paste and Match Style into an empty document fixed it. Odd it wasn’t responding to the conversion command though.

That can work, so long as you don’t need inline formatting. The conversion tool will work to preserve such things as italics, highlights and revision markings (as well as any marked exclusions in the option panel). The No Style command on the other hand is almost synonymous with cutting the text and using Paste and Match Style (you could even say it is a harder command than even that, since it blows away whatever contextual paragraph formatting already exists, whereas Paste and Match Style at least respects the formatting at the cursor point). So I would be wary about recommending that method if the source material has inline formatting that may be important.