david said:

Aren't you the programmer in this case?

nope, not for the o.e.b. reader-program. i _am_ the programmer for my program, which takes a text-file in z.m.l. format. this is my own project as an individual; i wrote it as a present for michael hart. for the o.e.b. viewer, i would have volunteered my services toward sheparding the project and designing the user-interface and functionality. but, as i said, since jon noring has now started his own open-source effort to make a reader-app, i would suggest programmers support him instead. ***

And I'm saying DON'T maintain an XML file. Maintain the text, in a structured, normalized format (i.e. add some parameters by which paragraphs can be spaced, quotes can be used, etc., ala LaTeX).

that's what i'm saying, david. and z.m.l. is my version of that "structured, normalized format". but the company line here is that the x.m.l. file will be the master.

If you have it in beta test already, why not submit what kinds of files IT can produce

my program is a viewer-program. it doesn't produce files. it takes ordinary plain-text raw-ascii files as _input_ -- i.e., files just like the current e-texts in the library -- and displays them, giving the user the complete range of functionalities they should expect in an electronic-book. generating other versions of an e-text -- like .html -- (and i'll try to remember to preface "html" with a period) is an add-on for a later version of the program. the purpose of my program is to give the end-user all of the _benefits_ of a marked-up file, without any markup. to do that, my program has to figure out the _structure_ of the file on its own. naturally, once it has _done_ that, it will be relatively straightforward for it to churn out an .html file (or an .rtf file) that reflects that structure. as far as generating a .pdf, the end-user can do that by printing the e-book to a .pdf driver.

The point is, turf-wars, name-calling, and vaporware projects aren't adding value to the overall goals of PG, as I read them.

i agree. but my program is not "vaporware". and if i can -- as i say -- give the benefits of markup to end-users without requiring project gutenberg to actually _do_ any markup, then i think i'll add immense value to the overall goal of the project. but i'm sure the x.m.l. advocates will _still_ want to do markup. some people just _like_ doing things the hard way... ;+) -bowerbird