re: Re: [gutvol-d] Re: aspects of a well-done e-book
I can hate IE and still support it. Honest! What I do, personally, is create a minimum functionality that will work in all browsers. Then, if I see a need that goes beyond that, and only some of the browsers support it, fine. As long as it doesn't degrade the minimum functionality in all browsers, I'm willing to add it. That is what the page numbers markup currently does. It hides the page numbers for those the minimum, default behavior, but if you have a browser that supports it, you can see those page numbers appear. Similarly with poetry. It has features that allow the browser to rewrap nicely if there is a long line, if the necessary CSS support is there ... but if not, it still displays the poem with its normal indents, it just doesn't rewrap nicely for you. If I try something and it dies on one of the browsers, I take it back out or find another compatible way. In my case, at the very least, if you find something I've worked on that does NOT degrade gracefully in Lynx, etc.... Let me know. I consider that a bug in my work. Josh ----- Original Message ----- From: "D. Starner" <shalesller@writeme.com> To: "Project Gutenberg Volunteer Discussion" <gutvol-d@lists.pglaf.org> Subject: re: Re: [gutvol-d] Re: aspects of a well-done e-book Date: Wed, 20 Oct 2004 09:21:03 -0800
"David A. Desrosiers" writes:
a big shame, since i.e. still has -- what -- 93% of all surfers?
And decreasing every day.
Users aren't using MSIE because it is the superior product, they're using it because they have no idea there are significanly more secure, functional, compliant browser alternatives out there, and because it came with their pee-cee, with a nice convenient icon right on their desktop.
And nothing's going to fix that in the forseeable future. And what about us who serf the net through the services of a library, and have no option on which browser to use?
I really think you'll are dismissing IE and Lynx too quickly. We can't just support Mozilla, now or in the future. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/listinfo.cgi/gutvol-d
At 01:41 PM 10/20/2004 -0500, you wrote:
That is what the page numbers markup currently does. It hides the page numbers for those the minimum, default behavior, but if you have a browser that supports it, you can see those page numbers appear. Similarly with poetry. It has features that allow the browser to rewrap nicely if there is a long line, if the necessary CSS support is there ... but if not, it still displays the poem with its normal indents, it just doesn't rewrap nicely for you.
OK, but I have a question. I regularly use Lynx because of convenience. I prefer plain text but I will sometimes use lynx to convert html when necessary. Let's say that I do, in fact, want the page numbers. How am I supposed to get them if my browser doesn't support it? Lynx doesn't do css as far as I know, so what you're saying is that page numbers will always be hidden from me unless I want to look at the raw html source. Because plain text is, among other things, removing the markup from html, wouldn't that also eliminate the page numbers? I can use IE and it is accessible to the blind, but according to what you said IE hides different styles anyway. So, unless I misunderstood the above completely, some information will always be inaccessible to me. Right? Please don't tell me to use Mozilla or some other browser. At some point they will probably be accessible, but not for now. They are working on it but aren't there yet. I would like to repeat that I still prefer plain text and normally I wouldn't even care about line indents or page numbers. However, it would be nice to at least be able to access the information if I have a need for it.
--- Tony Baechler <tb@baechler.net> wrote:
OK, but I have a question. I regularly use Lynx because of convenience. I prefer plain text but I will sometimes use lynx to convert html when necessary. Let's say that I do, in fact, want the page numbers. How am I supposed to get them if my browser doesn't support it?
The markup I'm currently using for page numbers will not display them on non-CSS-capable browsers -- and by default won't display on CSS capable browsers either unless you change the stylesheet / switch to an alternate stylesheet. It would be possible to use a different markup, which wouldn't display page numbers on CSS-capable browsers (which can hide sections of HTML), but would always display them on non-CSS-capable browsers. As text-mode browsers are the main example of non-CSS browsers in use today, the former markup made more sense to use, as it replicates the behavour exhibited by the text-only edition (which doesn't record page numbers). Both markup styles allow you to navigate to a particular page number, even in non-CSS browsers, by using named anchors (i.e. append #pageXXX to the end of the URL). As you say, the information is in the source file, but currently inaccessible to you. One of the ways to solve this problem is to switch to a relatively standard master document format, such as TEI, combined with flexible tools that could convert the source to other editions such as HTML or text, while allowing us to choose how much of the preserved information, and to also choose how that information was encoded. You could then easily generate for yourself a 'with page numbers' text edition of the document you're interested in. -- Jon Ingram __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
At 01:02 AM 10/21/2004 -0700, you wrote:
As you say, the information is in the source file, but currently inaccessible to you. One of the ways to solve this problem is to switch to a relatively standard master document format, such as TEI, combined with flexible tools that could convert the source to other editions such as HTML or text, while allowing us to choose how much of the preserved information, and to also choose how that information was encoded. You could then easily generate for yourself a 'with page numbers' text edition of the document you're interested in.
So, does this mean that I now not only have to download the master xml file, the css, and a set of conversion tools? You must be kidding, right? If it came to that, I would rather have the plain text and forget the page numbers. It is already inconvenient to use "lynx -dump -nolist filename.htm." Why in the world would I want to run it through a conversion tool and still have to do that anyway? OK, so a plain text file can be output directly from the xml. I still have to go through at least one extra conversion step that I wouldn't have to otherwise. I had a look at sgml just to see how hard it would be to get plain text. What a royal pain! I gave up when it kept complaining about some file missing when I was using their samples.
--- Tony Baechler <tb@baechler.net> wrote:
So, does this mean that I now not only have to download the master xml file, the css, and a set of conversion tools?
If you wanted material in plaintext format which wasn't in the plaintext edition provided already, yes.
If it came to that, I would rather have the plain text and forget the page numbers.
If you want the mainstream plain text edition, then you download the mainstream plain text edition. If you want to create your own edition with extra material, then at the moment you're completely out of luck, as there's no way for you to generate it. With a transformable master document, then you get the chance to get your hands on this information in the format you want, for the first time. -- Jon Ingram __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
So, does this mean that I now not only have to download the master xml file, the css, and a set of conversion tools? You must be kidding, right? If it came to that, I would rather have the plain text and forget the page numbers. It is already inconvenient to use "lynx -dump -nolist filename.htm." Why in the world would I want to run it through a conversion tool and still have to do that anyway? OK, so a plain text file can be output directly from the xml. I still have to go through at least one extra conversion step that I wouldn't have to otherwise.
Why? The whole idea behind PG moving to XML is not to complicate things, it's to give more flexibility while retaining simplicity. How about this situation: PG files are, by default, coded in XML. All other formats are then automatically generated from that XML format. There would still be TXT versions, there would still be HTML versions. Getting those would be no harder than it is for you to retrieve a TXT file now. All this conversion stuff should be done by the PG back-end, not the end-user (why make a human do a machine's job?). That way, instead of manually preparing every different format like what goes on at PG for the most part now, we could make every format available with only the effort of creating a super-format from which every other format could be derived and a set of tools which could automatically generate other formats from the super-format. If someone wants the entire PG library to be available in some obscure format, then it could be if they can just write a converter which outputs that format. Cheers, Holden
At 05:49 PM 10/21/2004 +0100, you wrote:
So, does this mean that I now not only have to download the master xml file, the css, and a set of conversion tools? You must be kidding, right? If it came to that, I would rather have the plain text and forget the page numbers. It is already inconvenient to use "lynx -dump -nolist filename.htm." Why in the world would I want to run it through a conversion tool and still have to do that anyway? OK, so a plain text file can be output directly from the xml. I still have to go through at least one extra conversion step that I wouldn't have to otherwise.
Why? The whole idea behind PG moving to XML is not to complicate things, it's to give more flexibility while retaining simplicity. How about this situation:
Apparently context was lost here. The "why" is that, according to what Joshua was saying, the page numbers are not available anywhere in the plain text because they would look ugly. OK, I understand that and I myself might not even want them most of the time. However, if I decide that for a particular file I want them, I have to go to the master xml document and do my own conversion. The PG supplied plain text won't help me, and the html won't work correctly in Lynx or IE. Therefore, I have to redo the conversion to get the information I want in the plain text file or whatever other format. This does not seem simpler to me.
Tony Baechler wrote:
according to what Joshua was saying, the page numbers are not available anywhere in the plain text because they would look ugly.
However, if I decide that for a particular file I want them, I have to go to the master xml document and do my own conversion.
This does not seem simpler to me.
That may not be simple but is still better than what you have now: if the txt file happens to lack the page numbers there is no way you could get them short of redoing the book. In TEI, it may be not quite simple to set up, but you *can* do it. (And you can do lot more.) Im my eyes that's a big advantage. Of course, XML is not and has never claimed to be the solution to all the world's problems. ZML is :-) -- Marcello Perathoner webmaster@gutenberg.org
Tony Baechler wrote:
So, does this mean that I now not only have to download the master xml file, the css, and a set of conversion tools? You must be kidding, right? If it came to that, I would rather have the plain text and forget the page numbers. It is already inconvenient to use "lynx -dump -nolist filename.htm." Why in the world would I want to run it through a conversion tool and still have to do that anyway? OK, so a plain text file can be output directly from the xml. I still have to go through at least one extra conversion step that I wouldn't have to otherwise.
Why? The whole idea behind PG moving to XML is not to complicate things, it's to give more flexibility while retaining simplicity. How about this situation:
Apparently context was lost here. The "why" is that, according to what Joshua was saying, the page numbers are not available anywhere in the plain text because they would look ugly. OK, I understand that and I myself might not even want them most of the time. However, if I decide that for a particular file I want them, I have to go to the master xml document and do my own conversion. The PG supplied plain text won't help me, and the html won't work correctly in Lynx or IE. Therefore, I have to redo the conversion to get the information I want in the plain text file or whatever other format. This does not seem simpler to me.
Why must _you_ do it? If the information's available, then it would be TRIVIAL to add an option to the TXT or HTML converter which says "check here if you want page numbers included." We're really arguing over features in a system which hasn't been built yet, where even the form of the system isn't even set yet. _I_ can envision a system where we have the standard TXT and HTML files generated in the same format as we have them now but where there's a simple web page where you can configure the version you want. Want Page Numbers? Tick a box. Want each chapter in a separate file? Tick a box. So, whereas before, you had to have the standard TXT or HTML versions because that was all that was available, now we can actually talk about making customised versions as people want them. Maybe the settings could even be stored as a Cookie so you choose which settings you want once then every time you look at a text on PG, the text will be created as _you_ like it. We can only do cool stuff like this _because_ we're creating this new super-format which contains information far beyond what was previously available in the TXT and HTML versions. Cheers, Holden
participants (5)
-
Holden McGroin -
Jonathan Ingram -
Joshua Hutchinson -
Marcello Perathoner -
Tony Baechler