Indesign-epub-kindle formatting problem: footnotes export with massive indent.

[Hitch]

Originally Posted by DNSB

That I can agree with. Though at times, taking the hammer to the author's computer seems like it would be more useful.

Amen, brother, amen.

Hitch

[JSWolf]

Originally Posted by Hitch

Yabbut, sometimes, man, that sledgehammer is hard to beat from an emtionally-satisfying standpoint. :-)

God knows, I've seen some books that I'd have LOVED to hammer....

Hitch

I went back to the original code and found that there are not bold/italic that I can see in the main text. It's only in the other stuff that there is some bold/italic but only a small amount. So I'm not bothered with my sledgehammer. It worked very well.

If I wanted to read this I would need to merge the mess and then figure out where to split and then see what else needs to be fixed.

[jackie_w]

Originally Posted by JSWolf

After having a look at the original CSS, there is no bold or italic in the main text that actually matters. I didn't find any bold or italic in the main text. If I am incorrect, please let me know where so I can see the code.

Perhaps you didn't look hard enough. Every <span> with class="CharOverride-4" is italic. There are hundreds of those.

There's also some weird technique used for positioning of the ornamental scenebreak images. Mass deletion of what, at first glance, look like excessive ids will mess those up because CSS is applied by individual id. Look at page Petrified_Minds_TRIPLE_KINDLE_FINAL.mobi-6.xhtml for an example.

[Tex2002ans]

Originally Posted by jackie_w

Perhaps you didn't look hard enough. Every <span> with class="CharOverride-4" is italic. There are hundreds of those.

Hence the more surgical approach—deleting known useless style info (absolute positioning), then Calibre EPUB->EPUB conversion.

It's how I typically deal with really atrocious InDesign->EPUBs or Google Docs->EPUB. (If you think InDesign is bad, you should see Google Docs's code!)

Note: Like a few InDesign oddities I've been running across lately:

In some files, InDesign assigns an "Italic" font, but uses "font-style: normal" within the CSS.

So in a clean document, it should look like this:

<p>This is an <i>italic</i> word.</p>

but InDesign->EPUB may appear like this:

<p>This is an <span class="CharOverride-4">italic</span> word.</p>

span.CharOverride-4 {
	font-family:"Minion Pro Italic";
	font-style:normal;     <----- See here. Should say italic.
	font-weight:normal;
}

I'm unsure of how/why...

I've also run across similar in some DOCXs I've gotten from authors. Toxaris's EPUBTools doesn't handle these types of wrongly-styled fonts properly, but he is aware of the issue (and I believe he was working on it for the next release).

If you just mass throw away <span>s/fonts without looking closely, you'd also lose this sort of information.

[Hitch]

Originally Posted by Tex2002ans

Hence the more surgical approach—deleting known useless style info (absolute positioning), then Calibre EPUB->EPUB conversion.

It's how I typically deal with really atrocious InDesign->EPUBs or Google Docs->EPUB. (If you think InDesign is bad, you should see Google Docs's code!)

Note: Like a few InDesign oddities I've been running across lately:

In some files, InDesign assigns an "Italic" font, but uses "font-style: normal" within the CSS.

So in a clean document, it should look like this:

<p>This is an <i>italic</i> word.</p>

but InDesign->EPUB may appear like this:

<p>This is an <span class="CharOverride-4">italic</span> word.</p>

span.CharOverride-4 {
	font-family:"Minion Pro Italic";
	font-style:normal;     <----- See here. Should say italic.
	font-weight:normal;
}

I'm unsure of how/why...

I've also run across similar in some DOCXs I've gotten from authors. Toxaris's EPUBTools doesn't handle these types of wrongly-styled fonts properly, but he is aware of the issue (and I believe he was working on it for the next release).

If you just mass throw away <span>s/fonts without looking closely, you'd also lose this sort of information.

I don't know the reasoning, but we see this all--all--the time. It depends a lot on the training of the InDesigner, and also, what font files s/he is using. If you use Adobe's built-in (cloud) fonts, then you will get exactly that cruft--you'll get a span calling the "italic" (Font! Not simply italicization, right?).

The Indesigner has to be careful, in order to get what we think of as:

<i>italicized text</i>

Otherwise, you get the span calling the font FACE.

I've never bothered to experiment to find the "best" way, because speaking bluntly, we get files from all the corners of the globe. It's a miracle if we don't see 35-50 "character overrides" in a file, so my standards have changed, let's just say.

We had a file today that my Queen o'Quotes described as "not bad" (in INDD standards, right?). She then added "no paragraph styles, but other than that, pretty clean."

Sheesh, talk about lowered standards, for the love of heaven....

I agree that GDocs are actually worse.

Hitch

[Tex2002ans]

Originally Posted by Hitch

I don't know the reasoning, but we see this all--all--the time. It depends a lot on the training of the InDesigner, and also, what font files s/he is using. If you use Adobe's built-in (cloud) fonts, then you will get exactly that cruft--you'll get a span calling the "italic" (Font! Not simply italicization, right?).

That's what I was suspecting... Adobe's Cloud font nonsense.

(And guess what happens if you open the file but aren't a part of their monthly fee structure...)

So this Italic font face issue is a more recent addition?

Originally Posted by Hitch

I agree that GDocs are actually worse.

It actually makes me angry, you can send in a perfectly styled document in, but get complete gibberish out.

Is there a better way to import/apply/export Styles in Google Docs?

[JSWolf]

I've had another go at this and I've managed to keep the italics and cleaned up the code very much.

It was a lot easier the second time now that I knew what to look for. And it even took less time.

[Hitch]

Originally Posted by Tex2002ans

That's what I was suspecting... Adobe's Cloud font nonsense.

(And guess what happens if you open the file but aren't a part of their monthly fee structure...)

So this Italic font face issue is a more recent addition?

I seem to remember this at least...hell, 7-8 years back? I think it existed with the old Typekit subscriptions, too. And Pages (the Mac word processor) has had this same exact issue for dog's years. We used to get a lotta lotta work from Pages users, between that white background cruft and the MIA italics. It's gotten better, but the Case of the Missing Italics still plagues them.

It actually makes me angry, you can send in a perfectly styled document in, but get complete gibberish out.

Is there a better way to import/apply/export Styles in Google Docs?

I know, right? Google is a damned internet company. You'd think that they could focus on the underlying HTML, right? But noooooooooooooo, they're thinking about how they can be like Apple and make everything drag-drop and easy-peasy. Ugh.

It scalds my bum, too, brother.

Hitch

[Tex2002ans]

Originally Posted by JSWolf

I've had another go at this and I've managed to keep the italics and cleaned up the code very much.

It was a lot easier the second time now that I knew what to look for. And it even took less time.

And? Would you be able to list a few steps on how you did it?

Originally Posted by Hitch

I seem to remember this at least...hell, 7-8 years back? I think it existed with the old Typekit subscriptions, too. And Pages (the Mac word processor) has had this same exact issue for dog's years. We used to get a lotta lotta work from Pages users, between that white background cruft and the MIA italics. It's gotten better, but the Case of the Missing Italics still plagues them.

Thanks for the info.

And I haven't had the "pleasure" of working with anything from Pages yet.

I usually noticed missing italics further along in the process after too aggressive initial cleanup steps. Nowadays, it's one of the first things I look for.

Originally Posted by Hitch

I know, right? Google is a damned internet company. You'd think that they could focus on the underlying HTML, right? But noooooooooooooo, they're thinking about how they can be like Apple and make everything drag-drop and easy-peasy. Ugh.

A while back, I came up with a "markdown" -> LibreOffice -> Google Docs workflow, so I could mass convert my changelogs.

(See the ~steps in my Reddit answers from 7 months ago: /r/LibreOffice: "How do I replace formatting tags surrounding text with that text formated?".)

But the annoying step then became Styles within Google Docs.

If I made any sort of adjustments, the super clean Styles I applied in the LibreOffice step became botched.

Side Note: And has everyone seen, LibreOffice 7.1 introduced a new "Style Inspector":

https://wiki.documentfoundation.org/...tyle_inspector

It allows you to easily spot direct formatting + what's being applied where (similar to Inspect Code in your browser).

[JSWolf]

Originally Posted by Tex2002ans

And? Would you be able to list a few steps on how you did it?

I used Calibre's editor. I first removed unused CSS classes. Then I went into the CSS and removed all the stuff that was for fixed layout. I then removed unused CSS classes. And in the main text, I searched for position: and using Diaps Editing Toolbag, I left the span with just the class and removed the rest of the spans. I also removed any span that did not have a class. I also search/replaced the body into just a paian <body>. The override style that was just for italics, I changed from a span to an <i> and then I changed all the multiple </i><i> so the italics are just one <i>some text</i> I also did errors checks here and there to see what else needs fixing. The only thing wrong now is the NAV. But that's no big deal.

[DNSB]

Originally Posted by JSWolf

I used Calibre's editor. I first removed unused CSS classes. Then I went into the CSS and removed all the stuff that was for fixed layout. I then removed unused CSS classes. And in the main text, I searched for position: and using Diaps Editing Toolbag, I left the span with just the class and removed the rest of the spans. I also removed any span that did not have a class. I also search/replaced the body into just a paian <body>. The override style that was just for italics, I changed from a span to an <i> and then I changed all the multiple </i><i> so the italics are just one <i>some text</i> I also did errors checks here and there to see what else needs fixing. The only thing wrong now is the NAV. But that's no big deal.

When playing with the file, I changed most of the "Chapter-Title" items to a hx tag instead of a p tag which made it trivial to recreate the Nav and toc.ncx documents. At least, it was in Sigil. I found deleting the style="position bla...bla" items cleaned the absolute positioning. I also dumped the style="width bla...bla" settings. Looking at the CharOveride-xx bits, I replaced some of them with the appropriate bold, italic, smallcaps, uppercase, etc. bits and bobs while sending the rest to /dev/nul. I ended up doing 2 passes at the conversion and while the final result did not use the fonts from the original file since, IMHO, they were not well suited to an eInk screen, the result was at least readable.