[LH3614 | LH3790] Compile error: some linked sections in the compiled document (PDF) start with <$rst_scene>

Before I assigned layouts to each section in compile, I had some of the sections linked in the text of my document start with <$rst_scene>.

There is no such issue when I compile the original document in MacOS. This only happens if I open the doc in the Windows beta.

After assigning all the layouts in compile, this issue went away, except in the TOC, where some of the sections start by <$rst_scene>.

Also, the page numbers in the TOC are not correct. They are all the same (6). If I compile in macOS, the page numbers of the same TOC are correct.

As this wasn’t fixed in beta 19 or beta 20, I attach some screenshots showing the remaining issues in the TOC (with beta 20).

Here is how the TOC appears in Mac OS:

Here is how it appears in Windows (beta 20) after compile:

I’m using a variation of the Paperback 6"x9" compile format in case this matters. I’m happy to send it if you remind me where it’s located.

I have made a ZIP file with a test project that should help reproduce all the issues I have reported that are still not corrected. Please let me know if you’d like me to send it to support, and how.

HI Manni,

Please send the zipped test project to win3beta@literatureandlatte.com with a link to this thread and attention it to Bryan.


You’re welcome, done, and thanks! :slight_smile:

Hi Manni,

I’m not able to reproduce this in your test project, which means most likely it has something to do with your compile format. In the Compile window, you can click on the gear icon in the bottom left to export your custom format. Please either upload that here or send it to win3beta@literatureandlatte.com with a link to this thread.

Thank you!

Hi Bryan,

My compile format, as indicated, is a variation of the paperback 6x9 template.

I attach it here along with the section layout/compile options used.

If I use my own custom compile format (also a 6x9 format) exported from the Mac, I don’t get the <$rst_scene> errors, but the page numbers are still identical in the TOC.

Paperback (6 x 9).zip (5.12 KB)

Thanks. These have both been filed.

I haven’t seen the <$rst_scene> issue in mt test project (my main project crashes scrivener PC during compile, so I can’t test it for this).

However, the page numbers issue hasn’t been solved in beta 21/RC1. the page numbers are all the same in the TOC.

I still have linked sections (for example in the TOC) starting with <$rst_scene> with beta 22 / RC2.

The issue above is still not fixed in beta 23

Still not fixed in beta 30, which means that the PC version is still unable to compile a TOC properly here.

FYI, if the bug number [LHxxxx] is not listed in a new version’s release notes, then that means it wasn’t fixed in that release and you don’t need to post that it’s not fixed.

You have said so many times, and I can read, so when you see such a post from me, it means that you don’t need to post the same message again. I am sure you can find a better way to use your time.

Oh, look, we agree! If you’re not going to include new information when you do this kind of reposting, you’re contributing to the clutter and wasting everyone’s time. I’ll stop if you will, deal?

Yes, we agree that if you don’t have anything to contribute to a discussion, as is the case here, it would be nice if you could step out of it and refrain from adding to the clutter and wasting everyone’s time. You’ve been wrong in the past about the usefullness of “bumping” reports that have still not been resolved after many months and I will be the judge of when it’s opportune to bring back some unresolved issues.

This bug is one of the few compile bugs here that produce a completely unprofessional, unacceptable result for the compilation of a manuscript. It makes the software 100% unusable for professional use. I have no idea why, nearly four months after they were filed and 12 betas after they were reported, they are still not fixed. I have left 10 weeks and 7 betas since my last one-line “bump”, so it’s not as if I am wasting a lot of bandwidth.

I’m just checking that they are not forgotten, or that there isn’t another reason that prevents these from being fixed.

As you are not in a position to provide any useful information on this, it would be nice if you could keep your patronising posts to yourself. These “bumps” are not addressed to you, and your contribution in this matter has a negative value: zero valuable information, 100% waste of time.

Thank you for your understanding.

The devs themselves have said that if it has a bug number assigned, they aren’t going to forget it.

They also don’t tend to share with us the internal details of why one bug is prioritized over another.

Simply put, have some faith in the devs.

I have some faith in the devs, but after nearly four months and 12 betas without a fix for a bug that makes the software unusable for professional use (i.e. compiling a publishable document), I feel that a reminder can’t hurt, especially as it’s not the only one.

I haven’t been able to compile a usable document in six months of beta testing, and most of these issues were reported as early as beta 19, almost four month ago. Thankfully I use Scrivener for Mac to compile, but moving to the PC version is not possible at this stage as compile is still crippled by such bugs.

Anyway, my reminder was one line, thanks to you it’s one page now, and it’s staying at the top of the thread for even more attention. So keep posting :slight_smile:.

Manni, I decided to have a look over this, since I also wanted to understand how to do a manual ToC, which is what I think you must be doing, for a Word, PDF, etc. output, as the automatic ToC on ebooks seems to handle itself.

I think it’s worth prefacing, and as may help your feeling of being overlooked, that as far as I know serious work on the Compile abilities of Scriv 3 Win has only begun two or so release versions ago. And in that time, for one big thing, they’ve cleaned up all the difficulties with font appearance, which is kind of fundamental, so proper to do first.

Ok, then. With some hours work, I think I’ve corralled pretty much the state of this area, which should be useful to Tiho & Co. as they get into making all this work.

  • Each trial, I did Copy Special: Copy Documents as ToC, and pasted the results into a leading page titled Table of Contents. This is somewhat broken - you have to select your pages from bottom to top (not top-bottom), and I think be in a single editor, before Copy Documnets as ToC will be active so you can click it.
  • Basically, the <$> tags you can embed, and are embedded for Formats like Paperback, in the Title Options, don’t work at all. No result, and that includes your <$rst_scene> which doesn’t print but has the side effect. So this is the center of what they have to tackle.
  • I got your <$rst_scene> printing, when I didn’t do the next item, but let’s isolate that.

May be important: you can get your ToC to look as you’re after – mostly – by instead embedding the tags in the page chapter titles, as you find them in the Binder. For example, ‘Chapter <$t:chapter> – Your Title’.

You have to do that on all levels of the outline, or it won’t work – you’ll get repeated ToC entries instead of the real lines which don’t have tags. Great fun.

And when you do, you won’t get page numbers either. I didn’t get ‘the same’, as you did, I got ? question mark, always.

Lastly, I couldn’t seem to get <$rst_scene> to work this way, added into the chapter titles, so scene numbers just kept incrementing.

Then, although this method shows the basic functionality is there, it’s a lot of trouble. What I might suggest if you need that pro output right now is to compile your ToC in Mac Scrivener, then copy-paste-substitute it in on the Win Scriv Word or whatever output you’re using.

Here are some other things that are not right yet, for the team:

  • as described, selecting pages so that you can successfully copy-special them as ToC is hinky
  • compile format settings for first line indents don’t work, and actually the radio buttons don’t select properly either: try the fourth one…
  • You wouldn’t use those for ToC, I found, at least as matters appear, but still need to work. ToC formatting seems to be doable on the block you’ve copied in as special – wondering how far that goes?? Fonts at least, but margins/indents didn’t seem ok.

Ok, that’s my unintended afternoon spent, somehow actually relaxing?? Hmm.

@Narrsd: thanks for taking the time to investigate this. Yes I do generate the TOC manually (by selecting all the sections I want to have in the TOC in the binder and copying them into a Table of Contents section). Unfortunately I can’t make any manual changes after that, because we’re publishing non fiction with dozens of chapters, sections and subsection (first volume is 470 pages long, second volume is 250 pages long) so it just has to be handled.

Then if I have to do anything with Scrivener Mac to compile, then I’d rather use Scrivenenr Mac for everything, We output from the same manuscript directly to EPUB for kindle and to PDF for print to Amazon KDP and Ingramspark, which is why Scrivener is so amazing in the first place. So there is no way to collate different outputs into one file, and frankly we don’t have the time to deal with this kind of workaround when releasing a book, which often requires frequent updates in a hurry. Anything that slows down or can cause errors is not an option during a book launch. So Scrivener Mac is used now.

However, we’d like to leave the Mac platform and go back to PC. There is no way this can be done given Scrivener PC current state, and the fact that compile is still completely unusable.

Unfortunately even the font issues you mention have not been resolved.

I have reported this issue with the Special Elite font months ago: https://forum.literatureandlatte.com/t/compile-problems-with-front-matter/46238/1

It’s still there. Apparently it’s not there if you create the section in Scrivener PC, only when the manuscript was created on a Mac, which means that it might never be resolved as it seems to be good enough for the team to ask Mac users to recreate sections that the PC version can’t handle properly.

Basically compile is still not functional as far as I can see. It’s been the case for months, and although a few of the reported issues have been fixed, we’re still a long way from being able to use this. Every time I try to compile my test document, it still looks like a broken experiment: no title page, wrong spacing for some fonts, errors in TOC… Just garbage.

I have no idea what the priorities are for the devs, I’m just hoping that issues like these are not forgotten, and that by the time it moves out of beta all these issues will be solved. In the meantime, we have to keep the Mac to release our books. We released the last one in October (on the Mac), let’s see if the next one (in the first half of 2020) can be released on PC.

I’ll check back in a couple of months, when it’s time to decide on which platform we do the formatting :slight_smile:

Manni, it sounds you are wise, in your publishing circumstances, indeed to stick with the Mac version for now.

It’s what I would do, and one can remember this is a Beta, with release extended to allow fixing all such things as this that have turned up. I would say up-fron t that I have quite high confidence in Lee and Tiho’s team, having dealt with deep issues here for, well, enough years; it’s just that they need the time. Software of this kind is not at all easy.

  • on the compile-time tokens, this is so non-functional at the moment that I imagine it has ‘do-next’ priority, again now that Compile is the development focus of attention.

  • the font issue, in reading through;its postings, sounds different. If Bryan is correct, the real problem is on the Mac side – something not quite right that for Mac output they get away with. Given it doesn’t occur when creating the document on Win, this should not be an issue for long, once other things you need are in place. The workaround for documents partially created on Mac sounds that you accept as doable, and that will get you through.

I would just ask if you’ve tried one of those Mac-created projects on the latest Beta 30, with:

  • open the project
  • Go to the File | Options | Editing | Options tab, and set both Display Font Hinting and Print & PDF Font Hinting are set to default (on the right). This is a new pair of settings, so may need to be changed on a previous project.
  • Fully Exit Scrivener (File | Exit)
  • Start Scrivener again, which should be on the same project you closed, and now see if your Special Elite font issues are still present. This restart is by past experience likely necessary to get the effect of the new settings.

Ok, and we might keep fingers crossed there.

I appreciate the nature of needs for your full project-to-formatted-purchaseable-ebook operation, which are more stringent probably than those of the many using Scrivener at present primarily to compose.

At the same time, more and more of us are going to self-publishing for fiction etc. as well, so the abilities you need should be addressed well, I think we can be confident.

It’s just that the primary editing abilities pretty much had to go in and be tuned first, and then the Compile can be updated to deal well with all of them.

Hoping this helps, and once again it sounds you are on a quite sensible path, Manni. These added notes should help Tiho and Lee – and Bryan can tell us if they need to be put in a separate posting, to be seen.

Regards each,