I observed a bunch of things in the PG collection that were somewhere between maddening deficiencies in quality and simply how I wouldn't have done things. I could have made inflammatory demands that the whole system be rewrought according to my word. Instead I came up with my own custom DVD. And I'll testify that MH in discussing the idea was annoyingly non-paternalistic in not telling me how it had to be. ;) So, when someone complains, it is great when they can just go fix something themselves. There's the story of the king who demanded the whole world be covered in soft leather to keep his foot from being struck on a stone. Maybe someone should come up with a custom DVD with all the good works in EPUB format. I would respect PG if it were to refuse to host any and all of these bleeding edge formats. But I would love to be given the authority to create a raw text format without the 80-char line breaks. I agree that having these breaks (in the only TXT format available ) makes them unusable. The first-time visitor to PG probably won't be impressed that tools may be available to fix it.
On Sat, 5 Dec 2009, Greg M. Johnson wrote:
I observed a bunch of things in the PG collection that were somewhere between maddening deficiencies in quality and simply how I wouldn't have done things. I could have made inflammatory demands that the whole system be rewrought according to my word. Instead I came up with my own custom DVD.
By the way, Greg Newby is still anxiously awaiting some snail mail or instructions on downloading this or other collections you have!!!
And I'll testify that MH in discussing the idea was annoyingly non-paternalistic in not telling me how it had to be. ;)
I'm afraid this is the major complaint I receive. . .that I won't tell people what to do unless and until they totally go out of their way to convince me-- and even then they don't seem to like it very much.
So, when someone complains, it is great when they can just go fix something themselves. There's the story of the king who demanded the whole world be covered in soft leather to keep his foot from being struck on a stone. Maybe someone should come up with a custom DVD with all the good works in EPUB format.
We have had any number of people come up with wonderful alternatives!!! Let's have more!!!
I would respect PG if it were to refuse to host any and all of these bleeding edge formats. But I would love to be given the authority to create a raw text format without the 80-char line breaks. I agree that having these breaks (in the only TXT format available ) makes them unusable. The first-time visitor to PG probably won't be impressed that tools may be available to fix it.
On Sat, Dec 05, 2009 at 12:01:47PM -0500, Greg M. Johnson wrote:
I observed a bunch of things in the PG collection that were somewhere between maddening deficiencies in quality and simply how I wouldn't have done things. I could have made inflammatory demands that the whole system be rewrought according to my word. Instead I came up with my own custom DVD. And I'll testify that MH in discussing the idea was annoyingly non-paternalistic in not telling me how it had to be. ;)
And encouraging you to "just do it!" :)
So, when someone complains, it is great when they can just go fix something themselves. There's the story of the king who demanded the whole world be covered in soft leather to keep his foot from being struck on a stone. Maybe someone should come up with a custom DVD with all the good works in EPUB format.
Doable, I think. The XML/RDF catalog does include EPUB links, though they are not part of the static collection.
I would respect PG if it were to refuse to host any and all of these bleeding edge formats.
But we do host them...it's just that we're generating them on demand, which has numerous practical benefits for the producers, and is close to transparent for the human readers.
But I would love to be given the authority to create a raw text format without the 80-char line breaks.
Everyone can do that. Reformatting is permitted, as part of the license. http://www.gutenberg.org/wiki/Gutenberg:Permission_How-To
I agree that having these breaks (in the only TXT format available ) makes them unusable. The first-time visitor to PG probably won't be impressed that tools may be available to fix it.
That's why we provide MOBI, EPUB and other formats on demand. That way, the readers just need to click the chosen link. 80-character lines are only one of the choices. -- Greg
But we do host them...it's just that we're generating them on demand, which has numerous practical benefits for the producers, and is close to transparent for the human readers.
Three problems with the "on demand" approach [which in general I like] 1) It doesn't do the "spine" stuff right like TOC and covers. 2) If the "on demand" has problems with the generated results you ought to let people submit versions of those file formats that do work, and those submissions ought to override the "on demand" stuff until if and when the "on demand" version gets fixed. 3) It would be nice if you could provide a version of your conversion tools to PG "authors" so that they could work to make the submitted HTML work correctly with the conversion tools. Right now we "authors" are guestimating to the results of the "on demand" outputs by cross-compiling the HTML to EPUB and MOBI using one of a variety of non-PG conversion tools -- and then submitting the HTML to PG when that works -- which seems kind of silly given that we are actually targeting the unseen PG tools.
James Adcock wrote:
But we do host them...it's just that we're generating them on demand, which has numerous practical benefits for the producers, and is close to transparent for the human readers.
Three problems with the "on demand" approach [which in general I like]
1) It doesn't do the "spine" stuff right like TOC and covers.
It builds the TOC from your HTML headers. If the TOC doesn't come out right its because your HTML header structure is a mess.
2) If the "on demand" has problems with the generated results you ought to let people submit versions of those file formats that do work, and those submissions ought to override the "on demand" stuff until if and when the "on demand" version gets fixed.
That's another (binary) file for the WWers to maintain ... A better solution is to repost a HTML file that works. Convert to XHTML 1.1 and leave fancy formatting out.
3) It would be nice if you could provide a version of your conversion tools to PG "authors" so that they could work to make the submitted HTML work correctly with the conversion tools. Right now we "authors" are guestimating to the results of the "on demand" outputs by cross-compiling the HTML to EPUB and MOBI using one of a variety of non-PG conversion tools -- and then submitting the HTML to PG when that works -- which seems kind of silly given that we are actually targeting the unseen PG tools.
http://www.gutenberg.org/tools/epubmaker-0.02-preview-2009-11-26.tgz -- Marcello Perathoner webmaster@gutenberg.org
1) It doesn't do the "spine" stuff right like TOC and covers.
It builds the TOC from your HTML headers. If the TOC doesn't come out right its because your HTML header structure is a mess.
Sorry, I have yet to see a MOBI or EPUB automatic conversion that actually contains a conforming TOC. Can you give me an example automatic conversion book# that works the way you say it does?
Jim Adcock wrote:
1) It doesn't do the "spine" stuff right like TOC and covers.
It builds the TOC from your HTML headers. If the TOC doesn't come out right its because your HTML header structure is a mess.
Sorry, I have yet to see a MOBI or EPUB automatic conversion that actually contains a conforming TOC. Can you give me an example automatic conversion book# that works the way you say it does?
Give me an example where the HTML headers are structured well and the TOC comes out wrong. I mean this way: h1 Title by Author h2 Chapter 1 h2 Chapter 2 If the TOCs are all messed up its the fault of DP: They use headers everywhere they need a bigger font. -- Marcello Perathoner webmaster@gutenberg.org
If the TOCs are all messed up its the fault of DP: They use headers everywhere they need a bigger font.
Sorry, we are talking past each other -- I have yet to see a PG epub or mobi file which even has a TOC -- its not a question of whether or not that TOC is any good. Here's what I mean: I take my epub or mobi reader software, I push the dedicated button on that software to take me to the TOC. Does pushing that button take me to the TOC in a PG epub or mobi file? No. Why not? The epub or mobi file doesn't actually contain a TOC. It may contain TEXT somewhere inside the doc that says "Table of Contents", but in an epub or mobi file that is not the same thing as actually having a TOC. In a conforming mobi or epub file the TOC is specified in the "spine" file, not in the text contents file. Again, am I missing something, or can you show me ANY automatically generated PG epub or mobi file where pushing the "TOC" button on my epub or mobi reader software actually takes me to the TOC?
Jim Adcock wrote:
Again, am I missing something, or can you show me ANY automatically generated PG epub or mobi file where pushing the "TOC" button on my epub or mobi reader software actually takes me to the TOC?
ALL PG epub files have a TOC. Unzip them and look for a file toc.ncx. -- Marcello Perathoner webmaster@gutenberg.org
ALL PG epub files have a TOC. Unzip them and look for a file toc.ncx.
I stand corrected. The PG epubs do include a TOC. The PG mobis do not include a TOC. How come? I can take your epubs and file format translate them to mobis, for example by Calibre2 ebook-convert, and the resulting mobi DOES have a TOC. So why do the PG generated mobis do not have a TOC ?
James Adcock wrote:
ALL PG epub files have a TOC. Unzip them and look for a file toc.ncx.
I stand corrected.
The PG epubs do include a TOC.
The PG mobis do not include a TOC.
How come?
I can take your epubs and file format translate them to mobis, for example by Calibre2 ebook-convert, and the resulting mobi DOES have a TOC.
So why do the PG generated mobis do not have a TOC ?
Better ask mobipocket. We use their official 'mobigen' conversion tool for linux. -- Marcello Perathoner webmaster@gutenberg.org
So why do the PG generated mobis do not have a TOC ?
Better ask mobipocket. We use their official 'mobigen' conversion tool for linux.
Mobipocket is Amazon. The latest version of mobigen is called kindlegen at: http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000234621 Not that that seems to help any. Supposedly it has better support now for NCX but that didn't cause it to create a TOC for me. What did "work" for me was either of the following two approaches: 1) Use Calibre ebook-convert instead of mobigen. Apply it to either your epub or your opf and it generates a book including TOC. You'd need to check of course that it doesn't introduce other problems for you. Or: 2) I CAN generate a TOC using kindlegen and using your opf (extracted from your epub files) when I perform the following changes: a) in your opf explicitly add a toc.htm file <manifest> ... <item href="toc.htm" id="item8" media-type="application/xhtml+xml"/> ... </manifest> And <guide> <reference href="cover.jpg" type="cover" title="Cover Image"/> <reference type="toc" title="Table of Contents" href="toc.htm" /> </guide> Where then the toc.htm contains basically the same information you are already generating for the toc.ncx except in html format -- which then begs the question what "support" for NCX actually means? But in any case taking this approach (which you can see is also the approach taken in the worked "Sample" book example distributed with kindlegen) creates a MOBI file with TOC support as users would expect.
Sorry, also just got an Amazon email pointing me to this doc: http://s3.amazonaws.com/kindlegen/AmazonKindlePublishingGuidelinesV1.3.pdf where page 11 it says: TOC guideline #1: the Logical TOC (NCX) is mandatory The Logical Table Of Contents is very important for our mutual customer's reading experience as it allows them to easily navigate between chapters on Kindle 2. So all Kindle books should have both logical and HTML TOCs. Users expect to see an HTML TOC when paging through a book from the beginning, while the logical table of contents is an additional way for users to navigate books. So indeed they want both the toc.ncx and the toc.htm -- still haven't figured out what they think they are doing with the toc.ncx! -----Original Message----- From: gutvol-d-bounces@lists.pglaf.org [mailto:gutvol-d-bounces@lists.pglaf.org] On Behalf Of James Adcock Sent: Monday, February 01, 2010 11:02 AM To: 'Project Gutenberg Volunteer Discussion' Subject: [gutvol-d] Re: Formats and gripes
So why do the PG generated mobis do not have a TOC ?
Better ask mobipocket. We use their official 'mobigen' conversion tool for linux.
Mobipocket is Amazon. The latest version of mobigen is called kindlegen at: http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000234621 Not that that seems to help any. Supposedly it has better support now for NCX but that didn't cause it to create a TOC for me. What did "work" for me was either of the following two approaches: 1) Use Calibre ebook-convert instead of mobigen. Apply it to either your epub or your opf and it generates a book including TOC. You'd need to check of course that it doesn't introduce other problems for you. Or: 2) I CAN generate a TOC using kindlegen and using your opf (extracted from your epub files) when I perform the following changes: a) in your opf explicitly add a toc.htm file <manifest> ... <item href="toc.htm" id="item8" media-type="application/xhtml+xml"/> ... </manifest> And <guide> <reference href="cover.jpg" type="cover" title="Cover Image"/> <reference type="toc" title="Table of Contents" href="toc.htm" /> </guide> Where then the toc.htm contains basically the same information you are already generating for the toc.ncx except in html format -- which then begs the question what "support" for NCX actually means? But in any case taking this approach (which you can see is also the approach taken in the worked "Sample" book example distributed with kindlegen) creates a MOBI file with TOC support as users would expect. _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
James Adcock wrote:
2. So all Kindle books should have both logical and HTML TOCs. Users expect to see an HTML TOC when paging through a book from the beginning, while the logical table of contents is an additional way for users to navigate books.
As most PG ebooks already contain a TOC inside the HTML, its pointless to generate another one. -- Marcello Perathoner webmaster@gutenberg.org
As most PG ebooks already contain a TOC inside the HTML, its pointless to generate another one.
Sigh, you are going around in circles. The issue is that you are generating MOBI files that do not correctly implement the TOC standard of MOBI files. The result of this is that when a user of a PG file clicks on the dedicated "TOC" button on their e-reader device, the MOBI file you generate fails to take them to the TOC. This is a file format failure on the part of the file format YOU are generating. Yes, the HTML files that the creator of the PG book often also contain a "TOC" in HTML format. IF, for example, you were to generate a toc.htm pointing to the "TOC" already in one of the books' HTML files and correctly link that toc.htm to your opf file, THEN when the PG user clicks on the dedicated "TOC" button in their ebook reader then that TOC button WOULD correctly function and it would take them to the TOC the user has already generated in one of their html files. Or alternatively, if they have already created a file called toc.htm you could just link to that correctly as required in the opf file and everything would work. Or, if you are generating a TOC in NCX format you could with trivial changes also generate a toc.htm which you could correctly link into the opf file and then the TOC button would also work. Or you could use Calibre ebook-convert software which would do this automatically for you and again everything would actually work. But, instead you continue to pimp the resulting MOBI file format because YOU think YOU should be the one to choose which devices PG users should be reading on, rather than generating valid files in the file formats that PG customers need to read on the devices they already own. I think this is silly. Let the marketplace decide. If Amazon acts in an onerous way to customers then customers will choose to buy from Apple and read in EPUB format. If Apple acts in an onerous way to customers then customers will choose to buy from Amazon and will read in MOBI format. Having the choice helps drive the e-book vendors into less onerous behavior -- hopefully! -- So far all that Apple has succeeded in doing is driving up the price for new releases for all ebook readers from $9.99 to $15.99 -- thanks Jobs, that's quite an accomplishment! -----Original Message----- From: gutvol-d-bounces@lists.pglaf.org [mailto:gutvol-d-bounces@lists.pglaf.org] On Behalf Of Marcello Perathoner Sent: Monday, February 01, 2010 11:57 AM To: Project Gutenberg Volunteer Discussion Subject: [gutvol-d] Re: Formats and gripes James Adcock wrote:
2. So all Kindle books should have both logical and HTML TOCs. Users expect to see an HTML TOC when paging through a book from the beginning, while the logical table of contents is an additional way for users to navigate books.
As most PG ebooks already contain a TOC inside the HTML, its pointless to generate another one. -- Marcello Perathoner webmaster@gutenberg.org _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
James Adcock wrote:
As most PG ebooks already contain a TOC inside the HTML, its pointless to generate another one.
Sigh, you are going around in circles. The issue is that you are generating MOBI files that do not correctly implement the TOC standard of MOBI files.
mobigen is generating MOBI files that ...
The result of this is that when a user of a PG file clicks on the dedicated "TOC" button on their e-reader device, the MOBI file you generate fails to take them to the TOC. This is a file format failure on the part of the file format YOU are generating.
Not at all. The epub files I generate validate with epubcheck and the TOC displays correctly on a ADE readers. mobigen then, for whatever reason of its own, fumbles a perfectly valid toc.ncx in a perfectly valid epub file. This is Amazon's problem. I suggest they download a copy of the epub spec and give it to their developers.
Or you could use Calibre ebook-convert software which would do this automatically for you and again everything would actually work.
Calibre is slow and converts everything first to an interim format (Sony LRF I think) which loses most formatting. But foremost calibre is a kitchen sink that has dozens of dependencies some of which I cannot install on ibiblio. E.g. it wants cherrypy v2 whereas I use cherrypy v3 for gutenberg development. (What calibre needs a web application server for is beyond me.)
But, instead you continue to pimp the resulting MOBI file format because YOU think YOU should be the one to choose which devices PG users should be reading on, rather than generating valid files in the file formats that PG customers need to read on the devices they already own.
I use the official kindlegen v 1.0 (as of today) that Amazon says publishers should use to generate files for the Kindle. Save your breath to complain to Amazon, because its their application that is broken and not my epub files. If my files don't pass epubcheck, I will fix them. If Amazon needs some non-standard gimmick inserted because they can't be bothered to implement the spec, then I will definitely NOT insert it.
I think this is silly. Let the marketplace decide. If Amazon acts in an onerous way to customers then customers will choose to buy from Apple and read in EPUB format. If Apple acts in an onerous way to customers then customers will choose to buy from Amazon and will read in MOBI format.
Let me know when `the marketplace´ has fixed the bugs in their app. -- Marcello Perathoner webmaster@gutenberg.org
Not at all. The epub files I generate validate with epubcheck and the TOC displays correctly on a ADE readers.
You are leaving out the TOC element in the guide structure of the epub files. While it is legal to do so in EPUB [not MOBI], that ADE displays a "TOC" [actually the NCX guide structure] even when you are leaving out of the guide can be considered "an extension" at best, a non-conforming behavior of ADE at worse. NCX is NOT a "TOC" per se, see: http://www.openebook.org/2007/opf/OPF_2.0_final_spec.html#Section2.4.1 particularly 2.4.1.1 where in comparison it shows how TOC, List of Illustrations, etc are SUPPOSED to be implemented at: http://www.openebook.org/2007/opf/OPF_2.0_final_spec.html#Section2.6
Jim Adcock wrote:
Not at all. The epub files I generate validate with epubcheck and the TOC displays correctly on a ADE readers.
You are leaving out the TOC element in the guide structure of the epub files. While it is legal to do so in EPUB [not MOBI], that ADE displays a "TOC" [actually the NCX guide structure] even when you are leaving out of the guide can be considered "an extension" at best, a non-conforming behavior of ADE at worse.
From the epub spec:
Within the package there may be one guide element, Reading Systems are not required to use the guide element in any way.
The guide is optional on both sides, the publishing side and the consumer side. If Amazon makes it a requirement to have a guide in the epub they clearly didn't understand the spec. -- Marcello Perathoner webmaster@gutenberg.org
On Tue, Feb 2, 2010 at 9:48 AM, Marcello Perathoner <marcello@perathoner.de> wrote:
The guide is optional on both sides, the publishing side and the consumer side. If Amazon makes it a requirement to have a guide in the epub they clearly didn't understand the spec.
Clearly. You've been around for a while; you know that in practice there are optional features that are mandatory if you want decent support for the user. -- Kie ekzistas vivo, ekzistas espero.
The guide is optional on both sides, the publishing side and the consumer side. If Amazon makes it a requirement to have a guide in the epub they clearly didn't understand the spec.
Amazon doesn't make it a requirement to have a guide in epub, they make it a requirement to have a guide in mobi. Both epub and mobi can be made from OPF, they just have slightly different requirements on that OPF file set. You could easily generate the set of files required for epub, generate that file format, then add the one extra file required for a conforming mobi -- which is just a slightly different syntax than the ngx file, add one link statement in the opf, and recompile the set of files for a fully conforming mobi. But instead you blame Amazon for the fact that YOU are choosing to make files that will not work correctly on the majority of e-book readers being sold in the market. You could easily make them work if you wanted to, but you don't want them to work. Other web sites for books including sites for free books using basically the same set of tools that you are using, instead of making excuses and finger-pointing ARE making files that work correctly on the majority of e-book readers being sold in the market. It's not like this is a whole lot of work for you one way or another. It's just that you WANT to pimp the files you are making for Kindles.
Jim Adcock wrote:
But instead you blame Amazon for the fact that YOU are choosing to make files that will not work correctly on the majority of e-book readers being sold in the market. You could easily make them work if you wanted to, but you don't want them to work.
If I didn't want them to work I wouldn't generate them in the first time. To recap for the last time: 1. I do generate epub files that pass epubcheck and display correctly on ADE mobile readers. 2. Amazon provides a converter "kindlegen" that claims to convert epub files into their proprietary mobi format. 3. kindlegen fumbles the perfectly valid toc that is inside my epubs and generates a mobi file without toc (your claim). 4. You tell me that I should volunteer more unpaid time to work around a bug in Amazon's converter, reverse engineer their closed proprietary format for which they provide no documentation maybe and test it on a dozen devices that I should buy out of my own pocket. IMHO you should bugger the people that chose to make the format proprietary, to not document it in any way and on top of that release buggy converter software. Remember another textbook example: that Internet Explorer even in its 8th incarnation still does not follow w3c standards. And why is that possible? Because developers all over the world chose to work around Microsofts bugs instead of forcing them to fix their software. I'm not going down that slippery slope: If I would I'd spend more time working around other people's bugs than writing new functionality. But YOU are perfectly free to volunteer your time to save Amazon some bucks: Take my epubs, patch them, and convert them to mobis that display the toc when you hit the toc button, and redistribute them on your site. -- Marcello Perathoner webmaster@gutenberg.org
I'm not going down that slippery slope: If I would I'd spend more time working around other people's bugs than writing new functionality.
But YOU are perfectly free to volunteer your time to save Amazon some bucks: Take my epubs, patch them, and convert them to mobis that display the toc when you hit the toc button, and redistribute them on your site.
-- Marcello Perathoner webmaster@gutenberg.org
I had a car like this once. The turn signal was on the right side of the steering column. The headlight dimmer was on the left side. The window winders worked backwards. The inside door locks would lock when you pulled them up, and unlock when you pushed them down. An iconoclastic car' which was one reason I liked it. No concessions.
But YOU are perfectly free to volunteer your time to save Amazon some bucks: Take my epubs, patch them, and convert them to mobis that display
the toc when you hit the toc button, and redistribute them on your site. Again, the OPF file format specifies that TOC and NGX are separate things, intended for separate purposes. ADE screws the pooch on this one, providing one interface for both the TOC and NGX. Given that ADE screws the pooch, you and many other epub implementers make a pragmatic decision to target ADE for your generated epubs, generate a NGX, and leave out the TOC. Kindle expects to see both TOC and NGX and uses them for distinct purposes -- as OPF specifies! If Kindle were to emulate ADE's mistakes, then there could also not be a separate TOC and NGX on Kindle, fulfilling their separate purposes as specified in the OPF specification. It is not a question of wasting your time or wasting my time but rather wasting PG "customers" time because what PG is providing today to customers is broken. It would be less broken if there weren't a lot of extra PG verbiage at the start of books making it harder for customers to find the embedded HTML TOC which would allow the customers to navigate to that which they want to read. But it would be even better if customers could push the "TOC" button on their machine and have a TOC actually displayed -- as happens with "real" e-books. Further, the whitewashers' typically require an additional "real" TOC to be implemented in the HTML, which then is also not actually being used, resulting in additional wasted time and energy on the part of the volunteers. PG for example, could simply adopt a convention that a TOC.html be shipped with a submitted HTML, linked into that doc, and then you could link to that TOC.html, and the time and effort that whitewashers are asking of submitters then would not be wasted. It would be fine if you don't want to do it right if PG would allow submission of generated EPUBs and MOBIs so submitters could choose to do it right and not have their time and efforts wasted. But, you don't allow that to happen either! Again, all that these policies today accomplish is that customers get frustrated with PG, take PG books apart and rebuild them properly -- taking off the PG name and verbiage in the process, and redistribute them on other sites. I just think it would be nice if PG volunteers get recognized for the time and effort they contribute by having people actually read "PG" books, as opposed to rebranded ex-PG books where the name has been taken off so customers don't even realize they are reading something which is 99% PG efforts.
James Adcock wrote:
So why do the PG generated mobis do not have a TOC ?
Better ask mobipocket. We use their official 'mobigen' conversion tool for linux.
Mobipocket is Amazon. The latest version of mobigen is called kindlegen at:
http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000234621
kindlegen tells me that it builds a TOC. Now if Amazon would release their "Kindle for PC" for Linux too, I could actually check the generated files... knowing that the Kindle runs on Linux where's the big holdup? $ ./kindlegen pg31142.epub *********************************************** * Amazon.com kindlegen(Linux) V1.0 build 85 * * A command line e-book compiler * * Copyright Amazon.com 2009 * *********************************************** opt version: try to minimize (default) Info(prcgen): Added metadata dc:Title "On the Nature of Thought / or, The act of thinking and its connexion with a perspicuous sentence" Info(prcgen): Added metadata dc:Date "2010-01-31" Info(prcgen): Added metadata dc:Creator "John Haslam" Info(prcgen): Added metadata dc:Rights "Public domain in the USA." Info(prcgen): Added metadata dc:Source "http://www.gutenberg.org/files/31142/31142-h/31142-h.htm" Info(prcgen): Parsing files 0000001 Info(prcgen): Resolving hyperlinks Info(prcgen): Building table of content URL: /tmp/fileY6tCul/31142/toc.ncx Info(prcgen): Computing UNICODE ranges used in the book Info(prcgen): Found UNICODE range: Basic Latin [20..7E] Info(prcgen): Found UNICODE range: General Punctuation - Windows 1252 [2013..2014] Info(prcgen): Found UNICODE range: Latin-1 Supplement [A0..FF] Info(prcgen): Building MOBI file, record count: 0000023 Info(prcgen): Final stats - text compressed to (in % of original size): 054.13% Info(prcgen): The document identifier is: "On_the_Natur-cuous_sentence" Info(prcgen): The file format version is V6 Info(prcgen): Saving MOBI file Info(prcgen): MOBI File successfully generated! $ -- Marcello Perathoner webmaster@gutenberg.org
Now if Amazon would release their "Kindle for PC" for Linux too, I could actually check the generated files... knowing that the Kindle runs on Linux where's the big holdup?
Don't know other than presumably not enough people in the word run Linux to make it worth their while. You CAN however use Linux to install Mobipocket's free mobile device compatible Reader -- Mobipocket being part of Amazon -- said reader supports about 50 different popular mobile devices. The Mobipocket Reader will also allow you to confirm the fact that you are not adding a conforming TOC to your mobi files. Read: http://www.mobipocket.com/en/DownloadSoft/ProductDetailsReader.asp and look for the little penguin on the right hand side of the page.
Marcello Perathoner <marcello@perathoner.de> writes:
A better solution is to repost a HTML file that works. Convert to XHTML 1.1 and leave fancy formatting out.
That's a rather important issue. Often even justification hurts. Line width of ebook readers is limited and acceptable justification is not possible in most cases. That's esp. true for German texts. -- Karl Eichwalder
I'm not talking about "fancy formatting" -- I'm talking about "basic formatting" -- html to epub and mobi converter software all seems to differ in terms of how much vertical whitespace gets inserted where such that even the most basic stuff ends up ugly. Not that HTML browsers are *totally* immune to this problem either.
participants (9)
-
David Starner -
don kretz -
Greg M. Johnson -
Greg Newby -
James Adcock -
Jim Adcock
-
Karl Eichwalder -
Marcello Perathoner -
Michael S. Hart