I'd like to refocus the discussion to what I think is one the key issues: author-author and author-publisher communication. First, I think that the distribution problem should not be a concern of LaTeX development. TeX/LaTeX will increasingly be distributed through distributions like teTeX as opposed to users downloading the core packages individually; those distributions will define which packages are available to the average users, as well as provide update facilities which will depend heavily on the upgrade procedures which are common to the target platform (e.g. rpm). While I agree that it is extremely important to have well-maintained distributions, this issue is external to LaTeX. So the question remains what packages as well as coding conventions (!) should I use if my goal is to maximize the exchangeablility of my documents. This includes: - The ability to easily recycle snippets of my documents by myself as well as current or future collaborators. - Increase the chance that my documents will run on future versions of LaTeX. - Make it easy for my co-authors not only to run my documents, but also to change them or add their contributions without creating a big mess. - Be sure that a document that I prepare will be accepted by a reasonable publisher in my field for direct electronic submission, and will not be retyped or otherwise mangled in unpredictable ways. - Allow my documents to be translated into other formats (HTML, XML or whatever else may come along) with the least amount of losses. This is a whole different question from what should be distributed as LaTeX: There are many things that I would like to do in certain types of documents (think of letter classes) where the above issues are not really first priority. However, one of the main advantages of LaTeX, when properly used and maybe improved, is that it has the potential to achieve achieve very good document exchangeablility as defined above. David Carlisle wrote: > > and UNLESS IT IS WELL DOCUMENTED, which, as > > far as the practical problems go, is problem number one > > Documented, and agreed. If you (for example:-) were to volunteer to > draw up a list of `must have' packages, and wrap them all in some > consistent installation and documentation format, and document how this > is the minimum required latex installation for document interchange. I'll try to start this list from my point of view, I'd be willing to collect everybody's answer to the question "In my professional writing, which tools are indispensable, and which ones do I prefer to use when alternatives are available". Please send them by private mail (this list is getting too noisy), maybe I'll also ask on c.t.t. I'd also like to know from the publishers on this list what they think about these issues. For Mathematics, at least the areas that I work in, the needs are rather modest: - The AMS packages are absolutely indispensable, as is the AMS font collection. Comments: this may seem rather trivial, but other than the AMS I haven't seen a publisher who didn't screw up on vanilla amsmath stuff (this includes Elsevier a couple of years ago, I suspect this may have improved by now) and even this year one publisher (not the big one with the yellow books) seemed to use the 2.09 based version, with easy to imagine problems that had to be corrected in the page proofs. SIAM implements functionality like subequations in a slightly different way in their author classes (apart from the issue that such stuff IMHO shouldn't really go into a class file), and I have seen many things which should be really standard but which are not (theorems, for example). In many cases the core functionality of LaTeX is either broken (equarray) or insufficient (theorems), so that the extension packages are needed for basically ANY work in the field. Thus, the basic LaTeX provisions should be removed from all documentation (personally I also think that stuff like equarray should produce a warning "You are using a broken command"). Summary: Here I think it's mainly a documentation problem which prevents that very necessary and useful packages are not always used. - graphics/graphicx for inclusion of illustration. - some good bibliography package (natbib)? (I have to admit that I never got round to starting a bibliography database, and I haven't missed it much. For some people this seems to be quite important. Also, I guess I would really start using natbib, for example, if publishers were to tell me "if you start using this very good bibliography package, we won't screw up your references any longer," in other words, if natbib would be elevated to be a standard publishing tool.) - Some frontmatter package which is at least equivalent to the functionality that the AMS classes provide. (We've started this discussion, some more comments on frontmatter below.) Physics: Here I am not so sure what the main issues are, but I'd guess that for a lot of stuff the above applies, too. I guess some provision should be made for the consistent mark-up of units (I have seen publisher's packages which provide for this, but again, this is not really be addressed unilaterally by a publisher) as well as a different set of special symbols. Apparently the frontmatter is more tricky as sometimes papers are written by lots of people. Anything else? Computer Science: The math stuff probably applies here, too. Some standardized mark-up for program listings? Humanities? Maybe this is not so critical here as few publishers would consider accepting LaTeX anyway? Anything different for Astronomy? I should stress here that I do not want subject specific standards. In my opinion, an updated RevTeX is not a desirable goal. What we need is a collection of standard packages (like amsmath) which can be loaded for certain purposes, complemented by a set of rules which specify what a portable document may contain, so that ANY publisher can process the document with only header changes with their production class. Of course it would be nice if they would make their classes public... This raises the issue about what should be admissible in a portable LaTeX document. E.g., should things like \enlargethispage be legal in such documents? The answer is not clear to me. One could either explicitly discourage people to use them, or to expect any production class to ignore any visual mark-up and provide the functionality with different macros. Then there are red herrings like \beq and \eeq that some people place all over, the general question of what macros one may define in portable LaTeX documents etc. Probably publishers know better what problems may come up, but the important thing is that this does not belong documented in a publisher's instruction file but into the most basic LaTeX reference book (meaning Lamport's reference, with all due respect to Lamport, should be banned). Other issues may be: - Output to PDF, thus disqualifying fonts which are not also available in Postscript Type 1. - Mark-up of tables (I think this is an area where LaTeX is really deficient, both in functionality and in the necessity of visual mark-up even for many trivial tables). - Guidelines for including graphics (psfrag???) I am sure this list could be much longer. Anyway, most of these problems mostly require adequate documentation from an authoritative source (cathedral style, if you want to call it like this), apart from the problem of defining and implementing a universal frontmatter interface. Frank Mittelbach wrote: > this stability is extremely important in the latex community, even > upward compatible changes are considered bad by the majority of the > users as we often had to find out because any such change means that > some document only works if everybody uses version xyz dated... so > portability goes down the drain. the need to be up-to-date if > extensions are part of the game is far more accepted (ie getting a new > package) but to be forced to change "the latex installation" is > unfortunately something most people think is an unnecessary luxury > since after all it does work. In the context of frontmatter I believe that the benefits by far outweigh the disadvantages. The problem is already there: If I want to publish in journal X, I have to download journal X's preprint class plus documentation (assuming journal X is nice enough to provide one), possibly change my document so that x.cls runs it. All of my co-authors will have to do the same if they want to be able to process the file. So if it is possible to, once and for all, provide all the means necessary in the base of LaTeX so that individual author classes become obsolete, even on the expense of compatibility problems with old installations, this would make a lot of peoples' lifes much easier. In any case, I feel there are people who are much more competent than I am to address the frontmatter issue, but I would be happy to contribute to the discussion, or write some hacks or documentation if some consensus about the best way to approach this can be reached. On a final note, the motivations of the publishing trade are still mysterious to me: Sebastian Rahtz wrote: > > ultimately incompatible. I really know SGML/XML (Sebastian, what do > > you hope to get out of the LaTeX3 project that you think you cannot > > get out of SGML?), > I want a reliable batch-oriented page makeup system, no more, no > less. I want to store my text in XML, and have LaTeX produce beautiful > pages when I give it a style sheet Are you speaking for yourself, or for Elsevier? While I could see that XML/MathML may make sense for me in certain circumstances, because I may want to reuse the logical structure, I don't see why this should matter for a publisher whose job it is to get the thing on paper, and possibly into an online repository (PDF?). There does not seem to be a widely available user interface for XML, so currently, it also does not seem realistic to expect authors to submit XML. So what's the problem with LaTeX (apart from the ones that we discussed, and seem very much fixable)? It should be much preferable to, say, Word's .doc format or rtf??? Marcel