[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Request for feedback about LaTeX setup changes

From: Carsten Dominik
Subject: [Orgmode] Request for feedback about LaTeX setup changes
Date: Mon, 5 Apr 2010 15:13:31 +0200

Dear all,

I need some feedback.

Here is new new section from the list of changes, about the LaTeX setup. I would like to hear honest answers if I have gone completely crazy, of if this actually makes any sense.


- Carsten
      Changes to the intended use of =org-export-latex-classes=

So far this variable has been used to specify the complete header
of the LaTeX document, including all the =\usepackage= calls
necessary for the document.  This setup makes it difficult to
maintain the list of packages that Org itself would like to call,
for example for the special symbol support it needs.  Each time I
have to add a package, I have to ask people to revise the
configuration of this variable.  In this release, I have tried to
fix this.

First of all, you can *opt out of this change* in the following
way: You can say: /I want to have full control over headers, and
I will take responsibility to include the packages Org needs/.
If that is what you want, add this to your configuration and skip
the rest of this section (except maybe for the description of the
=[EXTRA]= place holder):

  (setq org-export-latex-default-packages-alist nil
        org-export-latex-packages-alist nil)

/Continue to read here if you want to go along with the modified

There are now two variables that should be used to list the LaTeX
packages that need to be included in all classes.  The header
definition in =org-export-latex-classes= should then not contain
the corresponding =\usepackage= calls (see below).

The two new variables are:

1. =org-export-latex-default-packages-alist= :: This is the
     variable where Org-mode itself puts the packages it needs.
     Normally you should not change this variable.  The only
     reason to change it anyway is when one of these packages
     causes a conflict with another package you want to use.
     Then you can remove that packages and hope that you are not
     using Org-mode functionality that needs it.

2. =org-export-latex-packages-alist= :: This is the variable
     where you can put the packages that you'd like to use across
     all classes.  For example, I am putting =amsmath= and =tikz=
     here, because I always want to have them.

The sequence how these customizations will show up in the LaTeX
document are:
1. Header from =org-export-latex-classes=
2. =org-export-latex-default-packages-alist=
3. =org-export-latex-packages-alist=
4. Buffer-specific things set with =#+LaTeX_HEADER:=

If you want more control about which segment is placed where, or
if you want, for a specific class, have full control over the
header and exclude some of the automatic building blocks, you can
put the following macro-like place holders into the header:

  [DEFAULT-PACKAGES]      \usepackage statements for default packages
  [NO-DEFAULT-PACKAGES]   do not include any of the default packages
  [PACKAGES]              \usepackage statements for packages
  [NO-PACKAGES]           do not include the packages
  [EXTRA]                 the stuff from #+LaTeX_HEADER
  [NO-EXTRA]              do not include #+LaTeX_HEADER stuff

If you have currently customized =org-export-latex-classes=, you
should revise that customization and remove any package calls that
are covered by =org-export-latex-default-packages-alist=.  This
applies to the following packages:

- inputenc
- fontenc
- graphicx
- longtable
- float
- wrapfig
- soul
- t1enc
- textcomp
- marvosym
- wasysym
- latexsym
- amssymb
- hyperref

If one of these packages creates a conflict with another package
you are using, you can remove it from
=org-export-latex-default-packages-alist=.  But then you risk
that some of the advertised export features of Org will not work

You can also consider moving packages that you use in all classes
to =org-export-latex-packages-alist=.  If necessary, put the
place holders so that the packages get loaded in the right
sequence.  As said above, for backward compatibility, if you omit
the place holders, all the variables will dump their content at
the end of the header.

Damn, this has become more complex than I wanted it to be.  I
hope that in practice, this will not be complicated at all.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]