al said:
> What bowerbird failed (or didn't bother)
> to mention was that
> using curly braces for page numbers
> and square brackets for footnotes \
> are practices that are documented in
> PG's Volunteers' FAQ (V.98, V.99, V.103).
> As such, my "personal practice" is not
> an invention of my own, but are PG-standard,
> documented, practices that I've adopted for my projects.
discussions here are often so pointless it's not worth bothering.
and yet i persist. sometimes i think _i_ must be the stupid one.
but then, no, i realize, no, it's not me that's the stupid one at all.
***
so...
what al failed (or didn't bother) to mention is that
whether or not any contributor _follows_ the f.a.q.
is entirely a personal matter up to them...
and that's why the f.a.q. don't really matter much...
not unless the whitewashers enforce a particular aspect.
and this one has not been enforced.
so the vast majority of the .txt files have no pagenumbers.
(well, actually, it _is_ enforced. because v.98 actually instructs
producers that they should _not_ keep pagenumbers, except in
"exceptional" cases. al tried to slip a fast one by us there, eh?)
so p.g. has failed to create a convention about how it is done,
even inside of its own cyberlibrary, let alone _outside_ of itself.
and let me tell you that i respect michael hart's _principled_
decision not to enforce a standard much more than i respect
a naive belief that -- just because it's in the f.a.q. -- you have
established a convention. i don't respect that naivety at all...
on the other hand, michael's unwillingness to take a stand
_has_ meant that the producers have overruled the f.a.q.
d.p. postprocessors have taken to including pagenumber info
in their .html versions over the course of the last few years...
many now include the pagenumbers as a matter of _routine._
that's the good news.
the bad news is that the laissez faire attitude is paramount
in d.p. postprocessors. they do things however they want.
and they change how they do things whenever they want to.
so, over the course of those last few years, they've treated
pagenumber info in countless ways, with zero consistency.
so it will be difficult or impossible to construct a "standard"
from the d.p. practices, especially since the information is
buried in the source .html, and not evident on the surface.
it's also the case that there continue to be major problems
with _all_ of their implementations, for reasons that might
well be unavoidable, such as browsers that do not support
the kind of functionalities that might be necessary to walk
that tightrope i talked about between "pro" and "anti" forces.
but, for people who like to view the glass as being 2/10 full
instead of 8/10 empty, please enjoy the fact that the people
who finish off the e-texts at d.p. now value pagenumbers...
yet al still remains clueless...
and his cluelessness moves up to a higher level as well.
because remember that the _reason_ we want a convention
is so that the developers of viewer-programs will support it,
by programming the necessary capabilities into their apps...
does anyone know any app developers who have done that?
i mean, besides _me_ with _my_ apps? yeah, i thought not...
the convention, even if obtained, is just a means to an end.
and the pointlessness continues...
one of the useful aspects of pagenumbers, as don points out,
is they allow us to refer back to the page-scans of the book...
but the f.a.q. betrays no knowledge of this beneficial purpose,
and thus fails to enlighten the e-text producers of this linkage.
if it _was_ based on this broad goal, the f.a.q. would also show
awareness that pagenumbers per se are but a small part of the
overall needs, along with things like _the_original_linebreaks_
and _the_original_end-line-hyphenates_. without those other
vital aspects, it's similar to "baking a cake" with sugar as your
only ingredient; the thing you get out at the end won't be cake.
i talk more about this in the reply i drafted over the weekend,
which i still intend to send today, so i won't belabor it now...
-bowerbird