Formatting Titles and contents table in V3

First of all congratulations for the release of V3 :slight_smile:

Also I’ll start with a huge thanks for implementing a feature I requested a long time ago, which is the ability to format words;/parts of a title using markdown.

This works great, but I ran into a few problems while implementing this in an existing book:

  • While this produces the expected result when compiling, i.e. the formated words in the titles are properly formatted, if one generates a table of content, markdown will appear in the titles in the table of contents, which is not desired.
    For example, “This is my wonderful title” will produce the correct title in the compiled file “This is my wonderful title”, but in the title of contents the title will appear as: “This is my wonderful title”. So I have to reformat these manually in the TOC.
  • When checking “generating an HTML table of contents”, only the main chapter headings are listed (as in V2) so I use a “replace” in my custom format preset to replace the <$p> in the TOC with nothing when compiling for ebook. In V2, this works great and gets rid of everything between the end of th e title and the question mark that appears if you leave the <$p> in the content table (works great for print, but not for e-book). In V3, the question mark disappears but it looks like each tab appears as a visible underlined section.
  • There is still an (already reported in V2) bug/limitation in the generated table of contents that means that with short titles, the single “tab” automatically generated isn’t enough to align the page number to the right, So I have to manually add one tab before the <$p> for these short titles to get the page number vertically aligned for print/PDF. As a result, when complied for ebook, the underlined section after the title is twice as long as when only the initial tab is present.

It would be great if these issues could be fixed. If the above doesn’t make sense, please let me know and I’ll take some screenshots.

Otherwise really enjoying exploring V3, but right now my priority is to get my mobi and epub files for existing book re-compiled and ready, as I’m looking forward to seeing the improvement in the Kindle preview.

Keep up the good work! 8)

Any chance to get a reply on this? Are these issues aknowledged and will they be fixed?

Thanks!

Hi,

Sorry, I somehow missed this. Thanks for the kind words. The first issue sounds like a bug which I’m going to look at tomorrow. The other issues don’t sound like bugs but I’ll go through why once I’ve double-checked. If you don’t hear back in a couple of days, please bump the thread - it won’t be because I’m ignoring you but just because we’re really busy.

Thanks again!
Keith

Thanks Keith. I’ll bump this up if I don’t hear from you in the next couple of days…

Hi Keith,

Just bumping this as requested…

Another bump for Keith…

Hi,

I can’t reproduce asterisks appearing in titles in the table of contents. Could you possibly post a sample project demonstrating this?

Thanks,
Keith

Hi Keith,

You are correct regarding the asterisks,

I did some tests starting from scratch and there are no asterisks in the result from compile.

However, the part that should be in italics doesn’t appear in italics in the TOC, even if the asterisks are correctly stripped. The part in italics is only properly formatted in the content itself, not in the table of contents.

Also, each tab in the title inserted in the TOC - either automatically when generated or manually to make up for short titles, I created one such title called “short” to illustrate the issue - becomes a series of spaces underlined when compiled for Kindle, which doesn’t look good (see MOBI sample). If you don’t add a manual tab for short titles in the generated TOC, then the page number isn’t aligned when compiled for MS Word/PDF (see PDF sample).

I attach my test project (along with the resulting PDF and MOBI) which reproduces all these issues.

Hope this helps!
test.mobi.zip (6.29 KB)
test.pdf (30.7 KB)
test.scriv.zip (258 KB)

Bump for Keith :slight_smile:

Another bump for Keith…

Sorry to insist, I know this might look like minor issues to you but at the moment V3 is not usable for me.

I can live with the extra tab needed with short titles, that bug was already present in V2, but I can’t live with the tabs showing as underlined spaces when I compile for Kindle. That looks too unprofessional. And I need the tabs as I also compile to PDF (for free samplers etc), I can’t simply delete them (which I would do if I was only compiling for Kindle).

If I can specify a tab character in my replacement string, please let me know as I could replace:
tab tab <$p> with nothing (for short titles) then
tab <$p> with nothing (for standard titles)
instead of just replacing <$p> with nothing, which works great with V2 as the tabs don’t show up as visible underlined space when there is no <$p> if I compile for Kindle. And add the italics manually in the TOC, as I do now in V2.

Otherwise I’ll just forget about V3 and I’ll keep using V2 for now,

Thanks for your help!

Bump for Keith

Any chance to get a reply on this? Just to know what to expect in V3.

Bump for Keith.

Would it be possible to get a reply regarding this? Especially regarding whether it’s possible to specify a tab character in a replacement field, and how, if you believe that the problems reported are not bugs hence are not going to be fixed?.

Thank you.

Very disappointed in the lack of reply and support on this.

I’ve been a happy user of Scrivener for years and have never experienced being ignored in such a way. I know it’s more or less the standard attitude these day but for me that’s one of the things that set L&L and Scrivener apart: the quality of its support.

I understand you are busy, but this is not what I’m used to with L&L.

I’m going back to Scrivener V2.0 as it looks like there is no way to get V3.0 to do what I need it to do in order to be able to compile both for Kindle and PDF.

Have nevertheless a happy holiday!

Manni, did you actually email Mac support with this issue? L&L tries to make it very clear that the support forums are not a good way to get time-critical support.

Hi,

I’m sorry I haven’t got back to this earlier and that you are feeling ignored - it’s not that I didn’t do work on what you reported. If you need or are waiting for a reply from us directly, it’s always best to email us - we guarantee a reply when you email us. We do make it clear that we can’t guarantee answers from staff to everything on the forums in the same way we can with email: https://forum.literatureandlatte.com/t/about-the-forums/38394/1 It has been even more difficult to answer everything on the forums with the thousands of emails we have received following Scrivener 3’s release.

Anyway, as to your questions:

  1. I have fixed the problem of formatting not appearing in ToC titles for 3.0.1.

  2. You should not be using a ToC with <$p> tags and tabs in them when exporting to ePub. Such ToCs should be used for PDF. print and rich text formats (Word, RTF) only. For ebooks, you should use a ToC that is just a list of links, by selecting the documents in the binder and either using Edit > Copy (for a flat list) or Edit > Copy Special > Copy Documents as Structured Link List (if you want an indented, structured ToC). This is the whole point of Scrivener allowing you to choose different front matter for different file formats - your front matter for RTF/Print would use a ToC with the <$p> tags, whereas the front matter for ebooks would not. That this ever worked was only an accident of Apple’s way of converting HTML4, which was used in ePub 2. (And incidentally, you can get exactly the same results with ePub 2 in Scrivener 3 as you can with ePub in Scrivener 3, seeing as they are the same; it’s ePub 3 that is brand new in Scrivener 3 and works a little differently.)

  3. That extra left tab is inserted when pasting the <$p> ToC in case the user wants to use a tab in the custom title prefix separator in Compile. This allowed for neatly setting out “1. Something”, “2. Something Else” etc. This is quite obscure, though, so I have removed that tab for 3.0.1 so that there will no longer be an issue with short titles.

All the best,
Keith

Hi Keith,

Thanks for the detailed reply :slight_smile:

I was only expecting an answer because you were following this thread and asked me to bump it if I didn’t get any reply. Had you asked me to email instead, I would have done that. I will email for support in the future, unless I want a wider response from the forums. Also you had not responded to the other issues but only said you wanted to investigate the first one initially, implying the other issues were not bugs. You had told me you would explain once you had investigated the first one. This is why I didn’t know whether you were actually working on this, or were not. I’m glad to see you were :slight_smile:.

I do know that my TOC shouldn’t have <$p> in it for Kindle. This is why I had set-up replacements to take them out when compiling for Kindle, and leave them in when compiling for PDF in V2. The reason I was doing that was because I had to format the TOC manually, as it’s was not possible to format parts of titles. Given that my book is a 480 pages non-fiction, with dozens of sub-sections many of which needing italincs in part of the titles, it was VERY time consuming to do so manually every time something changed in the TOC, so having just one TOC for both made more sense.

Now if V3.0.1 is able to format a TOC properly so that I can generate one automatically for PDF (with <$p>) and one for Kindle (without <$p)>, that is great. I didn’t know that we could use copy as structured list (which is what I need) to generate a TOC for Kindle without the <$p>, hence why I generated a single one using copy special as TOC and had found a way to get rid of the <$p> automatically during a compile using a replace.

I do use a different front matter for the e-book and the PDF, but as V2 was unable to generate a properly formatted TOC in either case due to the lack of formatting, reformatting twice wasn’t an option anyway.

Just to clarify, I hope that we can still output a properly formatted TOC for PDF? The single tab before <$p> WAS useful, as it allowed to get the page numbers aligned to the right. There was only a problem with short titles, as these needed two tabs, not just one. If you have taken the tab out, does it mean that the page numbers are not right aligned anymore? That would be an issue for me. The only problem with the tabs in V3 is that they now appear as underlined when there is no <$p>. As far as I’m concerned, it’s still a good thing to have the page numbers right aligned for PDF compiling, so I would want to keep this appearance from the copy special to TOC. If you’ve only taken the tab out in the copy special as a structured list, then we’re good.

I can’t wait to give 3.0.1 a try (any ETA for this?) and will in the future email you for support.

In any case, thanks for fixing this.

All the best,

Manni

Hi Manni,

Normally there is no need to email support if I have replied here and said I will look at it because usually I’m on top of it. It’s just that if you’re getting frustrated waiting here then it’s a good idea to email to chase it up. In this case, this was a little more complicated and I ended up working on the issues in fits and starts among other issues over the past couple of weeks.

To clarify with <$p>, I haven’t taken out the right-aligned tab, only the first left-aligned one. Currently there is a single left tab put about a half-inch across and then the right-aligned tab that sets up the <$p> on the right. The left tab is what I’ve removed - that was there for users who want to format their contents like this:

1.[tab]Title[tab]<$p>

If you really want to keep trying to use the same ToC with the <$p> in it, then you should set up your replacements to remove both the tab and the <$p>. Hold down Options in the replacements field to enter a tab there without tabbing out of the field.

I was hoping to release 3.0.1 today but it will now be early next week.

All the best,
Keith

Perfect, thanks a lot for the detailed explanation, I got it. The hold down option is what I was missing to try the replacement road, I’ll try that as well if two separate TOCs turn out not to be ideal.

I’ll test all this next week when 3.0.1 is out and I’ll report back. Have a good week-end!

All the best,

Manni

Just to report that using “option” to replace first “tab tab <$p>” (to deal with my short titles with two tabs) then “tab <$p>” to deal with normal titles with just one tab allows me to generate a perfect TOC for my Kindle version from the same TOC (with page numbers) that I use for PDF etc. As the removal of the left tab should fix the short titles issue and as the formatting present in the titles themselves should be reflected in the TOC in 3.01, it looks like TOCs won’t need any manual tweaking anymore, I’ll confirm this when V3.01 is released. Thanks again, whatever the outcome I can say goodbye to V2.0 now!

Happy to report that the short titles and markdown formatting in TOC is fixed in 3.0.1 as expected, so thanks a lot for that.

Compile to Kindle/Mobi works fine, however, I can’t compile to PDF anymore. The progress bar reaches the end, but whatever process following that gets frozen page 2 or 3 with 100% CPU use (saying: “Processing page 2”. I get this even if I don’t ask to view the PDF after compile, so it does happen during the compile process, not with Acrobat viewer. This is not related to a specific error on a specific page because if I select a random section of the document and compile the selection, I get the same error page 2 or 3 (so a different page entirely). The only way out is a “force quit” of Scrivener.

Any idea what might be causing this in V3.0.1? I get this issue whether I use one of my custom format presets of one of the standard ones. I don’t get this if I try to compile the Scriviner tutorial. However, I never had this issue in V2.x and I was able to compile to PDF with V3.0 (initial release), so it seems to be a bug introduced with V3.0.1.

My file is a fairly large (480 page) non fiction book.

Happy holidays to everyone!