Re: Feature Request: Uber Document Class
On 8.02.05, Andreas Vox wrote: Luke Simon [EMAIL PROTECTED] writes: 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. We already have the ObsoletedBy directive, that can take care of some of this cases. E.g. converting from article to article(scr) will map LyX-List to Labeling: # List style definition Style List ObsoletedBy Labeling End My version of dinbrief.layout (http://wiki.lyx.org/Layouts/Dinbrief) has 29 ObsoletedBy declarations not only to make it backwards compatible, but also to facilitate conversions of documents from other letter classes. However, it doesnot work backwards. For backwards compatibility (scr to standard classes) one could * use an ObsoletedBy clause in every non-scr layout file, or * rename the Labeling style to List (and add a Labeling ObsoletedBy List to the new scr-layout). (Only sensible if both Styles are 100% compatible. * have something like a DegradesTo directive, that gives the best approximation for cases where a Style is not available (together with a warning to the user as currently). The last option would also be of wider use: e.g. I have defined a CondensedItemize list that has less vertical spacing than the standard Itemize. If I pass my *.lyx file to someone (who doesnot have my gm-extensions.inc layout file) CondensedItemize will be converted to Standard. With Style CondensedItemize # my definitions DegradesTo Itemize End it would at least approximately work as expected. BTW, any volunteers who want to enhance this error dialog to allow userdefined mappings? :-) The DegradesTo directive would do exacly this (replacing the converted to Standard with whatever Style is given as approximation. Günter -- G.Milde web.de
Re: Feature Request: Uber Document Class
On 8.02.05, Andreas Vox wrote: > Luke Simon <[EMAIL PROTECTED]> writes: > 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. We already have the "ObsoletedBy" directive, that can take care of some of this cases. E.g. converting from article to article(scr) will map LyX-List to Labeling: # List style definition Style List ObsoletedBy Labeling End My version of dinbrief.layout (http://wiki.lyx.org/Layouts/Dinbrief) has 29 ObsoletedBy declarations not only to make it backwards compatible, but also to facilitate conversions of documents from other letter classes. However, it doesnot work backwards. For backwards compatibility (scr to standard classes) one could * use an ObsoletedBy clause in every non-scr layout file, or * rename the Labeling style to List (and add a Labeling ObsoletedBy List to the new scr-layout). (Only sensible if both Styles are 100% compatible. * have something like a "DegradesTo" directive, that gives the best approximation for cases where a Style is not available (together with a warning to the user as currently). The last option would also be of wider use: e.g. I have defined a "CondensedItemize" list that has less vertical spacing than the standard Itemize. If I pass my *.lyx file to someone (who doesnot have my gm-extensions.inc layout file) CondensedItemize will be converted to Standard. With Style CondensedItemize # my definitions DegradesTo Itemize End it would at least approximately work as expected. > BTW, any volunteers who want to enhance this error dialog to allow > userdefined mappings? :-) The DegradesTo directive would do exacly this (replacing the "converted to Standard" with whatever Style is given as approximation. Günter -- G.Milde web.de
Feature Request: Uber Document Class
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. 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. An Uber Document Class might seem like overkill, but for the very early stages of writing, I think it would be very useful, and in the long run it would improve productivity of writing.
Re: Feature Request: Uber Document Class
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 cutpaste 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
Feature Request: Uber Document Class
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. 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. An Uber Document Class might seem like overkill, but for the very early stages of writing, I think it would be very useful, and in the long run it would improve productivity of writing.
Re: Feature Request: Uber Document Class
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 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
