it won't be long at all before you have examples right in front of you of what i've said all along: plain-text files, done right, can be your "master", generating all the other formats your users want. this bears on the d.v.d. issue, because it means that you won't need to include anything but the plain-text files and the pictures, for most e-texts. someone who wants an .html version, or a .pdf, or an .rtf, will be able to generate it themselves, using the exact specs they want (font, size, etc.), using an interface tool included right on the d.v.d. there is one problem that still stands in the way: your plain-text files are _not_ being "done right". for the most part, they are very close, but there is one huge exception. your plain-text files do not have any indication of which picture-file is included where. it is typical to mark the spot of an illustration with:

[illustration: this is the caption of the picture.]

but if you look at that, you'll see that -- although it nicely tells users that "a picture goes right here" -- it doesn't tell them _the_filename_ of that picture! at first, i thought this was just a simple "oversight", based on the fact that most plain-text viewers won't automatically incorporate pictures into their display... (i should note that, over here on the mac platform, the standard text-editor will indeed incorporate them, and has for about a decade. even though it does so rather clumsily, implementation-wise, it's not unknown.) anyway, i believed when i notified the people in charge that my viewer-program will happily display a picture at the point where it should be included, if they'd just include the _name_ of the picture-file it should display -- because otherwise, how would it know which one? -- that they would say, "hey, that's cool, thank you", and start putting the picture's filename in the illustration tag. amazingly, though, for reasons that i still cannot fathom, when i politely asked that this change in policy be made, the reply was a brusque "no". not only that, but when i persisted, thinking there was a simple misunderstanding, because why would they reject such a sensible suggestion, the responses got increasing hostile. and i was perplexed... leaving their hostility aside, i am still trying to be polite here. it _makes_sense_ to include the filename in the illustration tag. even the readers of a plain-text file might want to know exactly which illustration it was that goes in that spot, might they not? after all, why even tell them that "a graphic was placed here", if you're not going to inform them _which_ graphic that it was? it seems -- i don't know -- a little _silly_ to do that, doesn't it? and it makes even more sense to include the graphic filenames once you're aware of a viewer-program that will splice them in the display of the plain-text file, don't you think? i certainly do. and the real kicker here is that this graphic-filename information is _already_being_generated_, for construction of the .html file! but it is being _willfully_discarded_ from the plain-ascii file! why? i'm not asking anyone to do any extra work to include the names; in fact, it takes an extra step of work to toss out this information! why is this _useful_information_ being _intentionally_ thrown out? (i wrote a program to recover the filenames from the .html file, so i've now engineered a workaround to this problem for myself, but i wonder why it is you'd throw info away in the first place...) and so i submit -- once again -- my request to change this policy. -bowerbird