James Kilfiger writes: > What is your view of the aim in terms of compatiblity with 2e. Should > there be source compatiblity or formatting compatiblity. I'd say the > first is essential, if only in a compatiblty mode, the second may be > desirable, but only in a compatitblty mode. i have very strong feelings on compatibility and several people have already learned about it when i rejected a sensible change in the 2e kernel for reasons of compatibility. my main argument for 2e is that LaTeX 2e is an exchange medium as well as a typesetting machinery. this means that even sensible change/enhancements have to be judged as to whether introducing an incompatibility between two maintenance releases of LaTeX2e is worth the price. many people argue that this is no problem because feature X is not there in previous releases so couldn't have been used, but the problem in fact lies in the other direction: once a new feature is introduced and people and package writer use it they produce documents and/or packages which only work with LaTeX <date> and since a lot of people are unable to upgrade on regular basis this introduces a situation comparable to the last days of LaTeX2.09 where half of the installations couldn't process the documents of the other half (unless one kept at least three or four different `LaTeXs' around and even then) This is our basic strategy for not changing article.cls to produce a more decent layout or for adding feature X to the kernel (see ltnews07.tex) even if we agree that it would be sensible but this is all concerning 2e. James asked about 2e* and eventually ltx3. for what i'm currently doing i have somewhat different views. first of all, all the concepts and all the code that is currently being discussed and produced is explicitly written as a package solution to run on top of LaTeX2e. (this will change eventually but then we are going to call the beauty not 2e* but 3 or 2000:-) this means that a new class/package file that makes use of these concepts is a) something new that should run on every LaTeX2e installation that has installed the corresponding packages (and installing new packages is far easier than installing a new kernel) b) a document that uses a new class would not have any compatibility issues, other than with different versions of the 2e* package. the latter will certainly be a problem for a while which means hat it will take a while until something like a 2e* package can be reliably be used in production. But any document that uses the new classes or packages using the new concepts will also be "new", ie written with that information in mind. but what about all the million documents aready written? answer: as long as we are within 2e* and do not provide replacements for things like article.cls then nothing is going to change their formatting since they wouldn't even notice that there is additional stuff is around (since they do not load it). both together will allow us to thoroughly test the new concepts on a wider scale without compromising the production environment that LaTeX2e provides. in case we actually provide replacements for classes like article.cls there should be no difference either in the sense that a replacement for article.cls should of course keep the document command interface (100%) and as far as possible (no guess for a percentage) the layout. but i consider replacements for article.cls, report.cls and the like (within 2e*) more or less only as a test case for the templates (i.e., can we reproduce the (wonderful :-) original LaTeX layout) and at that state it should be done under different names to avoid any compatibility issues for the production environments at all. the moment we actually produce a kernel containing those concepts there is of course the need to produce replacements of the standard classes (as well as of a lot of packages that may benefit from the new concepts). As far as those replacements are concerned i agree that they should at least provide source compatibility and as far as possible also formatting compatibility. preferably this should be achieved automatically. but i wouldn't get totally unhappy if there is a need to automatically change 2e documents into ltx3 document via some translation process. after all, if you do not allow for this you either have to abandom any improvment (such as a better though perhaps not fully compatible float mechansim) or you have to provide a very very elaborate compatibility mode. what is more appropriate remains to be seen. right now i would not like to make predictions on what is better. frank