Note to Beta Testers: Compile

The Compile command in Scrivener 3 is very different from the Compile command in Scrivener 1.9. This can make it challenging to decide what behaviors are bugs and what behaviors are correct, but unexpected, especially if you are transferring an existing project from an older version. I’ve seen a few “bug” reports which fall into the second category and are really support requests. So, to help the intrepid Windows development team focus on actual bugs, I wanted to point out some useful support resources.

The best introduction to the new Compile command can be found in the upgrade guide for (Mac) Scrivener 2 users, here: … date-guide
It’s designed to walk you through the process of transitioning an existing project to the new Compile formats.

You might also find the Mac Scrivener 3 tutorial resources and manual useful, which can be found here: … ategory=43
and here: … ser-guides


…or they are bugs that are neglected because they can’t be reproduced by the devs or the team for one reason or another.

I’ve reported many compile bugs that are still not fixed in the last two release candidates. They are bugs because I come from 3.0 on the Mac, so I’m familiar with the new compile format.

Usually it takes me a lot of persistence to get the devs to look into compile bugs. In the end, they are logged (and hopefully resolved), but frankly you should improve the communication on beta feedback. Some reports are left without any answer for weeks. Some are still not logged after weeks. If you think it’s not a bug, or if you can’t reproduce it, say so. Assuming that it’s not a bug doesn’t help.

From the beta tester side, it’s frustrating and alienating to report issues and have the feeling that they are being ignored. Some of them have been logged but are still not fixed in release candidates. Some of them, despite sending test projects showing the issues, are still not logged as bugs after weeks of reporting.

I honestly don’t understand how you can call these latest betas release candidates with all these outstanding compile issues. The software is simply not usable to compile anything here, and I’m using the same projects and the same compile formats as on the Mac, which produces perfect results.

Seeing you now suggesting many of these reports are due to ignorance on the part of the beta testers doesn’t help.

I have sent a test project to Tiho for a compile issue that has now been resolved ( This project shows all the issues I’ve reported in separate threads over the last few weeks, issues that are still not resolved. I had sent a test project to Bryan a few weeks ago, that also showed all the issues,

I’ve emailed a PDF showing the compile issues to Tiho, with a list of all the threads describing the still outstanding bugs, I’ve not received a reply yet:

Exisiting issues (already reported over the last weeks/months): Some linked sections start with <$rst_scene>. Also, the page numbers in the TOC are not correct (they are all the same). This is visible in the TOC of the attached PDF. The title page (cover in .jpg) in my front matter doesn’t compile in the PDF. The copyright page appears entirely in italics, centred, with the wrong font size. The parts using the Special Elite font (uploaded to Bryan weeks ago) have too narrow spacing between letters and are in bold. It’s not possible to select all the sections in scrivenings. Only the current section is selected. When I import a Mac document that has lists with check marks, these lists are converted to bullet points. This means that I can’t use the PC version of Scrivener even to edit a manuscript, as it changes the content.

New issues in beta 22 / RC2: Like the OP of that thread, I’m getting *** instead of new lines and I don’t get new pages even when specified in the compile template. The header isn’t correct. It shows <section_title> instead of the actual header, which should be different on each page depending on odd/even.

If you believe any of the above is not a bug, please say so in the thread so we can investigate this further.

These might be issues that don’t happen to every one, like the compiling crash that was finally fixed, or issues that you can’t reproduce, but that doesn’t mean it’s due to ignorance.

From my point of view, you should only call a beta a release candidate if all the known bugs are fixed or are believed to be fixed. Otherwise it means you’re happy to release the software with known bugs? That doesn’t make sense.

I really don’t mind when Scrivener 3.0 is released. You’re doing your best to meet deadlines, while providing a free version of the full software in the meantime. I have no idea why anyone is complaining about this.

But I do find the way bug reports are handled frustrating, mainly due to communication issues. Seeing logged bugs unresolved in a Release Candidate, and seeing unlogged bugs being ignored doesn’t inspire confidence in the end result. I hope this is only a perception, and that these issues are being worked on and will be resolved by the time the final product is released.

Please note that I am not part of the development team, and am not responsible for logging or fixing bugs. I simply observed that some posts about issues do seem to result from confusion about the new Compile function. Since I am part of the support team, that’s an area where I can attempt to help.

I will say that in a complex function like Compile, it is quite likely that any particular observed misbehavior results from interactions among several pieces of code. A group of unfixed bugs may all stem from the same interaction, so they may require a fairly difficult analysis before ultimately being fixed as a group. The sheer number of bugs fixed in a release is not a good metric for the amount of progress the release represents.

I’ll also note that Scrivener 3 for Mac had three significant bug fix releases in the six months after the 3.0 release, despite a very extensive (private) beta. The idea that a release version should have no bugs is a laudable goal, but extremely unrealistic in practice.


I didn’t say “no bugs”, I said “no known bugs”. :slight_smile:

A private beta is more limited in scope, so it makes sense to find more bugs once the software is released to a wider group. I would expect most of the bugs fixed in the point releases on the Mac 3.0 to have been found by users who were not in the beta group. If that wasn’t the case, then you had the wrong beta testers, or you released a product too early. I had a few minor issues with 3.0 on the Mac, but overall it was very stable and fully functional as far as I was concerned.

With this open beta, you have a lot more users providing feedback, I suspect that many 1.9 users are now using 3.0 daily. While the software seems mostly stable, compile is still not usable here with beta versions called Release Candidates.

Frankly I find it worrying that there is no more active effort to try to fix these many outstanding bugs. The compiled output of the PC version is pure garbage here. It’s not one minor issue here or there, it’s a multitude of major issues that make the document unusable: wrong fonts, wrong spacing, wrong formatting, no cover, no headers, wrong page numbers in the TOC, control codes inserted… I mean, how can you call a Release Candidate a version that has all these issues? Is compile considered to be a non-essential feature of the software? Or are the issues I experience and report not experienced by anyone else?

I understand that you are from the support team and not the development team, but I don’t understand why compile bugs that have been reported for weeks are still not logged, which means they are even less likely to be fixed that those that have been logged. Again, if these are believed not to be bugs, I’d like to investigate in case I’m mistaken, and if they are bugs, then why are they not logged?

If compile is not a priority, please let me know and I’ll stop spending time beta testing and reporting issues.

If compile is a priority, then please look at the bug reports in the list above that have still not been logged, and prioritize them so we can decide whether they are bugs or not. I don’t understand why they are being ignored both by the devs (not logged) and by support (no reply/update after weeks).

As far as I know, every single time we’ve investigated a reported bug that had been ignored or dismissed, it became clear that it was a bug in the end: the compiler crashing with some documents, no cover on .mobi files, unreadable text with dark mode, etc… Initially, the response was “you’re doing something wrong” or “that’s the way it’s supposed to be”. No one is expecting a beta not to have any issues, that’s what a beta is. If I didn’t want to spend some time testing I would wait for the release, but when you ask users to spend time reporting issues, I think it would be nice to not patronize them and to not leave reports unlogged and unanswered for weeks.

As I said, I understand it takes time to resolve some issues, the problem is with the lack of communication/action regarding many reports and the conflicting message sent by labelling the last two betas “release candidates” when they are far from being ready to be released, at least given the way they behave here.

Compile is absolutely a priority. It’s probably the single most unique feature of Scrivener. And the state of the Compile command is definitely one of the reasons why the release has been postponed.


Great, thanks, that’s reassuring. :slight_smile:

So hopefully at some point someone from the team will either log or comment on the still unlogged threads reported above.

As far as I am concerned, they are outstanding bugs that are unlikely to be corrected as they have not been logged yet, so they are either being incorrectly dismissed as user error or the team can’t reproduce them despite all the info provided,

I find it rather disturbing, how you intervene with this topic.
When I reported that Scrivener compiles to invalid epub, you brushed the topic away, siding with some ###, and then, when I asked, why it isn’t being filed, you said there too, that’s not your task. . But you did not even point the devs to the topic.
So what’s the point that you are here?

And now you post this, practically ridiculing everyone as too idiot to understand the new compiler. What do you want to achieve? Except of upsetting frustrated beta testers?

I’m not sure how pointing out support resources for the new Compile feature counts as “ridicule.”

I made the transition myself as a Mac beta tester, before the resources I’ve linked in this thread existed. It wasn’t fun. But if you’d like to prove that you’re smarter than I am by ignoring them, feel free.


First and foremost you told as we’'d have no clue what we are doing.
Pointing to resources came as an afterthought to that.

Having read all the posts in this thread, I think you’re the only person who is being in any way rude; the original post included useful resources, was courteous and (to me, at least) very useful.

Of course, I’m upset!
I’m still furious how she treated my first posting the invalid epub-bug. She didn’t even achnoledge that it IS a bug, after the devs filed it; much less apologize for her dismissal.
And now here she comes again dismissing compiler issues.

Hmm. Per Manni’s conversation above, I think there are actually some very real frustrations coming out here.

  • There often surely is something in tone, that ‘if you just understood the program…etc.’ It’s mainly from the ‘Greek Chorus’ who follow around ‘helping’ staff or so they see it, but some official commenters here could be a bit more thoughtful about using the brittle pitch.
  • It’s in fact an exceedingly complex ‘program’, with a myriad of details that are in no means corralled in abstractable locales to be noted on a mental picture map, and understood. This is in great part due to Scrivener’s range of Swiss Army ability, so I don’t complain professionally, but I do observe how easy it can be for those expecting all the help it actually gives in writing to be always easy, or to assimilate, to suspect matters missing or wrong.
  • This roving distinction between those who ‘support’, those who ‘log’, and so forth leads to a good deal of frustration surely – when there is any answer whatsoever to the donated effort of producing a bug report, which seems relatively seldom. As Manni says, and many others feel.
  • One would think support in a Beta area would clearly include what is apparently called ‘logging’, or at least heads up to the person who logs, which could be a much more effective means of filtering with actual attention…no?
  • Professionally, we can appreciate that for all the disconnection, this is even in the Beta area a huge client base, and with not an Amazon headquarters full of experts to attend. I don’t know an easy answer, but starting out with the idea that the writer has actually seen something valuable to know would be not just an emollient, but a lead to getting the best clear information – and each worthy solution.
  • I do find in looking that the use-past-Mac-upgrade suggestion from @Kewms is going to be useful, and I’ve gotten a lot of good insight already from own realization to just use the Mac 3 manual for general Win 3 acclimatization. There are good things…
  • I did also find just by opening that upgrader, immediate fresh meat for real bugs jumps out, at least one of which hasn’t had notice from reporting, and where both could use the fresh clues to get fixed. So I will report.

I suppose one could hope that, but in the whirlwind of beta releases and bug-fixing, it’s not always reality. I’ve participated in betas ranging from lots of back-and-forth with the developer, to zero acknowledgement you even submitted a bug report and zero publicly accessible reports (even in cases, e.g. iOS, where you think the organization would have enough people for that). This is the first I can recall where the bug tracking system was exposed outside of a bugs-fixed listing at release. It’s not clear to me if a) Bryan, who is meticulous about tagging threads, is the only bug logger, or b) of multiple loggers, Bryan is the only one who makes the effort to tag the thread. There have been some assumptions, and complaints based on those assumptions, but do we know for sure?