Footnote problem in kepub conversion

[JSWolf]

Originally Posted by theducks

Knowing when (and how) to abandon some of the TadPub styles is important.

I have books that the whitespace before a chapter head is almost 25% on my Libra2 (a huge screen compared to many phones) and another 25% after
(I have saved searches that shrink that to 6%, keeping some sense of a chapter head block). Other things I see: 2em chapter heads.those only fit if ONLY numbers.

I only re-code for myself. Ans I have been doing this for almost 13Y.
FWIW I started with a 5" RMSDK based device whe there wer block number on the right edge that smeared the last letters of text when the showed.
My solution was to adjust the body margins and text size:
The right margin gave it room for 3 digits
by raising the text size, it became larger relative to the numbers. The pros have tricks that are needed to work on less compliant devices.(Kobo is a friendly device to code for)

body {
    margin-top: 0;
    margin-bottom: 0;
    margin-left: 2pt;
    margin-right: 16pt;
    font-size: 1.2em;
    text-align: justify;
    }

I find 6% too large and a waste of space. I use 0.8em top/bottom margin for most chapter titles. But if I was making eBooks for sale, I'd use 1em top/bottom for chapter titles.

[JSWolf]

Originally Posted by Liudprand

Thanks again. I'll dm my email in a bit (I'm out and about).

Mine is a Kobo Libra 2. I checked the top 10 nonfiction books I have on there (i.e. the 10 most recently opened), and they all have the formatting I'm talking about, displaying correctly. But I'm not sure how they all show up on a phone or tablet.

The industry is run my morons. What works for pBooks does not always work for eBooks. So when you create your eBook for sale, do it so it works.

Take your eBook with the superscripted 1 for the tap zone and load it onto your Libra 2 as an ePub and try to tap the 1. It's not going to be easy. But if you used [01] in the same size as the main body font, it would be quite easy to tap and you'd keep your numbering.

[JSWolf]

Originally Posted by Liudprand

Yes, I agree with that. But I also think one of the reasons is that the tools for producing ebooks are not yet user-friendly enough for people to casually play around with different style/formatting options in a way that would allow the industry practice to evolve more rapidly.

Mind you, I think I'll go to my grave with my preference for the traditional look and feel of superscript footnotes!

Most tools are garbage. Vellum and Kindle Create are two examples of really awful tools.

However, Mobileread supports the two best tools available. They are calibre and Sigil. They allow you to play around with different style/formatting options in a way that would allow the industry practice to evolve more rapidly but the industry is run by morons who are fixing in their wrong ways.

[JSWolf]

Originally Posted by Liudprand

I may be wrong (always, always... ), but, as far as I know, it's not possible to specify the use of text figures in a typeface that doesn't use them (or something approximating them) as a default figure style - such as Georgia. Which I hate.

Minion, Garamond etc. contain glyphs for text fonts, but they're not selectable even if you have the stomach to wade into Calibre and fiddle with code. Again, I may be wrong.

But what I'm talking about is a purchased ebook. Again, as far as I know, I can't do anything with purchased ebooks on my device through Calibre - purchased books on my device don't even show up in Calibre when I plug the device in, so I don't see how I could do anything beyond changing the settings on the device itself. That's why I'm saying I'd prefer this option to be incorporated into device options. Which I realise is not a Calibre issue in any way.

Take a look at Kindles. They allow you to use your own choice of font. If the eBook has embedded fonts to make sure that certain font features work correctly, the user is still going to use his/her font choice. So when you are making an eBook, you have to design your book with the idea that the font being used won't have any special font features because in a lot of cases, the font used won't.

[JSWolf]

There are a lot of people here on Mobilread who can make eBooks better then the industry.

[BetterRed]

Originally Posted by Liudprand

Indeed. All the more reason to disguise that fact in the marketing and production, if you want to sell more books! To be fair, most readers of a book like that would have no objection to her being an academic - but they will often be turned off by anything signalling that the book is written in an academic style, and (especially) that the writer and publisher are keen to communicate the book's academic good standing. (There are readers who actually respond positively to the kind of impenetrable and self-important prose that academics are too often guilty of producing, but they're much fewer in number.)

Perhaps you're right, the author's earlier works, "Mistress Bradstreet" and "The Woman Who Named God", have superscripted cues and numbering within chapters, they were published by Little, Brown & Co. (Hatchette).

Likely she switched to another literary agent.

BR

[colinsky]

Perhaps a bit off topic (and not solving the OP's actual problem that everyone seems to have ignored, which was about sequence numbering rather than the display of footnotes themselves)...

I recently read an Oxford University Press book which tried to get around the small-tap-area problem by not only linking the footnote anchor itself but a few words previous to it. This seemed a good compromise between the standard printed approach and a reasonable digital experience. (see attached)

Regarding the use of numbers -- I've had the problem of multiple unnumbered notes in a book (* or the like), where clicking on one took me to a page of multiple notes, without any clue as to which note was the specific one I was referencing. So numbers do provide some value, even in e-books...

[Liudprand]

Originally Posted by JSWolf

Don't use green text. Leave it as black. It's hard to read on a white background. Please go fix your post to remove the awful green.

It's not my post. I was quoting someone else. Maybe go and ask them, no doubt just as courteously, to change it?

[Liudprand]

Originally Posted by JSWolf

That remains the standard for PAPER BOOKS! It does not work well on eBooks. The tap zone is TOO SMALL! What I do is [01] in the same body text size for the tap zone and it works. Doing 1 as a superscript doesn't work. Also, doing it my way means you can have the line height smaller without throwing off the line spacing. Kindles use a line space that's too large.

No, you're wrong. I understand you think it looks bad and is difficult to use. I happen to disagree. The point is that it's used almost universally by book publishers that produce ebook versions of the books they've published on paper. That's all I mean by "industry standard". It may be that - in your view - lots of people can make ebooks better than the publishing industry do. But my original query was prompted by the fact that I'm doing a job FOR THE PUBLISHING INDUSTRY, so I need to conform with what they want - which, by happy coincidence, happens to be what I prefer, both aesthetically and ergonomically.

[Liudprand]

Originally Posted by JSWolf

The industry is run my morons. What works for pBooks does not always work for eBooks. So when you create your eBook for sale, do it so it works.

Take your eBook with the superscripted 1 for the tap zone and load it onto your Libra 2 as an ePub and try to tap the 1. It's not going to be easy. But if you used [01] in the same size as the main body font, it would be quite easy to tap and you'd keep your numbering.

I'm sorry, but this is just... silly. I've already pointed out that every nonfiction book I have that contains footnotes uses "the superscripted 1 for the tap zone". No doubt there are a few that don't - and using non-superscripts in square brackets is something I've certainly seen in academic journals. But the idea that everyone out there using 99% of professionally published ebooks is stabbing away a the screen in frustration, completely unable to hit the superscript note cues, is... let's just say, counterfactual. I'm really confused about how nearly everyone on here is convinced it's a completely impractical/unacceptable style, to the point where even my mention of it invokes fits of derision and condescension, when LITERALLY THE WHOLE OF THE BOOK INDUSTRY STILL USES IT IN EBOOKS.

[colinsky]

While it's quite an interesting debate as to how foot- and endnotes can best be utilized in ebooks, I'd also like to try to help the original poster. The initial issue raised is the following:

In the conversion from WORD to EPUB, the numbering option setting (number footnotes consecutively through the document vs. restart numbering for each section) is being ignored -- see attached.

OBSERVED BEHAVIOR: Regardless of the document setting, numbering proceeds consecutively through the entire book.
DESIRED BEHAVIOR: Numbering follows source document preference.

The poster also mentioned that the wordtoepub tool does preserve numbering preferences properly, which suggests that the relevant information is present in the source file.

[Liudprand]

An assignment for anyone else tempted to shout at me on here that superscript note cues are completely unthinkable newbie nonsense, please fine me 1 [one] example on Amazon - or wherever you can access it - of a professionally published ebook version of a print book (no self-publishers, please!) that does not use superscript note cues. Maybe someone will succeed in this mission; I just haven't been able to find one.

And "the publishing industry is full of morons" isn't really a germane response. I mean, it might be true; but if it is, then the morons are in charge of what remains, at least for now, the standard practice within the industry, and people need to recognise that at least on a factual level, even if it enrages them.

[Liudprand]

Originally Posted by colinsky

While it's quite an interesting debate as to how foot- and endnotes can best be utilized in ebooks, I'd also like to try to help the original poster. The initial issue raised is the following:

In the conversion from WORD to EPUB, the numbering option setting (number footnotes consecutively through the document vs. restart numbering for each section) is being ignored -- see attached.

OBSERVED BEHAVIOR: Regardless of the document setting, numbering proceeds consecutively through the entire book.
DESIRED BEHAVIOR: Numbering follows source document preference.

The poster also mentioned that the wordtoepub tool does preserve numbering preferences properly, which suggests that the relevant information is present in the source file.

A thousand thank yous! This whole thread has spun away from my original point - which is partly my fault. But I'm still struggling with this very problem.

If anyone's interested, I've got as far as formatting the text in LibreOffice Writer, and making each chapter its own section - which has the equivalent effect of section-breaks with note numbering by chapter in Word. LO has its own native ePub export function, which I've tried, and which DOES preserve within-chapter note numbering. But (like WordToEpub), it messes up other formatting stuff, such as spacing and page-breaks before chapter headings.

Since I'm such a coding ignoramus, my next task is to fix those issues using Sigil with PageEdit integrated. Hoping I can get it done the WYSIWYG way, and not dabble in any code-editing. I'll keep y'all posted...

[DNSB]

Originally Posted by Liudprand

Since I'm such a coding ignoramus, my next task is to fix those issues using Sigil with PageEdit integrated. Hoping I can get it done the WYSIWYG way, and not dabble in any code-editing. I'll keep y'all posted...

While PageEdit is a massive improvement over BookView (I still have horrible memories of how QTWebKit could crapify an epub), I still prefer to edit in the code view with the preview pane on a secondary monitor.

And, yes, MobileRead is very susceptible to thread drift. From librarians to vampire weaknesses in three short messages.

[Liudprand]

Originally Posted by DNSB

While PageEdit is a massive improvement over BookView (I still have horrible memories of how QTWebKit could crapify an epub), I still prefer to edit in the code view with the preview pane on a secondary monitor.

And, yes, MobileRead is very susceptible to thread drift. From librarians to vampire weaknesses in three short messages.

Yes - I imagine I might well graduate to that approach with a little practice.