"space between paragraphs using same style" disappears on reflowable epub

[Man Myth Legend]

This is a bit maddening, I'm publishing a book of poetry and just need spaced between the sections. Spaces between paragraphs is not an abstract function of written text but seems to be incredibly complex to accomplish. Orignally I just hit retun to show a space, as I do in word processing doc. Those spaces disappeared when I saved to epub. After digging I found that I needed to use paragraph styles above and below, did that and those spaces also disappeared. Then I found someone suggesting I use forced line breaks and that worked! Then someone else said that's bad form, and that I should use paragrpah styles. I discovered there's paragraph style "space between paragraphs using same style"...that's what I need! Applied it...disappeared. I've spent hours trying to get spaces between my paragraphs, please can someone tell me what I'm missing? Is there some setting I need to click to preserve paragraph style spacing in epub?

[Derek Cross]

Don't use Returns for line spacing use Space After in your Paragraph Style.

It's helpful to know a bit of HTML and CSS if you're going to create Reflowable ePubs.

[James Gifford—NitroPress]

That spacing, like all automatic spacing around bullets etc., is not exported to the HTML structure of EPUB.

The solution is to use two or three styles for things like bullets — one for all middle elements, one for the top element, and (sometimes) one for the bottom element. Even then, spacing difference can disappear into standard <ol> and <ul> formats, and some CSS overrides are needed to get the spacing that ID (and Word) do both automatically and with features like "space between paragraphs" settings.

All or most layout apps have such "auto adjust" and fancy override features that exist only within the app layouts and direct exports to print or PDF. You have to learn to work around them for flexible exports.

[Man Myth Legend]

I guess I'm confused bc the consesus here is that pargraph styles is the appropriate way to create spacing, but "space between paragraphs of the same style" IS a paragraph style element...it's in the exact same tab as the "space above" and "space below" functions so it's a bit agitating when it doesn't work. Essentially if only space above and space below work then I need to apply a different style to top or bottom line of text everywhere there's a break. I'm publishing a book of poetry so it's like 2 lines and then a break, 3 lines then a break...a lot of spacing. To go through the whole book and have to apply different styles to every 2nd or 3rd line of text seems incredibly inefficient to have to do in a software that had decades of development to be flexible and efficient to the task of layout design. It really seems like I'm missing something, that Adobe would have come up with an easier way to do this than me having to comb through my whole book applying different paragraph styles every few lines just to create spacing between the text.

Is there a way I could apply the "space between paragraphs of the same style" with HTML in a way that would render on the epub? In effect, I'm much more interested in figuring out how to globally apply space between paragraphs than in having to do it manually all through the document.

[James Gifford—NitroPress]

"Space between styles" is a paragraph style element ONLY within InDesign. It doesn't export or translate to any other format.

Word and other word processors do all kinds of little things that aren't obvious, such as adjusting the space after periods, in between bullets, etc. so on yadda yadda. These tweaks will show up in print, and equivalents like PDF, but they don't represent any inherent style or setting that any downstream process like HTML or EPUB or generic word formats will preserve.

ID is the same. It has some internal tweaks and tricks that disappear on export. All of this paragraph auto-spacing stuff is one such.

ETA: Just in case that's not clear, there are different things going on here. Setting the space above and below paragraphs is a simple part of Paragraph Styles, and fairly fixed and absolute. It's that automatic "collapse space between identical styles" that is something of an app hack and not easily replicable on export.

As for "globally apply space" — that's a basic aspect of paragraph styles, and will (largely) be preserved on export. However, export to EPUB is subject to some magic fudge factors that aren't always evident; if you don't like how an EPUB doc looks on a vanilla EPUB reader, all you can do is adjust the setting in ID to get the desired export — even if it looks "off" in ID — or use CSS to adjust the style at export.

It's very possible to have an optimal ID document for print and export it to optimal EPUB (and Kindle) — but it's all in mastery of CSS.

[TᴀW]

I think the ePub export feature in InDesign was written before they added the feature to "remove space between paragraphs of the same style" (might be wrong there, but I think it's correct). This is probably why exporting to ePub doesn't support the feature.

I think you're quite right to expect it to be supported.

What I would do is supply a custom CSS file (there is an option to do so in the ePub export options dialog), that would eliminate the space-above for any <p> tag that has the same class (=paragraph style in CSS lingo) as the previous one. According to ChatGPT, the CSS looks like this, but I haven't tested it, and I'd need to look up this particular CSS selector, as I'm more of an InDesign guy than an HTML/CSS one!

.same-class + .same-class {
  margin-top: 0;
}

You'd replace .same-class with the name of your paragraph style. If it has spaces, you'll have to inspect the HTML to see what InDesign converted the name to. (I think it replaces spaces with hyphens.)

HTH,

Ariel

[James Gifford—NitroPress]

The EPUB export has been updated several times.

I think it's just a gap in how the export process handles the more complex formatting — for example, there are a number of formatting elements that depend on padding in CSS, but ID does not export padding, at all, for any purpose. Things like "space between same" are an internal, ID-specific feature, and it's more straightforward to just skip over it than try to interpret it into clean, standards-compliant export code.

Excuse me, as well, if I don't think ChatGPT is the authority here. 🙂

[TᴀW]

CSS to remove space between similar classes is hardly rocket science, and there's no real reason InDesign doesn't do it except for the general principle that they leave many features half-baked.

I also would not rely on ChatGPT. Indeed, in this case, I think we'd need 2 selectors (to target the first element of each pair and change its margin-bottom to 0, and then 2nd element of each pair and change its margin top to 0).

In any case, I think the correct answer here is for the OP to include a custom CSS file with the appropriate CSS.

[James Gifford—NitroPress]

ID exports solid EPUB; most validation errors I have seen in quite a while are from broken internal organization of the document, not export faults.

What it does not do is bend over backwards trying to match or implement every layout feature, such as the automatic 'space between same styles' ability. These are generally not exported (completely) because the feature doesn't exist in EPUB. The only solution would be for ID to create those three styles and implement them correctly, and that's asking a lot given the gulf between ID/PDF/print and e-doc conventions.

CSS may not be rocket science, but unless the user has some web-design experience, it's as much gibberish as any code. It's easy to tiptoe into it with little single-style fixes such as you presented, but as with so many things, there's quite a bit of understanding that goes into knowing what and where to apply the band-aid.

(And besides general skepticism of ChatGPT as a mature info source, EPUB is one area where general web-scraping can lead right off a high cliff at every turn. Mountains of outdated, incomplete, wonky material out there.)

[Derek Cross]

If you're using a Mac, BBEdit is an excellent application for editing ePubs.

[James Gifford—NitroPress]

I don't think exported EPUBs should ever be edited, any more. That's an obsolete approach if you are starting from a tool like ID.

The whole "build-a-bear" e-book world is stuck on these obsolete, unnecessary approaches (which, to be fair, were once the only approach) and it's time for serious book designers to move on.

[TᴀW]

To this very day, there's no way to create decent ePub from InDesign without using a custom CSS file, in my experience. That's part of the InDesign create-an-ePub workflow...

[TᴀW]

Likewise, it can be very difficult (impossible?) to create a decent navigation pane for your ePub without editing the ePub outside of InDesign. 

For instance, if the navigation pane has to include a table of images, i.e., link to images, not text. So the Navigation Pane would say: "Fig. 1: HMS Victoria", and the link would be to a picture...

[Derek Cross]

Exactly – all professional ePub producers crack open and fine-tune their ePubs.

[James Gifford—NitroPress]

And all pros outline fonts when sending files for print. 😄

Well, the ones who learned old techniques do. 😄 😄

[Derek Cross]

Outlining fonts, with certain exceptions, is not good practice for a number of reasons.

[James Gifford—NitroPress]

Well, IMVHO and that of most of the publication developers I know, neither is editing EPUBs. It's part of an entirely obsolete workflow and development concept. But if your tool set is 'building with legos' instead of 'injection molding' — I guess crack them open and manually build indexes, etc., the same way some designers still doggedly outline print docs.

I haven't cracked an EPUB in many years. Haven't needed to, any more than I've needed to "fix" PDFs. The place to build/fix is upstream.

[TᴀW]

I'd be curious to know how you create a navigation TOC as I described above without cracking open the ePub.

[James Gifford—NitroPress]

I define the TOC in InDesign (often with considerably more levels than for a print TOC) and specify it at export time. In some books I also define a print/inline TOC (usually briefer) and include that as well. It works flawlessly.

That you can do all kinds of aftermarket, JC Whitney, hot-rod things to exported end formats (PS, EPS, PDF, EPUB, SVG) is not necessarily an argument that you should, or that it's best practice (any longer). The last time I did it was with PS files exported from very primitive, noncompliant apps to get them to be compatible with our printers' RIPs. I think that was 30 years ago. And there was an era when the 'build a bear' method was the only way to get anything but a very basic EPUB. But that was 10 years ago.

If you're one of those who can't stand to drive a stock car and has to mod it in your garage, fine — I won't argue you should do it differently. But it's way, way past time that newcomers and rising pros should still be taught/told that this is the right/proper/efficient/necessary process. It's not (hot rod clubs excepted).

[TᴀW]

Yes, I begin with an InDesign TOC which I include in the export and is then converted to a navigation pane. But when I need the items in the nav pane to link to images, not text, there is no way to do that without editing it outside InDesign that I'm aware of.

For some books it's a basic requirement to do this, so if you have any suggestions, fire away.

[James Gifford—NitroPress]

Well, you can always come up with "one more thing" that is either outside ID's basic capabilities or is so niche that nothing short of hand-building can create it. My question, then, would be "is there a better alternative, rather than trying to preserve a feature for its own sake?"

But an inline TOF is no trick at all, and if I had to include figures in a dynamic TOC, I'd simply TOC a caption or anchor style. I've no doubt there are other solutions that can be implemented from the "injection molding" approach rather than the "lego" model.

ETA: If it's not easy enough to separate the figure links from the text TOC, a hybrid TOC link to an inline TOF could be elegantly rendered. And I'm not sure there aren't more integral alternatives; it's just not a problem I've tackled.

These may not be *exactly* what you're aiming for, but the entire nature of e-publishing demands different aims, not necessarily just trying to replicate every aspect of a print book with LED backlighting. (Which is, for example, why I'm on the side that FXL is obsolete and should not be used; it's a "wrong road" for digital publishing however normal or natural it seemed a decade ago.)

[TᴀW]

I've made dozens of ePubs. The publisher I work for has specific requirements for the nav pane.

This is neither niche, nor just "one more thing." It's an issue that arises whenever the nav pane has to link to a page that does not itself contain the text that should appear in the nav pane.

In any such case, the ePub has to be edited externally.

I completely agree with the underlying principle that as much as possible should be done within InDesign.

However, if an external CSS file needs to be added (which is easy to do, and supported by ID's export-to-ePub feature) or any other external tweaking need be made, that's absolutely fine.

I disagree with the need to be a purist about these matters, so external editing is fine too, if needed. It is cumbersome, especially if further edits needs to be made down the line.

If something can be done in InDesign and is instead done externally, perhaps that is a sign of a slight lack of professionalism.

But if it cannot be done in InDesign, and the publisher/customer wants it, it can and should be done externally.

[James Gifford—NitroPress]

Okay. I have no further argument. But I do complex to very-complex books, in print and EPUB simultaneously, and have never had to edit an ID-exported EPUB.

I'd simply suggest, mildly, that there is probably an alternate way to get the results you describe without having to manually define a nav entry; while it may be purist to suggest that an upstream solution is better than a downstream one, I suggest that only because I've had dozens of... encounters... with EPUB gurus who insist that "X cannot be done!" or "...cannot be done except in this way I've developed!" — and proved them wrong.

I completely accept that you're doing what's best/necessary/required to get your projects done to a specific client's demands. But — again not saying this is your position — myopia and a resistance to give up old processes are endemic out there in the world of experts who have published 400 EPUB novels. Myself, I utterly ran out of patience with that crowd a couple of years ago, and yes, it's made me a bit prickly on the topic. 🙂

[Derek Cross]

James Gifford seems quite knowledgeable about producing Reflowable ePubs, but he tends to be maybe a bit too confident in his views. In my experience, most commercial book publishing managements don't have a clue about digital publishing technology. They employ a process for simple word-heavy books like novels and biographies. Only specialist technology publishers such as O'Reilly and Pearson have the in-house expertise to produce complex ePubs. Powerful applications, like InDesign, don't have the ability to write good CSS; the markup tends to contain far too many tags that tend to get in the way of accessibility features. Cracking open the ePub and fine-tuning the code is often the way forward.

[James Gifford—NitroPress]

Derek, I am taking a very specific and deliberate viewpoint on EPUB creation, and choosing not to lard it with "but on the other hand, and if you choose differently, and once upon a time..."

No, ID does not produce perfect EPUBs by itself, or seamlessly, but I have found over the last several years (of producing books that approach maximum levels of complexity and content) that management of the layout in ID, and expert management of CSS, can produce outstanding results without any need to use old-school file-surgery. It's that simple.

If someone is more comfortable using a three-stage approach (ID setup, CSS and EPUB file management), they're perfectly welcome to; we all have longstanding practices for which there are probably "better" options that have come along over time,

But I am adamant that "EPUB surgery" not be passed along any further to newcomers or developing pros coming into the field, any more than they should be taught to edit PDFs or SVGs at the file level. It's not just obsolete, but representative of an entire, widespread, sloppy, somewhat ignorant praxis that keeps getting presented as The Way To Do E-Books. It's not, no matter how mainstream or even essential it might have been ten years ago.

The methods I have found, explored and to some degree develop accomplish everything the Sigil/Calibre/code-edit approach can do, and in many cases, it only takes a bit of selective CSS to get there from an ID export.

I am perhaps more... aggressive in this viewpoint because we're up against a vast number of "web experts" who, even if they knew something useful ones, should be barred from telling users, especially newcomers and novices, anything more than where to find the on button of a Kindle reader. They keep promoting not just "builder" practices — which again, I don't think are bad, just obsolete — but grossly outdated, complex and pointless hacks they learned back in the earliest days and have never bothered to update. And then they will argue, argue, argue — there are several, draped with likes and stars and accolades, who have long rants about how InDesign can't possibly create EPUBs — it's crap, you see. Just crap. And many have huge blogs or websites or how-to libraries that cover a decade, with vast amounts of completely outdated information they never bother to update or even flag as 'archival.'

Just look at the continuing flow of newcomers and moderately skilled users who come here looking for EPUB help, and have watches YouTube videos or worked through training blogs or the like... and have almost everything completely wrong. We have to lead them through many unnecessary backtracking steps to get them to what should be simple solutions.

I'd really like this overwhelming tide of misinformation, outdated information and flat out ego-driven bad information to stop influencing newcomers. So I am perhaps more than politely adamant about using new approaches — even though I know they have limitations, just as all the prior approaches did.

In a a nutshell, it's time for e-book development to join the rest of the field, and be done by a designer using something like InDesign, to produce a finished book file using the same focus and practices we do to create a PDF, a PO document, or a print book. Not the steampunk "build it like an app" approach that is about code and linkages and file structures, and puts everything about design and layout and "books" over on a shelf.

I routinely produce new books, in InDesign, with the result being print PDFs and a distribution- or Kindle-ready EPUB, from a single file. I'll put any of my books up against those from any publisher you think is a current master of the process. And the bulk of what I know about the technique is in my book, which I update every six months or so, and in the answers I try to provide here, often with some good support from other e-book creators who are working in 2023, not 2010.

No one here is carefully explaining the clumsy, workaround processes of how we did things in CS3 or CS6 or even some later versions; there's a sense of professionalism and SOTA that underlies nearly every answer when someone says they're using an obsolete ID feature or practice, and guidance to the modern tool, feature, practice and workflow.

That's where I am on EPUB. Simple enough.