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

[Manni]

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.

[Manni]

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:

TOC correct in Mac OS.png (868.9 KiB) Viewed 1172 times

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

TOC Errors #1 (page numbers identical) and #2 (corrupted entries).JPG (185.27 KiB) Viewed 1172 times

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.

[thePhilosoraptor]

HI Manni,

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

Thanks!

[Manni]

You're welcome, done, and thanks!

[thePhilosoraptor]

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!

[Manni]

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.

Compile options.JPG (242.72 KiB) Viewed 1133 times

[thePhilosoraptor]

Thanks. These have both been filed.

[Manni]

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.

[Manni]

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

[Manni]

The issue above is still not fixed in beta 23

[Manni]

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

[devinganger]

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.

[Manni]

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.

[devinganger]

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?

[Manni]

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.