View Single Post
Old 06-20-2009, 01:29 PM   #17
DaleDe
Grand Sorcerer
DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.
 
DaleDe's Avatar
 
Posts: 11,470
Karma: 13095790
Join Date: Aug 2007
Location: Grass Valley, CA
Device: EB 1150, EZ Reader, Literati, iPad 2 & Air 2, iPhone 7
Quote:
Originally Posted by wallcraft View Post
If MobiPocket was still an independent company I think it would be busy extending the MOBI format to allow it to display all (or most) of the ePub format. This would not fix the "don't render the markup correctly" issue, since this is the entire point of the MobiPocket approach, but it would allow MOBI to compete on a more or less level playing field going forward.

One way of looking at ePub is that it is a single target for publishers. This is how it is apparently viewed in the UK for example. An extended MOBI format does not break this approach, because ePub is the source but on the device you get MOBI. Just as today, the source is an OEB 1.0 ebook and the target is MOBI.

Another way of looking at ePub as at the reading device level, with the argument that reading devices are getting more powerful all the time and so can render ePub directly. Mobile ADE is the only current implementation of that approach. If FictionWise actually switches from eReader to ePub it will be (or might be) the 2nd. Note that other "ePub" software on handhelds is not even close to conforming to the standard (I'm not sure about Stanza, but I think it is in the largely non-conforming category). In most cases, if a small-screen device also supports MOBI then using Calibre for ePub to MOBI first will give a better result on the screen.
Mobipocket already has a converter for ePUB as the source format and does even support some CSS in the creation process but removes it in the final format. So it can use ePUB as a publisher source although I don't think it is currently as good as it could be.

As a reading device Adobe is not the only game in town although it may have the best rendering currently. Hanlin can read ePUB and FBReader can also. FBReader is better than Hanlin but both are available. ZuluReader for Windows Mobile devices is coming along nicely these days. I agree that converting to Mobi is much better on a Hanlin device than reading ePUB.

I agree with the original author on most of what he says but towards the end when he says Mobi displays wrong but still displays. This is a function of the Reader itself and not the format of the data. This trick would work with almost any format if you simply ignored the format and rendered the data until you could sync up.

His comments on Lit are interesting. Hanlin can render LIT but the performance is terrible. Now I better understand why. I actually like LIT for its rendering ability and built in image viewing on later readers. As all the eBook Readers move to 400 MegaHertz processors this will be improved I believe. The new power management can allow this without giving up too much battery life.

CSS can be unbearably complicated with all the multi-levels and overrides. This is the reality of CSS and makes rendering difficult. Faster processors will help but some better coding guidelines I think would help even more. It needn't be as complicated as it is for eBooks.

Dale
DaleDe is offline   Reply With Quote