Greetings,
I have an issue with compile in Scrivener 3.1.1.0 on Windows. I have a single page that has two footnotes on it. I’m attempting to compile a modified version of the Paperback (5.06" x 7.81") format into a PDF. The first footnote shows just fine in compile, but the second doesn’t show anywhere in the compiled document. Is there some trick that I’m missing. The footnotes appear to be of the same type and I don’t see anywhere to change footnote settings for compile, so I’m kind of at a loss here.
Hi. Well there are a few settings in compile as regard to footnotes, but as to whether these will fix your issue or not is another story.
In case you are saying you can’t find any settings concerning the footnotes (rather than meaning you can’t find the one setting):
First three items in the list.
. . . . . . . . . . .
Have you tried compiling to other formats ?
And maybe try different page sizes ? (Bigger ones, who knows… – I know it is far fetched, but maybe there is something buggy that forces your second footnote to fall off the “paper”.)
In your project, do your footnotes both appear here ? (in the inspector panel) :
I have played with the settings you indicated. I’ve also tried other formats and have narrowed it down to only the Paperback (5.06" x 7.81") format for compile not showing more than one footnote per page. Even the 6" x 9" format seems to work correctly.
As I’m a developer by day, and tend to love problem solving, I’m starting with a fresh format and slowly adding settings to match the 5.06" x 7.81" format and see if I can track down exactly where the problem is. It may take me a bit as I have a fairly busy weekend and may not get very far today, but I will report back if / when I discover what’s causing the issue.
Sorry, forgot to add, my footnotes are displaying correctly in the inspector, and as I said all other formats I’ve tried appear to show them correctly.
My take on it is that 5.06" x 7.81" is a small page size, so perhaps not enough space can be allocated for footnotes in the PDF export to allow for more than one. I would try exporting to RTF or DOCX and opening it in Word/whatever, where you should be able to control the space available for footnotes, and if you can sort it out there, print/export to PDF from that.
Note: (1) I’m a Mac user and I’ve never tried compiling to paperback size or PDF; (2) I don’t have Word … I use a Mac only word processor which allows you to allocate the maximum space allowed for footnotes on the page.
Through experimentation it appears this is exactly the problem. Somewhere between 8" high and 7.81" high, it loses the second and following footnotes. Weird. Looks like I’ll be compiling to another format and creating the PDF from there. Kind of a bummer as I really like the way Scrivener handles the compile as far as setting up different margins for the “inside” and “outside” of the page based on where the spine would be. Some other software I’ve used make that far more difficult.
What if you manually force (insert to your document) a page break for that specific page ?
Therefor (maybe) giving that page enough room for 2 footnotes.
Or (b) decrease slightly (or perhaps just the opposite – increase instead) the bottom margin in your compile format’s page settings ? (Although that would affect your whole book…)
→ Or perhaps even better : increase Footer margin (?)
These are just hypothetical… I never had to play with footer margin nor dealt with a similar issue.
These are simply the things I personally would try/investigate.
[Edit] Using a slightly smaller font for your footnotes might also allow you to squeeze in the second one.
If you can compile to the page dimensions you want your PDF to be in another format and retain both footnotes, Calibre could be an easy workaround in that case. All you would have to do is convert to PDF.
Does anyone know where the footnotes end up AFTER the compile phase ?
Are they at the bottom of the text area as defined by the page’s margins ? Or just below that bottom margin ? Or rather inside the footer (as in “stretching it upwards”) ?
I could run a few tests to find out, but I don’t really have the time for now.
If someone knows, that’d be appreciated.
@nightflameauto: Looks like I’ll be compiling to another format and creating the PDF from there. Kind of a bummer as I really like the way Scrivener handles the compile as far as setting up different margins for the “inside” and “outside” of the page based on where the spine would be. Some other software I’ve used make that far more difficult.
One of the ideas of Scrivener’s design is that it provide a bounty of tools to make post-compile formatting easier (the bounty of which often presents a confusion that it’s actually a book design and production tool. It relies on coding toolkit libraries for typesetting and PDF output, which should be a clue it’s not up to that task in the slightest). So you should be able to make use of these settings to set up alternating margins, and have those settings conveyed into other tools that are capable of laying out text that way. I.e. you might well be able to just open the thing up in LibreOffice or whatever and click the one-shot PDF button. But even if there are tweaks you would like to make, at least a large percentage of the setup is already done for you.
@Vincent_Vincent: Are they at the bottom of the text area as defined by the page’s margins ? Or just below that bottom margin ? Or rather inside the footer (as in “stretching it upwards”) ?
I have highlighted in yellow the one bug I have found in this with simple testing. Obviously, I am not seeing the issue with only one single footnote per page as I’ve got five here.
Thanks Amber.
That is not quite answering my question (what I wanted to know was within which “zone of the page” the footnotes land to), but I guess it doesn’t really matter that much in the end.
The issue (not quite a bug in my opinion – perhaps more of a PDF caprice (?)) is directly related to the very small page size the OP wants his output PDF to be.
I suppose that if increasing/decreasing the output page’s bottom margin and footer don’t fix it for him, he’ll have to resort to compiling to another format anyways. (Which I suspect he already did.)
I may not understand the question then, as the brackets in the illustration are meant to indicate where and how footnotes are inserted. I do agree it should not be too relevant to the report though. In this example we are even intentionally inserting too many footnotes into one page, so that layout is forced to use the subsequent page, which it successfully does. It’s not in the screenshot, but there is a sixth footnote on page 3 (the bug is that the marker itself isn’t evaluating, not that the footnote vanishes).
So again, that’s why I need a reproduction case for this.
The issue (not quite a bug in my opinion – perhaps more of a PDF caprice (?)) is directly related to the very small page size the OP wants his output PDF to be.
I don’t think that should be a problem. As noted above, we insert footnotes until running out of space, and then start using the next page, as is conventional in book design. It’s a lot more complicated than that—once you start thinking of all the logical steps that go into balancing footnote content with text content between multiple pages, and how doing so creates space on pages that previously didn’t have space, etc.
I ended up going with a different format altogether and then stitching it together in a PDF package I have.
Then, when I got all done with that, I reverted to using the same format for softcover as I do for hardcover so page numbers line up between versions.
I have my suspicions that part of the problem lies in the length of my first footnote on the page that was having problems. It was a sci-fi story with an explanation about what a “made up” term meant in universe that got a bit wordy, which probably used up the available room in the smaller format.
No matter. I learned a ton about Scrivener’s formatting abilities during compile while playing with this. And I’m a person that thinks any new knowledge is a good thing, so all’s well that ends well.
@Vincent_Vincent: Within the footer, just above the bottom margin or just below it, pushing the bottom margin upward ?
I don’t think any of those descriptions really fit how it works in the illustration, as they operate in the main text frame.
@nightflameauto: I have my suspicions that part of the problem lies in the length of my first footnote on the page that was having problems.
That could be an ingredient, yes. I’ve just run a quick test, and if a footnote is actually larger than a page, it does not properly balance it between multiple pages and loses it entirely. I don’t think that aspect of footnote layout is working at all.
Ok. So I’ll take that as a “just above the bottom margin as defined in the page’s setup at compile” answer to my question.
Meaning that in order to potentially fix this issue, the bottom margin should have been decreased, giving the main text frame more “printable” space.
Should the footnotes been bellow the bottom margin (between it and the footer), then the move would have been to increase the bottom margin value instead.
Which are both not so great solutions in the end anyways, since they affect the whole book, and not just the problematic page.
We don’t really know what is going on anyway, but yeah, I would agree with you that the problem has nothing to do with where the margin is, nor is moving that around a solution to anything I can think of.
I hope at this point it is clear what solution we use, and how it works. It’s extremely common and nothing unusual. If you have too many footnotes on one page they flow onto the next. No need to change the size of the whole layout.
It is just that searching the net for similar issues, I ended up on forum pages of other softwares reporting the very same problem. For some the solution was to increase the bottom margin. For others it was the opposite.
That’s why I was asking where the footnotes ended up, to know weither the margin had to be decreased or increased.
Think of it this way: if you have a cupboard that can fit 15 cups, and you have 17, then the easiest solution from a programmer and designer perspective is to arrange for a system that puts the remaining two cups on another shelf.
If that routine fails, a “user” of the cupboard might come along and think to tear it apart and increase the size of the shelf to fit 17 cups.
What you’re suggesting isn’t something we should do to fix it, does that make more sense?
Interestingly enough, it didn’t move the dropped footnotes in the smaller format. In fact, it pretended the footnote didn’t exist once it dropped it. To the point it didn’t even flag it as a footnote in the main text and the footnote text didn’t show anywhere. That was the part that was frustrating me.
