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