X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil] [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) Date: Sat, 9 Jun 90 17:59:26 CET Reply-To: LaTeX-L Mailing list From: bbeeton Subject: Re: Front matter definitions To: Rainer Schoepf Status: R X-Status: X-Keywords: X-UID: 127 regarding the distinction between "frontmatter" and "backmatter", yes, there are both, but i have found that, as a general rule, treating all the information that might reasonably go into a full citation or an archive as frontmatter is more convenient than dividing it up on the basis of where it will actually be printed. for example, some publications put an author's address at the beginning of the document, some at the end. and some even put it in a separate section with short author biographies. (at the math society, we've been calling this all "topmatter", with the implication that it's to be included in a file at the top, and it's up to the macros to put it in the "right" place.) regarding the date, as in leslie's question, i believe there are (at least) two dates: date of record, and date a copy was generated. if i have two files representing two versions of a document, it's important for me to know which is earlier or later. for that to be known, somehow the last update date has to be associated with the file itself, and it is *not* satisfactory to simply let \date=\today when the document is run through latex -- that only results in major frustration. there are some software management tools that allow this information to be included in a file automaticaly, or the originator can do it by hand; however, this is not something that any implementation of tex knows how to handle properly if the information isn't there. [end flame] there are yet other front matter elements not listed by don -- subject classification, keywords and dedication come to mind in the math society's journal styles. but he's correct that every publisher is going to have one or more styles, different possibly from anyone else's. that's one of the reasons that sgml standardizes *how* to generate a markup system for any class of documents, not the elements that must/may be present for particular classes. providing a good framework and tools for implementing a publisher's required/desired styles is what latex should do, not lock all documents into just a few predetermined ones. -- bb