
don said:
OK, I'm willing to listen to how I can improve any "book files" (whatever they are) PG provides today.
are you kidding? have you ever even _looked_ at any of the output -- .mobi or .epub -- that is being generated by p.g.? don't you feel any need to inform yourself before you speak?
What great secret do you share with them that the rest of us aren't privy to?
um, it's no "great secret" what the obvious flaws are, don... because -- d'uh -- the obvious flaws are terribly _obvious_. but, since you don't seem to be able to _see_ the obvious, i'll give you a few examples to sharpen your observation... first, the e-books start with legalese. you know that, right? and maybe you're accustomed to it, and you've "accepted" it, but if you want an improved product, move it _all_ to the end. what usually comes next is the title-page gunk of the p-book. that's typically too much information, too fast, and undesired. you should open with the equivalent of the cover of a p-book; that is, the title (and subtitle, if any) and the author (and the co-creators, if there were any), contact info, creation date of this latest version, and the e-book's canonical online address. that's all! all of this info should present itself compactly, on one screen, even if the end-user has their fontsize cranked up fairly high... p.g. e-texts _often_ get this "cover-page" screen badly wrong. *** next should come the table-of-contents. _without_question_. people should know -- with certainty -- where the t.o.c. is, and it should be in a convenient location, so let's make it standard. nor should this be one of those sprawling 10-screens things... indeed, _this_ table of contents should fit _on_a_single_screen_. even if, once again, the person sets their font-size fairly large... if you've got one of those sprawling table-of-contents monsters, make that the _next_ section, and call it "the extended contents". but the second screen should be a compact overview of the book, and a quick way to jump even to the sections at the very end of it. another thing which you can consider is to split up the monster. let's say the book has 5 sections, with 10 chapters in each one... the table-of-contents in the front could just list the _sections_. then, at the start of each section, you have another linked list, which gives the person all the chapter names for that section, plus links to the previous and next section-headers. this allows the reader to gracefully page through the sections of the book, getting a good idea of the chapters contained within each one... this is far preferable to a sprawling table-of-contents up front, where the screen-breaks will never coincide with each section... there are other ways you can make this work, too. for instance, p.g. has a book along the lines of "365 recipes"... yep, there's a recipe for every day of the year. pretty nifty, eh? so in that book, i turned each month into its own section, with the appropriate number of entries for the days of that month... depending on the book, there might be other ways that you can separate the table of contents into chunks that are meaningful. again, the idea is to make something that works as an _e-book_. that's the ideal, anyway. but, getting back to our reality... project gutenberg derivative formats often botch the t.o.c. badly. in many books, the items get joined together in one big jumble... in the worst cases, not al that atypical, the links don't even work. this sets a bad impression even before the person starts reading, not to mention the worse fact that it hurts the t.o.c. functionality. on the one hand, i know that the problem largely revolves around the fact that it's difficult to anticipate all of the t.o.c. snowflakes... so i'm tempted, for half a second, to excuse marcello's poor work. on the other hand, it shouldn't be that difficult to detect the t.o.c., and do whatever work is necessary to make it work in a useful way. (sorry, marcello, i tried to be nice, because i know you're a big fan.) *** a list of illustrations might come next, if the book has any... even if there wasn't one in the p-book, there should be one in the e-book. there's no law against improving the product. *** after that, you can put the obtuse crap from the title-and-verso. but... as far as most front-matter goes, it's not a bad idea to _move_it_ to the end of the book. an introduction should stay in the front, obviously, and a dedication doesn't take much effort to skip over, but a lot of the other stuff that's often presented as front-matter could -- quite easily -- be read at the end, and be just as useful. if you _do_ leave this stuff up front, though, you absolutely must give the person a link to skip it, and jump right into the book... do p.g. derivative formats do any of this? no, sadly, they don't. so these are ways that those formats could easily be improved. *** this is just to get you started, don. if you need more input, on matters involving the interior, i can give that to you as well. but you really should look for yourself. -bowerbird p.s. oh, and i know that a _lot_ of you other people are just as uninformed as don is, but -- unlike don -- you're too stupid to even ask any questions to get the knowledge you are lacking...

I wasn't asking about how they needed improvement. The assertion was made that a means is available for handling those improvements. I am asking for a description of the means provided by PG for improving them. On Tue, Jan 31, 2012 at 11:10 AM, <Bowerbird@aol.com> wrote:
don said:
OK, I'm willing to listen to how I can improve any "book files" (whatever they are) PG provides today.
are you kidding? have you ever even _looked_ at any of the output -- .mobi or .epub -- that is being generated by p.g.?
don't you feel any need to inform yourself before you speak?
What great secret do you share with them that the rest of us aren't privy to?
um, it's no "great secret" what the obvious flaws are, don...
because -- d'uh -- the obvious flaws are terribly _obvious_.
but, since you don't seem to be able to _see_ the obvious, i'll give you a few examples to sharpen your observation...
first, the e-books start with legalese. you know that, right? and maybe you're accustomed to it, and you've "accepted" it, but if you want an improved product, move it _all_ to the end.
what usually comes next is the title-page gunk of the p-book. that's typically too much information, too fast, and undesired.
you should open with the equivalent of the cover of a p-book; that is, the title (and subtitle, if any) and the author (and the co-creators, if there were any), contact info, creation date of this latest version, and the e-book's canonical online address.
that's all!
all of this info should present itself compactly, on one screen, even if the end-user has their fontsize cranked up fairly high...
p.g. e-texts _often_ get this "cover-page" screen badly wrong.
***
next should come the table-of-contents. _without_question_. people should know -- with certainty -- where the t.o.c. is, and it should be in a convenient location, so let's make it standard.
nor should this be one of those sprawling 10-screens things... indeed, _this_ table of contents should fit _on_a_single_screen_. even if, once again, the person sets their font-size fairly large...
if you've got one of those sprawling table-of-contents monsters, make that the _next_ section, and call it "the extended contents". but the second screen should be a compact overview of the book, and a quick way to jump even to the sections at the very end of it.
another thing which you can consider is to split up the monster. let's say the book has 5 sections, with 10 chapters in each one...
the table-of-contents in the front could just list the _sections_.
then, at the start of each section, you have another linked list, which gives the person all the chapter names for that section, plus links to the previous and next section-headers. this allows the reader to gracefully page through the sections of the book, getting a good idea of the chapters contained within each one... this is far preferable to a sprawling table-of-contents up front, where the screen-breaks will never coincide with each section...
there are other ways you can make this work, too.
for instance, p.g. has a book along the lines of "365 recipes"... yep, there's a recipe for every day of the year. pretty nifty, eh? so in that book, i turned each month into its own section, with the appropriate number of entries for the days of that month...
depending on the book, there might be other ways that you can separate the table of contents into chunks that are meaningful.
again, the idea is to make something that works as an _e-book_.
that's the ideal, anyway. but, getting back to our reality...
project gutenberg derivative formats often botch the t.o.c. badly. in many books, the items get joined together in one big jumble... in the worst cases, not al that atypical, the links don't even work. this sets a bad impression even before the person starts reading, not to mention the worse fact that it hurts the t.o.c. functionality.
on the one hand, i know that the problem largely revolves around the fact that it's difficult to anticipate all of the t.o.c. snowflakes... so i'm tempted, for half a second, to excuse marcello's poor work.
on the other hand, it shouldn't be that difficult to detect the t.o.c., and do whatever work is necessary to make it work in a useful way. (sorry, marcello, i tried to be nice, because i know you're a big fan.)
***
a list of illustrations might come next, if the book has any...
even if there wasn't one in the p-book, there should be one in the e-book. there's no law against improving the product.
***
after that, you can put the obtuse crap from the title-and-verso.
but...
as far as most front-matter goes, it's not a bad idea to _move_it_ to the end of the book. an introduction should stay in the front, obviously, and a dedication doesn't take much effort to skip over, but a lot of the other stuff that's often presented as front-matter could -- quite easily -- be read at the end, and be just as useful. if you _do_ leave this stuff up front, though, you absolutely must give the person a link to skip it, and jump right into the book...
do p.g. derivative formats do any of this? no, sadly, they don't. so these are ways that those formats could easily be improved.
***
this is just to get you started, don.
if you need more input, on matters involving the interior, i can give that to you as well. but you really should look for yourself.
-bowerbird
p.s. oh, and i know that a _lot_ of you other people are just as uninformed as don is, but -- unlike don -- you're too stupid to even ask any questions to get the knowledge you are lacking...
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

On Tue, Jan 31, 2012 at 11:50:47AM -0800, don kretz wrote:
I wasn't asking about how they needed improvement. The assertion was made that a means is available for handling those improvements. I am asking for a description of the means provided by PG for improving them.
http://www.gutenberg.org/wiki/Gutenberg:Contact_Information http://www.gutenberg.org/wiki/Gutenberg:Readers%27_FAQ#R.26._I.27ve_found_so... Also, for background: http://www.gutenberg.org/wiki/ErrorCorrection -- Greg

Thanks, greg. It's basically send us an email describing the errors. I'm not sure how that would apply to "handling these improvements" in the manner we're discussing here. I don't expect it scales well. On Tue, Jan 31, 2012 at 1:26 PM, Greg Newby <gbnewby@pglaf.org> wrote:
On Tue, Jan 31, 2012 at 11:50:47AM -0800, don kretz wrote:
I wasn't asking about how they needed improvement. The assertion was made that a means is available for handling those improvements. I am asking for a description of the means provided by PG for improving them.
http://www.gutenberg.org/wiki/Gutenberg:Contact_Information
http://www.gutenberg.org/wiki/Gutenberg:Readers%27_FAQ#R.26._I.27ve_found_so...
Also, for background: http://www.gutenberg.org/wiki/ErrorCorrection
-- Greg
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

On Tue, Jan 31, 2012 at 02:42:27PM -0800, don kretz wrote:
Thanks, greg. It's basically send us an email describing the errors. I'm not sure how that would apply to "handling these improvements" in the manner we're discussing here. I don't expect it scales well.
That's why we're talking about a New Way. The information below reflects the means currently available, as you requested. -- Greg
On Tue, Jan 31, 2012 at 1:26 PM, Greg Newby <gbnewby@pglaf.org> wrote:
On Tue, Jan 31, 2012 at 11:50:47AM -0800, don kretz wrote:
I wasn't asking about how they needed improvement. The assertion was made that a means is available for handling those improvements. I am asking for a description of the means provided by PG for improving them.
http://www.gutenberg.org/wiki/Gutenberg:Contact_Information
http://www.gutenberg.org/wiki/Gutenberg:Readers%27_FAQ#R.26._I.27ve_found_so...
Also, for background: http://www.gutenberg.org/wiki/ErrorCorrection
-- Greg
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

Hi BB, On some points I do agree with you, but on other I would have to disagree. As far as the PG legalese, we agree that should be at the end. Table of contents: it depends which table you are considering. The one of the ebook, the one you can get to by the touch (press) of a button! Yes, that one can be simplified. As for the original, well, it is easy enough to add links. Furthermore, some/many want to keep things as original as possible. The same goes for the others things you considered flawed. regards Keith. Am 31.01.2012 um 20:10 schrieb Bowerbird@aol.com:
don said:
OK, I'm willing to listen to how I can improve any "book files" (whatever they are) PG provides today.
are you kidding? have you ever even _looked_ at any of the output -- .mobi or .epub -- that is being generated by p.g.?
don't you feel any need to inform yourself before you speak?
What great secret do you share with them that the rest of us aren't privy to?
um, it's no "great secret" what the obvious flaws are, don...
because -- d'uh -- the obvious flaws are terribly _obvious_.
but, since you don't seem to be able to _see_ the obvious, i'll give you a few examples to sharpen your observation...
first, the e-books start with legalese. you know that, right? and maybe you're accustomed to it, and you've "accepted" it, but if you want an improved product, move it _all_ to the end.
what usually comes next is the title-page gunk of the p-book. that's typically too much information, too fast, and undesired.
you should open with the equivalent of the cover of a p-book; that is, the title (and subtitle, if any) and the author (and the co-creators, if there were any), contact info, creation date of this latest version, and the e-book's canonical online address.
that's all!
all of this info should present itself compactly, on one screen, even if the end-user has their fontsize cranked up fairly high...
p.g. e-texts _often_ get this "cover-page" screen badly wrong.
***
next should come the table-of-contents. _without_question_. people should know -- with certainty -- where the t.o.c. is, and it should be in a convenient location, so let's make it standard.
nor should this be one of those sprawling 10-screens things... indeed, _this_ table of contents should fit _on_a_single_screen_. even if, once again, the person sets their font-size fairly large...
if you've got one of those sprawling table-of-contents monsters, make that the _next_ section, and call it "the extended contents". but the second screen should be a compact overview of the book, and a quick way to jump even to the sections at the very end of it.
another thing which you can consider is to split up the monster. let's say the book has 5 sections, with 10 chapters in each one...
the table-of-contents in the front could just list the _sections_.
then, at the start of each section, you have another linked list, which gives the person all the chapter names for that section, plus links to the previous and next section-headers. this allows the reader to gracefully page through the sections of the book, getting a good idea of the chapters contained within each one... this is far preferable to a sprawling table-of-contents up front, where the screen-breaks will never coincide with each section...
there are other ways you can make this work, too.
for instance, p.g. has a book along the lines of "365 recipes"... yep, there's a recipe for every day of the year. pretty nifty, eh? so in that book, i turned each month into its own section, with the appropriate number of entries for the days of that month...
depending on the book, there might be other ways that you can separate the table of contents into chunks that are meaningful.
again, the idea is to make something that works as an _e-book_.
that's the ideal, anyway. but, getting back to our reality...
project gutenberg derivative formats often botch the t.o.c. badly. in many books, the items get joined together in one big jumble... in the worst cases, not al that atypical, the links don't even work. this sets a bad impression even before the person starts reading, not to mention the worse fact that it hurts the t.o.c. functionality.
on the one hand, i know that the problem largely revolves around the fact that it's difficult to anticipate all of the t.o.c. snowflakes... so i'm tempted, for half a second, to excuse marcello's poor work.
on the other hand, it shouldn't be that difficult to detect the t.o.c., and do whatever work is necessary to make it work in a useful way. (sorry, marcello, i tried to be nice, because i know you're a big fan.)
***
a list of illustrations might come next, if the book has any...
even if there wasn't one in the p-book, there should be one in the e-book. there's no law against improving the product.
***
after that, you can put the obtuse crap from the title-and-verso.
but...
as far as most front-matter goes, it's not a bad idea to _move_it_ to the end of the book. an introduction should stay in the front, obviously, and a dedication doesn't take much effort to skip over, but a lot of the other stuff that's often presented as front-matter could -- quite easily -- be read at the end, and be just as useful. if you _do_ leave this stuff up front, though, you absolutely must give the person a link to skip it, and jump right into the book...
do p.g. derivative formats do any of this? no, sadly, they don't. so these are ways that those formats could easily be improved.
***
this is just to get you started, don.
if you need more input, on matters involving the interior, i can give that to you as well. but you really should look for yourself.
-bowerbird
p.s. oh, and i know that a _lot_ of you other people are just as uninformed as don is, but -- unlike don -- you're too stupid to even ask any questions to get the knowledge you are lacking... _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
participants (4)
-
Bowerbird@aol.com
-
don kretz
-
Greg Newby
-
Keith J. Schultz