Re: 14.8 million ipads sold (in 9 months) during 2010
michael said:
so we can try to figure out what devices are being used the most to download and, presumably, read our eBooks. . .so we can optimize for those readers.
my goodness. no sooner do i issue my "i'm opting out" post than michael hart himself makes a bone-headed statement... you had the right answer _before_, michael. don't go now and let the people-of-wrong mess you up... you do _not_ want to "optimize" for any specific machine, i don't care how many downloads that machine generates. you want a master-format that can convert for any device. the people-of-wrong finally got that part of the equation, but they're still ass-backwards in that they want to _do_ the conversion _for_ your end-users. that's doing it wrong. you want your end-users to download the master-format and then do the conversion for themselves. big difference, because when they have the master-file, they have the power to convert to _any_ format that they might want in the future. it also gives them the ability to control certain variables, which -- believe it or not -- they cannot do in many of the viewer-programs that are out today. just as a "for instance", do you know that an end-user often cannot choose between having a justified rendering versus a ragged-right display? they're _stuck_ with the setting in place during file-creation. that's some major bull-crap, if you ask me. why shouldn't the end-users be able to specify that, to their preference? the answer is that they _can_, if _they_ do the conversion... so give them the ability to do those conversions themselves, using their own preferences on all the important dimensions, for _whatever_ machine they happen to be using at the time... you'll have empowered them by future-proofing them, which is what i'd expect the project gutenberg founded by michael hart would be holding up as its _goal_. or did i misunderstand you? *** jim said:
Namely, html OUGHT to be the default input submission format, PG providing strong suggestions about how to write good HTML to well-support EPUB and MOBI, and that pg txt70 files have pretty much gone the way of the dodo, and ought to be supported as a file format that is computer-generated -- like EPUB and MOBI -- via a computer script from the submitted HTML.
jim, you seriously need to take your head out of your butt and take a good look around at the scenery for a change... really... a breath of _fresh_air_ would do you a lot of good... seriously... using .html as a master-format would be ludicrous. ridiculous. i would love to see you try to come up with code to make it work. because you would waste a whole lotta time in the feeble attempt, plus it would keep you busy, and occupied, and hopefully quiet... simply, .html needs to be an _output_ format, not an _input_ format.
If BB or other want to muck around with pretty printers let them do so as a way to help themselves generate preliminary html which they can then finish cleaning up before they submit it to PG.
"pretty printers?" you display your ignorance so witlessly. using z.m.l. -- or r.s.t. for that matter -- i can churn out an .html file which knocks the socks off anything you do, and i can also churn out a .pdf that looks very _beautiful_ (or "pretty", if you prefer, both words apply fine, thanks.) i can also convert out .epub and .mobi (by using kindlegen). and not only can _i_ do this, but _any_ end-user can do it, if they're talented enough to run an app and click a button. so i see your condescension, and raise it back to you _double_. but, you know, have a nice day, and all that... :+) -bowerbird
I don't mean optimize for one machine at the expense, to the exclusion of others, and bb should know that by now. I just mean ADDING new formats targeting the new machines, not wiping out their competitor formats. . . . mh On Fri, 21 Jan 2011, Bowerbird@aol.com wrote:
michael said:
so we can try to figure out what devices are being used the most to download and, presumably, read our eBooks. . .so we can optimize for those readers.
my goodness. no sooner do i issue my "i'm opting out" post than michael hart himself makes a bone-headed statement...
you had the right answer _before_, michael.
don't go now and let the people-of-wrong mess you up...
you do _not_ want to "optimize" for any specific machine, i don't care how many downloads that machine generates.
you want a master-format that can convert for any device.
the people-of-wrong finally got that part of the equation, but they're still ass-backwards in that they want to _do_ the conversion _for_ your end-users. that's doing it wrong.
you want your end-users to download the master-format and then do the conversion for themselves. big difference, because when they have the master-file, they have the power to convert to _any_ format that they might want in the future.
it also gives them the ability to control certain variables, which -- believe it or not -- they cannot do in many of the viewer-programs that are out today. just as a "for instance", do you know that an end-user often cannot choose between having a justified rendering versus a ragged-right display? they're _stuck_ with the setting in place during file-creation.
that's some major bull-crap, if you ask me. why shouldn't the end-users be able to specify that, to their preference? the answer is that they _can_, if _they_ do the conversion...
so give them the ability to do those conversions themselves, using their own preferences on all the important dimensions, for _whatever_ machine they happen to be using at the time...
you'll have empowered them by future-proofing them, which is what i'd expect the project gutenberg founded by michael hart would be holding up as its _goal_. or did i misunderstand you?
***
jim said:
Namely, html OUGHT to be the default input submission format, PG providing strong suggestions about how to write good HTML to well-support EPUB and MOBI, and that pg txt70 files have pretty much gone the way of the dodo, and ought to be supported as a file format that is computer-generated -- like EPUB and MOBI -- via a computer script from the submitted HTML.
jim, you seriously need to take your head out of your butt and take a good look around at the scenery for a change... really... a breath of _fresh_air_ would do you a lot of good... seriously...
using .html as a master-format would be ludicrous. ridiculous. i would love to see you try to come up with code to make it work. because you would waste a whole lotta time in the feeble attempt, plus it would keep you busy, and occupied, and hopefully quiet...
simply, .html needs to be an _output_ format, not an _input_ format.
If BB or other want to muck around with pretty printers let them do so as a way to help themselves generate preliminary html which they can then finish cleaning up before they submit it to PG.
"pretty printers?" you display your ignorance so witlessly.
using z.m.l. -- or r.s.t. for that matter -- i can churn out an .html file which knocks the socks off anything you do, and i can also churn out a .pdf that looks very _beautiful_ (or "pretty", if you prefer, both words apply fine, thanks.)
i can also convert out .epub and .mobi (by using kindlegen).
and not only can _i_ do this, but _any_ end-user can do it, if they're talented enough to run an app and click a button.
so i see your condescension, and raise it back to you _double_.
but, you know, have a nice day, and all that... :+)
-bowerbird
using z.m.l. -- or r.s.t. for that matter -- i can churn out an .html file which knocks the socks off anything you do, and i can also churn out a .pdf that looks very _beautiful_ (or "pretty", if you prefer, both words apply fine, thanks.)
The simple answer to "I can do it" is to actually show that you can do it, but everything I see "churned out" is butt ugly -- and then excuses are made. Once you can make something "pretty" using your own tools and books of your own creation, then put your tools online so that those of us who actually make books can put the proposed tools to the test -- except that the tools WON'T work, as anyone who has created books for PG can already tell you. Even simple books have too many exceptions to the rule for pretty printers to work, as K&R already discovered over 30 years ago. HTML is far from perfect for PG needs, but it can be made to work, as 10s of thousands of HTML formatted books for PG already attest -- as does the preference from real users to download HTML or one of its derived formats. Or, better yet, put up some ZML or RST test files on the PG website and count on your fingers and toes how many customers you actually get for your newly invented file formats! Good luck on that one! The idea that end customers want to run your tools to generate their own book formats is ludicrous. They want to put an ebook on their ebook reader and read it, period, end of story. And not be faced with ugliness from PG or any other vendor. That's the whole point of ebooks -- a black box encapsulated lump of goodness which you do not have to muck with! Some ebooks from PG and other places pass this test -- and others don't.
On 01/24/2011 11:25 PM, Jim Adcock wrote:
using z.m.l. -- or r.s.t. for that matter -- i can churn out an .html file which knocks the socks off anything you do, and i can also churn out a .pdf that looks very _beautiful_ (or "pretty", if you prefer, both words apply fine, thanks.)
The simple answer to "I can do it" is to actually show that you can do it, but everything I see "churned out" is butt ugly -- and then excuses are made.
No excuses! He *has* written a tool (on Mac OS 7.5) that is *almost* in beta now and you may backchannel him for a copy and it really *works* (in the sense that it sometimes manages to print a splash screen before it dies a horrible death.) But don't tell him that or, out of spite, he will spend another couple of years to program the best tool on earth to do just what you need and then put it on the top shelf because you don't deserve to use it.
HTML is far from perfect for PG needs, but it can be made to work, as 10s of thousands of HTML formatted books for PG already attest -- as does the preference from real users to download HTML or one of its derived formats.
What we need is a library, that is: a body of texts done all the same way. 10.000s of books made in HTML just attest that you can do books in HTML in 10.000 different ways. It is practically impossible to teach good markup to people that have had a prior exposure to HTML: as markup editors they are mentally mutilated beyond hope of regeneration. In book markup HTML is a problem not a solution.
Or, better yet, put up some ZML or RST test files on the PG website and count on your fingers and toes how many customers you actually get for your newly invented file formats! Good luck on that one!
These 10 books were made with rst: 34605 34654 34978 35031 35034 35044 35077 35078 35079 35080 You can test them on your devices of choice and tell me what doesn't work. -- Marcello Perathoner webmaster@gutenberg.org
On 1/26/11 8:25 PM, Marcello Perathoner wrote:
These 10 books were made with rst:
34605 34654 34978 35031 35034 35044 35077 35078 35079 35080
The generated HTML of those looks fine to me. Are there any plans to do generated PDF as well? It just looks slightly better on my old and trusty iRex Iliad. Regards, Walter
On 01/26/2011 09:47 PM, Walter van Holst wrote:
On 1/26/11 8:25 PM, Marcello Perathoner wrote:
These 10 books were made with rst:
34605 34654 34978 35031 35034 35044 35077 35078 35079 35080
The generated HTML of those looks fine to me. Are there any plans to do generated PDF as well? It just looks slightly better on my old and trusty iRex Iliad.
I already generate PDF from RST in the lab. But which PDF should it be? PDF letter for U.S.? PDF A4 for the rest of us? PDF for Kindle? Kindle DX? -- Marcello Perathoner webmaster@gutenberg.org
On 1/26/11 10:15 PM, Marcello Perathoner wrote:
I already generate PDF from RST in the lab.
Great.
But which PDF should it be?
PDF letter for U.S.? PDF A4 for the rest of us? PDF for Kindle? Kindle DX?
Neither my Iliad, nor any of my PDF viewers on any computer I have access have problems with the first two options. It is a matter of resizing for the viewer or printer (scale PDF fit to paper) and you're done. The US Letter format is not that much different from the A4 we use in the civilised world. I don't know about the latter two options, if they are just simplifications of the PDF standard, I don't care either because you can render those PDFs on other devices as well. Regards, Walter
On 01/26/2011 10:25 PM, Walter van Holst wrote:
On 1/26/11 10:15 PM, Marcello Perathoner wrote:
I already generate PDF from RST in the lab.
Great.
But which PDF should it be?
PDF letter for U.S.? PDF A4 for the rest of us? PDF for Kindle? Kindle DX?
Neither my Iliad, nor any of my PDF viewers on any computer I have access have problems with the first two options. It is a matter of resizing for the viewer or printer (scale PDF fit to paper) and you're done. The US Letter format is not that much different from the A4 we use in the civilised world. I don't know about the latter two options, if they are just simplifications of the PDF standard, I don't care either because you can render those PDFs on other devices as well.
A PDF built for A4 will have very small type when viewed on an Iliad, or are you saying you can set negative margins so as to zoom into the page? -- Marcello Perathoner webmaster@gutenberg.org
On 1/26/11 10:38 PM, Marcello Perathoner wrote:
Neither my Iliad, nor any of my PDF viewers on any computer I have access have problems with the first two options. It is a matter of resizing for the viewer or printer (scale PDF fit to paper) and you're done. The US Letter format is not that much different from the A4 we use in the civilised world. I don't know about the latter two options, if they are just simplifications of the PDF standard, I don't care either because you can render those PDFs on other devices as well.
A PDF built for A4 will have very small type when viewed on an Iliad, or are you saying you can set negative margins so as to zoom into the page?
Precisely. Just tap on the zoom icon and draw a diagonal with the stylus for the viewing area and you can reduce the margins to zero. A4 readability is good enough, especially when the typesetting has been done in a reasonably professional manner, meaning no more than about 17 words per line and proper line spacing. BTW, you _can_ read an A4 PDF on the screen of an iPhone 4, I wouldn't recommend doing it for more than just a few lines, but it is doable. The screen of that device is that good. Regards, Walter
Hi Everyone, I will step in here to say a thing or two about PDF. My remarks are not directed in particular to a specific person. First off PDF is a modified Post-script language! 2 It is not necessarily bound to a particular page size. Page size is only part of the metrics. And a render does not need to respect them. 3 Scaling can be (depending on how it was created) done in the renderer and not on the rasterized form. 4 It is not just for paper. Apple has used it as a description language for screen display 5 Most PDFs are actually of poor quality. A good PDF should be scalable to any size without loss of quality. But, this also, depends on the render and resolution of the output device! On the other side EPUB and MOBI suffer from the same problems. regards Keith. Am 26.01.2011 um 22:38 schrieb Marcello Perathoner:
On 01/26/2011 10:25 PM, Walter van Holst wrote:
On 1/26/11 10:15 PM, Marcello Perathoner wrote:
I already generate PDF from RST in the lab.
Great.
But which PDF should it be?
PDF letter for U.S.? PDF A4 for the rest of us? PDF for Kindle? Kindle DX?
Neither my Iliad, nor any of my PDF viewers on any computer I have access have problems with the first two options. It is a matter of resizing for the viewer or printer (scale PDF fit to paper) and you're done. The US Letter format is not that much different from the A4 we use in the civilised world. I don't know about the latter two options, if they are just simplifications of the PDF standard, I don't care either because you can render those PDFs on other devices as well.
A PDF built for A4 will have very small type when viewed on an Iliad, or are you saying you can set negative margins so as to zoom into the page?
-- Marcello Perathoner webmaster@gutenberg.org _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
"M." == Marcello Perathoner <marcello@perathoner.de> writes:
M.> On 01/26/2011 09:47 PM, Walter van Holst wrote: >> On 1/26/11 8:25 PM, Marcello Perathoner wrote: >> >>> These 10 books were made with rst: >>> >>> 34605 >>> 34654 >>> 34978 >>> 35031 >>> 35034 >>> 35044 >>> 35077 >>> 35078 >>> 35079 >>> 35080 >> >> The generated HTML of those looks fine to me. Are there any plans to do >> generated PDF as well? It just looks slightly better on my old and >> trusty iRex Iliad. M.> I already generate PDF from RST in the lab. M.> But which PDF should it be? M.> PDF letter for U.S.? M.> PDF A4 for the rest of us? M.> PDF for Kindle? M.> Kindle DX? If one size has to fit all, A5 is better than A4. It is more similar to the standard book size, and for print two pages in one is OK. But probably several combinations of size, margins and point size should be provided. Carlo
I downloaded Marcello's top ten in epub format last night and spent a little time looking at them on my Sony Reader: 1. They all have a working html contents page (TOC) which can be used to navigate around the document (and that's better than the older generated epubs), also I think the idea of putting a back link to the TOC on every chapter head is excellent and I shall copy it with my hand-crafted epubs. 2. Using the XML TOC (the .ncx file) works but it takes 3-5 seconds to open, which makes this unacceptable as a navigational tool. This is true for all ten epubs, but it isn't true of other XML TOCs, either for older PG epubs or for my hand-crafted versions. And in many cases these are much bigger and more complex TOC structures. The only consistent difference I can see between the 'marcello ten' and previous epubs is that the structure of the PG licence is included in the TOC, but this isn't that complex, so I'm not convinced that is an explanation. 3. The layout seems to me to be, like the curate's egg, 'good in parts'. Actually that's a bit negative, perhaps 'mostly good but with some irritating flaws' might be fairer. I'll just concentrate on the flaws: - Chapter headings generally are in too big a font size, (or too bold, or with too large margins, or more than one of the aforegoing). I am working on a font-size range of 90%-135% of the browser default in my hand-crafted versions. I find anything smaller is too wearing to read, and anything bigger just gets broken across more than one line (and looks all wrong). Also I would split chapter headings (CHAPTER I) say from the chapter title (COMING INTO THE WILDERNESS) and do the title in a smaller font. And while I'm about it I don't think Latin chapter numbers are practical on the limited screen size of an e-reader (Try to fit CHAPTER LXXXVIII - YANKEE DOODLE COMES TO TOWN from Thackeray's 'The Virginians' (PG8123), or CHAPTER XVI - IN WHICH M. SEGUIER, KEEPER OF THE KING'S SEALS, LOOKS MORE THAN ONCE FOR THE BELL, IN ORDER RING IT, AS HE DID BEFORE from Dumas pere's 'The Three Musketeers' PG1257 to see what I mean). - The front matter isn't always broken into pages correctly (I think, as I don't have the originals). This may seem like niggling, but in a book you often have only page boundaries to delimit important stuff like the title, author, publication date, dedication, etc. from less important things like publishing history, printing history, other titles by the same author, or other titles in the same series, adverts for Mars bars (you can find these in wartime Penguin paperbacks explaining why the price has gone up from 2d to 3d!), etc. I think the interesting question here is whether the layout problems are artifacts of the html/epub generator(s), in which case they can presumably be fixed if other people agree with me, or whether they come from eccentricities of the encoding in rst format by the transcriber. 4. I haven't yet found any block quotes in any of the books. I'm thinking of, for example, poems or, more frequently, letters which Victorian novelists often put into their text. These typically feature smaller fonts and right-justified text (for letter heads, closing compiments, signatures, etc). It would be reassuring to see that rst can deal with those. 5. Having looked at the html in the epub file I find it somewhat harder to read than that in older epubs or html files. Mainly, I think, because it's the product of a generator not a human. If PG goes the rst route I fear we might be at the start of a slippery slope which ends in the rst becoming the only format that can be understood by humans. (And it appears that rst generation is effectively already in production, as instanced by the 'marcello ten'). Has anybody worried about the lifespan or broad acceptance of rst in the wider world? I can only find references to it as a Python documentation tool. How likely is it that rst tools will be available and supported in a few decades, or that there will be stable and detailed definitions of rst by industry standards bodies for implementations to conform to? Bob Gibbins BTW Is there anywhere on the PG site I could put one or two of my hand-crafted epubs for readers of this forum to look at. I don't run my own web site, but as I seem to be slowly coming to the conclusion that hand-crafted epubs using a standard subset of html are the most practical answer, particularly for the thousands and thousands of great books that are already in the PG archive, I suppose I should be prepared to expose some examples for criticism. Original Message:
These 10 books were made with rst:
34605 34654 34978 35031 35034 35044 35077 35078 35079 35080
You can test them on your devices of choice and tell me what doesn't work.
-- Marcello Perathoner webmaster@gutenberg.org _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
On 01/27/2011 05:44 PM, Robert Gibbins wrote:
2. Using the XML TOC (the .ncx file) works but it takes 3-5 seconds to open, which makes this unacceptable as a navigational tool.
This is a known bug for Sony. They are too dumb to cache the TOC. It opens instantaneously everywhere else.
- The front matter isn't always broken into pages correctly (I think, as I don't have the originals).
The frontmatter, like everything eles, is broken where the producer puts pagebreaks.
I think the interesting question here is whether the layout problems are artifacts of the html/epub generator(s), in which case they can presumably be fixed if other people agree with me, or whether they come from eccentricities of the encoding in rst format by the transcriber.
Font sizes are specified in the CSS. But I'd prefer *not* to have a discussion about things that are a matter of personal taste.
4. I haven't yet found any block quotes in any of the books. I'm thinking of, for example, poems or, more frequently, letters which Victorian novelists often put into their text. These typically feature smaller fonts and right-justified text (for letter heads, closing compiments, signatures, etc). It would be reassuring to see that rst can deal with those.
RTFM: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html
5. Having looked at the html in the epub file I find it somewhat harder to read than that in older epubs or html files. Mainly, I think, because it's the product of a generator not a human. If PG goes the rst route I fear we might be at the start of a slippery slope which ends in the rst becoming the only format that can be understood by humans.
RST is much more human-readable than HTML because it is designed to be human-readable. The generated HTML is much more correct than the HTML you find in run-of-the-mill PG books. If you want the HTML to be pretty, you can format it with tidy. I don't believe your ereader will care, except that all the whitespace will eat up its scarce memory.
BTW Is there anywhere on the PG site I could put one or two of my hand-crafted epubs for readers of this forum to look at. I don't run my own web site, but as I seem to be slowly coming to the conclusion that hand-crafted epubs using a standard subset of html are the most practical answer, particularly for the thousands and thousands of great books that are already in the PG archive, I suppose I should be prepared to expose some examples for criticism.
Not on the PG site but Greg Newby can provide you with webspace if you need it. -- Marcello Perathoner webmaster@gutenberg.org
Has anybody worried about the lifespan or broad acceptance of rst in the wider world? I can only find references to it as a Python documentation tool. How likely is it that rst tools will be available and supported in a few decades, or that there will be stable and detailed definitions of rst by industry standards bodies for implementations to conform to?
Yes I worry about this. RST is just a resurrection of the early K&K Un*x technical documentation work of the 1970s -- which was tried and rejected by a previous generation of document writers, leading to the currently accepted approach of balanced context-independent tags which are found in HTML and XML. I would love to see an XML based approach, or an EPUB3 based approach -- which are more-directly aimed at actually coding books -- BUT, the tools aren't out there widely available, AND there aren't the people out there to code the books into a PG-specific XML version, nor in an EPUB3 version. In short, what would you need to get ANY file format to work: WIDELY available authoring tools everywhere. WIDELY available rendering tools everywhere. WIDE near universal acceptance among eBook Readers. WIDE near universal acceptance of that file format by PG would-be book authors. If you don't have this then what happens? Then would-be PG authors simply "route around damage" by choosing to publish to some other distribution site other than PG. Then PG can pick up the book from that site, where it is found written in say, HTML, and now PG once-again has an HTML book which is incompatible with PG's internally chosen boutique file format, and then PG is right back to the same situation as they are today. Again, IN PRACTICE, I would recommend HTML plus a PG suggested style guide, such that those submitters who actually care can minimize problems by submitting to the suggested PG HTML coding style. Do I WISH there was a better solution? Yes. Do I find that what others are suggesting as "the cure" to be an improvement? No.
... as I seem to be slowly coming to the conclusion that hand-crafted epubs using a standard subset of html are the most practical answer, particularly for the thousands and thousands of great books that are already in the PG archive, I suppose I should be prepared to expose some examples for criticism.
Same conclusion that most of us I think have already come to: Write to a KISS subset of HTML that will "correctly" render to the widest possible number of HTML, EPUB, and MOBI readers. In practice the debate ends up being how extremely KISS to keep it, and what to do when (as is almost always the case) one finds elements in the book which one is encoding which don't fit nicely into one's existing KISS-HTML paradigm ideas.
What we need is a library, that is: a body of texts done all the same way.
I don't disagree, but nobody is going to go back and fix books done years ago, in part because all the other volunteers will flame them if they try to do so.
These 10 books were made with rst:
Well, looking at a couple of them what I see is that you have chosen very simple books in the first place, and generated ugly results even then.
On 01/28/2011 10:40 PM, James Adcock wrote:
Well, looking at a couple of them what I see is that you have chosen very simple books in the first place, and generated ugly results even then.
A good bug report goes like this: In the file A when viewed on device B in chapter C in the p that starts with D I see E. It should be E' instead. Just saying something is ugly won't get you nowhere except into my file of perpetual ignorage. So, is anything measurable coming our way? Or are you just wasting everybody's time? -- Marcello Perathoner webmaster@gutenberg.org
On Fri, Jan 28, 2011 at 2:45 PM, Marcello Perathoner <marcello@perathoner.de> wrote:
On 01/28/2011 10:40 PM, James Adcock wrote:
Well, looking at a couple of them what I see is that you have chosen very simple books in the first place, and generated ugly results even then.
A good bug report goes like this: In the file A when viewed on device B in chapter C in the p that starts with D I see E. It should be E' instead.
Just saying something is ugly won't get you nowhere except into my file of perpetual ignorage.
So, is anything measurable coming our way? Or are you just wasting everybody's time?
(A) Anyone with that attitude shouldn't be in design. (B) Last time I pointed out it should be E', you swore up and down against all evidence it should be E. Time is money, Marcello, and I don't see the value in trying to make a good bug report for you. -- Kie ekzistas vivo, ekzistas espero.
So, is anything measurable coming our way? Or are you just wasting everybody's time?
You are now playing BB's game, namely you propose tools which do not work and then tell the PG community that it is our job to support you, the would-be tool maker. There are many many well-formatted books at PG, including many coming from DP recently. Start by reading the DP guidelines, and looking at the HTML code they are using, for example. And historically De Vinne has many many good books about what it takes to make an attractive paper-based book which can be used for understanding of how attractive books were made -- and also the dynamics which lead to ugly paper books being made. I just mentioned one of these recently. Make the commitment the rest of us have already made, if you haven't already, and purchase a MOBI and/or an EPUB device, buy and read some commercial ebooks, as well as reading PG free ebooks, and you will rapidly discover what works and doesn't work, and how there are people out there who know how to do it "right" -- which isn't too hard really! -- and how others continue to generate garbage that doesn't work because they continue to deceive themselves. And/or they work for authors or publishers who don't know what they are talking about and force the eBook transcriber to take approaches which really really doesn't work. Also, "Kindle Formatting" by Joshua Tallent gets much of it right re the MOBI world, not that I agree with all his detailed suggestions. Ultimately for the book transcriber getting most of it right isn't a problem. The problem is that each non-trivial book leads to unique challenges where one says "gosh, how do I code this part to correctly represent the intent of the original author/publisher while working on almost all of the HTML/EPUB/MOBI devices out there?" There are already a ton of tools out there that "kind-of help" translate txt files into html -- except they typically generated garbage HTML code. Which leads most of us to rapidly figure out "fugettaboutit" -- its easier just to write HTML by hand.
Yes, people WILL "go back an fix books done years ago," so they fit needs that were never even dreamed of.... After all, that's exactly what WE have been doing to an assortment of Gutenbergish publications all along. If they find working with our editions too stultifying, they will just start from scratch, they way I did, and, as a result, they will get exactly what they want. mh On Fri, 28 Jan 2011, James Adcock wrote:
What we need is a library, that is: a body of texts done all the same way.
I don't disagree, but nobody is going to go back and fix books done years ago, in part because all the other volunteers will flame them if they try to do so.
These 10 books were made with rst:
Well, looking at a couple of them what I see is that you have chosen very simple books in the first place, and generated ugly results even then.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
These 10 books were made with rst:
Well, looking at a couple of them what I see is that you have chosen very simple books in the first place, and generated ugly results even then.
And digging deeper into those, I find that the generated EPUB and MOBI is garbage, which will prove to be problematic on many eBook Readers, which in turn is presumably caused by considering HTML as an output-rendering file format, where you really don't care about the quality of the HTML being generated. If you want to generated good, consistent output on real-world eBook Readers, you need to keep your EPUB and MOBI as clean and as "KISS" as possible.
participants (10)
-
Bowerbird＠aol.com -
David Starner -
James Adcock -
Jim Adcock
-
Keith J. Schultz -
Marcello Perathoner -
Michael S. Hart -
Robert Gibbins -
traverso＠posso.dm.unipi.it -
Walter van Holst