[Marcel Oliver:] > > If you look at these classes, they point to some problem which will > > grow in the future: The standard LaTeX classes have a rather > > restricted set of front matter commands. So every publisher is > > extending them in mutually incompatible ways. [Sebastian Rahtz:] > I agree 110% about this. Front matter is an area that causes immense > pain and suffering for all concerned, and a standard markup would be a > huge plus. Past discussion among the LaTeX team raised the issue that each documentclass usually has, in addition to the frontmatter elements that are clearly of general applicability, one or two other elements that are unlikely to be relevant for any other publisher (or publication) than the one to which the documentclass is written. The \commby element in amsart is an example, and \subjclass would be as well if it were named \MathReviewsClassificationNumbers which is its real semantics in the amsart context. The proposed solution was to have a special frontmatter section where elements unknown to the documentclass could be ignored---perhaps with a warning---instead of generating a fatal error message. In other words, rather like BibTeX, where fields in a .bib entry not recognized by the .bst file are simply skipped over silently. Indeed one idea was to actually put the frontmatter into BibTeX form, more or less, and I think Johannes Braams might have done a prototype at one point. I seem to recall that this has also been proposed a time or two by other people on comp.text.tex or latex-l. There is also a resonance here with the standardized file header syntax advocated by Nelson Beebe (CTAN: filehdr.el etc), though it's my impression that he envisioned those headers mainly as a top-of-file _comment_, separate from the real contents of the file; in the frontmatter case the file header would be part of a document's content. In my opinion the principal barrier to a package implementation of BibTeX-style or filehdr-style frontmatter handling is resolving certain complex data structure issues with the author data. If you want to be able to print multiple author names and addresses in different forms depending on the documentclass, you need a capable data structure, and while the amsart data structure is more abstracted than that of the generic article documentclass, I still see room for improvement. At least, if one wants to handle publishing requirements like printing the address as a footnote with different authors sharing the same footnote number if they have the same address (how does the user indicate in the frontmatter that an address is shared? probably some sort of label-ref mechanism). Or how do you handle special cases like former address current address temporary address during 1997 while this author is on sabbatical these authors have the same institution address but different email addresses this author has two addresses, actually, and they both have equal standing this author died since the submission of the article and we want to use a different type of footnote marker on his name for a footnote explaining that the article is being published posthumously And then you might want to change three or more author names A, B, C, ... to the form "A et al." in the running head, or for two authors use initials instead of first names in the running head, and so on. The only way to make this possible across a wide range of documentclasses is for the granularity of the data structure to be fine enough to handle even the most esoteric rendering requirements of the most esoteric classes. Costs include (1) the macros to put all the pieces together must then become more complex, for all documentclasses even those that have simple rendering needs, and (2) it takes more work for authors (or publishers's submission-processing staff) to provide all the required markup. Next complication: after you have broken down your data in resplendent detail, you discover that it has become difficult to conveniently handle special exceptions outside the set of special exceptions that you already arranged to handle (in your gloriously baroque macros), and certain things that are semantically orthogonal to the data structure (such as "linebreak here, in the main list of authors, but not in the running head of course"). There needs to be some sort of escape mechanism. One of these days when I get a round tuit I'll probably end up writing a new frontmatter interface, but if someone else can manage to do it first and save me the work, so much the better. Michael Downes, [log in to unmask]