lyx_mirror/src/TextClass.h

427 lines
14 KiB
C
Raw Normal View History

// -*- C++ -*-
/**
* \file TextClass.h
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* Full author contact details are available in file CREDITS.
*/
#ifndef TEXTCLASS_H
#define TEXTCLASS_H
#include "ColorCode.h"
#include "Counters.h"
#include "FloatList.h"
#include "FontInfo.h"
#include "Layout.h"
#include "LayoutEnums.h"
#include "insets/InsetLayout.h"
#include "support/docstring.h"
#include "support/types.h"
#include <boost/noncopyable.hpp>
#include <map>
#include <set>
#include <vector>
namespace lyx {
namespace support { class FileName; }
class Counters;
class FloatList;
class Layout;
class LayoutFile;
class Lexer;
/// Based upon ideas in boost::noncopyable, inheriting from this
/// class effectively makes the copy constructor protected but the
/// assignment constructor private.
class ProtectCopy
{
protected:
ProtectCopy() {}
~ProtectCopy() {}
ProtectCopy(const ProtectCopy &) {};
private:
const ProtectCopy & operator=(const ProtectCopy &);
};
/// A TextClass represents a collection of layout information: At the
/// moment, this includes Layout's and InsetLayout's.
///
/// There are two major subclasses of TextClass: LayoutFile and
/// DocumentClass. These subclasses are what are actually used in LyX.
/// Simple TextClass objects are not directly constructed in the main
/// LyX code---the constructor is protected. (That said, in tex2lyx
/// there are what amount to simple TextClass objects.)
///
/// A LayoutFile (see LayoutFile.{h,cpp}) represents a *.layout file.
/// These are generally static objects---though they can be reloaded
/// from disk via LFUN_LAYOUT_RELOAD, so one should not assume that
/// they will never change.
///
/// A DocumentClass (see below) represents the layout information that
/// is associated with a given Buffer. These are static, in the sense
/// that they will not themselves change, but which DocumentClass is
/// associated with a Buffer can change, as modules are loaded and
/// unloaded, for example.
///
class TextClass : protected ProtectCopy {
public:
///
virtual ~TextClass() {};
///////////////////////////////////////////////////////////////////
// typedefs
///////////////////////////////////////////////////////////////////
/// The individual paragraph layouts comprising the document class
// NOTE Do NOT try to make this a container of Layout pointers, e.g.,
// std::vector<Layout *>. This will lead to problems. The reason is
// that DocumentClass objects are generally created by copying a
// LayoutFile, which serves as a base for the DocumentClass. If the
// LayoutList is a container of pointers, then every DocumentClass
// that derives from a given LayoutFile (e.g., article) will SHARE
// a basic set of layouts. So if one Buffer were to modify a layout
// (say, Standard), that would modify that layout for EVERY Buffer
// that was based upon the same DocumentClass. (Of course, if you
// really, REALLY want to make LayoutList a vector<Layout *>, then
// you can implement custom assignment and copy constructors.)
typedef std::vector<Layout> LayoutList;
/// The inset layouts available to this class
typedef std::map<docstring, InsetLayout> InsetLayouts;
///
typedef LayoutList::const_iterator const_iterator;
///////////////////////////////////////////////////////////////////
// Iterators
///////////////////////////////////////////////////////////////////
///
const_iterator begin() const { return layoutlist_.begin(); }
///
const_iterator end() const { return layoutlist_.end(); }
///////////////////////////////////////////////////////////////////
// Layout Info
///////////////////////////////////////////////////////////////////
///
Layout const & defaultLayout() const;
///
docstring const & defaultLayoutName() const;
///
bool isDefaultLayout(Layout const &) const;
///
bool isPlainLayout(Layout const &) const;
/// returns a special layout for use when we don't really want one,
/// e.g., in table cells
Layout const & emptyLayout() const
{ return operator[](emptylayout_); };
/// the name of the empty layout
docstring const & emptyLayoutName() const
{ return emptylayout_; }
/// Enumerate the paragraph styles.
size_t layoutCount() const { return layoutlist_.size(); }
///
bool hasLayout(docstring const & name) const;
///
Layout const & operator[](docstring const & vname) const;
///////////////////////////////////////////////////////////////////
// reading routines
///////////////////////////////////////////////////////////////////
/// Enum used with TextClass::read
This is one of a series of patches that will merge the layout modules development in personal/branches/rgheck back into the tree. Design goal: Allow the use of layout "modules", which are to LaTeX packages as layout files are to LaTeX document classes. Thus, one could have a module that defined certain character styles, environments, commands, or what have you, and include it in various documents, each of which uses a different document class, without having to modify the layout files themselves. For example, a theorems.module could be used with article.layout to provide support for theorem-type environments, without having to modify article.layout itself, and the same module could be used with book.layout, etc. This patch adds the backend. The ModuleList class holds a list of the available modules, which are retrieved from lyxmodules.lst, itself generated by configure.py. There are two LFUNs available: modules-clear and module-add, which do the obvious thing; you can test by typing these into the minibuffer, along with the name of one of the available modules: URL (a CharStyle), Endnote (a Custom Inset), and---with the spaces---End To Foot (View>LaTeX and look at the user preamble), which are themselves in lib/layouts. There are some others, too, that allow theorems to be added to classes like article and book. The GUI will come next. Issues: (i) The configure.py script could be improved. It'd be nice, for example, if it tested for the presence of the LaTeX packages a particular module needs. But this would mean re-working the LaTeX script, and I don't know how to do that. Note that at present, the packages are ignored. This will change shortly. (ii) I've used std::string in LyXModule, following what seemed to be a precedent in TextClass. If some of these should be docstrings, please let me know, and I'll change them. (iii) There is at present no distinction between LaTeX and DocBook modules. Should there be? That is: Should there be modules that are available when the document class is a LaTeX class and others that are available only when it is DocBook? Or should there just be one set of modules? Each module can of course indicate for what it is suitable in its description. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19893 a592a061-630c-0410-9148-cb99ea01b6c8
2007-08-29 17:59:49 +00:00
enum ReadType {
BASECLASS, //>This is a base class, i.e., top-level layout file
MERGE, //>This is a file included in a layout file
MODULE, //>This is a layout module
VALIDATION //>We're just validating
This is one of a series of patches that will merge the layout modules development in personal/branches/rgheck back into the tree. Design goal: Allow the use of layout "modules", which are to LaTeX packages as layout files are to LaTeX document classes. Thus, one could have a module that defined certain character styles, environments, commands, or what have you, and include it in various documents, each of which uses a different document class, without having to modify the layout files themselves. For example, a theorems.module could be used with article.layout to provide support for theorem-type environments, without having to modify article.layout itself, and the same module could be used with book.layout, etc. This patch adds the backend. The ModuleList class holds a list of the available modules, which are retrieved from lyxmodules.lst, itself generated by configure.py. There are two LFUNs available: modules-clear and module-add, which do the obvious thing; you can test by typing these into the minibuffer, along with the name of one of the available modules: URL (a CharStyle), Endnote (a Custom Inset), and---with the spaces---End To Foot (View>LaTeX and look at the user preamble), which are themselves in lib/layouts. There are some others, too, that allow theorems to be added to classes like article and book. The GUI will come next. Issues: (i) The configure.py script could be improved. It'd be nice, for example, if it tested for the presence of the LaTeX packages a particular module needs. But this would mean re-working the LaTeX script, and I don't know how to do that. Note that at present, the packages are ignored. This will change shortly. (ii) I've used std::string in LyXModule, following what seemed to be a precedent in TextClass. If some of these should be docstrings, please let me know, and I'll change them. (iii) There is at present no distinction between LaTeX and DocBook modules. Should there be? That is: Should there be modules that are available when the document class is a LaTeX class and others that are available only when it is DocBook? Or should there just be one set of modules? Each module can of course indicate for what it is suitable in its description. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19893 a592a061-630c-0410-9148-cb99ea01b6c8
2007-08-29 17:59:49 +00:00
};
/// return values for read()
enum ReturnValues {
OK,
ERROR,
FORMAT_MISMATCH
};
/// Performs the read of the layout file.
/// \return true on success.
This is one of a series of patches that will merge the layout modules development in personal/branches/rgheck back into the tree. Design goal: Allow the use of layout "modules", which are to LaTeX packages as layout files are to LaTeX document classes. Thus, one could have a module that defined certain character styles, environments, commands, or what have you, and include it in various documents, each of which uses a different document class, without having to modify the layout files themselves. For example, a theorems.module could be used with article.layout to provide support for theorem-type environments, without having to modify article.layout itself, and the same module could be used with book.layout, etc. This patch adds the backend. The ModuleList class holds a list of the available modules, which are retrieved from lyxmodules.lst, itself generated by configure.py. There are two LFUNs available: modules-clear and module-add, which do the obvious thing; you can test by typing these into the minibuffer, along with the name of one of the available modules: URL (a CharStyle), Endnote (a Custom Inset), and---with the spaces---End To Foot (View>LaTeX and look at the user preamble), which are themselves in lib/layouts. There are some others, too, that allow theorems to be added to classes like article and book. The GUI will come next. Issues: (i) The configure.py script could be improved. It'd be nice, for example, if it tested for the presence of the LaTeX packages a particular module needs. But this would mean re-working the LaTeX script, and I don't know how to do that. Note that at present, the packages are ignored. This will change shortly. (ii) I've used std::string in LyXModule, following what seemed to be a precedent in TextClass. If some of these should be docstrings, please let me know, and I'll change them. (iii) There is at present no distinction between LaTeX and DocBook modules. Should there be? That is: Should there be modules that are available when the document class is a LaTeX class and others that are available only when it is DocBook? Or should there just be one set of modules? Each module can of course indicate for what it is suitable in its description. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19893 a592a061-630c-0410-9148-cb99ea01b6c8
2007-08-29 17:59:49 +00:00
bool read(support::FileName const & filename, ReadType rt = BASECLASS);
///
bool read(std::string const & str, ReadType rt = BASECLASS);
///
ReturnValues read(Lexer & lex, ReadType rt = BASECLASS);
/// validates the layout information passed in str
static bool validate(std::string const & str);
///////////////////////////////////////////////////////////////////
// loading
///////////////////////////////////////////////////////////////////
/// Sees to it the textclass structure has been loaded
bool load(std::string const & path = std::string()) const;
/// Has this layout file been loaded yet?
/// Overridden by DocumentClass
virtual bool loaded() const { return loaded_; }
///////////////////////////////////////////////////////////////////
// accessors
///////////////////////////////////////////////////////////////////
///
std::string const & name() const { return name_; };
///
std::string const & description() const { return description_; };
///
std::string const & latexname() const { return latexname_; }
protected:
/// Protect construction
TextClass();
///
Layout & operator[](docstring const & vname);
///////////////////////////////////////////////////////////////////
// non-const iterators
///////////////////////////////////////////////////////////////////
///
typedef LayoutList::iterator iterator;
///
iterator begin() { return layoutlist_.begin(); }
///
iterator end() { return layoutlist_.end(); }
///////////////////////////////////////////////////////////////////
// members
///////////////////////////////////////////////////////////////////
/// Paragraph styles used in this layout
LayoutList layoutlist_;
/// Layout file name
std::string name_;
/// document class name
std::string latexname_;
/// document class description
std::string description_;
/// available types of float, eg. figure, algorithm.
mutable FloatList floatlist_;
/// Types of counters, eg. sections, eqns, figures, avail. in document class.
mutable Counters counters_;
/// Has this layout file been loaded yet?
mutable bool loaded_;
/// Is the TeX class available?
bool texClassAvail_;
This is one of a series of patches that will merge the layout modules development in personal/branches/rgheck back into the tree. Design goal: Allow the use of layout "modules", which are to LaTeX packages as layout files are to LaTeX document classes. Thus, one could have a module that defined certain character styles, environments, commands, or what have you, and include it in various documents, each of which uses a different document class, without having to modify the layout files themselves. For example, a theorems.module could be used with article.layout to provide support for theorem-type environments, without having to modify article.layout itself, and the same module could be used with book.layout, etc. This patch adds the backend. The ModuleList class holds a list of the available modules, which are retrieved from lyxmodules.lst, itself generated by configure.py. There are two LFUNs available: modules-clear and module-add, which do the obvious thing; you can test by typing these into the minibuffer, along with the name of one of the available modules: URL (a CharStyle), Endnote (a Custom Inset), and---with the spaces---End To Foot (View>LaTeX and look at the user preamble), which are themselves in lib/layouts. There are some others, too, that allow theorems to be added to classes like article and book. The GUI will come next. Issues: (i) The configure.py script could be improved. It'd be nice, for example, if it tested for the presence of the LaTeX packages a particular module needs. But this would mean re-working the LaTeX script, and I don't know how to do that. Note that at present, the packages are ignored. This will change shortly. (ii) I've used std::string in LyXModule, following what seemed to be a precedent in TextClass. If some of these should be docstrings, please let me know, and I'll change them. (iii) There is at present no distinction between LaTeX and DocBook modules. Should there be? That is: Should there be modules that are available when the document class is a LaTeX class and others that are available only when it is DocBook? Or should there just be one set of modules? Each module can of course indicate for what it is suitable in its description. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19893 a592a061-630c-0410-9148-cb99ea01b6c8
2007-08-29 17:59:49 +00:00
///
std::string opt_fontsize_;
///
std::string opt_pagestyle_;
This is one of a series of patches that will merge the layout modules development in personal/branches/rgheck back into the tree. Design goal: Allow the use of layout "modules", which are to LaTeX packages as layout files are to LaTeX document classes. Thus, one could have a module that defined certain character styles, environments, commands, or what have you, and include it in various documents, each of which uses a different document class, without having to modify the layout files themselves. For example, a theorems.module could be used with article.layout to provide support for theorem-type environments, without having to modify article.layout itself, and the same module could be used with book.layout, etc. This patch adds the backend. The ModuleList class holds a list of the available modules, which are retrieved from lyxmodules.lst, itself generated by configure.py. There are two LFUNs available: modules-clear and module-add, which do the obvious thing; you can test by typing these into the minibuffer, along with the name of one of the available modules: URL (a CharStyle), Endnote (a Custom Inset), and---with the spaces---End To Foot (View>LaTeX and look at the user preamble), which are themselves in lib/layouts. There are some others, too, that allow theorems to be added to classes like article and book. The GUI will come next. Issues: (i) The configure.py script could be improved. It'd be nice, for example, if it tested for the presence of the LaTeX packages a particular module needs. But this would mean re-working the LaTeX script, and I don't know how to do that. Note that at present, the packages are ignored. This will change shortly. (ii) I've used std::string in LyXModule, following what seemed to be a precedent in TextClass. If some of these should be docstrings, please let me know, and I'll change them. (iii) There is at present no distinction between LaTeX and DocBook modules. Should there be? That is: Should there be modules that are available when the document class is a LaTeX class and others that are available only when it is DocBook? Or should there just be one set of modules? Each module can of course indicate for what it is suitable in its description. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19893 a592a061-630c-0410-9148-cb99ea01b6c8
2007-08-29 17:59:49 +00:00
/// Specific class options
std::string options_;
///
std::string pagestyle_;
///
std::string class_header_;
///
docstring defaultlayout_;
Fix bug 4037 and related problems. The patch has been cleaned up a bit from the one posted to the list. The basic idea has two parts. First, we hard code an "empty layout" (called PlainLayout, for want of a better name) in TextClass and read it before doing anything else. It can therefore be customized by classes, if they want---say, to make it left-aligned. Second, InsetText's are divided into three types: (i) normal ones, that use the "default" layout defined by the text class; (ii) highly restrictive ones, such as ERT and (not quite an inset) table cells, which demand the empty layout; (iii) middling ones, which default to an empty layout and use the empty layout in place of the default. (This is so we don't get the same problem we had with ERT in e.g. footnotes.) The type of inset is signaled by new methods InsetText::forceEmptyLayout() and InsetText::useEmptyLayout(). (The latter might better be called: useEmptyLayoutInsteadOfDefault(), but that's silly.) The old InsetText::forceDefaultParagraphs() has been split into these, plus a new method InsetText::allowParagraphCustomization(). A lot of the changes just adapt to this change. The other big change is in GuiToolbar: We want to show LyXDefault and the "default" layout only when they're active. There are a handful of places where I'm not entirely sure whether we should be using forceEmptyLayout or !allowParagraphCustomization() or both. The InsetCaption is one of these. These places, and some others, are marked with FIXMEs, so I'd appreciate it if people would search through the patch and let me know whether these need changing. If they don't, the FIXMEs can be deleted. git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@22966 a592a061-630c-0410-9148-cb99ea01b6c8
2008-02-12 17:31:07 +00:00
/// name of empty layout
static const docstring emptylayout_;
/// preamble text to support layout styles
docstring preamble_;
/// latex packages loaded by document class.
std::set<std::string> provides_;
/// latex packages requested by document class.
std::set<std::string> requires_;
///
unsigned int columns_;
///
PageSides sides_;
/// header depth to have numbering
int secnumdepth_;
/// header depth to appear in table of contents
int tocdepth_;
/// Can be LaTeX, DocBook, etc.
OutputType outputType_;
/** Base font. The paragraph and layout fonts are resolved against
this font. This has to be fully instantiated. Attributes
FONT_INHERIT, FONT_IGNORE, and FONT_TOGGLE are
extremely illegal.
*/
FontInfo defaultfont_;
/// Text that dictates how wide the left margin is on the screen
docstring leftmargin_;
/// Text that dictates how wide the right margin is on the screen
docstring rightmargin_;
/// The type of command used to produce a title
TitleLatexType titletype_;
/// The name of the title command
std::string titlename_;
/// Input layouts available to this layout
InsetLayouts insetlayoutlist_;
/// The minimal TocLevel of sectioning layouts
int min_toclevel_;
/// The maximal TocLevel of sectioning layouts
int max_toclevel_;
private:
///////////////////////////////////////////////////////////////////
// helper routines for reading layout files
///////////////////////////////////////////////////////////////////
///
bool deleteLayout(docstring const &);
///
bool convertLayoutFormat(support::FileName const &, ReadType);
/// \return true for success.
bool readStyle(Lexer &, Layout &);
///
void readOutputType(Lexer &);
///
void readTitleType(Lexer &);
///
void readMaxCounter(Lexer &);
///
void readClassOptions(Lexer &);
///
void readCharStyle(Lexer &, std::string const &);
///
void readFloat(Lexer &);
///
void readCounter(Lexer &);
};
/// A DocumentClass represents the layout information associated with a
/// Buffer. It is based upon a LayoutFile, but may be modified by loading
/// various Modules.
///
/// In that regard, DocumentClass objects are "dynamic". But this is really
/// an illusion, since DocumentClass objects are not (currently) changed
/// when, say, a new Module is loaded. Rather, the old DocumentClass is
/// discarded---actually, it's kept around in case something on the cut
/// stack needs it---and a new one is created from scratch.
///
/// In the main LyX code, DocumentClass objects are created only by
/// DocumentClassBundle, for which see below.
///
class DocumentClass : public TextClass, boost::noncopyable {
public:
///
virtual ~DocumentClass() {}
///////////////////////////////////////////////////////////////////
// Layout Info
///////////////////////////////////////////////////////////////////
/// \return true if there is a Layout with latexname lay
bool hasLaTeXLayout(std::string const & lay) const;
/// A DocumentClass nevers count as loaded, since it is dynamic
virtual bool loaded() { return false; }
/// Inset layouts of this doc class
InsetLayouts const & insetLayouts() const { return insetlayoutlist_; };
/// \return the layout object of an inset given by name. If the name
/// is not found as such, the part after the ':' is stripped off, and
/// searched again. In this way, an error fallback can be provided:
/// An erroneous 'CharStyle:badname' (e.g., after a documentclass switch)
/// will invoke the layout object defined by name = 'CharStyle'.
/// If that doesn't work either, an empty object returns (shouldn't
/// happen). -- Idea JMarc, comment MV
InsetLayout const & insetLayout(docstring const & name) const;
/// an empty inset layout for use as a default
static InsetLayout const & emptyInsetLayout() { return empty_insetlayout_; }
///////////////////////////////////////////////////////////////////
// accessors
///////////////////////////////////////////////////////////////////
/// the list of floats defined in the document class
FloatList const & floats() const { return floatlist_; }
///
Counters & counters() const { return counters_; }
///
std::string const & opt_fontsize() const { return opt_fontsize_; }
///
std::string const & opt_pagestyle() const { return opt_pagestyle_; }
///
std::string const & options() const { return options_; }
///
std::string const & class_header() const { return class_header_; }
///
std::string const & pagestyle() const { return pagestyle_; }
///
docstring const & preamble() const { return preamble_; }
/// is this feature already provided by the class?
bool provides(std::string const & p) const;
/// features required by the class?
std::set<std::string> const & requires() const { return requires_; }
///
unsigned int columns() const { return columns_; }
///
PageSides sides() const { return sides_; }
///
int secnumdepth() const { return secnumdepth_; }
///
int tocdepth() const { return tocdepth_; }
///
FontInfo const & defaultfont() const { return defaultfont_; }
/// Text that dictates how wide the left margin is on the screen
docstring const & leftmargin() const { return leftmargin_; }
/// Text that dictates how wide the right margin is on the screen
docstring const & rightmargin() const { return rightmargin_; }
/// The type of command used to produce a title
TitleLatexType titletype() const { return titletype_; };
/// The name of the title command
std::string const & titlename() const { return titlename_; };
///
int size() const { return layoutlist_.size(); }
/// The minimal TocLevel of sectioning layouts
int min_toclevel() const { return min_toclevel_; }
/// The maximal TocLevel of sectioning layouts
int max_toclevel() const { return max_toclevel_; }
/// returns true if the class has a ToC structure
bool hasTocLevels() const;
/// Can be LaTeX, DocBook, etc.
OutputType outputType() const { return outputType_; }
protected:
/// Constructs a DocumentClass based upon a LayoutFile.
DocumentClass(LayoutFile const & tc);
/// Needed in tex2lyx
DocumentClass() {}
private:
/// The only class that can create a DocumentClass is
/// DocumentClassBundle, which calls the protected constructor.
friend class DocumentClassBundle;
///
static InsetLayout empty_insetlayout_;
};
/// DocumentClassBundle is a container for DocumentClass objects, so that
/// they stay in memory for use by Insets, CutAndPaste, and the like, even
/// when their associated Buffers are destroyed.
/// FIXME Some sort of garbage collection or reference counting wouldn't
/// be a bad idea here. It might be enough to check when a Buffer is closed
/// (or makeDocumentClass is called) whether the old DocumentClass is in use
/// anywhere.
///
/// This is a singleton class. Its sole instance is accessed via
/// DocumentClassBundle::get().
class DocumentClassBundle : boost::noncopyable {
public:
/// \return Pointer to a new class equal to baseClass
DocumentClass & newClass(LayoutFile const & baseClass);
/// \return The sole instance of this class.
static DocumentClassBundle & get();
private:
/// control instantiation
DocumentClassBundle() {}
/// clean up
~DocumentClassBundle();
///
std::vector<DocumentClass *> documentClasses_;
};
/// convert page sides option to text 1 or 2
std::ostream & operator<<(std::ostream & os, PageSides p);
} // namespace lyx
#endif