On Fri, May 07, 2004 at 03:07:05PM +0200, Georg Baum wrote: > Helge Hafting wrote: > > > Georg Baum wrote: > >>Only as long as there is no better solution. > >> > >> > > An having unprintable include-book, include-report, include-letter and so > > on is a better solution? > > I never wanted unprintable documents. I only said that subdocuments should > not have the lyx header, and they should know nothing about the document > class (so only one include type and not include-letter etc).
I see a problem here. What paragraph types should be selectable in such a document? Letters don't have sectioning, the other classes are almost useless without that. Or do you propose that this subdocument-of-any-class document should contain a reference to the master, so the type could be looked up that way? That might be troublesome if a subdocument is transferred somewhere without the master. [...] > > >>It is. You don't know wether the subdocument can be compiled at all, > >> > >> > > Yes, I often know that. The subdocument isn't necessarily planned > > as such, it could very well be a standalone document with some > > content I want included in something larger. > > True. Therefore conversion needs to be easy and as far as possible > automatic. > That makes it easier, sure. [...] > > >>If you are a careful user, and know all the possible problems, you can > >>ensure manually that everything is ok. This might work perfectly for you, > >>but in general I think it is better to enforce the correctness > >>technically. > >> > >> > >> > > Nonexpert users doesn't put stuff in the preamble, experts knows > > how the preamble works. It seems to me problem you try to prevent > > applies to a narrow group. > > I don't agree. If somebody has a document that is so large that it is useful > to split it up in parts, then the probability is high that some special > stuff is needed. Indeed, particularly if they don't wrap that up in a custom document class. > Also while you can expect that expert users know how the preamble works, it > happens that you open a document that you created 6 months ago and forgot > that it was a subdocument. Then you change something, and later you wonder > why the original master document does not work anymore. > I am not sure that a subdocument class is the way to solve this particular problem. It might help, but it creates some other problems: 1. Users wondering why in the world they cannot include another document 2. Some documents are meant to be used both standalone and as inclusions. Do you want to support that at all? > >>it in some special place, reconfigure lyx. This problem would vanish if > >>the .layout files could be embedded into the .lyx file, but then we have > >>again the double data definition problem. > >> > >> > > Not a problem if the documents are of the same class. They really > > should be, or you'll get trouble even without preambles. Chapters and > > sections doesn't exist in "letter", so including a book or article > > may fail without any preamble magic. > > I am talking of documents of the same class here. If you have a book with 10 > chapters, one file per chapter, you have 11 definitions of the layout if > the .layout file is embedded in the .lyx file. Who ensures that they are > the same? This is exactly the problem of double data definition that I want > to avoid. > I see, you worry about the layout definition changing over time? > > I see nothing wrong in making a new feature-poor document class > > that can be included in anything. (Useful if you want to include > > something both in reports and articles, for example. And > > if you don't care to match the document types.) This should solve > > your problem. But please don't plan restrictions that hit power > > users just so some newbie won't get a latex error. That will happen > > anyway if they experiment with latex commands (ERT or preambles). > > I think you still misunderstand me: I do not want to restrict any type of > user. Printing selected parts or converting a document for standalone usage > should be as easy as it is now. > Fine, but how do you want to avoid restrictions? The classes differ greatly in what paragraph types they support. Allowing only the common ones is very restrictive, allowing all breaks as badly as today's inclusion of a different typed document. Looking it up in the master file means we need to have the master file around too. That have its own set of problems, particularly if they aren't in the same directory an/or the user moves the files around. Still, it might be better than the current situation. Helge Hafting
