Capabilities of different formats

[atsoat]

I have been buying Microsoft Reader or mobipocket files from fictionwise/booksonboard/cyberread and then converting them to .lrf files to load onto my Sony PRS-505. I have not bought an eReader format book yet, despite their additional discount at fictionwise.

I'm curious as to whether there is any significant difference in the capabilities of these different formats - i.e. are there any features that are available in one format that are not available in others?

If there are significantly different capabilities, then do publishers actually make use of any of these features, or generally speaking will the same book look and behave similarly regardless of the purchased format?

I suppose what I'm really asking is, should I be preferring one format over another when purchasing books from a technical perspective?

[llasram]

Originally Posted by atsoat

I suppose what I'm really asking is, should I be preferring one format over another when purchasing books from a technical perspective?

This question seems to come up pretty often... If you you look around you can find several threads on this top.

The short answer is that eReader is definitely the worst -- eReader books use a very limited, proprietary, non-SGML markup language called "PML". Mobipocket uses HTML 3.0 with proprietary extensions while LIT uses a somewhat confused subset of OEBPS 1.0, which has markup somewhere between HTML 4.0 and XHTML with a hybrid/subset of CSS 1 & 2. The upshot is that LIT content is more technically advanced and easier to work with at a markup level (for example, it is forced to follow XML well-formedness rules), but most people may not notice much of a difference between the two.

Hope that helps.

[Jellby]

Mobipocket does not support CSS, the set of HTML tags it supports can be found here.

[AlexBell]

Originally Posted by Jellby

Mobipocket does not support CSS, the set of HTML tags it supports can be found here.

Actually, Mobipocket does support some CSS, erratically and not up to W3C standards.

I've been exploring what CSS Mobipocket does support, and am working on a Test Suite.mobi which imports an external CSS file. I know that
<p class="bold"> for example works, as well as other formatting options.

Regards, Alex

[llasram]

Originally Posted by AlexBell

I've been exploring what CSS Mobipocket does support, and am working on a Test Suite.mobi which imports an external CSS file. I know that <p class="bold"> for example works, as well as other formatting options.

Are you generating the Mobipocket book with mobigen? In which case it's mobigen which understands CSS, not the Mobipocket renderer.

[DaleDe]

Originally Posted by llasram

This question seems to come up pretty often... If you you look around you can find several threads on this top.

The short answer is that eReader is definitely the worst -- eReader books use a very limited, proprietary, non-SGML markup language called "PML".

Actually while eReader is non-standard it has the best support for extended characters of any of the formats out there. So if this is important it is a good format.

[llasram]

Originally Posted by DaleDe

Actually while eReader is non-standard it has the best support for extended characters of any of the formats out there. So if this is important it is a good format.

I assume by "extended characters" you just mean characters not in the Unicode Latin script? In which case I don't believe this is really true. On the encoding end, all the current major e-book formats allow the encoding of any Unicode character. On the display end, even if granting that the glyph complement in the eReader default font set is larger than others, it still doesn't include glyphs for all Unicode characters -- that requires font embedding, which AFAIK is currently only supported by EPUB, BBeB, and Topaz.

[DaleDe]

Originally Posted by llasram

I assume by "extended characters" you just mean characters not in the Unicode Latin script? In which case I don't believe this is really true. On the encoding end, all the current major e-book formats allow the encoding of any Unicode character. On the display end, even if granting that the glyph complement in the eReader default font set is larger than others, it still doesn't include glyphs for all Unicode characters -- that requires font embedding, which AFAIK is currently only supported by EPUB, BBeB, and Topaz.

NO, see special characters in the wiki for a comparison. They are in the unicode set but many tools only support a very small subset, basically not much more than ASCII. Of course embedding can include anything you need.

Dale

[Jellby]

Originally Posted by DaleDe

Actually while eReader is non-standard it has the best support for extended characters of any of the formats out there. So if this is important it is a good format.

I've used &xxxx; codes in mobipocket format for accented letters, Cyrillic script, punctuation... with no problem. I sort of assume it would work for anything, as long as I use a font that has the correct glyphs.

[AlexBell]

Originally Posted by llasram

Are you generating the Mobipocket book with mobigen? In which case it's mobigen which understands CSS, not the Mobipocket renderer.

No, I write my own XHTML file and import it into Mobipocket Creator with its external CSS file. Then I build the file and out comes a prc file.

Pardon my ignorance, but I don't even know what mobigen is.

Regards, Alex

[llasram]

Originally Posted by AlexBell

Pardon my ignorance, but I don't even know what mobigen is.

Oh, no worries! 'Mobigen' is Mobipocket's command-line tool for doing what you describe doing with Mobipocket Creator -- creating a Mobipocket book from XHTML, OEB, etc. content. As I'm pretty sure it's the same code under the hood, same difference in this case -- it's mobigen / Mobipocket Creator which understands CSS and converts XHTML+CSS into the HTML 3.0ish markup (with no CSS) the Mobipocket renderer understands.

[DaleDe]

Originally Posted by llasram

Oh, no worries! 'Mobigen' is Mobipocket's command-line tool for doing what you describe doing with Mobipocket Creator -- creating a Mobipocket book from XHTML, OEB, etc. content. As I'm pretty sure it's the same code under the hood, same difference in this case -- it's mobigen / Mobipocket Creator which understands CSS and converts XHTML+CSS into the HTML 3.0ish markup (with no CSS) the Mobipocket renderer understands.

Even MobiGen is very selective in what it understands about CSS. Mostly it does not work well with a separate file but will understand inline statements. The latest Windows Reader will do translations of ePUB which typically needs CSS but I am not sure if it has the same verision mobigen under the hood as the one you get when you download MobiCreator.

Dale

[AlexBell]

Originally Posted by DaleDe

Even MobiGen is very selective in what it understands about CSS. Mostly it does not work well with a separate file but will understand inline statements. The latest Windows Reader will do translations of ePUB which typically needs CSS but I am not sure if it has the same verision mobigen under the hood as the one you get when you download MobiCreator.

Dale

Again, I don't agree. Admittedly I haven't done a lot of work in this area, but my impression is that mobigen/Mobipocket Creator works at least as well with an external CSS file as they do with local CSS.

Either way, my original post was to oppose the statement that Mobipocket does not understand CSS. Whether its through mobigen or Mobipocket Creator or something else under the hood I still think that Mobipocket does understand some CSS, though it is erratic and not up to W3C standards.

Regards, Alex

[tompe]

Originally Posted by AlexBell

Either way, my original post was to oppose the statement that Mobipocket does not understand CSS. Whether its through mobigen or Mobipocket Creator or something else under the hood I still think that Mobipocket does understand some CSS, though it is erratic and not up to W3C standards.

That is like saying that a program displaying a text file understand CSS just because there are programs that can convert a file using CSS to a text file. In the MobiPocket format you cannot represent the information available in a HTML file plus CSS. And it is nearly always tha format you are referring to when you say MobiPocket.

[HarryT]

Originally Posted by tompe

That is like saying that a program displaying a text file understand CSS just because there are programs that can convert a file using CSS to a text file. In the MobiPocket format you cannot represent the information available in a HTML file plus CSS. And it is nearly always tha format you are referring to when you say MobiPocket.

If the tool that one uses to create the MobiPocket file understandards CSS, what practical difference does it make whether or not the CSS elements actually end up in the created file or not?