[Tex2002ans]

Originally Posted by Hitch

Footception? Really? You're killing me here. :-)

lol, I just took the term from that LaTeX thread!

I thought Footnoteception sounded better, but might as well continue with the precedence. :P

Originally Posted by Hitch

Well...in print, it would be relatively simple; you could indent the sub-notes. Perhaps that's the answer here?

Hmm, perhaps if the Footnotes were relatively short, but Alcuin7's source document has footnotes that are PAGES long. And ALREADY use indentation for long numbered lists within footnotes. (Also mentioned this poor readability to him via PM.)

The indentation goes on for pages and pages, and it becomes impossible to follow "which level" you are on after going 2-3 pages away.

* * *

And according to a quick skimming of the document, I don't see why it couldn't be*:

123, 123a, 123b, 123b1, 124, [...].

His specific book doesn't really have DISTINCT sets of footnotes (like Author/Translator/Editor).

* Note: Well, besides Word not supporting it. :P

Originally Posted by Hitch

We need Toxaris for this. I "know" that there's a huge issue surrounding Word's built-in x-refs, which is what you're talking about. The cross-referencing and indexing functions work in a way that's unique to Word, [...] But honestly, Tex, I don't remember it that clearly and we should ask Tox. What he doesn't know about Word isn't worth knowing, in terms of the export to HTML.

This is Word's built-in Save As HTML... and it doesn't even export them properly. Bah!

* * *

I'll have to read up on Word's cross-ref functionality and come up with a better test document as an MWE (Minimal Working Example).

I also tested his DOCX in LibreOffice 6.1.3:

Opening his initial DOCX (created in Word 2003), LibreOffice was chugging away for MINUTES (about 4 minutes), the RAM usage just kept climbing up and up (>3GBs) and the progress bar didn't move... so I killed it.

I opened/saved his DOCX in Word 2016. LibreOffice was able to open this one after a little. And as you predicted, the cross-refs within footnotes didn't work. They weren't clickable.

(Also wasn't able to save the DOCX in LibreOffice, it froze. I let it chug away for about 15 minutes, and it got stuck with no forward progress. I'll probably have to create a document and submit a bug report.)

* * *

And on Word's Indexes... I did test DOCX Save As HTML about a year ago, and found it to also unleash some HIDEOUS HTML, but at least it worked (if I remember correctly).

Calibre also converted when you did DOCX->EPUB, but it turned everything into a hideous nest of [1], [2], [3] links, which became absolutely impossible to follow.

So something like:

cats, 82, 84, 119
dogs, 84, 123

became:

cats, [1], [2], [3]
dogs, [2] (since "84" already had a link), [4]

Again, I'll have to go back and come up with another good test document.

Originally Posted by Hitch

And if you just export it to HTML, not using the Docx-->ePUB functionality in Calibre? Is it different, or no?

Just tested DOCX->HTMLZ on his source file, and Calibre generates the exact same HTML as the DOCX->EPUB.

Originally Posted by BetterRed

Cross References in Word are implemented via Word Fields, the primary use of which is MailMerge and Excel integration. Word Fields can be nested. But I don't think foot/chapter/end notes use Word Fields, hence they don't inherit Field nestability.

This is what a single "cross-ref within Footnote":

bondholders.<sup>119</sup>

with a clickable 119 looked like when I ripped apart the footnotes.xml file:

Original, DOCX from Word 2003:

Spoiler:

<w:r w:rsidRPr="00971AE9">
	<w:t>bondholders.</w:t>
</w:r>
<w:fldSimple w:instr=" NOTEREF _Ref517136847 \h  \* MERGEFORMAT ">
	<w:r>
		<w:rPr>
			<w:vertAlign w:val="superscript"/>
		</w:rPr>
		<w:t>119</w:t>
	</w:r>
</w:fldSimple>

DOCX from Word 2016:

Spoiler:

<w:r w:rsidRPr="00971AE9">
	<w:t>bondholders.</w:t>
</w:r>
<w:r w:rsidR="0028080B">
	<w:fldChar w:fldCharType="begin"/>
</w:r>
<w:r w:rsidR="0028080B">
	<w:instrText xml:space="preserve"> NOTEREF _Ref517136847 \h  \* MERGEFORMAT </w:instrText>
</w:r>
<w:r w:rsidR="0028080B">
	<w:fldChar w:fldCharType="separate"/>
</w:r>
<w:r>
	<w:rPr>
		<w:vertAlign w:val="superscript"/>
	</w:rPr>
	<w:t>119</w:t>
</w:r>
<w:r w:rsidR="0028080B">
	<w:fldChar w:fldCharType="end"/>
</w:r>

Yuck. :P

Originally Posted by Hitch

LOL, there are probably people who would say that's wrong, too. You know how it is.

There's only the Tex way, or the wrong way. :P

Originally Posted by Hitch

I have the latest Kindle, AFAIK, the KFire 10, and I don't think it can override, even though it does allow user-selected line-heights/spacing and body text alignment.

Gitden Reader has been my go-to reading app on my phone, and it works exactly how I imagine in there. The user-justification works fantastically.

Only thing about Kobo Forma (at least the books I've tested on), is it overrides centered <div>s too, so centered images get shifted left. But I consider that a software bug/quirk (and I'll have to report it to them).

Again, this should be on Amazon to actually fix the functionality in their renderer, NOT be pulling books down over common CSS/formatting. If the buttons are there on the device, they should override any sort of Publisher formatting:

User >>> Publisher > Device Defaults.