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