Superscript best practices?
 

I'm probably being a little persnickety, but does anyone have some CSS that consistently produces desirable superscript results across a variety of readers/applications? Superscript links for endnotes is where I'm ultimately going with this.

Just from an html standpoint, I tend to use the following CSS applied to a <span> element:
And the html would look like:
I find that seems to look the best... and doesn't mess with the line-spacing at all. However... ADE just seems to ignore that CSS and my poor number three is vertically aligned with the rest of the surrounding text. The only CSS I can get ADE to respect (with regard to superscripts) is:
Which unfortunately, when I get the superscript jacked up to where I think it looks good, really starts butchering the line-spacing. It makes for ugly paragraphs. Does anyone have a "one-size fits all" solution that will maintain a consistent line-spacing when using ADE or any other readers/apps?

I use simply:

or:

Since it depends on each reader there is no way to show superscripts easily across a variety of devices. Some people, myself included, tend to show them as bracketed numbers [1].

But that gets awkward when the text includes them and refers to them, as it did in a recent book I worked on.

Those viewing epubs on bigger screens can get away with smaller superscripts. They require a microscope on my Sony Reader.

The method I use is outlined here. This prevents ugly variations in line spacing in ADE and allows you to alter the vertical position of the superscript by changing the line-height.

Obviously, the reader application should really handle superscripts properly without having to resort to tricks to avoid irregular line-spacing, but this is the result of a fault in CSS2 itself. The readers are merely applying the (defective) standard.

Hi

This is another problem people using LibreOffice and Writer2xhtml do not have to worry with.

They select either Style/superscript or Insert/endnote while textprocessing to write (nothing really unusual) and when they export to EPUB, this is how the end result looks like: (This is a Sigil view extract, text on top, code lower)

http://pix.toile-libre.org/upload/img/1310223027.png

Of course, if you are not happy with the style you can modify character styles or endnotes characteristics in LibO like you wish to suit your needs.

Thanks guys!

Jelby's second example is the one that works the best for me. Thanks for the suggestion Roger, but I since I'm going to end up in a code editor before the ebook is done anyway... I prefer to just start in a code editor from the get go. Using a word processor, then exporting (or using a plugin), and then tweaking the resulting code just isn't my cup of tea. ;)

Of course, your choice for your book is the best. Thank you for commenting it, most don't do it. :)

I will just comment, if I may, in a general way because I also had the opportunity to produce some books and like you, I do not like to tweak the resulting code and I limit it to the utmost.

My point is that, with a reasonably complex book, you can now make an EPUB without tweaking the resulting code.

What's a reasonably complex book ? One including any text using styles, lots of notes, tables, ordered lists, TOCs, meta-data, images of nearly any kind, including floating images, adding custom style sheets, embedding fonts and more. You just have to use LibreOffice with the standard odt format. I sincerely says it covers 99% of ebook production needs though I did not do any statistical study of any kind. My feeling. ;)

This can be produced within LibreOffice and exported straightaway as an EPUB within LibreOffice using its extension writer2xhtml. It's very comfortable indeed.

Why are people using code editors then? This is a puzzling question. :)
I would say there are always exceptions to any rule *, that not everybody produces text in odt format and that diversity is the salt of mankind.

* For the time being, for example drop-caps are one of them, but that may change soon.

PS: Here is an example where I made use of another feature, automatic style-mapping of style attributes.

I can't speak for others, but I don't want an additional word processor like LibreOffice on my laptop. I already have Office, which I also need for my work. I have some very good Word macro's that do a lot of post-OCR processing and takes out an enormous amount of errors. The export to filtered is not ideal (understatement...), but it a macro is developed to solve that.
What is more, I like to have control over the code. I have some standards regarding to the code and things I want and don't want.
Even if I would use a plugin like this, I still would manually check and alter the code.

For what it is worth, I tried working with LibreOffice, OpenOffice, StarOffice and so on, but I did not like it... The wordprocessor is reasonable, but the rest was not up to par for me.

Hi Toxaris,

I heard about Word users and their lingering html conversion problems. True, if you do not like LibreOffice, there is nothing it can do for you. But this is your choice. Fair enough. :)

But...

I would be just curious to know which "standards" the xhtml transcription made by writer2xhtml is infringing upon?

I can tell you that, provided the user made a clean work out of his odt file, his EPUB code will be spotless clean too. The main point is easy to remember, it's to use styles throughout in the odt. The user has total control over it.

Furthermore, you also can customize automatic style-mapping options (for styles or style attributes) to suit your tastes.

If an odt file is a mess though, with a lot of "hard formatting" for example, well, then probably the garbage in, garbage out rule will apply... It makes really very clean work but does not perform any miracles yet. :)

roger64: The epub you posted produces exactly the sort of ugly variation in line spacing that must be avoided. It does this in both ADE and calibre's reader, because that's what's specified in the css standard. The sup tag needs to be modified in the css to reduce the line-height in order to prevent this. See my earlier post for an example of what superscripts should look like. Jellby's method and mine are essentially the same, though mine allows a bit more control over vertical positioning.

Hi Charleski

One of the pleasures of MR is that we may have constructive threads. Thanks all of you for your insight and research on this field. To be honest, I really did not dig so deep in superscript. :)

To sum it up for my point:

Writer2xhtml produces an xhtml code which is very respectful of standards. One of its advantages is to drastically reduce the necessity of code tweaking.

The latter remains necessary at times, for example for drop-caps and nicely customized superscript tags.

Somebody disagrees? ;)

I don't disagree at all... it seems like a nice plugin. It just won't fit into my workflow. ;)

The problem is, LibreOffice and the Writer2xhtml plugin, just don't have anything to do with my original question. I wasn't looking for a program to do something for me. I was looking for some in depth, behind the scenes, code-level details on how to get superscripts to behave in a consistent manner across a variety of ereaders and applications. I got those details from Jelby and charleski's examples.

It seemed like I only got an advertisement/endorsement from your post. And in fact, Writer2xhtml will generate the same line-spacing issues (with superscripts) that prompted me to ask my question in the first place! Nothing wrong with a little advertising, but make sure it meets someone's needs before you do it. ;)

Although Word gives bad HTML, cleaning up only costs me about 15-30 minutes now. After my macro is finished, it will take me a few minutes.

I am referring to my own standards. As an example, the example you gave earlier in the thread would not pass my standard. I tend to avoid attributes in spans and alike. I would transfer that always to a CSS stylesheet. I find it is ugly code. It is correct code, but not for me.

Writer2xhtml is open source, so it could be modified to produce epubs using the correct css to prevent the line-spacing issue. It's highly modular, though, and the css generation used for ePub export is part of the more general style generation package, so I'm not sure if the author would want to modify it globally or just for epubs.

I've just attempted my first endnotes using Jellby's rule above:

a.note {
font-size: 75%;
vertical-align: text-top; /* doesn't affect line height */
}

Although mine reads:

span.endnote-ref {
font-size : 75%;
vertical-align : text-top;
}

This works great in the main body-copy, but in my smaller indented quotes, the endnote references actually come out larger than they do in the body-copy, when I was hoping they would appear smaller than the quotation paragraph style, which is:

p.quote {
font-family : Georgia, serif;
font-weight : normal;
font-style : normal;
font-size : 0.83em;
text-decoration : none;
font-variant : normal;
line-height : 1.2;
text-align : left;
color : #000000;
text-indent : 0px;
margin : 16px 32px;
}

How can I make the rule for "font-size: 75%;" apply to the paragraph style it is relevant to?