How to fix "forcefully closed opened Tag" warnings from KindleGen

I’m using Scrivener 3.0.2 and compiling to KF8. When I open my compiled book in Kindle Previewer 3 (3.21.0), after converting, when I open the Conversion Log, I get warnings such as the following:

Info(prcgen):I1002: Parsing files 0000071 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="1248"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body28.xhtml line: 0000044 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="1536"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body28.xhtml line: 0000286 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="1636"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body30.xhtml line: 0000067 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="2431"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body56.xhtml line: 0000013 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="2443"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body56.xhtml line: 0000021 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="2629"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body62.xhtml line: 0000013 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="2639"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body62.xhtml line: 0000019 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="2646"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body62.xhtml line: 0000025 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="2674"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body62.xhtml line: 0000043 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="2750"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body67.xhtml line: 0000017 Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: <p amzn-src-id="2756"> in file: /private/var/folders/z_/hrzw0vrs4fvg1ktqm728vtv00000gn/T/PEOISg/conv_tmp/pEpubOut/extractedEpub/html/body67.xhtml line: 0000021

As far as I can tell, these warnings are not a big deal because the book appears to work fine in Kindle Previewer. Still, I want to fix the errors in my Scrivener document if possible.

I see that each error has a file name and line number (for example: /body62.xhtml line: 0000025), but there seems to be no easy way to identify these errors from within Scrivener.

In an initial attempt to fix this, I exported from Scrivener to ePub 3 and opened the compiled file in Sigil. Since the epub file structure has the same file names (body62.html), I can manually open each relevant file and then count the lines to go to each location indicated in the warning log, but this is very cumbersome. Is there a better way to handle this within Scrivener itself?

The easiest way to trace back the source of an error is to go into your compile settings, under the general options tab on the right-hand side, and enable Save source files in a folder with exported Kindle file. In theory the ePub should be the same—but it’s better to work with the actual source files used to create the file.

Compiling with that option you will get a folder with all of the files that Scrivener feeds to KindleGen to create the .mobi. In here you will find your “body62.html” and so forth, and opening those in a coding editor will help you get to the right line that is indicated in the error message (TextWrangler is a good free one if you don’t have one—a good editor will show you line numbers and let you jump straight to a line with a command). In my experience the line count can sometimes be one or two off, so sometimes you’ll need to look around, but the problem should be near by—and from that you can see the context and find your way back to where it came from in Scrivener.

In some cases the problem might be coming from compile settings however. If the error is around the edge of a binder item rather than in the middle of it, it could be a separator setting for example. We have a fix one or two recently reported bugs here, so if you post a little code snippet of the problem area I might be able to identify it and help you work around it.

Going back to ePub—even though as I say it’s better to use the same format for tracing down errors since there might be minor differences in line counts and such, the fundamental HTML should be similar enough that you can run a validity check on the ePub. If that comes out clean, then chances are high that whatever you are seeing isn’t originating from Scrivener somehow, but from KindleGen. The HTML in those errors isn’t immediately familiar to me—those class names look to be generated by Amazon, but I might be wrong.

Thank you, turning on the debug information was very helpful and that allowed me to locate the source of the problem.

It appears to be related to the separators-- for some reason, one paragraph tag is nested inside the other. Any idea of how I might fix it?

Example 1:

[code]

電車に乗ろう!

[/code]

Example 2:

[code]

割とストレートに答えれば良い。

[/code]

Thanks! That is indeed a bug that has been fixed for the next update. In the meanwhile there is a workaround that should get things valid again:

  1. Edit the compile Format you’re working with.
  2. In the Section Layouts pane, locate the layout you are using for section text and click on it.
  3. In the “Settings” tab, add a CSS class name (any valid CSS name is fine here).

Repeat for any layouts that handle text around separators.

This will insert a div around the section—by itself it will be invisible and won’t impact layout (unless you are doing some fancy stuff with CSS that does not take into account the addition of a div), but it should be enough to avoid the separator paragraph getting somewhat “merged” with the previous paragraph.

Ok, perfect! Thank you for explaining the workaround.