Word joiner Unicode character in InDesign export for reflowable epub

[sidneydavenport]

I've recreated a printed book for reflowable epub in InDesign and it's about ready for export. I'll be using Sigil for CSS and some XHTML tweaks. Now I'm ready to concentrate on Kindle.
I don't want to imbed fonts, per James Gifford's InDesign to Kindle but I've used Unicode 2060 (word joiner) character in Gentium Plus between em dashes and the word they should be glued to. Should I just use CSS to put the Gentium+ back in? Thanks.

[James Gifford—NitroPress]

I'm not sure all these pieces add up to a workable solution, at least, not one applicable to EPUB export.

Your goal is to "glue" an em-dash to a word?

I'm not sure how you hit on using the joiner character or even where (in what app) that would work, but moving forward, I'm not completely sure it will work in either regular HTML or EPUB X/HTML. (Emphasis on "not sure.") But if you have the character in the text, it should export to the paragraph content in either and thus be present as Unicode 2060 or HTML ⁠ (and I note there's even a named variant, ⁠ — cool, didn't know that one). If the export isn't stripping this character, you shouldn't have to do anything, especially not anything font- or CSS-related; it's a content element, not a font/style element.

If the character is not being exported, the approach I'd use over all the Sigil-ing and EPUB editing and Unicoding is just to create a character style that applies no-break, apply it across each dash/word combination, and define it in export CSS as white-space:nowrap. That means backing up a little in your formatting but would be the "organic" approach, IMHO.

I am going to experiment with this out of curiosity; let me know if the character is exporting for you, which would be the hinge between different solutions.

[James Gifford—NitroPress · Accepted solution]

Cleaning up some messy edits here:

The joiner character is definitely exported, and definitely does not work in either Thorium or Kindle Previewer.

The nowrap technique definitely works in both.

So, I think the character style with nowrap is your only sure way to keep the em-dash with the desired text. The joiner character is definitely (there and) ignored by both viewers, so all the pooking around with fonts and such isn't useful.

But let me know if I've missed something, here.

ETA: And, belatedly, I know there is a similar problem with the non-joiner character; more than one user attempting to export Farsi or Arabic to EPUB has had trouble getting the character flow correct around that special character. So there's something specific going on with this class of glyph, I just don't know exactly what.

[sidneydavenport]

Thanks. Huge help as is your book. Thanks for updating it.

[James Gifford—NitroPress · Accepted solution]

Glad you found it useful. The v3.1 edition should stand for a while; I haven't made any but relatively small fixes since.

To close out the problem, some further testing confirmed what I thought: the readers are following a high-level rule that dashes are always an acceptable break point, regardless of anything like a following joiner or other hyphenation rules. Only by wrapping the dash in that no-break style is this rule, er, overruled. Interesting discovery.

My annoyance with en and em dashes is that they seem to be handled as special cases by InDesign, which will break just the dash to the next line.