View Full Version : Superscript best practices?


DiapDealer
07-09-2011, 12:09 AM
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:
/* End note superscript style */
.end-note {
font-size: .80em;
vertical-align: baseline;
position: relative;
bottom: .6em;
}


And the html would look like:
<span class="end-note"><a href="../Text/EN3.xhtml" id="EN3">3</a></span>

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:
/* End note superscript style */
.end-note {
font-size: .80em;
vertical-align: .6em;
}


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?

Jellby
07-09-2011, 04:43 AM
I use simply:

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

<a class="note" href="../Text/EN3.xhtml" id="EN3">3</a>

or:

sup { /* this is already rendered as superscript */
font-variant: normal; /* for use in smallcapped text */
line-height: 0; /* do not alter the line separation */
}

M<sup>me</sup> de Bellière

mrmikel
07-09-2011, 07:34 AM
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.

charleski
07-09-2011, 09:14 AM
The method I use is outlined here (http://www.mobileread.com/forums/showpost.php?p=814110&postcount=70). 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.

roger64
07-09-2011, 11:53 AM
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 (http://pix.toile-libre.org/?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.

DiapDealer
07-09-2011, 01:08 PM
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. ;)

roger64
07-10-2011, 03:20 AM
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.

Toxaris
07-10-2011, 05:20 AM
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.


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.

roger64
07-10-2011, 06:09 AM
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...


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.

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. :)

charleski
07-10-2011, 07:29 AM
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 (http://www.mobileread.com/forums/showpost.php?p=814110&postcount=70) 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.

roger64
07-10-2011, 10:55 AM
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? ;)

DiapDealer
07-10-2011, 12:20 PM
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. ;)

Toxaris
07-10-2011, 01:39 PM
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?



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.

charleski
07-10-2011, 05:42 PM
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.

virtual_ink
07-21-2011, 01:20 AM
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?

virtual_ink
07-21-2011, 01:31 AM
Oh hang on. The code within the xhtml is:

<span class="endnote-ref" xml:lang="en-GB" style="font-size:1.1em;">15</span>

This appears in the quote but not the body para style. I'm exporting from IDCS5.5. I've removed everything after the "endnote-ref" and it seems to be working. Some sort of ID bug?

ProDigit
04-14-2012, 11:38 AM
old thread, but a valid question:
Can I just keep with html superscripts? (eg by writing something like below?):
<sup>superscript text</sup>

If I don't really care how small the text is, would this work for epub, or should I make a "class" thing, to describe the superscript style, and add extended class tags to every piece of text within the HTML that I want to see in Superscript?

HarryT
04-14-2012, 11:53 AM
Should work just fine - try it and see.

I'd suggest, though, avoiding the use of superscript for footnote references; they are too small to use on many touchscreen devices.

ProDigit
04-14-2012, 03:13 PM
Super script does not work on my Astak Ez Reader Pro when I read straight from an HTML, I'm still struggling somewhat to create the ePub I want, but with ePubPack I'm already helped a lot!

Jellby
04-14-2012, 05:28 PM
You can use <sup></sup>, and then style it as you want it, if you want: exact font size, exact alignment...