Re: New mobile devices page (pls. proofread)
michael said:
In this case, it was specified they had a browser, thus presuming an "agent" that could be worked with.
yes, but one doesn't read books using that browser. you can _download_ book-files using that browser. (which are then read using the non-browser part.) but the project gutenberg landing-pages are not in a good form to do that, as currently constructed. jim is asking for a new construction, to make it easy for those reader-machines to download your books. the easiest way -- which is what i just suggested -- is to link to some "deep" pages on the site, but that has been "officially discouraged" by your webmaster, at least in the past, and sometimes it gets enforced. -bowerbird
On Tue, 1 Dec 2009, Bowerbird@aol.com wrote:
michael said:
In this case, it was specified they had a browser, thus presuming an "agent" that could be worked with.
yes, but one doesn't read books using that browser.
_I_ do, and I do it as part of my demonstrations all the time, from large screens, to laptops, to netbooks, to cellphones, to Palms and other PDA's. People love it!!!
you can _download_ book-files using that browser. (which are then read using the non-browser part.)
You can also do a "save page" and stay in browsers.
but the project gutenberg landing-pages are not in a good form to do that, as currently constructed.
One of the things I am pushing for.
jim is asking for a new construction, to make it easy for those reader-machines to download your books.
I'm not pushing as hard for those, yet, simply because there aren't enough of them. With Kindle recently yak up a storm of numbers up to nearly 2 million, when not saying one word about sales up until then, I suspect a little manipulation of sales figures ensued. However, even if Kindle and Sony each had 2 million it would be only one per thousand cellphones. When/if these devices reach 10% of other options, then it may be time to give them more attention, but not as in more attention than any other device people used to read our eBooks. I don't know if anyone here is really aware of it, but there are already places that have more cellphones per person than 1.00. . .and not just certain cities but a matter of entire countries, not just most developed. This is why I have been pushing so hard for cellphones to be used to read our eBooks, because more have eBook access through cellphones than just plain computers or ereaders or PDAs. . .COMBINED!!!
the easiest way -- which is what i just suggested -- is to link to some "deep" pages on the site, but that has been "officially discouraged" by your webmaster, at least in the past, and sometimes it gets enforced.
We have put up some experimental pages where you should be able to try anything you want. . .GO FOR IT!!!
-bowerbird
On Wed, Dec 2, 2009 at 1:37 AM, Michael S. Hart <hart@pglaf.org> wrote:
We have put up some experimental pages where you should be able to try anything you want. . .GO FOR IT!!!
The tool I created was a simple wrapper around the existing etexts, which reflows/reformats the existing HTML version of the work, for display on the lowest-common-denominator device; a browser. If you're all talking about taking the existing site's landing pages and making them appropriate for browsing on the Kindle/Iliad/etc., and having the standard landing page links work appropriately for each device (also very doable), then I'll need to mirror the content that drives those landing pages. I don't have access to that from my local mirror of the PG archive itself. I'm happy to clean that up and help make something work for those other devices, using the existing landing page paradigm, but that's not what I thought we were originally talking about. I thought we wanted to add additional links ON those landing pages, that would be appropriate for use on non-desktop browsing clients.
On Wed, Dec 02, 2009 at 08:21:35AM -0500, David A. Desrosiers wrote:
On Wed, Dec 2, 2009 at 1:37 AM, Michael S. Hart <hart@pglaf.org> wrote:
We have put up some experimental pages where you should be able to try anything you want. . .GO FOR IT!!!
The tool I created was a simple wrapper around the existing etexts, which reflows/reformats the existing HTML version of the work, for display on the lowest-common-denominator device; a browser.
If you're all talking about taking the existing site's landing pages and making them appropriate for browsing on the Kindle/Iliad/etc., and having the standard landing page links work appropriately for each device (also very doable), then I'll need to mirror the content that drives those landing pages. I don't have access to that from my local mirror of the PG archive itself.
This is what I've been talking about. I understand what you're asking for, but it doesn't need to be that hard. Some good examples of what the landing pages would look like (with standard HTML, style sheets, .htaccess, or other aspects), with static files, would be great. I suggest this approach because: - The back end at gutenberg.org is not easily portable. - Building your own interactive back end, using the catalog RDF/XML file is not necessary for the landing page purpose
I'm happy to clean that up and help make something work for those other devices, using the existing landing page paradigm, but that's not what I thought we were originally talking about. I thought we wanted to add additional links ON those landing pages, that would be appropriate for use on non-desktop browsing clients.
This is a related goal, so don't hesitate to offer further examples & ideas. Ultimately, we'd like as much of the content on gutenberg.org (including the collection, wiki pages, and eBook catalog landing pages) to work on a much wider variety of devices. This can include automated conversion of the eBook files (which is already in place, and additional converters are fairly easy to use). Since we already have some reasonable converts in place, my current interest is in making the surrounding files (i.e., the Web site, not the eBooks) friendlier. -- Greg
On Wed, Dec 2, 2009 at 10:16 AM, Greg Newby <gbnewby@pglaf.org> wrote:
Since we already have some reasonable converts in place, my current interest is in making the surrounding files (i.e., the Web site, not the eBooks) friendlier.
Fair enough... other than wget'ing the entire front-facing page for each landing etext, how do I go about replicating that here, so I can begin testing some of those modifications?
On Wed, Dec 02, 2009 at 01:41:30PM -0500, David A. Desrosiers wrote:
On Wed, Dec 2, 2009 at 10:16 AM, Greg Newby <gbnewby@pglaf.org> wrote:
Since we already have some reasonable converts in place, my current interest is in making the surrounding files (i.e., the Web site, not the eBooks) friendlier.
Fair enough... other than wget'ing the entire front-facing page for each landing etext, how do I go about replicating that here, so I can begin testing some of those modifications?
The landing pages are quite similar. Why not just choose a small subset (like 5)?
From my point of view, if you can provide a few good samples, I can pick them up and put them in the backend on the site. I could send the .php script that generates the pages, if it might help. (The PHP won't work solo, because it has some external dependencies, including our Postgres database and a bunch of other PHP files.)
Extracting whatever is different from your pages, and applying them to pages on the site, is something I will be able to do for stuff like css and HTML changes. Or, if it gets complicated, we'll think of another approach. (If I didn't apologize lately: sorry that it's not easy for us to provide additional people usernames on the site, or set up a sandbox. Only the public Wiki area enables this, but it doesn't run the landing pages that we're trying to address.) -- Greg
Greg Newby wrote:
From my point of view, if you can provide a few good samples, I can pick them up and put them in the backend on the site. I could send the .php script that generates the pages, if it might help. (The PHP won't work solo, because it has some external dependencies, including our Postgres database and a bunch of other PHP files.)
I'm moving away from PHP and towards python with genshi templates. See http://www.gutenberg.org/cache/epub/97/pg97.bibrec Building a mobile bibrec is just a question of a new genshi template and a new CSS. -- Marcello Perathoner webmaster@gutenberg.org
One other option might be to just install a redirect option on the main pages that would go to a page with instructions for your routine. . . . On Wed, 2 Dec 2009, David A. Desrosiers wrote:
On Wed, Dec 2, 2009 at 1:37 AM, Michael S. Hart <hart@pglaf.org> wrote:
We have put up some experimental pages where you should be able to try anything you want. . .GO FOR IT!!!
The tool I created was a simple wrapper around the existing etexts, which reflows/reformats the existing HTML version of the work, for display on the lowest-common-denominator device; a browser.
If you're all talking about taking the existing site's landing pages and making them appropriate for browsing on the Kindle/Iliad/etc., and having the standard landing page links work appropriately for each device (also very doable), then I'll need to mirror the content that drives those landing pages. I don't have access to that from my local mirror of the PG archive itself.
I'm happy to clean that up and help make something work for those other devices, using the existing landing page paradigm, but that's not what I thought we were originally talking about. I thought we wanted to add additional links ON those landing pages, that would be appropriate for use on non-desktop browsing clients. _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
yes, but one doesn't read books using that browser.
_I_ do, and I do it as part of my demonstrations all the time, from large screens, to laptops, to netbooks, to cellphones, to Palms and other PDA's. People love it!!!
*Sigh* -- might be nice if one of you actually invested in an ebook reader and try using it. Preferably the Kindle simply because that has the largest ownership and is generally the most capable. Why do people buy an ebook reader when presumably they also almost all also own a computer with an HTML browser? Answer: the ebook reader gives a better more book-like reading experience. Why MOBI or EPUB format and not HTML? Because MOBI and EPUB formats understand what is necessary to make an ebook reader "book-like experience" work IN PRACTICE -- HTML does not. Here's an example: I start reading some PG book using HTML format on my laptop while I am at the airport. I get on the plane. I have to turn off the laptop. When the seatbelt light goes off I bring out my laptop to continue reading the PG book. Does it work? PROBABLY NOT! Here's a counterexample: I have a copy of Magic Catalog in my Kindle. I am at the airport. I open Magic Catalog. I find I book I want to read. I click on the book. Automagically the book downloads to my Kindle. I get on the plane. I have to turn off the Kindle. When the seatbelt light goes off I bring out my Kindle to continue reading the PG book. Does it work? YES! Why? Because Ebook Readers and MOBI and EPUB formats understand what is necessary to give readers a "book-like experience." HTML doesn't -- because HTML was never designed to give a book-like experience. Neither was PDF -- PDF is designed to allow printers to print documents in a reliable fixed format. Why do people in the Ebook community continue to trash PG and get their free ebooks elsewhere -- even when those ebooks are derived from PG works? Because PG continues to not understand Ebooks and what it is all about. It seems silly to me given all the excitement around ebooks and ebook readers and given that the books are coming from PG volunteers to begin with that PG doesn't do the last 1/10th of 1% of what is necessary to get it to work with ebook readers. Should the existing PG site work with the built-in browsers in Kindle or some other ebook reader? Maybe it should, or maybe it shouldn't -- but the fact remains that IT DOESN'T -- it comes out looking like a hopeless and unusable hash. Other sites DO work, for example mnybks.net and freekindlebooks.org -- Why? Because the creators of those sites own ebook readers, care about ebook readers, and most importantly care about the owners of ebook readers.
James Adcock wrote: [snip]
Why do people buy an ebook reader when presumably they also almost all also own a computer with an HTML browser? Answer: the ebook reader gives a better more book-like reading experience. Why MOBI or EPUB format and not HTML? Because MOBI and EPUB formats understand what is necessary to make an ebook reader "book-like experience" work IN PRACTICE -- HTML does not.
Not quite. As most people understand, both the MOBI and the ePub formats are little more than compressed collections of HTML files. This is why PG can produce MOBI an ePub files on the fly; if an HTML version exists, just add a few metadata files, compress them together, and voilà, there's your e-book. Just as an experiment, download an ePub file but save it with a .zip extension; you should be able to use your favorite zipping tool to explore everything that's in it. Your confusion probably arises from the fact that /software/ which is designed explicitly to deal with ePub or MOBI files is /also/ designed to display the interior HTML in a way that makes it more "book-like" (e.g. page-oriented, with new pages starting at the beginning of chapters). If this same software is presented with basic HTML frequently it will display it in exactly the same manner it did the newer compressed formats. The old MobiPocket reader could actually open HTML files directly, and once opened you could not tell whether the e-book was in MOBI or HTML format. I also know from experience that the first generation Sony readers would also render HTML just as easily, and with the same presentation, as their own proprietary LRF format. My favorite software, µBook doesn't recognize the .epub extension, but can read HTML from inside of zip files, so I just save ePubs as zips and µBook handles them just fine. So, if you are looking for that "book-like reading experience," you should be more concerned with what software you are using than what file format you are downloading. There is plenty of software available, for a multitude of hardware platforms, much of it free, that will display basic HTML using the "book-like", paginated paradigm. On a related note, if you are producing an e-book, and you want to make it accessible to the largest audience, you should also focus on HTML, as it is the well-spring from which virtually all other formats can flow.
Your confusion probably arises from the fact that /software/ which is designed explicitly to deal with ePub or MOBI files is /also/ designed to display the interior HTML in a way that makes it more "book-like" (e.g. page-oriented, with new pages starting at the beginning of chapters).
My "confusion" is over why anyone would consider reading HTML via any of the major HTML browsers a "book-like" experience. I certainly know at least something about the internal formats of E-book files having made literally about 20,000 such E-books from PG HTML files. I've tried as many ways as I can figure out what HTML browsers can be "adjusted" to give a "book-like reading" experience and have always been stumped. Tried things like playing with the accessibility features, etc. Problems include no ability to set or adjust margins, no easy way to set the reading width, no easy way to choose a sensible reading font or sensible reading size, no way to adjust background vs. foreground contrast ratios to make the contrast less blinding, etc. It's not that all the e-book reader software "works" either, for example Adobe Digital Editions (ADE) ALSO doesn't have any way to set sensible margins. And it's not that the e-book readers are perfect either, for example Kindle doesn't allow sensible margin adjustments on PDF files -- where in effect often one would like to set a NEGATIVE margin allowance to remove some of the margin hard-wired into the PDF file. Kindle DX seems to perform automagic PDF margin trimming in portrait mode, but not in landscape mode. Also when one plays with the HTML browser to make book reading a more "book-like" reading experience, then that in turn screws up one's use of the HTML browser for non-book-reading "normal web site" experiences. Agreed that EPUB and MOBI are basically ENCAPSULATED HTML -- plus "SPINE" information. What then is the difference? HTML isn't encapsulated, is missing spine information, and comes with browsers which "don't get it." On the positive side, HTML browsers can do YouTube which I think is the way the HTML world is heading: namely video. We should be very happy that other people who like to read are willing to buy dedicated hardware to do so when they could instead be buying flip video cameras to film god say what! In short, I think we the entire computer world is actually still very much in the early days of learning what it takes to make reading a pleasant and transparent experience on one-or-another chunk of hardware. The paper book industry has had at least 400 years to figure this out -- too bad the CS types (of which I am one) don't look to the paper book industry to see how it ought to be done!
Jim Adcock wrote:
Your confusion probably arises from the fact that /software/ which is designed explicitly to deal with ePub or MOBI files is /also/ designed to display the interior HTML in a way that makes it more "book-like" (e.g. page-oriented, with new pages starting at the beginning of chapters).
My "confusion" is over why anyone would consider reading HTML via any of the major HTML browsers a "book-like" experience. I certainly know at least something about the internal formats of E-book files having made literally about 20,000 such E-books from PG HTML files.
I agree with your question; "why would anyone consider reading HTML via any of the major HTML browsers?" Particularly when you can read HTML via most of the major e-book readers? Perhaps more to the point, why would anyone think that when you have an HTML file you /should/ read it in a browser?
jim is asking for a new construction, to make it easy for those reader-machines to download your books.
There are two separate ideas I have suggested: Make "friendly" versions of the landing-pad pages that don't have frames nor images nor a lot of extra goop that is compatible with ebook readers and other small format devices. Make a "friendly" version of the PG website that doesn't have frames nor images nor a lot of extra goop that is compatible with ebook readers and other small format devices. [mnybks.net being an example of this second approach]
the easiest way -- which is what i just suggested -- is to link to some "deep" pages on the site, but that has been "officially discouraged" by your webmaster, at least in the past, and sometimes it gets enforced.
Again, Magic Catalog, in either MOBI or EPUB format at http://www.freekindlebooks.org/MagicCatalog/magiccatalog.html, is an example of such a "deep linking." I'd rather that it use ebook reader friendly landing pad pages, rather than direct "deep linking" but one cannot use something that doesn't exist. No offense, but it seems silly to "officially discourage" something when one is not willing to provide a viable alternative. Or else, simply admit that PG continues to remain hostile to the ebook community - which to me is also seems silly - every machine and every machine manufacturer, whether it is Dell, or Apple, or Mickysoft, or Amazon, or Sony, or what have you - each of these machines and manufacturers comes with its own particular mix of good and evil, and it seems to me the best approach is for PG to remain agnostic to the users choice of reader machine - and to try to support those machines which people are *actually* reading books on! Certainly the idea that cellphone companies don't come with their own mix of good and evil is highly laughable!
participants (8)
-
Bowerbird＠aol.com -
David A. Desrosiers -
Greg Newby -
James Adcock -
Jim Adcock
-
Lee Passey -
Marcello Perathoner -
Michael S. Hart