Table of Contents and PDF

I did the auto generated method and it looks great until I compile. When I look at the PDF I end up with all my page numbers on a new line.

Section One

On some I end up with something like:

Sec … 5

I’ve tried to manually create a ToC but again once I compile the alignment is way off.

Introduction … 1
Section One … 3
Sec … 5

I’m just looking for ideas on how to get a ToC that will look like it does in scrivener once I compile to PDF. If it’s even possible. The writer (I’m the computer guy helping him) is willing to buy Office if that’s our only choices for a ToC. (going from what I have read that seems to be the common route, at least for ebooks not sure about PDF).

I’m guessing you just need to flip the “Compile As-Is” switch on, for the ToC item in the Binder (open the Inspector with the blue ‘i’ button on the right side of the toolbar). That will keep the compiler from reformatting it to look like the rest of the book. You probably do not have sufficient tab stops to display the table in your normal style, and that is why the last tab is wrapping to the next line (that’s just a peculiarity of the text engine).

Whether or not to make your ToC in a word processor depends upon how much this is going to be shuffled around once you’re done with Scrivener. What something like Word gives you is the ability to mark all of the headings with styles, and then it can use those styles to generate a dynamic ToC based on the current structure of the document. The one you create with Scrivener is just text. If you open it in Word and transpose two chapters, it will not react. So that is where you get situations where people leave this stage to the word processor. If you’re basically just trying to get final output at this point, then the static ToC method is everything you need.

I’ve tried the As-Is in the compile option with no luck. However when clicking the blue i I see the page just like it prints it which hopefully means I can try to format it to not wrap. I’m not sure how to set tab stops and what not yet but I’m guess your right on that.

Thank you for that info!

Throwing in a quick edit:
Editing from the inspector view didn’t help me much. Still ended up with non uniform page numbers

title … 1
page …2
blah …4

Just to make sure we are on the same page: the blue ‘i’ icon I referred to opens a third column in the main window, along the right. It contains various details about the item you are currently editing, or have selected, in the main editor. It does not bring up any kind of page preview, and I’m not sure you could be looking at.

You wouldn’t even need to know how to set tab stops to fix this problem. The [b]Edit/Copy Special/Copy Documents as ToC[/b] function generates all of the tab stops for you (otherwise it would look messed up there as well). All you have to do is:

  1. Use the [b]View/Layout/Show Inpsector[/b] menu command (same as clicking the blue ‘i’ button, but we seem to not be referring to the same thing so I’ll stick with the non-ambiguous menu name). After doing this, a third column should appear on the right side of the window (probably with an index card at the top, some general info in the middle, and a note field at the bottom.)
  2. You can ignore 99% of that. All you need to do is verify that the index card shows your ToC document, then in the middle “General” section, check off “Compile As-Is”.
  3. Now use [b]File/Compile...[/b] and select “Print” to get a quick preview (if that preview is too small, it is for me, you can use the “PDF” menu at the bottom of the preview window to open the print preview in your main PDF viewer).

Again, I think we’re talking about two different things here. The Inspector is not something you could use to edit the main text from in any way, or view print previews from. It’s just a strip of options and settings that most everything in your binder has available to it (like colour labels, keywords, auxiliary notes, cross-references to other sections in the binder, etc.).

Edit #:
Links to images to explain:
How I want it to look and how I would expect it to compile: … a04651.jpg

How it actually ends up compiling, this is with the inspector open: … 4a4f77.jpg

We were talking about the same thing except that once I hit that button my ToC page went from the pretty (I just wish it would look like this when I compile lol):

Introduction … <?p>
One … <?p>

(not sure if that is the correct placeholder for page numbers or not off the top of my head)


Not sure why it did that or if I hit something and didn’t notice that until after I opened the inspector thing.

As for my issue though I’ve tried compiling with it checked and uncheck (the as-is) and it doesn’t seem to make a diff.

I just got back to my friends house that I’m helping this stuff with so I’ll double check some things and compile a few more times and see what I come up with. :slight_smile:

Turning on/off the inspector does in fact swap it between the two styles listed above. My guess is because of the resizing of the editor window but not 100%. I say that because if I max the window it fades back into the pretty one and if I resize it back to part of the screen it swaps back to the 2nd layout lol.

Edit 2:
The only difference in having the as-is checked vs unchecked is that when it’s checked it looks like the style above (2nd one not the pretty one) while when it’s unchecked it looks the same with some of the page numbers being inline with the section … ex: one … 2 (doesn’t span the whole page, just about 3-5 dots then a page number)

Edit 3:
Just throwing this in… when it does look like:

If I try to delete so the 1 is on the same line like so: Introduction1 and then try to hit tab to space them apart it goes directly to a newline with just 1 tab. Not sure if that’s useful info or not.

Oh, I see what you mean. That is nothing to worry about you can leave it open if you want or closed. The editor in Scrivener is not a WYSIWYG thing like a word processor might be. It’s just a place to type. You aren’t actually switching styles when you open the inspector, you are just decreasing the width of the window, causing everything to word-wrap at an earlier point.

That is what I was explaining before, the text engine does not insert ad hoc tab stops if you have none left on that line. So when you hit tab under those conditions, it doesn’t know what to do and just jumps to the next line. That might happen if you make your editor really narrow, too, but that is just natural word-wrapping. If the editor is wide enough, and tabs wrap, then you know things aren’t set up right.

Well, back to the root problem, here are some facts and one suggestion that may help you:

  • The [b]Edit/Copy Special/Copy Documents as ToC[/b] command has a preset formatting baked into it when you paste. This includes all of the tab stops you need, at predetermined widths, based upon assumptions that will work for most people (A4 and US Letter compatible). Hence, if the paper size you are using is narrow, then the precise measurements used will be incorrect—they will be too wide and be collapsed as you describe. You will need to learn how to use the ruler ([b]Cmd-R[/b]) to move the tabs around so that they do not fall outside of the text block.
  • The Compiler has the ability to change the way your document looks when you compile. This is done in the Formatting compile option pane. This applies to all text that runs through it with two notable exceptions:

[*] Compile As-Is documents. These have their checkbox set, and doing so tells the compile to ignore this document and just pass it through as you created it in the editor.

  • [b]Format/Formatting/Preserve Formatting[/b] command applies a blue rectangle around selected text in the editor. Anything within that rectangle will be ignored by the Formatting rules in the compiler. This is good for stuff like blockquotes.
  • It is possible to completely disable all of that in the Formatting compile option pane by merely unchecking the option at the top of that pane, “Override text and notes formatting”. This is a global switch, so typically it is better to use a local exclusion via one of the aforementioned methods.
  • Worst case, if you can’t figure out something in the compiler like this, 99 times out of a 100 it will be more efficient for you to just compile an RTF file out, open that in Word or whatever wp you prefer, and just fix it right there. The compiler is a nice convenience when it works for you, and if you take the time to learn it in depth it can do incredibly powerful things—but it is also somewhat option. You will nearly always need to compile, but if you don’t want to learn it or mess with it, you can just flip the Format As switch to Original, compile as RTF, and then fix it all up in a wp. That is the expected route anyway, the only major difference between everyone is where they choose to step off.