john said:

Hello Al, Juliet and Jim: Thanks for your detailed replies.

i guess those detailed replies were sent backchannel. i wonder why, in response to a post sent to a public listserve, people reply privately. why not in public, so everyone benefits?

More generally, I now understand that, if I can contribute at all, it would be to help in packaging content for others to convert to PDF, XML, or whatever other format may become fashionable In this connection, the reply from Juliet looks very enticing.

again, why not put this "enticing" reply on the public record?

To explain: I am one of the XML true believers and TEI, or something like it, is ultimately the way to go.

i'm glad you shared that with us, john. it's always good to know when someone is "a true believer", and "logic" might not apply...

But TEI seeks to be all-inclusive and doomed to be very big and complicated (think SGML).

well, very good. at least your "true believer" status doesn't prevent you from seeing some problems with the religion...

And working with XML is so painful and error-prone for humans.

again, most excellent. most of the "true believers" tend to gloss over the difficulties... but you seem to be more aware.

I don't know how big the PGTEI subset is, but there is a good chance that it might be expressible in lightly marked-up text, which can easily be parsed into XML.

my research shows you can assume that a "lightly marked-up text" will indeed be sufficient to cover the p.g.t.e.i. subset, and i agree that the lightly marked-up text can easily be parsed into x.m.l.

If that were the case, I can become usefully involved at the DP end.

it's possible.

To state Basil Fawlty's bleedingly obvious, it might then become PG's long-term aim to provide PGTEI versions of all texts, from which all styled versions can be derived-- and the only one version to be maintained.

there is a certain appeal to that logic, unquestionably... (and, since it's _logic_, there's no religion needed here!)

In summary, without being very clear about it, I had thought that I might be able to contribute to PG by generating more refined documents from existing books (gratuitous, I admit); but now I suspect that I might be more useful by wrestling with the software.

well, first, that original belief of yours was not "gratuitous". the fact that it doesn't fit nicely within the p.g. workflow is as much the fault of the workflow as with your orientation. but we know who holds the power in this situation. i'm not sure that your .pdfs were indeed "more refined" -- i have become a bit allergic to that typical latex look, and there were some other basic problems with your output -- but your original intention was certainly a worthwhile one. and it would have been fun to pursue that approach a while.

(gratuitous, I admit); but now I suspect that I might be more useful by wrestling with the software.

as i said, it's possible. but you might find some potholes on that road too. i'd suggest that you study what rfrank has done at d.p. you will learn a lot from the false paths he has taken... however, john, before you disengage here entirely, i must share a certain question with you. pardon my impertinence. there's no need for you to answer this question, or even try to answer it. and i will add that i have no motive here to challenge your status as a "true believer" even if i could. (and part of your being a "true believer" is that i could not.) however, for the sake of those of us who are _not_ "believers", let alone "true", i feel a need to articulate this side of the wall. you've conceded that t.e.i. and x.m.l. are too complicated for most humans, including the vast majority of volunteers at d.p. and you've posited that light mark-up can be converted into these more-complicated systems for storage as the "master" from which we could then generate multiple e-book formats. so this is the layout in your head, as far as i can tell: s = simple system = light mark-up c = complicated system = heavy markup (p.g.t.e.i. or x.m.l.) m = multiple e-book formats so you're suggesting that the workflow look like this: s -> c -> m where "s" is what people work on, "c" is the master format that is maintained as the p.g. library, and "m" is the output. in particular, you're saying that you might be of some use in converting "s" into "c". and perhaps also "c" into "m". cool... the question i have is this: why shouldn't "s" be the "master" format, instead of "c"? after all, you've conceded that "s" is simple to maintain, whereas "c" is difficult. so why not maintain the library in a _simple_ format, and then -- whenever we want to convert the books into the "m" multiple output formats -- make the s->c conversion the first step in that process? further, why not skip the "c" step entirely, and just convert "s" into "m" directly, if it's possible, and why wouldn't it be? oops. i guess that's two questions. but you get my drift... -bowerbird