<p class="ps15">Perhaps the decision to delegate the search for serialization deals was due to the rejection by the American Nature Association in the previous letter. Subsequent correspondence does reveal that there was one successful serialization deal.<a href="footnotes.xhtml#fn48" class="fn-marker" id="fn48">48</a></div></p>
The error Sigil reports is “Opening and ending tag mismatch: p line 26 and div”. There does indeed seem to be a stranded div end tag.
Looking at the other offending file, I find in both cases the problem is the last paragraph in the file and both end with a footnote–perhaps a clue. Here is the end chunk of the other file:
<p class="ps11">Major Wood had placed Grey Owl at Lake Ajawaan in 1931 and had Beaver Lodge built to meet his specifications. Wood later defended him when officials in Ottawa raised doubts about the value of retaining his services. He was with Grey Owl when he died on 13 April 1938, reporting "At 8.25 in the morning, he died very quietly, and pictures taken show that the congestion in his lungs [pneumonia] was very slight, which all goes to prove that he had absolutely no resistance whatever." After Grey Owl’s death, Wood was one of the diehards that refused to believe the allegations against him for some time. After finally giving in, Wood wrote “I care not whether he was an Englishman, Irishman, Scotsman or Negro. He was a great man with a great mind, and with great objectives which he ever kept before him.”<a href="footnotes.xhtml#fn82" class="fn-marker" id="fn82">82</a></div></p>
</body>
</html>
Can you spot any other ingredients in the mix that might be involved? I’ve run a quick check of both footnote types (inline/linked), positioned as the final text in a section, and do not run into any HTML containment errors like you demonstrate here.
This is my test project, maybe give that a look and see what I’d need to do to modify it to reproduce the bug, or send a snippet copy of your own project (you can DM me that to keep it out of the public forum, by clicking on my avatar and then the Message button). All I would need is one chunk in the binder that shows it happening, so a stripped down Save As copy of the project is fine, and would keep the project and compile settings intact.
This almost certainly is a side-effect of a fix we made to footnotes in 3.4, that resolved cases where empty lines in footnotes would end up printing those lines into the source text where the footnote came from, breaking paragraphs in half and so forth. So code that is stripping newlines might be a factor here if too much is being stripped in some scenarios.
Oh wait, I did just notice there is a problem with the final paragraph. It’s not a validity level problem according to ePubCheck and Sigil, but it isn’t good form. Basically the last paragraph is not a paragraph (<p>...</p>). So we should fix that, but it would be nice to have your condition in on the ticket as well, as they are undoubtedly related.
To reiterate, the problem I found is a minor issue that won’t throw a validity error in the checks I’ve tried. I have logged it, but I still do not know how to reproduce the problem you described.
Yes, I did see the result you posted before, but again, I don’t know how to get that result. Please read my earlier post, which outlines precisely what I found, and requests further information on how to reproduce what you saw.
@AmberV OK, I can reproduce it (macOS 15.3) with your test project by applying a paragraph style (I used “Centered Text”) to the footnoted text. Just compiling the “Forward” document alone is sufficient; the combination seems to be the div coming from the section layout and the paragraph style at the end, which then does wrap the last paragraph in the <p> tag for the class, and that lands in the wrong place for the closing </div> when there’s also a footnote at the end.
To make sure there isn’t another route to the bug:
Is using a styled paragraph something you were doing as well, @ds?
To reduce the chance of default formatting settings containing a trigger:
Go into Project ▸ Project Settings... under Formatting, and enable the Use different default formatting for new documents in this project setting. Leave the formatting itself as provided, by the template.
Click OK, and use the Documents ▸ Convert ▸ Text to Default Formatting... menu command in the “Foreward” section (all checkboxes disabled).
Compile again with these settings.
For example, it looks like other conditions that might cause the final paragraph to be handled manually, can cause it. Normal paragraphs just get <p>...</p>, and Scrivener doesn’t really do much itself about them. But a styled paragraph gets <p class="centered">...</p>, for example. A paragraph with unusual alignment (like justification) might get <p class="ps2">...</p>.
The problem can’t be due to any customizations in my project, because the steps I took to reproduce the problem use a new project with an unchanged project format.
Right, but your default formatting settings might be different from mine, which is a variable that most any new project will exhibit (especially our default templates, which leave the project setting disabled on purpose so that your defaults will always carry through). Changing the project to use its own formatting, and resetting the formatting to something we would both be using, would help illuminate whether something in your settings is causing it. If so, we could then take a look at what might do so.
To go back to your original report, where the opening <p> element is given, we do see a serial CSS class being applied to the paragraph, which is where I’m coming from with this. That would typically only happen if the final paragraph has some special formatting applied to it that makes it different from other paragraphs in the section, but that kind of action would stand out as a necessary ingredient. So perhaps some form of formatting that can be applied globally via default settings is triggering that condition when it shouldn’t (and that would in and of itself probably be a different bug).
