Luke Simon <[EMAIL PROTECTED]> writes: > > It would be very useful to have a document class that contained a union > of all known environments, so that in the early stages of writing a > paper, before you know exactly where you are going to submit it, you > could write it in the "Uber Document Class" and use environments as > needed. Then when you needed to actually submit the rendered PDF, you > could change the document class to a specific one and the environments > would be mapped to existing environments in that corresponding class and > if they didn't exist, then a predefined mapping for the target class > defined how to emulate the environment.
I don't think a so-called Ãber-Documentclass would be very helpful. The difficult part is to define the mapping from one environment to another. Once you have that, you could as well switch between classes directly. What I would like is a way that package introduce new layouts into a document. Then you could produce your own modular "Ãber-textclass". > > For example, some classes contain some subset of special environments > for addresses, phone numbers, email addresses, proofs, lemmas, theorems, > corollaries, etc, and since there is no, as far as I know, class that > contains all of them, you are forced to guess your best match and then > later do allot of manual changes to properly use the final target > document class. You can try that for yourself now already: Just create a new uber.layout which includes all the layouts you want. You might need to cut&paste a little to avoid certain conflicts, but then there you are. When you change from this class to an "unter-textclass" you will get errormessages for any paragraph whose layout can't be mapped. BTW, any volunteers who want to enhance this error dialog to allow userdefined mappings? :-) Ciao /Andreas
