What format to store books in? What software to read them with? - Page 2

kovidgoyal · 12-26-2007, 01:31 PM

.lit is basically a zip file with individual HTML/TXT and css files with metadata and optional support for DRM. It's basically epub lite.

.mobi/.prc is also basically a HTML container with support for metadata and DRM. Unfortunately it's even worse that .lit since it defines a proprietary extension to HTML.

.lrf is the compiled version of an XML based format (.lrs). Unfortunately the XML is used in a non-semantic way so it is not a good format for long term storage. However, it is the best supported ebook format at the moment.

Your best bet is to convert the book to XHTML and metadata to OPF. Package it all up in a zip file and your good to convert to any format in the future. Do not become dependent on proprietary formats or formats supported by a single app (like HTML0 the BD format, which is really just extremely crappy HTML). If you go the extra mile and make your zipped up HTML + OPF files into an .epub you can use the openberg firefox extension to view the ebooks on any platform.

Liviu_5 · 12-26-2007, 02:31 PM

Quote:

Originally Posted by kovidgoyal

.
Your best bet is to convert the book to XHTML and metadata to OPF. Package it all up in a zip file and your good to convert to any format in the future.

In principle yes, but in practice it depends on your time, number of books, tech expertise and so on. It's a big difference when you have 10 e-books in various formats, vs thousands upon thousands...

Also it depends on the value of the e-book for you, how likely you are to reread it, where...

This is why despite not being optimal, html and rtf are useful, since there are tons of free batch converters, where you give a command after minimal preparation and the computer does the work.

nairbv · 12-26-2007, 07:11 PM

I'll clarify my requirements a bit...

My feelings on one-file=one-book: I understand that some formats are actually zip files containing a bunch of other files. This is fine, .. I just don't want to have to think about it excessively. If convertLit made a zip file (and maybe it didn't have a .zip extension) and there was some reading software that I open that zip file in to open/read/convert the book, great.

If I need to write a script that calls convertLit, zips the directory, and renames the zip-file as somebook.epub or something else, ... I can handle that, .. but I'm not sure exactly what the appropriate extension is, or why the convertLIT program doesn't do this for me, or what exactly the resulting file type is, or what programs I can use to convert and read that file type in the future.

kovidgoyal: you say "If you go the extra mile and make your zipped up HTML + OPF files into an .epub" ... so is HTML+OPF the thing that convertLIT makes? does "going the extra mile" just mean renaming the file as .epub, or is more involved? Are there programs like convertLIT to do this for pdb/mobi files, HTML, txt, etc? (obviously conversion from txt/html/etc wouldn't automatically add unknown meta data, but maybe would just create a stub that I could edit later... or maybe would have command line options to add the data if I"m converting a directory of books all by the same author).

Plain RTF, TXT, or HTML won't do, because I'm not willing to abandon the information stored in my original files. If I convert a .lit file to .txt or rtf and delete my .lit file, ... then I know that in the future when I want to read it, I won't be able to tell my device "go to chapter 23" and have it know what I mean. Pictures will be lost. Author/ISBN/publisher and any other metadata information stored in the original file will be lost. When I convert my books, I'm not willing to lose that much data. I think that eventually itunes / Photo Gallery type software will be out to organize ebooks based on tags, genres, authors, etc. I want to retain the tags so I can use those programs when they're available.

One more thing is that I can't really open every single file and export it individually through BD. ... I mean, ... it's hundreds of books. It'd just take too long.

Also, I still just don't really understand why they've created the open format the way they have. Can anyone explain to me why the open standard format uses HTML to store the books, as opposed to just using a simple XML format? What's the advantage of HTML that wouldn't be easier in XML? Display information? Does a book really need that much display information? I don't want a book full of div tags and javascript and width="someNumberBiggerThanMyDisplay." I want the txt, maybe in a defined file-format like unicode so I know all my books are the same, and I want something like structural XML to break up chapters, say where pictures go, and add meta data. Is there some advantage or necessity I'm not seeing here? I guess occasionally making little bits of text bold or italic might be an issue, but it's not one that HTML handles wonderfully either.

My understanding of HTML is that it's inherently structural data, with display information hacked on to make it pretty for the web. We try to take out the display information with stuff like CSS. The structural data communicated by HTML is web specific, and not so appropriate for ebooks, hence having to add an XML file to an ebook format. So what do we retain in HTML? Display information? something it's not that wonderfully suited to and which isn't incredibly relevant for ebooks anyways?

I AM willing to lose funny unnecessary formatting information that I would presumably select on my device anyways, ... stuff like font sizes etc.

I mean, it also seems like it would make sense if every time you converted to the "open-standard-format," ... the resulting file should be approximately the same. If you have to convert to HTML, then two different conversion programs are going to write very different HTML.

Maybe there are some crazy looking colorful fun kids books that need to look like the original paper book, and so it's easier to just use complete HTML to have that kind of support?

Also, why are there so many acronyms for this thing? It's so confusing... opf and ops and epub and oeb and oebps and idpf and ocf???? OK I understand that some might be organizations and some might be file extensions and some might be standards for various files in the zipped up file blah blah blah. ..... but cmon, are they just trying to confuse us? How is the average user supposed to figure out if he has the right kind of file?? and then a directory might be the right kind of "file" too?

sorry for the rant, ... I'm just trying to understand all this, ... and maybe miss understanding something involved?

DaleDe · 12-26-2007, 07:19 PM

Quote:

Originally Posted by nairbv

I'll clarify my requirements a bit...

My feelings on one-file=one-book: I understand that some formats are actually zip files containing a bunch of other files. This is fine, .. I just don't want to have to think about it excessively. If convertLit made a zip file (and maybe it didn't have a .zip extension) and there was some reading software that I open that zip file in to open/read/convert the book, great.

If I need to write a script that calls convertLit, zips the directory, and renames the zip-file as somebook.epub or something else, ... I can handle that, .. but I'm not sure exactly what the appropriate extension is, or why the convertLIT program doesn't do this for me, or what exactly the resulting file type is, or what programs I can use to convert and read that file type in the future.

kovidgoyal: you say "If you go the extra mile and make your zipped up HTML + OPF files into an .epub" ... so is HTML+OPF the thing that convertLIT makes? does "going the extra mile" just mean renaming the file as .epub, or is more involved? Are there programs like convertLIT to do this for pdb/mobi files, HTML, txt, etc? (obviously conversion from txt/html/etc wouldn't automatically add unknown meta data, but maybe would just create a stub that I could edit later... or maybe would have command line options to add the data if I"m converting a directory of books all by the same author).

Plain RTF, TXT, or HTML won't do, because I'm not willing to abandon the information stored in my original files. If I convert a .lit file to .txt or rtf and delete my .lit file, ... then I know that in the future when I want to read it, I won't be able to tell my device "go to chapter 23" and have it know what I mean. Pictures will be lost. Author/ISBN/publisher and any other metadata information stored in the original file will be lost. When I convert my books, I'm not willing to lose that much data. I think that eventually itunes / Photo Gallery type software will be out to organize ebooks based on tags, genres, authors, etc. I want to retain the tags so I can use those programs when they're available.

One more thing is that I can't really open every single file and export it individually through BD. ... I mean, ... it's hundreds of books. It'd just take too long.

Also, I still just don't really understand why they've created the open format the way they have. Can anyone explain to me why the open standard format uses HTML to store the books, as opposed to just using a simple XML format? What's the advantage of HTML that wouldn't be easier in XML? Display information? Does a book really need that much display information? I don't want a book full of div tags and javascript and width="someNumberBiggerThanMyDisplay." I want the txt, maybe in a defined file-format like unicode so I know all my books are the same, and I want something like structural XML to break up chapters, say where pictures go, and add meta data. Is there some advantage or necessity I'm not seeing here? I guess occasionally making little bits of text bold or italic might be an issue, but it's not one that HTML handles wonderfully either.

My understanding of HTML is that it's inherently structural data, with display information hacked on to make it pretty for the web. We try to take out the display information with stuff like CSS. The structural data communicated by HTML is web specific, and not so appropriate for ebooks, hence having to add an XML file to an ebook format. So what do we retain in HTML? Display information? something it's not that wonderfully suited to and which isn't incredibly relevant for ebooks anyways?

I AM willing to lose funny unnecessary formatting information that I would presumably select on my device anyways, ... stuff like font sizes etc.

I mean, it also seems like it would make sense if every time you converted to the "open-standard-format," ... the resulting file should be approximately the same. If you have to convert to HTML, then two different conversion programs are going to write very different HTML.

Maybe there are some crazy looking colorful fun kids books that need to look like the original paper book, and so it's easier to just use complete HTML to have that kind of support?

Also, why are there so many acronyms for this thing? It's so confusing... opf and ops and epub and oeb and oebps and idpf and ocf???? OK I understand that some might be organizations and some might be file extensions and some might be standards for various files in the zipped up file blah blah blah. ..... but cmon, are they just trying to confuse us? How is the average user supposed to figure out if he has the right kind of file?? and then a directory might be the right kind of "file" too?

sorry for the rant, ... I'm just trying to understand all this, ... and maybe miss understanding something involved?

epub uses a subset of xhtml for the file or perhaps dtbook. xhtml is an xml file with a predefined dtd. XML means absolutely nothing with a defining file that tells you how to interpret the data. There is no such thing as a simple xml file. It has to be parsed to be used and that requires a parser that understands it. check ePUB in the wiki for more details on the various file formats in ePUB and other type of documents. There all documented to some degree in the wiki.

html itself is a kind of xml these days although it breaks some of the rules of a well designed xml file. xhtml is html that does obey the xml rules. Enjoy the wiki and then come back and ask questions.

Dale

nairbv · 12-26-2007, 07:23 PM

oops,.. I hit the submit button too many times and reposted so editing my post to remove the re-posted text.

nairbv · 12-26-2007, 07:30 PM

dalede: I know there would have to be a dtd regardless. By "simple" I just meant "simpler," not some specific imaginary undefined XML format.

It just seems to me like the full xhtml spec is overkill for ebook purposes. Maybe it's easier than starting from scratch but...

nairbv · 12-26-2007, 08:03 PM

ah... I just saw that you said "a *subset* of xhtml." That makes a lot more sense regarding my concerns of ease of parsing. I'm reading the wiki now and it also explains this point. Thanks.

I guess I should try to make epub my storage format... I'm still not sure how I get there using convertLIT though or whatever other software for the other formats...

Is there some kind of epub validator program? I mean, ... it sounds like I can just run convertLIT and zip the directory and rename the zip file .epub, and thus have an epub file? but I"m not sure if I'm supposed to add other files or something too? ...and I'm assuming that if I do it wrong, .. the file will still open just fine in the programs that read epub files just because they're probably written somewhat flexibly. So, is there a way to make sure I've done it correctly? Or command-line conversion programs that actually create complete/correct .epub files?

thanks

nairbv · 12-26-2007, 08:31 PM

i just found the epubcheck tool and added a link for it to the wiki.

DaleDe · 12-27-2007, 12:53 AM

Quote:

Originally Posted by nairbv

i just found the epubcheck tool and added a link for it to the wiki.

Good, thanks.

Dale

nairbv · 12-27-2007, 06:18 AM

".mobi/.prc is also basically a HTML container with support for metadata and DRM. Unfortunately it's even worse that .lit since it defines a proprietary extension to HTML."

I kind of like that actually in some senses (though I don't like that the extensions are hacked onto otherwise standard HTML). but .. I mean, ... it's stuff that makes sense in a book. It makes sense that a book should contain varying image sizes for varying ebook readers, ... or that an ebook should have a tag to skip to the next page. I think I would have preferred if epub had started from scratch and written up DTD's for an independent XML format that wasn't trying to conform to the not-so-book-optimized xhtml standard.

Separating chapters seems to require multiple HTML files. A from-scratch design would probably have a chapter tag, so the whole book could fit in one XML file that had the text of the whole book and all the meta data. Things like the mobi-extensions wouldn't seem like out of place hacks. Tags for headers and footers at the book or chapter level could be smoothly integrated. A quick short simple xslt or other script could quickly and easily convert to HTML if needed, and so things like firefox plugins and converters wouldn't really be any more difficult to write... I think it would be easier to write conversion software actually, and that such a format would preserve more of the essentially book-like information.

I just read the wiki on mobipocket files. I think the "guidelines" listed for creating a mobipocket book make sense. It seems like by letting people just write HTML, book authors are encouraged to write books as if they were writing a web page... specifying fonts and font sizes, using messes of nested and fixed with tables, .. Who knows? maybe even wacky javascript code to try to swap for device-appropriate image sizes? A stricter format could force book-authors to create books in a more consistent, simple, sensible way.

I haven't looked at how much of the xhtml spec is actually supported though. .. dale did say "a subset" ... and ... that does make me feel a lot better about it.

and... I probably will go with the epub format. It's not like I see a better alternative. I'm just ... whining I guess.

Oh ,.... and I noticed a script to convert the result of convertLIT into an epub book. This looks cool, ... it was in this thread:
https://www.mobileread.com/forums/showthread.php?t=11784

I'll probably use that with convertLIT to standardize on epub files. I guess... maybe you are right though about the suckyness of the mobi extensions-to-html, if they mean I can't do the same thing with mobi files. not that I was really saying I liked the idea of extensions to html either though...

... but, ... Why are there all these files (book designer install, and this conversion tool), that are only available as links in threads? Is there a way to store them in the wiki? It's hard to find files searching through threads, trying to find what page of the thread the file is on, ... and then trying to go through every page looking to see if there's been a updated version uploaded. Can we do something about that somehow?

nairbv · 12-27-2007, 06:18 AM

ugh.. my browser double-sent again somehow. I think it's cuz my proxy crapped out as I posted. Anyways, I'm just editing out the text of my second copy of an identical post, to remove clutter.

DaleDe · 12-27-2007, 10:28 AM

Quote:

Originally Posted by nairbv

... but, ... Why are there all these files (book designer install, and this conversion tool), that are only available as links in threads? Is there a way to store them in the wiki? It's hard to find files searching through threads, trying to find what page of the thread the file is on, ... and then trying to go through every page looking to see if there's been a updated version uploaded. Can we do something about that somehow?

I think that collecting the information stuff and tools out of the threads and placing them in the wiki is a good idea. It should be the first source for new users and reserve the forum to discuss the topics rather than document them.

I just takes effort to get everything where it belongs so this is an ongoing project. We need to get some guidelines defined.

Dale

kovidgoyal · 12-27-2007, 11:05 AM

The reason (I'm guessing) idpf went with xhtml is to ease adoption. There is a lot of code already out to deal with HTML. A new DTD would mean having to re-write a lot of code from scratch and chances are the new format would never catch on. Also XHTML gives the author more power and flexibility which isa good thing. STraitjacketing people for their own good is not the right approach.

derrell · 12-27-2007, 06:54 PM

Just read through the thread and I have been doing the same thing. Hunting around for a format to store all of my books in that is easily converted to others. I think I've settled on leaving them as oeb.
https://wiki.mobileread.com/wiki/Open_eBook
FBReader will read these, as a zip file, and they are also easy to convert back into a lit or a mobi pocket file or epub, its also easy to convert the html files into a plucker file which is what I use on my palm devices to read books. Never could get any of the mobi versions to work on my Sony Clie's without crashing.

nairbv · 12-28-2007, 02:46 AM

kovidgoyal:

A custom XML format would reduce to HTML with a very short/simple xsl script. Extra code wouldn't really be involved since the spec would provide an (obviously device customizable) xsl script that converted the whole thing to HTML in a consistent way. I'm not sure you'd even see a difference in how the browser rendered it.

And it's not like this means providing a special program everyone has to rely on. XSL stylesheets are pretty standard formating. I'm pretty sure it's a w3c standard. It's more like a default (but overridable) stylesheet, that would sort of go hand-in-hand with the DTD.

Look at, for example: http://www.w3schools.com/xml/simplexsl.xml
here, XML holding very specific customized data renders just fine in firefox, because it looks up the xsl stylesheet and internally converts to HTML (if you view source you'll just see XML). (example link came from http://www.w3schools.com/xml/xml_xsl.asp)

As a *base* format I think it would make more sense because of the advantages of being able to store all the data, all in the most practical way, but the software reader would still interpret it as HTML or XHTML or TXT or however you told it to interpret it, and because it would have the fastest and easiest means of conversion to other formats.

I feel like by hanging onto html standards they don't make writing of tools any easier, .. and if anything makes it more difficult because the epub files ends up so messy. ... and all at the expense of sacrificing our ability to store inherently bookish data.

Also, it's not about straight-jacketing people, it's about making sure it's easy to parse out relevant data. If someone's writing up some custom browser and doesn't want to support all of HTML for example, they can support a subset. Epub may have chosen a subset of XHTML to address this complexity issue, but it's a rigid subset. If they had chosen a purer XML, they could have left it up to the users (reader software developers and parser writers who minorly tweak the xsl stylesheeet) to decide what subsets *they* wanted to support. I think this would inherently add flexibility not straight-jacketing.

It would even benefit advertisers and such (not that I'm advocating helping them), since a minor tweak in the XSL could throw advertisements or anything else into a margin on the page. With the whole book stored in HTML, how do you go about adding non-book related information on the display end? It would have to be in a separate window of some sort. Less flexible.

Also, it's about reducing confusion. I don't know that much about epub, but it seems that someone creating an epub file might unthinkingly put a chapter title in an h1 tag, or in some HTML meta-data tag, or in some epub meta tag, or in the HTML's title tag, or even just add it in bold text at the start of a chapter. ... There are dozens of issues like this that would be resolved with a more rigid, consistent, purpose driven format. If you think giving someone one and only one place to store a title is "straight-jacketing" then I guess we just disagree. Of course there might be multiple titles types like "chapter 1" vs "section 1" etc, and then the actual title of the chapter, but the just mentioned distinction in data to be stored for a title represents that much more how a purpose driven XML would be better suited to storing the data in a non-confusing manner.

I know I'm stuck with epub for now, and this is all just theoretical, ... but I feel like what I'm suggesting would have made more sense. I'm not seeing any arguments that convince me otherwise.

12-26-2007, 07:23 PM	#20
nairbv Connoisseur Posts: 88 Karma: 15 Join Date: Nov 2007 Device: still looking for an ebook reader device	oops,.. I hit the submit button too many times and reposted so editing my post to remove the re-posted text. Last edited by nairbv; 12-26-2007 at 07:27 PM. Reason: repost

12-27-2007, 06:18 AM	#26
nairbv Connoisseur Posts: 88 Karma: 15 Join Date: Nov 2007 Device: still looking for an ebook reader device	ugh.. my browser double-sent again somehow. I think it's cuz my proxy crapped out as I posted. Anyways, I'm just editing out the text of my second copy of an identical post, to remove clutter. Last edited by nairbv; 12-27-2007 at 06:21 AM. Reason: accidental double-post.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Can a JBL read Fictionwise's multi-format books?	GA Russell	Ectaco jetBook	16	06-01-2010 10:32 PM
Looking for reading software on Android that will read Epub format	CJBarrow	Reading and Management	1	04-14-2010 03:28 PM
can we read books from the sony store ( or formerly sony store) and read them in the	SDRebel	Astak EZReader	27	01-22-2010 01:27 AM
Buuying books on the amazon store to read on Sony prs-505	Mayr	Sony Reader	3	10-08-2009 03:10 AM
What format do you like to "Store" your books in?	askyn	Workshop	11	10-16-2008 01:22 PM

12-26-2007, 01:31 PM	#16
kovidgoyal creator of calibre Posts: 43,826 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	.lit is basically a zip file with individual HTML/TXT and css files with metadata and optional support for DRM. It's basically epub lite. .mobi/.prc is also basically a HTML container with support for metadata and DRM. Unfortunately it's even worse that .lit since it defines a proprietary extension to HTML. .lrf is the compiled version of an XML based format (.lrs). Unfortunately the XML is used in a non-semantic way so it is not a good format for long term storage. However, it is the best supported ebook format at the moment. Your best bet is to convert the book to XHTML and metadata to OPF. Package it all up in a zip file and your good to convert to any format in the future. Do not become dependent on proprietary formats or formats supported by a single app (like HTML0 the BD format, which is really just extremely crappy HTML). If you go the extra mile and make your zipped up HTML + OPF files into an .epub you can use the openberg firefox extension to view the ebooks on any platform.

12-26-2007, 07:11 PM	#18
nairbv Connoisseur Posts: 88 Karma: 15 Join Date: Nov 2007 Device: still looking for an ebook reader device	I'll clarify my requirements a bit... My feelings on one-file=one-book: I understand that some formats are actually zip files containing a bunch of other files. This is fine, .. I just don't want to have to think about it excessively. If convertLit made a zip file (and maybe it didn't have a .zip extension) and there was some reading software that I open that zip file in to open/read/convert the book, great. If I need to write a script that calls convertLit, zips the directory, and renames the zip-file as somebook.epub or something else, ... I can handle that, .. but I'm not sure exactly what the appropriate extension is, or why the convertLIT program doesn't do this for me, or what exactly the resulting file type is, or what programs I can use to convert and read that file type in the future. kovidgoyal: you say "If you go the extra mile and make your zipped up HTML + OPF files into an .epub" ... so is HTML+OPF the thing that convertLIT makes? does "going the extra mile" just mean renaming the file as .epub, or is more involved? Are there programs like convertLIT to do this for pdb/mobi files, HTML, txt, etc? (obviously conversion from txt/html/etc wouldn't automatically add unknown meta data, but maybe would just create a stub that I could edit later... or maybe would have command line options to add the data if I"m converting a directory of books all by the same author). Plain RTF, TXT, or HTML won't do, because I'm not willing to abandon the information stored in my original files. If I convert a .lit file to .txt or rtf and delete my .lit file, ... then I know that in the future when I want to read it, I won't be able to tell my device "go to chapter 23" and have it know what I mean. Pictures will be lost. Author/ISBN/publisher and any other metadata information stored in the original file will be lost. When I convert my books, I'm not willing to lose that much data. I think that eventually itunes / Photo Gallery type software will be out to organize ebooks based on tags, genres, authors, etc. I want to retain the tags so I can use those programs when they're available. One more thing is that I can't really open every single file and export it individually through BD. ... I mean, ... it's hundreds of books. It'd just take too long. Also, I still just don't really understand why they've created the open format the way they have. Can anyone explain to me why the open standard format uses HTML to store the books, as opposed to just using a simple XML format? What's the advantage of HTML that wouldn't be easier in XML? Display information? Does a book really need that much display information? I don't want a book full of div tags and javascript and width="someNumberBiggerThanMyDisplay." I want the txt, maybe in a defined file-format like unicode so I know all my books are the same, and I want something like structural XML to break up chapters, say where pictures go, and add meta data. Is there some advantage or necessity I'm not seeing here? I guess occasionally making little bits of text bold or italic might be an issue, but it's not one that HTML handles wonderfully either. My understanding of HTML is that it's inherently structural data, with display information hacked on to make it pretty for the web. We try to take out the display information with stuff like CSS. The structural data communicated by HTML is web specific, and not so appropriate for ebooks, hence having to add an XML file to an ebook format. So what do we retain in HTML? Display information? something it's not that wonderfully suited to and which isn't incredibly relevant for ebooks anyways? I AM willing to lose funny unnecessary formatting information that I would presumably select on my device anyways, ... stuff like font sizes etc. I mean, it also seems like it would make sense if every time you converted to the "open-standard-format," ... the resulting file should be approximately the same. If you have to convert to HTML, then two different conversion programs are going to write very different HTML. Maybe there are some crazy looking colorful fun kids books that need to look like the original paper book, and so it's easier to just use complete HTML to have that kind of support? Also, why are there so many acronyms for this thing? It's so confusing... opf and ops and epub and oeb and oebps and idpf and ocf???? OK I understand that some might be organizations and some might be file extensions and some might be standards for various files in the zipped up file blah blah blah. ..... but cmon, are they just trying to confuse us? How is the average user supposed to figure out if he has the right kind of file?? and then a directory might be the right kind of "file" too? sorry for the rant, ... I'm just trying to understand all this, ... and maybe miss understanding something involved?

12-26-2007, 07:30 PM	#21
nairbv Connoisseur Posts: 88 Karma: 15 Join Date: Nov 2007 Device: still looking for an ebook reader device	dalede: I know there would have to be a dtd regardless. By "simple" I just meant "simpler," not some specific imaginary undefined XML format. It just seems to me like the full xhtml spec is overkill for ebook purposes. Maybe it's easier than starting from scratch but...

12-26-2007, 08:03 PM	#22
nairbv Connoisseur Posts: 88 Karma: 15 Join Date: Nov 2007 Device: still looking for an ebook reader device	ah... I just saw that you said "a subset of xhtml." That makes a lot more sense regarding my concerns of ease of parsing. I'm reading the wiki now and it also explains this point. Thanks. I guess I should try to make epub my storage format... I'm still not sure how I get there using convertLIT though or whatever other software for the other formats... Is there some kind of epub validator program? I mean, ... it sounds like I can just run convertLIT and zip the directory and rename the zip file .epub, and thus have an epub file? but I"m not sure if I'm supposed to add other files or something too? ...and I'm assuming that if I do it wrong, .. the file will still open just fine in the programs that read epub files just because they're probably written somewhat flexibly. So, is there a way to make sure I've done it correctly? Or command-line conversion programs that actually create complete/correct .epub files? thanks

12-26-2007, 08:31 PM	#23
nairbv Connoisseur Posts: 88 Karma: 15 Join Date: Nov 2007 Device: still looking for an ebook reader device	i just found the epubcheck tool and added a link for it to the wiki.

12-27-2007, 11:05 AM	#28
kovidgoyal creator of calibre Posts: 43,826 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	The reason (I'm guessing) idpf went with xhtml is to ease adoption. There is a lot of code already out to deal with HTML. A new DTD would mean having to re-write a lot of code from scratch and chances are the new format would never catch on. Also XHTML gives the author more power and flexibility which isa good thing. STraitjacketing people for their own good is not the right approach.

12-27-2007, 06:54 PM	#29
derrell Jack O' Apes Posts: 227 Karma: 1939 Join Date: Dec 2007 Location: Oklahoma Device: Ebookwise 1150, Nokia N810, EZ-Reader, HTC Droid Incredible, Archos 70	Just read through the thread and I have been doing the same thing. Hunting around for a format to store all of my books in that is easily converted to others. I think I've settled on leaving them as oeb. https://wiki.mobileread.com/wiki/Open_eBook FBReader will read these, as a zip file, and they are also easy to convert back into a lit or a mobi pocket file or epub, its also easy to convert the html files into a plucker file which is what I use on my palm devices to read books. Never could get any of the mobi versions to work on my Sony Clie's without crashing.

12-28-2007, 02:46 AM	#30
nairbv Connoisseur Posts: 88 Karma: 15 Join Date: Nov 2007 Device: still looking for an ebook reader device	kovidgoyal: A custom XML format would reduce to HTML with a very short/simple xsl script. Extra code wouldn't really be involved since the spec would provide an (obviously device customizable) xsl script that converted the whole thing to HTML in a consistent way. I'm not sure you'd even see a difference in how the browser rendered it. And it's not like this means providing a special program everyone has to rely on. XSL stylesheets are pretty standard formating. I'm pretty sure it's a w3c standard. It's more like a default (but overridable) stylesheet, that would sort of go hand-in-hand with the DTD. Look at, for example: http://www.w3schools.com/xml/simplexsl.xml here, XML holding very specific customized data renders just fine in firefox, because it looks up the xsl stylesheet and internally converts to HTML (if you view source you'll just see XML). (example link came from http://www.w3schools.com/xml/xml_xsl.asp) As a base format I think it would make more sense because of the advantages of being able to store all the data, all in the most practical way, but the software reader would still interpret it as HTML or XHTML or TXT or however you told it to interpret it, and because it would have the fastest and easiest means of conversion to other formats. I feel like by hanging onto html standards they don't make writing of tools any easier, .. and if anything makes it more difficult because the epub files ends up so messy. ... and all at the expense of sacrificing our ability to store inherently bookish data. Also, it's not about straight-jacketing people, it's about making sure it's easy to parse out relevant data. If someone's writing up some custom browser and doesn't want to support all of HTML for example, they can support a subset. Epub may have chosen a subset of XHTML to address this complexity issue, but it's a rigid subset. If they had chosen a purer XML, they could have left it up to the users (reader software developers and parser writers who minorly tweak the xsl stylesheeet) to decide what subsets they wanted to support. I think this would inherently add flexibility not straight-jacketing. It would even benefit advertisers and such (not that I'm advocating helping them), since a minor tweak in the XSL could throw advertisements or anything else into a margin on the page. With the whole book stored in HTML, how do you go about adding non-book related information on the display end? It would have to be in a separate window of some sort. Less flexible. Also, it's about reducing confusion. I don't know that much about epub, but it seems that someone creating an epub file might unthinkingly put a chapter title in an h1 tag, or in some HTML meta-data tag, or in some epub meta tag, or in the HTML's title tag, or even just add it in bold text at the start of a chapter. ... There are dozens of issues like this that would be resolved with a more rigid, consistent, purpose driven format. If you think giving someone one and only one place to store a title is "straight-jacketing" then I guess we just disagree. Of course there might be multiple titles types like "chapter 1" vs "section 1" etc, and then the actual title of the chapter, but the just mentioned distinction in data to be stored for a title represents that much more how a purpose driven XML would be better suited to storing the data in a non-confusing manner. I know I'm stuck with epub for now, and this is all just theoretical, ... but I feel like what I'm suggesting would have made more sense. I'm not seeing any arguments that convince me otherwise.

Advert

Advert