Aligning text

First, apologies - this may just be a basic word processing question, but I just can’t see how to do it.

I want to create some dialogue with speaker tags, and to have the whole thing indented, relative to the surrounding text (like I’m quoting from a play). I can do this so it looks fine in the Scrivener editor (see screenshot), but then when it exports, the alignment after the first tab is off (the tab seems to be removed). I can’t see a setting to change this. Any ideas?

Thanks,

Gareth.

[attachment=0]Screenshot 2021-01-13 at 11.21.00 am.png[/attachment]

Are you using a paragraph style for these dialogue sections?

If you use a style it should survive compiling, but you can make it even more robust by creating the same style in Compile.

I have something very similar for ingredients in my recipe collection.

:slight_smile:

Mark

Thanks, Mark.

I’m not using any paragraph styles within the text itself. If I create a bespoke style just for this, that would work, you think? I just can’t see why it’s stripping out the tab between the speaker prefix and the speech text.

My guess is that you have compile set to override text and notes formatting.

Styles in Scrivener are there for any text that is different from the default formatting. In your position, I’d simply highlight one of the dialogue elements—like the “ROM” line in your screenshot—then choose Format > Style > New Style from Selection… and in the dialog that comes up, give it a name, set a shortcut, decide whether you want it to include font and font size—if you uncheck those it saves the ruler settings for the paragraph—and make sure you choose the follow-on style—I’d imagine as you’re dealing with dialogue I’d make it “This Style”—and then save it.

Then, for all you’ve written so far, just select the chunks of dialogue and tap your shortcut. For all new writing, just tap your shortcut, write the dialogue, and when you want to go back to no style either choose it from the format bar or set a shortcut—you’ll need to do the latter in system preferences.

Note: (1) you can import styles from another project into the one you’re working on; (2) if later on you realise you need to modify the style, make the changes in one of your dialogue paragraphs and choose Format > Style > Redefine Style from Selection… and choose the style in question from the dropdown.

:slight_smile:

Mark

Just to try to convince you, here’s a list of ingredients in Scrivener, and the same list compiled to RTF and opened in Nisus Writer Pro—with no polishing done!
[attachment=1]Scrivener.png[/attachment]

[attachment=0]Nisus Writer Pro.png[/attachment]
:slight_smile:

Mark

That is brilliant - thank you so much, Mark. I shall follow your instructions and report back! :smiley:

Sorry, Mark, this isn’t working.

I’m exporting to ebook (epub). The “play style” text is different from the rest of the text (the play is quoted in normal prose style text). I’ve not set any styles for the body of the prose text, so maybe when I’m adding styles just for the “play style” text, it’s messing things up. Anyway, even when I uncheck the keep font and text style, it changes them, so some setting must be wrong somewhere.

Is it my compile settings at fault? Or the fact I haven’t allocated a style for the main body text within Scrivener?

OK, this is driving me crazy. Here is how the page looks in the Scrivener editor:

[attachment=2]Screenshot 2021-01-14 at 6.12.46 pm.png[/attachment]

And here is how it outputs (epub and mobi):

[attachment=1]Screenshot 2021-01-14 at 6.13.27 pm.png[/attachment]

Here are my style settings:

[attachment=0]Screenshot 2021-01-14 at 6.14.46 pm.png[/attachment]

In Compile, I’ve tried checking and unchecking “create styles for paragraphs using custom formatting”. And I’ve tried variations of “text and notes use default paragraph/custom/editor formatting”, with and without “preserve indents/common alignment”. Nothing seems to work.

HOWEVER, it DOES work when exporting to .RTF.

So is this an ebook formatting problem only?

You dhould have said you were compiling for ebooks. It’s the ebook reader who decides if the text is justified or not.

I’m sorry - you’re right. I thought I had. Does that mean that such formatting isn’t possible in ebook form?

I don’t think it’s possible in epub or mobi, only if you compile to pdf

Hi, I’m sorry I didn’t reply earlier … other things on my agenda. :frowning:

When I got your reply, I thought, “Have I got it all wrong? @Woodpig is talking about a script format which is a totally different matter about which I know nothing,”

But now it’s clear, you’re talking about compiling to ePub; that makes a huge difference, The thing is that ePub is a version of HTML and there are no such things as tabs in HTML. A further problem is that substituting spaces for tabs doesn’t really work either as in my experience HTML treats multiple ordinary spaces as a single space, so you need to ensure that they’re non-breaking spaces; then the font is controlled by the reader on their device, so the non-breaking spaces might not line up in different fonts because of the font metrics.

I don’t have an answer for you, I’m afraid. I can only hope that someone with more experience of ePub will come along to help.

Mark

No worries, Mark. As I said to the other poster: my sincerest apologies. I really thought I had mentioned that I was compiling to ebook (but I can see now I didn’t).

I’ll carry on investigating, but may just have to adopt a simpler layout. If I do work out a way, I’ll be sure to post it here.

Thanks once again for your help - sorry to send you down the wrong path!

Best wishes,

Gareth.

I think ebooks, like web pages, often use tables for this sort of thing.

As a general rule, it is difficult to impossible to force a particular layout in an ebook format, since they are designed to allow the reader software to reformat as needed.

Katherine

Thank you, Katherine. Yes, I think I’m giving up on trying to get the layout I want. Tables would create more difficulties, I think - in my experience, they don’t play well with ebooks.

Thanks again to everyone for their help. I’ll post here if any other solution presents itself.

I could maybe come up with a solution for you that works. CSS can produce the design you’re aiming for, but I’m not sure how well ebook rendering supports the tools you’d generally use to pull that look off.

The main questions for you are:

  • Are you willing to have something that looks different, but similar, in the editor? Producing optimal HTML is about producing good boxes of text. Typical word processing habits and automated conversions don’t always do that.
  • Do you mind using styles heavily?
  • Do you mind writing closer to the source? We can exert better control over the ebook by flipping on the raw markup switch in the compiler, which allows for direct HTML injection and thus easier to work with structures than what the simple converter can do. The downside is that the text in the styles is treated as plain-text, and should be written in mindfulness of the fact that it will end up in HTML without processing—i.e. if you type “1 < 2” into the editor, expect ePubCheck to throw validity errors.

Yeah, I agree that tables, while they probably could pull off the above look without too much hassle—aren’t the best tool for the job here. Plus it would be a nightmare having to write that much into tables in Scrivener, given how wonky the table code is.

Thanks very much, AmberV!

I think I’d be happy to use styles and tinker with CSS, etc. The text is only 700 words or so.

My son (who knows CSS) suggests something like this might work (where “SpeakerAndText” is a container DIV for the other two elements):


p {
	
}

#SpeakerAndText { 
	margin-top: 10%;
	margin-left: 10%;
	width: 80%; 
	height: auto; 
}

#SpeakerName {
	text-align: right;
	float: left;
	position: relative;
	max-width: 45%;
	display: block;
	padding-right: 20px;
}

#SpeakerText {
	text-align: left; 
	float: left;
	position: relative;
	max-width: 45%;
	display: block;
}

If that does work, how would I go about associating that CSS with the sections of text?

Sorry for the delay in responding. Yeah, something along those lines is going to be the best approach I think. Here are some tips for getting custom CSS working well with Scrivener:

  • Style names will be converted to valid CSS classes. So “Speaker and Text” would become “speaker-and-text”. If you want, you can also give your own CSS class names in the Styles compile format pane, right column.
  • The example CSS you provided uses IDs instead of classes (“#Example” vs “.example”). It is the latter syntax you want. You can only have one ID per document, but as many elements as you want can use a class. And Scrivener is going to be using classes to format your paragraphs and span elements.
  • The CSS compile format pane is where you put the custom CSS.
  • In my experience, the best way to do this is to set up your styles, maybe test a few different approaches at once in doing so, and then don’t worry about the CSS just yet. Compile the .epub so you can see first-hand what the HTML will look like in Sigil. Sigil lets you edit the CSS file directly, and it will update the preview pane in real-time as you do so. So it is an ideal environment for building designs.
  • When you’ve got the CSS tweaked how you want, in Sigil, copy and paste the results into Scrivener’s CSS compile format pane, at the very bottom. Now it should work automatically on compile.

As for how the text should be in the editor: my guess is that you’re going to have the best time keeping the name on one line and the indented text on another. It’s the difference between:

<p class="speaker-and-text"><span class="speaker">Name:</span> And now they talk...</p>

[code]

Name:

And now they talk...

[/code]

The latter is going to be a lot easier to manipulate, since each chunk of text is in its own separate element. It may be possible to do some voodoo to make the .speaker class display as a block element (like a paragraph), and go from there, so I wouldn’t entirely rule it out, but it may be hard to influence the design of the “speaker-and-text” paragraph class without messing up the “speaker” text, since technically they both descend from the same branch in the tree.

I would agree that the best HTML would be:

[code]


Name:


And now they talk…

[/code]

And Scrivener can do that, you’re going to have to toggle the raw markup setting on, in the Styles pane, for these two styles, and insert the div using the prefix/suffix fields. The downside to this approach is that anything you type into the editor within this style needs to be proper HTML, and all formatting must be through styles. So no typing in “Get yourself a bottle of A&E and sit down over here…”, but rather “Get yourself a bottle of A&E and sit down over here…”. :slight_smile:

I’d try the first method first, two sequential styles. With float clears and careful usage, it should in theory work without a master container around them.

[quote=“AmberV”]
Sorry for the delay in responding./quote]

No worries! Thank you so much for all of this. I shall work though it and get back with any questions.

Oh I did remember another approach you can take to make a div around the whole thing:

  1. Create a style named “Raw HTML Block” in your project. The stock Ebook compile format comes with a matching style by that name, which toggles the raw markup flag. As I mentioned before, anything you type into that style will be passed straight through to the output.
  2. So with that in mind, you can add lines before and after the dialogue section to open and close the div.
  3. To make life easier for yourself while writing, you can use Replacements to shorten the start and end code. For example: “-START” and “-END” could become “
    ” and “
    ”, respectively.

So that approach means having a couple of extra lines around the content, but it also makes it so you can leave the raw HTML flag off for the styles that you actually write within, leaving them to act more intuitively.

Just another approach to keep in mind, in case having two sequential paragraph styles on their own doesn’t work and you need a div, but would rather not be limited by composing proper HTML-safe text in the dialogue areas.