which format will win?

[DawnFalcon]

Originally Posted by Elfwreck

And the more verbose the coding, the longer the book takes to load.

Untrue. Badly untrue, and indeed I'd call this an urban legend.

In some cases, additional verbosity can lead to slower load times. However, there are many causes where the direct opposite is true - by being specific, you can eliminate areas where the software has to look up defaults, make assumptions based on other data and generally "decide what to do".

For example, handling inheritance in CSS is often extremely slow, since there are multiple, often conflicting rules which must be applied. While something like XPath is overkill, a better defined inheritance model - which would almost certainly be more verbose - would be considerably faster.

(Also, CSS is not code, it's script!)

[guyanonymous]

Originally Posted by DawnFalcon

(Also, CSS is not code, it's script!)

Feels like it's in code sometimes! Where's my CSS-Enigma machine to help me figure things out when stuff doesn't work as planned?

[guyanonymous]

Here's a timely article from Smashing Magazine: "The Future Of CSS Typography".

http://www.smashingmagazine.com/2010...uture-of-text/

[DawnFalcon]

"One of the most common CSS-related mistakes made by budding Web designers is creating inflexible style sheets that have too many classes and IDs and that are difficult to maintain."

Heh. One of the common mistakes web designers make when they gain a bit of experience is not defining enough and trying to rely on CSS's inheritance rules. Several experienced web designers I've worked with prefer to specify everything by managing the CSS creation with their own scripts - it's the only way to get things working properly (not to mention generating the different style sheets you need for each browser layout engine (the three different IE style sheets...))

When people resort to that sort of hackery, you know something is up. Sigh.

[kennyc]

Originally Posted by guyanonymous

Here's a timely article from Smashing Magazine: "The Future Of CSS Typography".

http://www.smashingmagazine.com/2010...uture-of-text/

CSS should die.

[gwynevans]

Originally Posted by orwell2k

I like to view the ePub (English/US) vs FB2 (Russian) eBook situation as an analogy with something from the old space race days. The problem was to solve how to write in zero-G environments. NASA poured millions into creating the Zero-G pen - a sealed pen that could pump the ink to the tip to allow writing in zero-G. This is the ePub equivalent - it has all the bells and whistles but is extremely complex and expensive and prone to failure. The Russian solution is FB2 - use a pencil - it does what you need, has the necessary design features, and works well!

Just to correct the above, the development was a private project by the owner of the pen company and not charged to NASA.

'Fisher did ultimately develop a pressurized pen for use by NASA astronauts (now known as the famous "Fisher Space Pen"), but both American and Soviet space missions initially used pencils, NASA did not seek out Fisher and ask them to develop a "space pen," Fisher did not charge NASA for the cost of developing the pen, and the Fisher pen was eventually used by both American and Soviet astronauts.'

See
http://history.nasa.gov/spacepen.html, http://www.thespacereview.com/article/613/1 and http://www.snopes.com/business/genius/spacepen.asp for more info.

[DawnFalcon]

Beat you to it (end of the post) :P

[orwell2k]

Originally Posted by DawnFalcon

Um, orwell, ePub's XHTML. There's not a massive amount of difference to chose from between the formats, you realise? Yes, the ePub renderers on devices need improving, but that doesn't reflect on the standards specification itself!

What you're talking about with fonts and CSS is perfectly possible for ePub - and the more advanced renderers such as Bookworm do that and more (MathML, embedded video, etc.)

Yes I understand that, and you're right the problem is primarily the renderers at the moment. But clearly there is a major problem if the format has all that capability, and the renderers fail to use it or worse, block the capability (or provide no access to use it).

The similarity of the formats is one thing, and I firmly believe ePub has potential to become an excellent format, but at the moment it is, for my reading purposes, somewhere between annoying and useless. This is primarily down to the capability I am used to with reading FB2. Anyone who has not used FB2 will not miss the capability, hence ePub probably seems good. But for me ePub, and Mobi, are both a step backwards in terms of the flexibility and ease with which I can read FB2 format books.

The one area where that is not true is with linking, as I have not found a way to follow links when reading FB2 books. But I work around this by placing footnotes and so on near the marked text when I create the book. I think, to be honest, this is another renderer issue as the format seems to support links, so it could be placed in the same class as most of the current ePub issues.

FB2 was never going to be a viable choice - it was not developed by the movers and shakers with a stake in the business end of eBooks (such as Adobe) and I guess in many ways it's also getting old now (10+ years or so?).

I am extremely biased - I don't think I've ever hidden that fact - as FB2 was my first real eBook format and as such I probably have sentimental as well as practical reasons to love it. But love it, I do, and I'm yet to find a good reason to move away from it - every other format is easily convertible to FB2, so perhaps in the end the "winning" format is somewhat irrelevant so long as the tools remain to allow users to read any format they wish? The ultimate in flexibility...

[Solitaire1]

Originally Posted by DawnFalcon

Untrue. Badly untrue, and indeed I'd call this an urban legend.

In some cases, additional verbosity can lead to slower load times. However, there are many causes where the direct opposite is true - by being specific, you can eliminate areas where the software has to look up defaults, make assumptions based on other data and generally "decide what to do".

For example, handling inheritance in CSS is often extremely slow, since there are multiple, often conflicting rules which must be applied. While something like XPath is overkill, a better defined inheritance model - which would almost certainly be more verbose - would be considerably faster.

(Also, CSS is not code, it's script!)

The reason I mentioned verbosity is to avoid ambiguity and confusion. However, there are ways to reduce the amount of code needed while still avoiding confusion and ambiguity.

One way via the use of commonly established defaults. The only time coding is needed is if it isn't the default. As an example, the default is one blank line between each paragraph (the amount of space is determined by the font in use), but this can easily be changed from this starting point. But if the default is fine no coding is needed.

Another way that might work even better is to avoid formatting within the ebook itself. Instead, the parts of the ebook are tagged to indicate what they are (such as Main Body, Chapter Heading, Page Header, and Page Footer) without any indication how they are to be displayed. This is one of the ideas behind CSS (separating the formatting of the text from what the text is).

The way the text will be displayed is handled by the ebook reader itself via a set of display defaults (such setting the reader to display the Main Body in Times New Roman 12 point with a 36 point indent on the first line of each paragraph and no blank space after the paragraph). The advantage of this is that the same ebook can be used on various ereaders, and each reader can be set to display the text in a manner suitable for it. It also avoids the problem of some types of formatting (such as full justification, and certain fonts) not being available since it's an issue of the ereader, not the ebook format.

[orwell2k]

Originally Posted by Solitaire1

The reason I mentioned verbosity is to avoid ambiguity and confusion. However, there are ways to reduce the amount of code needed while still avoiding confusion and ambiguity.

One way via the use of commonly established defaults. The only time coding is needed is if it isn't the default. As an example, the default is one blank line between each paragraph (the amount of space is determined by the font in use), but this can easily be changed from this starting point. But if the default is fine no coding is needed.

Another way that might work even better is to avoid formatting within the ebook itself. Instead, the parts of the ebook are tagged to indicate what they are (such as Main Body, Chapter Heading, Page Header, and Page Footer) without any indication how they are to be displayed. This is one of the ideas behind CSS (separating the formatting of the text from what the text is).

The way the text will be displayed is handled by the ebook reader itself via a set of display defaults (such setting the reader to display the Main Body in Times New Roman 12 point with a 36 point indent on the first line of each paragraph and no blank space after the paragraph). The advantage of this is that the same ebook can be used on various ereaders, and each reader can be set to display the text in a manner suitable for it. It also avoids the problem of some types of formatting (such as full justification, and certain fonts) not being available since it's an issue of the ereader, not the ebook format.

All good points, and one more reason I use FB2. The file is only concerned with content, and the display and formatting is handled by the reader, which is usually tailored for the device. So reading the same book on a PocketBook360 (5" display) and an Irex DR1000S (10" display) will obviously result in different formatting, different fonts (types as well as sizes), and so on.