Why do professional epubs look so different from each other?

[Solitaire1]

Originally Posted by rogue_ronin

That <span class="....> stuff is bad XHTML. The simplest way to do those is with <em> (emphasis) and <strong>. If you're seeing a lot of <span...>, it's because of the overuse of Word, and other programs that insert a lot of cruft.

<span...> and <div...> are generic containers, that should be used when there is no other tag that is appropriate. It's lazy markup. Both of them are overused, and lead to a vague, illegible, incomprehensible document. I only use <div...>, for instance, as actual divisions in my markup -- literally, largeish pieces of the book: ie: cover, frontispiece, foreword, section, chapter, appendix, colophon, etc. I only use <span...> for two unique tags: FirstLetter and FirstWord -- which don't have any easy equivalent in HTML.

A well-thought out set of XHTML tags for use in an ebook can actually make things a lot better and allow for an amazing amount of control.

Done well, you can have less tagging -- or you can ramp it up to quite a high level. The amount of tagging is dependent on the complexity of the document structure, though, not the display complexity.

I can give you a well-constructed ebook, and simply by editing the CSS, you can completely change the way it displays -- you wouldn't even have to open the ebook if the CSS were well-documented.



m a r

I think this is a matter of preference. Some people prefer indirect formatting (such as modifying the CSS to achieve formatting changes elsewhere in the document), while others prefer direct formatting (such as using the B or STRONG tags to make the text darker).

One of the reasons I tend to prefer direct formatting is based on my experience with styles in word processing. Although styles do make some formatting tasks easier (such as changing the font for certain parts of the ebooks), my experience has been that sometimes it takes more work to achieve a simple effect with indirect formatting.

I think that a good ebook format should allow the user the option of both direct and indirect formatting as well as a mixture of the two depending on the user's preference. To me, the key is to have consistent rules when tagging text.

[Terisa de morgan]

Well, my problem is: I don't write the ePub, I only edit the ePub Calibre creates for making look better at Stanza.

[AlexBell]

Originally Posted by rogue_ronin

That <span class="....> stuff is bad XHTML. The simplest way to do those is with <em> (emphasis) and <strong>. If you're seeing a lot of <span...>, it's because of the overuse of Word, and other programs that insert a lot of cruft.

I absolutely definitely could not disagree more. Or to put it another way I think the statement above totally incorrect.

I was designing websites long before I got into ebooks, and when designing websites settled happily into the habit of always checking that my XHTML and CSS were consistent with World Wide Web Consortium (W3C) standards - doing so very much increased the chances that my websites would display consistently on different browsers.

ePub is based on XHTML version 1.1 - it's right there in the specs. How can one expect to get consistent presentations if one does not live up to the basic fundamental standards of XHTML?

I know there are fudges and work arounds, and I know that they work sometimes. But in my opinion the first step in getting ePubs to appear consistently well in a range of readers is to get the original XHTML to meet standards.

I also accept without hesitation that it would be good to set up other standards - margin width etc - and that it would be good to find out how many people prefer serif rather than non-serif fonts, how many people prefer justified rather than ragged right margins, how many people prefer margins separated by an empty line and how many by paragraph indent, and so on.

But let's start from the basics. In my opinion the basic tool for writing a good, consistent ePub book is a good HTML editor and to get that XHTML to meet W3C standards.

Finally, and a little off topic, for website designers CSS is your friend, and external CSS is your best friend. It is dead simple to remove the empty line between paragraphs with CSS, set it once, and do it consistently.

Regards, Alex

[swr2408018]

I see some value in both perspectives here. Certainly Word (for example), generates css and html with a lot of boilerplate code. For purposes of conversion to ePub, one could eliminate most of that. And if you are trying to edit the raw code, it is arguably simpler to use the deprecated tags, and the result is much clearer at the local code level. However, if an ePub document uses well-chosen CSS boilerplate, it becomes much easier to globally modify important settings across the scope of the entire book. I think this is the direction we'd like the industry to take (and the direction we should take in authoring ePub books ourselves.)

Here's why I say that: as I'm reading this and some similar threads on other forums, there is a lot of interest in being able to personalize ebooks. Some people prefer wide margins (like physical books); others want little or no margin (minimize page turns). Some people like serif fonts; others not. Indented paragraphs versus space-separated paragraphs. Left justification versus full justification. Running page headers versus none.

For these features to be easily configured by a savvy reader, they need to be set in a standardized way in the CSS code so that we can quickly unpackage, tweak, and repackage an ePub (assuming this is not DRM-blocked.) Let's call this re-authoring personalization.

To be easily configured by a mainstream reader, they also need to be set in a standardized way in the CSS code so that the reader software/firmware knows exactly what to override at reading time. Let's call this runtime personalization.

Personalization may only be an "enthusiast" issue, however, the new B&N PC reader software actually exposes several of these choices as Settings-->Reading Preferences, and this suggests that there is broader interest in personalizing the reading experience (well beyond, say, the Sony software's size option):

Font
Text Size
Line Spacing
Margin (Slider)
Full Justification (Checkbox)
Underline Links (Checkbox)
Text Color
Selection Color

This raises two questions:

1) Can any nook owners say which if any of these personalization features are exposed on the reader device?

2) Has anyone experimented with how these settings interact with CSS and HTML settings? I suspect they simply override the book content, and while this will work for a lot of content, it may break some cases (e.g., if a user's chosen font is proportional and some of the content requires a non-proportional font.) To provide a better experience, the runtime personalization should be defined to only impact some set of identifiable styles.

Having a great cross-platform personalization story is going to require another full round of standardization around how to use CSS. The reading platforms (both hardware and software) will have to synch up on what features should be configurable, and the publishers will have to agree on how those features are driven by CSS, and then author conformant content. In the interim I can well imagine different vendors offering a variety of personalization options that are implemented by overriding book content.

Some of the folks on these forums are involved in both implementing reader software and authoring content. Would it make sense for them to come up with a strawman personalization proposal that developers and publishers could opt into using?

Steve

[John F]

Originally Posted by 6charlong

... When Sony switched to ePub I returned to their store and re-downloaded it. When I opened it on the 505, the first thing I got was the spinner (it’s the time-delay notice Sony Readers use) and the message: “Reformatting”. I had never seen that before. I was surprised when it finally came up with fully formatted margins and the same attractive formatting the book had in LRX.

...

Are you saying the 505 had fully justified text for EPub? I didn't think this was the case. Can anyone else verify this?

[Elfwreck]

EPubs look different for the same reason that websites look different: no two people, companies, or programs assigns HTML the same way.

And we're at the equivalent of 1998 for ePubs. Remember what the web looked like about ten years ago? Blinky backgrounds; all-left-justified text on pages, "back to top" links scattered around at random; accidental unclosed tags so the entire second half of a page was bold? Followed by "edgy" pages with black backgrounds and red text that scrolled over the background? And pages that tried hard to match how printed books work--200-400 words on a page with a "next" button?

We're seeing the equivalent with epubs. No standards, lots of tags but no control over the browsers, many companies insisting "you should read our books on our software & hardware, and if it sucks on other devices, you're reading it wrong."

[calvin-c]

Originally Posted by Solitaire1

I think this is a matter of preference. Some people prefer indirect formatting (such as modifying the CSS to achieve formatting changes elsewhere in the document), while others prefer direct formatting (such as using the B or STRONG tags to make the text darker).

One of the reasons I tend to prefer direct formatting is based on my experience with styles in word processing. Although styles do make some formatting tasks easier (such as changing the font for certain parts of the ebooks), my experience has been that sometimes it takes more work to achieve a simple effect with indirect formatting.

I think that a good ebook format should allow the user the option of both direct and indirect formatting as well as a mixture of the two depending on the user's preference. To me, the key is to have consistent rules when tagging text.

Question: who's doing the tagging? As a programmer I see a strong analogy between styles & objects (as in object oriented programming). Both take a long time to develop so they work properly in all situations-and it's much easier to just 'apply consistent rules' every time you need to do whatever it is the object (or style) would do.

But programmers not only work in teams, but programs are also passed along from one programmer to the next. (That is, if I leave this job the programs I wrote will remain-and it'll be up to the next programmer to make any changes that are needed.) So something I've also learned is that rules are only applied consistently when there's only one person applying them. Introduce more people into the process and you get inconsistent application of rules.

Converting to objects was hard, but worthwhile. The rules are now embedded in the objects & it no longer matters who uses the objects-the rules are now applied consistently. I suspect the same would be true of tagging. For a single-person operation, rules can be applied consistently & don't require the effort needed to properly develop styles. But if the process has different people applying the tags, then I suspect styles would give the best results.

[Terisa de morgan]

Originally Posted by Elfwreck

EPubs look different for the same reason that websites look different: no two people, companies, or programs assigns HTML the same way.

And we're at the equivalent of 1998 for ePubs. Remember what the web looked like about ten years ago? Blinky backgrounds; all-left-justified text on pages, "back to top" links scattered around at random; accidental unclosed tags so the entire second half of a page was bold? Followed by "edgy" pages with black backgrounds and red text that scrolled over the background? And pages that tried hard to match how printed books work--200-400 words on a page with a "next" button?

We're seeing the equivalent with epubs. No standards, lots of tags but no control over the browsers, many companies insisting "you should read our books on our software & hardware, and if it sucks on other devices, you're reading it wrong."

[rogue_ronin]

Originally Posted by AlexBell

I absolutely definitely could not disagree more. Or to put it another way I think the statement above totally incorrect.

I think we might actually be somewhat in agreement. By "bad" XHTML, I meant "vague and lazy", not "incorrect". <span...> is, of course, perfectly correct and to spec. I should have been less vague and lazy.

My argument is that <em> and <strong> are both valid XHTML, and are "direct" and easily comprehensible -- unlike a lot of the <span...> tags containing redundant and difficult to understand styles that are exported by programs like Word.

Originally Posted by AlexBell

ePub is based on XHTML version 1.1 - it's right there in the specs. How can one expect to get consistent presentations if one does not live up to the basic fundamental standards of XHTML?

I know there are fudges and work arounds, and I know that they work sometimes. But in my opinion the first step in getting ePubs to appear consistently well in a range of readers is to get the original XHTML to meet standards.

True. And the second step is for the readers to display it correctly.

Originally Posted by AlexBell

But let's start from the basics. In my opinion the basic tool for writing a good, consistent ePub book is a good HTML editor and to get that XHTML to meet W3C standards.

Yup. I believe that we get most of the junk because of the natural desire to find a shortcut. Quick conversions, or rough unedited exports lead to this ugly stuff. 'Course, you're starting see it in pbooks too, due to cost-cutting and profit maximization, but the expectations still remain higher, at least for now.

Originally Posted by AlexBell

Finally, and a little off topic, for website designers CSS is your friend, and external CSS is your best friend. It is dead simple to remove the empty line between paragraphs with CSS, set it once, and do it consistently.

That's where I'm coming from; a well-tagged document and a clearly commented CSS ought to be our reality, not our dream. As you say, "set it once" -- in other words, it actually improves editing and layout by eliminating the possibility of missing something (assuming good structural tagging.)

Originally Posted by swr2408018

I see some value in both perspectives here. Certainly Word (for example), generates css and html with a lot of boilerplate code. For purposes of conversion to ePub, one could eliminate most of that. And if you are trying to edit the raw code, it is arguably simpler to use the deprecated tags, and the result is much clearer at the local code level. However, if an ePub document uses well-chosen CSS boilerplate, it becomes much easier to globally modify important settings across the scope of the entire book. I think this is the direction we'd like the industry to take (and the direction we should take in authoring ePub books ourselves.)

I sort-of agree with you about the deprecated tags, but what tags are we discussing? Italic, bold, center, justify and left? Color?

The replacement tags can be as simple as adding <em>, <strong>, class="center", and class="justify".

It's similar for images. Basic, (very basic) layout is not terrifically more complicated than it was -- I'd like to see us help folks understand it, and for folks to not be shy to ask about it.

(Money at my mouth: feel free to PM me with any questions about this stuff -- I'm no expert, but the basics are not too hard. I was intimidated when I started, too.)

Originally Posted by swr2408018

(...snip...)

For these features to be easily configured by a savvy reader, they need to be set in a standardized way in the CSS code so that we can quickly unpackage, tweak, and repackage an ePub (assuming this is not DRM-blocked.)

(...snip...)

This would be great -- it's basically an XHTML microformat for the ebook (like FB2 is for XML). The side effect is that it doesn't merely affect ePubs, it becomes the root format for conversion to any other format.

I actually put a bunch of work into such a set of standards for my own formatting. It's highly unlikely that anyone else will ever use it, but it does make changing the display ridiculously easy.

What this means, though, is that you are creating an archive format -- the one source that you use when you convert for the limitations of your reading device. Consider Calibre; Calibre is an awesome tool that can make your life simpler and keep you happy -- but the ePubs that it creates, even from a well-tagged XHTML source, are not easily editable and comprehensible. It does what it does for good reason (flow sizes, automation, etc.) and it makes good-enough ebooks.

If there were an industry-wide set of CSS and XHTML standards, I bet that Calibre (or other tools) would ultimately try to abide by it. And manually changing ePubs would be less challenging.

Originally Posted by swr2408018

This raises two questions:

(...snip...)

CSS has always had a sort of override: CSS is trumped by a <style> header, a <style> header is trumped by directly applied styles, and directly applied styles are trumped by display engine personal settings.

It's just a matter of the software/readers behaving to standards.

Originally Posted by Elfwreck

EPubs look different for the same reason that websites look different: no two people, companies, or programs assigns HTML the same way.

And we're at the equivalent of 1998 for ePubs.

(...snip...)

We're seeing the equivalent with epubs. No standards, lots of tags but no control over the browsers, many companies insisting "you should read our books on our software & hardware, and if it sucks on other devices, you're reading it wrong."

100% in agreement. It's actually the natural order of things -- everybody is grabbing what they can, and not looking to either history or a future ideal. Or rather, they may be doing that, but not looking for the lessons and ideals that we are -- ie: transparent and easily customizable formats, beauty, etc.

m a r

[6charlong]

Originally Posted by John F

Are you saying the 505 had fully justified text for EPub? I didn't think this was the case. Can anyone else verify this?

I plugged the Sony in and discovered I had both the LRX and ePub versions of the book on it. I deleted the LRX and started the ePub and it is ragged right.

Apologies.

[Solitaire1]

Originally Posted by calvin-c

Question: who's doing the tagging? As a programmer I see a strong analogy between styles & objects (as in object oriented programming). Both take a long time to develop so they work properly in all situations-and it's much easier to just 'apply consistent rules' every time you need to do whatever it is the object (or style) would do.

But programmers not only work in teams, but programs are also passed along from one programmer to the next. (That is, if I leave this job the programs I wrote will remain-and it'll be up to the next programmer to make any changes that are needed.) So something I've also learned is that rules are only applied consistently when there's only one person applying them. Introduce more people into the process and you get inconsistent application of rules.

Converting to objects was hard, but worthwhile. The rules are now embedded in the objects & it no longer matters who uses the objects-the rules are now applied consistently. I suspect the same would be true of tagging. For a single-person operation, rules can be applied consistently & don't require the effort needed to properly develop styles. But if the process has different people applying the tags, then I suspect styles would give the best results.

Based on what you wrote, it seems like styles (for word processing) correspond to objects (for programming). If so, this could be very usable as long as there are some clear, simple, and consistent rules are established when formatting the ebook.

An ebook style guide that everyone agrees to follow would help to make this a reality. Once it becomes a firmly established tradition, that will provide an incentive for ebook formatters to follow that tradition since ebooks that don't follow that format will seem to look odd (nothing actually wrong, but it looks different that what has come to be expected). It is much like form that printed books currently take is the result of centuries of experience in formatting books.

One of the things that I like about HTML as an ebook format is that it is long established and can be easily mastered after only a small amount of study. The addition of CSS provides formatting control that HTML lacks. A combination of the two should be able to provide all of the formatting needed for an ebook.

[calvin-c]

Originally Posted by Solitaire1

Based on what you wrote, it seems like styles (for word processing) correspond to objects (for programming). If so, this could be very usable as long as there are some clear, simple, and consistent rules are established when formatting the ebook.

An ebook style guide that everyone agrees to follow would help to make this a reality. Once it becomes a firmly established tradition, that will provide an incentive for ebook formatters to follow that tradition since ebooks that don't follow that format will seem to look odd (nothing actually wrong, but it looks different that what has come to be expected). It is much like form that printed books currently take is the result of centuries of experience in formatting books.

One of the things that I like about HTML as an ebook format is that it is long established and can be easily mastered after only a small amount of study. The addition of CSS provides formatting control that HTML lacks. A combination of the two should be able to provide all of the formatting needed for an ebook.

You've got the nutshell, including the *long* time it takes to develop adequate styles (or objects). FYI, object-oriented programming was developed in the early 90's-and is only new being widely used. And even then, most of the 'use' doesn't take advantage of object-oriented programming features-the programmers are doing the same old code in 'the new language'. This would be, I think, like writing HTML with CSS, but the CSS only contains a couple of the most common styles-everything else is coded inline.

I hadn't actually thought about having industry-wide consistency. Programming is, pretty much, company-specific so I just hadn't thought in those terms. I suspect you're right-centuries of experience will be needed for that.

[rogue_ronin]

Originally Posted by calvin-c

You've got the nutshell, including the *long* time it takes to develop adequate styles (or objects).

Given the relative speed of society and technology, it will take less time, I think -- certainly not centuries. A decade or two, is my guess.

Originally Posted by calvin-c

This would be, I think, like writing HTML with CSS, but the CSS only contains a couple of the most common styles-everything else is coded inline.

I hadn't actually thought about having industry-wide consistency. Programming is, pretty much, company-specific so I just hadn't thought in those terms. I suspect you're right-centuries of experience will be needed for that.

Company-specific would be fine; you'd see several basic styles develop (a la Chicago Manual of Style, etc.)

As long as they're not designed to work around the flaws of currently dominant software/firmware, they would be welcome.

On another topic: could you flesh out your ideas about style? From my reading of your words, it looks to me that 'objects' in your analogy are closer to 'structure'. ie: a clear element naming-scheme in the XHTML that is then manipulated by CSS.

m a r

[Xenophon]

Originally Posted by calvin-c

You've got the nutshell, including the *long* time it takes to develop adequate styles (or objects). FYI, object-oriented programming was developed in the early 90's-and is only new being widely used. And even then, most of the 'use' doesn't take advantage of object-oriented programming features-the programmers are doing the same old code in 'the new language'. This would be, I think, like writing HTML with CSS, but the CSS only contains a couple of the most common styles-everything else is coded inline.

I hadn't actually thought about having industry-wide consistency. Programming is, pretty much, company-specific so I just hadn't thought in those terms. I suspect you're right-centuries of experience will be needed for that.

I generally concur. But it's worse than you think: Object oriented programming was developed in the mid-60's (do a search on "Simula" or "Simula-67"; or the history of SmallTalk, or...). It was popularized in the early '90s, and spent a solid decade as the software equivalent of 'I've got a hammer, so I'll treat every problem I encounter as a nail' -- even when the problem was a screw. We've not yet reached a point where OOP is used where it makes sense, but is avoided where that makes better sense.

Xenophon
(speaking in my professional capacity, for once)

[EowynCarter]

Every p-book is diffrent, i like ePub presisly because book can have differants formating, fonts and all.