Odd newline/wordwrap in EPUB output

[Nedlaw]

Hi, using ID 15.1.2 on Win10 1904 (still)

I am outputting a built-from-scratch document intended specifically for epub, It is for a client. The epub text is reflowable. I am having some difficulty with paragraphs -- notably the chapter number and figure numbering -- that want to insert a newline in the middle of words on output. I am converting the autonumbered paragraphs (chapter number and figure number) to text on output. (Or at least I think I am.)

In ID, everything looks normal.

However, when I look at the epub, I see this:

This may vary -- sometimes it's CHA/PTER, but you get the idea. Similarly, with the first numbered figure (and only the first), I get this:

I note that both of these seem to begin 4 chars wide and then break. The caption is its own style on its own paragraph marker. The figure is one line above on its own paragraph marker. This is not a caption wrapping around a graphic. The OTHER numbered figures, using the same style, look fine.

I have looked through the ID-generated HTML and CSS code, and I do not see anything that would cause this inappropriate wrapping... I do not see, for example, an odd table in the HTML that would squish the word Chapter, or some kind of narrow spacing in the CSS.

Any suggestions from the commuity?

Thanks as always for any help.

-j

[Mike Witherell]

What application are you testing it in?

[Nedlaw]

Oops. I should have provided samples. The wrap occurs in several different viewers -- sometimes better, sometimes worse. Theoretically, the word Chapter and its number should appear on the same line.

Adobe Digital Editions 4.5: shows full "chapter" but puts the number on the next line.

Calibre Viewer -- You can see that the column width is wide enough for a much wider paragraph:

Kindle Previewer 3 (recently updated):

Something is happening with that chapter number style to make it break like this.

To the extent they may help (and they don't help me because I don't see a problem) here is the html and css code generated by InDesign:

[Nedlaw · Accepted solution]

I think I have found the answer. On of the class spans for Chapter 1 is chapter-number_idGenBNMarker-1. There are also a marker-2 and marker-3 in the CSS. InDesign chose to export these as inline-block... which carries a width specification.

Removing the width specification in the CSS and re-saving removed the wrapping of the  chapter number. So this is a manual fix after-the-fact of epub production by InDesign.

Now: WHY does InDesign do this? That is, why does ID output an autonumbered chapter number (even one pounded into text during output) as inline-block? Perhaps there is a CSS mapping I can control for the output?

Does anyone know offhand?

Thanks.

-j

[Mike Witherell]

Were you  careful to use cleanly-applied paragraph and character styles throughout? Whenever you edit a paragraph style, you will see at the bottom a section labeled Export Tagging.

[Nedlaw]

Yes. Clean styles (and a vastly reduced stylesheet from my more usual PDF output). I see export tagging -- this may hold the answer. Right now, these are my settings:

Although the bottom part of the export tagging is hidden, it does NOT show output as inline-block. Here is the part of the CSS that caused the trouble:

So, left to its own devices, ID attached a second span _idGenBNMarker-1 that included width. I think I can direct it to export a single class to apply as a tag, but I'm still not sure where that second span class came from. Work in Progress.

Thanks!

[Nedlaw]

Update: The chapter_number paragraph style does include bullets and numbering settings. The bullets and numbering settings specify chapter number as a character style. That character style has its own export settings -- none of which specify 146px as width. Here are the character style settings:

I'm pretty sure that some skillful person could specifty the output styles for both the paragraph and number format and achieve correct output. I think this is where the two spans come from... but neither specifies a width, and the width got there somehow...

-j

[Nedlaw]

Update 2: I did a Google search for _idGenBNMarker-1 and found the following discussion on a KDP forum:

https://www.kdpcommunity.com/s/question/0D5f400000FHS2l/indesign-numbered-lists-break-into-multiple-...

It provides a work-around, as does my deleting the width setting. In both cases, you have to be careful. If you're editing the CSS, you need to know everything that that span class affects. I am guessing that correctly using the tag/class output would cure this, but -- personally -- I'd need some advice on that.

-j

[Nedlaw]

Now that I know what to look for (both in Google search and the CSS), I find that _idGenBNMarker-1 has been the subject of frantic posting since the change from CS6 to CC. The best wisdom I can find is to delete the width setting in the CSS (don't try to change it).

You can find more information here:

https://helpx.adobe.com/pdf/InDesign_EPUB_Changes_from-CS6-to-CC.pdf

https://community.adobe.com/t5/indesign/ebook-created-in-cc-2018/td-p/9852979?page=1

There may be an export tag mapping solution, but I have yet to find it.

-j

[Nedlaw · Accepted solution]

Update 3:

I think that I have a good solution for this problem, one that can be applied across a book and that doesn't require hand-editing the CSS.

The problem is that the span style _idGenBNMarker-1 (or -2, or -3) carries a width specification that is exceedingly narrow. No one seems to be able to state where that width comes from. It's not in the paragraph or character style of a numbered paragraph. ID puts it into the CSS regardless of whether you have a character style specified for the number in the Bullets & Numbering tab of the paragraph styles pane.  It may come from the internal ID programming that generates the unordered list... but I can't know that. When you have an autonumbered paragraph, it looks like this:

People have complained about this since the change from CS6 to CC, when the CSS engine was revamped (as explained in the Adobe PDF I found and included in the post above). Still, no one seems to know where these narrow widths are generated.

Here is what to do:

Create an additional simpla CSS for your book, like this one:

span._idGenBNMarker-1 {
display:inline-block;
text-indent:0;
width: auto;
}

This duplicates everything in the automatically generated CSS, but changes the specific width to auto. I named this CSS kill_marker.css

Include a span._idGenBNMarker-n for each numbered paragraph style (you'll have to look at the HTML code to identify them).

When you generate the epub, include the new CSS on the HTML and CSS tab:

The new CSS "Cascades over" the automatically generated CSS from InDesign, and corrects the narrow width setting by replacing it with width:auto;

And, as they say, Voila!

This is not a solution that changes the output style tag, but it does overcome the problem.

If someone has a better solution -- or knows where the narrow widths are coming from so that they can be corrected -- plase reply.

Best.

-j

[Bizfound]

I truly appreciate your persistence in recording your solution on the forum, despite no one responding. I just wanted you to know I'm having this exact problem, and I find your solution will work just fine for me. Thank you so much!

[Nedlaw]

Thanks for your thanks. I think this quirk is built into the ID HTML production engine. There is no way to adjust for it in the UI of ID -- it just does it for you. When I was researching this, I saw many cries for help, and no responses. It appears that those people who know the solution weren't looking for the solution (and so never stumbled on the cries for help). Hanging a new CSS on the output is a brute-force kind of solution, but with no access to the internal code that -- for unknown reasons -- makes the column so narrow, what can one do? Happy this worked for you.