IMPORTANT: (possibly) incompatible Change

IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

Dear all,

I have just checked in an important change - if you use LaTeX
export, you need to be aware of it.

1. Org contains now a much better system for handling special entities
    that are written like LaTeX macros, for example \therefore,  
\emptyset,
    etc.  I will write more about this in the release notes for 6.35.   
But
    already now thanks go to Ulf Stegemann without whom this would not
    have happened.

2. I could no longer keep the old setup for LaTeX export in
    org-export-latex-classes.  The disadvantage was that whenever you
    needed to make changes to the header, you would fix the value of  
this
    variable so that any changes I'd make in the future would not be  
visible
    to you.

    The way this is solved now is (excerpt from the upcoming release  
notes)

-----------------------------------------------------------------------------
* =org-export-latex-classes= no longer should be customized for packages

The HEADER part of this variable should now only contain the
documentclass macro, nothing else - at least normally.  All the
package calls via usepackage should go into
org-export-latex-packages-alist.  I moved all the default packages
that into a new variable org-export-latex-default-packages-alist.
This will allow me to add more packages (as needed) in the
future, withour requiring you to erase and then redo your
configuration of org-export-latex-classes.

So if you have customized this variable, please remove once more
(hopefully for the last time) your customization, so that it can
revert to its now much simpler default value.  Put all your
package definitions into org-export-latex-packages-alist.
I hope this works, and we will not get conflicts because of the
sequence in which packages are called.  If there are problems,
please let me know so that we can find a solution.
-----------------------------------------------------------------------------

I have not yet put this onto the master branch, but I will soon.
If you want to help testing this new setup, please check out the branch
new-entity-support from the git repo and let me know if you run into any
problems.

Thanks!

- Carsten (and Ulf)

Re: IMPORTANT: (possibly) incompatible Change

[Chris Gray]

Carsten Dominik wrote:

> -----------------------------------------------------------------------------
> * =org-export-latex-classes= no longer should be customized for packages

> The HEADER part of this variable should now only contain the
> documentclass macro, nothing else - at least normally.  All the
> package calls via usepackage should go into
> org-export-latex-packages-alist.  I moved all the default packages
> that into a new variable org-export-latex-default-packages-alist.
> This will allow me to add more packages (as needed) in the
> future, withour requiring you to erase and then redo your
> configuration of org-export-latex-classes.

> So if you have customized this variable, please remove once more
> (hopefully for the last time) your customization, so that it can
> revert to its now much simpler default value.  Put all your
> package definitions into org-export-latex-packages-alist.
> I hope this works, and we will not get conflicts because of the
> sequence in which packages are called.  If there are problems,
> please let me know so that we can find a solution.

Is it sufficient to change the variable that is being set from
org-export-latex-classes to org-export-latex-default-packages-alist?  Or
does the format of the list change at all?

Cheers,
Chris

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Mar 31, 2010, at 11:00 AM, Chris Gray wrote:

> Carsten Dominik wrote:
>
>> -----------------------------------------------------------------------------
>> * =org-export-latex-classes= no longer should be customized for  
>> packages
>
>> The HEADER part of this variable should now only contain the
>> documentclass macro, nothing else - at least normally.  All the
>> package calls via usepackage should go into
>> org-export-latex-packages-alist.  I moved all the default packages
>> that into a new variable org-export-latex-default-packages-alist.
>> This will allow me to add more packages (as needed) in the
>> future, withour requiring you to erase and then redo your
>> configuration of org-export-latex-classes.
>
>> So if you have customized this variable, please remove once more
>> (hopefully for the last time) your customization, so that it can
>> revert to its now much simpler default value.  Put all your
>> package definitions into org-export-latex-packages-alist.
>> I hope this works, and we will not get conflicts because of the
>> sequence in which packages are called.  If there are problems,
>> please let me know so that we can find a solution.
>
> Is it sufficient to change the variable that is being set from
> org-export-latex-classes to org-export-latex-default-packages- 
> alist?  Or
> does the format of the list change at all?

org-export-latex-default-packages-alist has the same format as org- 
export-latex-pakcages-alist.  And I am filling org-export-latex- 
default-packages-alist already with the correct set of default  
packages, so you should not touch that variable.

Only if you have previously customized org-export-latex-classes in  
order to add more usepackage statements, then you should remove your  
customization of that variable and list your set of additional  
packages in org-export-latex-packages-alist instead.

Am I making sense?

Thanks.

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Eric Schulte]

Carsten Dominik <carsten.dominik@gmail.com> writes:

[...]

> Only if you have previously customized org-export-latex-classes in
> order to add more usepackage statements, then you should remove your
> customization of that variable and list your set of additional
> packages in org-export-latex-packages-alist instead.
>
> Am I making sense?
>

This makes sense, but what about the case where I only want to include
some usepackage statements in certain latex document classes?  For
example I only want to use the "fullpage" package when exporting to my
"twocolumn" class.

Thanks -- Eric

>
> Thanks.
>
> - Carsten
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Mar 31, 2010, at 4:16 PM, Eric Schulte wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
> [...]
>
>> Only if you have previously customized org-export-latex-classes in
>> order to add more usepackage statements, then you should remove your
>> customization of that variable and list your set of additional
>> packages in org-export-latex-packages-alist instead.
>>
>> Am I making sense?
>>
>
> This makes sense, but what about the case where I only want to include
> some usepackage statements in certain latex document classes?  For
> example I only want to use the "fullpage" package when exporting to my
> "twocolumn" class.

Then you just continue to use org-export-latex-classes.

- Carsten

>
> Thanks -- Eric
>
>>
>> Thanks.
>>
>> - Carsten
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Mark Elston]

On 3/31/2010 5:35 AM, Carsten Dominik wrote:
>
> On Mar 31, 2010, at 11:00 AM, Chris Gray wrote:
>
>> Carsten Dominik wrote:
>>
>>> -----------------------------------------------------------------------------
>>>
>>> * =org-export-latex-classes= no longer should be customized for packages
>>  ...
>>> So if you have customized this variable, please remove once more
>>> (hopefully for the last time) your customization, so that it can
>>> revert to its now much simpler default value. Put all your
>>> package definitions into org-export-latex-packages-alist.
>>> I hope this works, and we will not get conflicts because of the
>>> sequence in which packages are called. If there are problems,
>>> please let me know so that we can find a solution.
>>
>> Is it sufficient to change the variable that is being set from
>> org-export-latex-classes to org-export-latex-default-packages-alist? Or
>> does the format of the list change at all?
>
> org-export-latex-default-packages-alist has the same format as
> org-export-latex-pakcages-alist. And I am filling
> org-export-latex-default-packages-alist already with the correct set of
> default packages, so you should not touch that variable.
>
> Only if you have previously customized org-export-latex-classes in order
> to add more usepackage statements, then you should remove your
> customization of that variable and list your set of additional packages
> in org-export-latex-packages-alist instead.
>
> Am I making sense?
>

So, org-export-latex-classes will no longer be used to define
LaTeX_CLASS classes?  Instead these classes will be defined in
org-export-latex-default-packages-alist?

The problem is mainly nomenclature, I guess, but my LaTeX_CLASS
definitions are usually a *lot* more than a list of packages.

It seems a little odd, but OK.

Mark

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

Hi Mark,

OK, it seems that I have really overstated this change.  You are of
course right that your header for a document type can be very long,
that that defining it in org-export-latex-classes is a viable option
(other being to put this stuff into a separate file).

So let me restate what I am trying to say in this thread.

------------------------------------------------------------------------------
Org-mode contains now a new variable `org-export-latex-default- 
packages-alist'
which contains all the LaTeX packages it needs to use for basic Org-mode
functionality.  The corresponding \usepackage statements used to be part
of the header definitions in org-export-latex-classes, and they had to
be repeated for each document class.  This is wasteful, error prone, and
hard to maintain.
Therefore, these packages are now collected in the new variable,
and they will be spliced into the header.

If you have customized the variable org-export-latex-classes, you need  
to
remove the following lines from each class definition:

\usepackage[AUTO]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}

If you have other packages you always want to use in all
classes, you can add them to another variable,
`org-export-latex-packages-alist'.
------------------------------------------------------------------------------


I think this makes more sense, thank you for making me clarify this.

- Carsten



On Mar 31, 2010, at 8:41 PM, Mark Elston wrote:

> On 3/31/2010 5:35 AM, Carsten Dominik wrote:
>>
>> On Mar 31, 2010, at 11:00 AM, Chris Gray wrote:
>>
>>> Carsten Dominik wrote:
>>>
>>>> -----------------------------------------------------------------------------
>>>>
>>>> * =org-export-latex-classes= no longer should be customized for  
>>>> packages
>>> ...
>>>> So if you have customized this variable, please remove once more
>>>> (hopefully for the last time) your customization, so that it can
>>>> revert to its now much simpler default value. Put all your
>>>> package definitions into org-export-latex-packages-alist.
>>>> I hope this works, and we will not get conflicts because of the
>>>> sequence in which packages are called. If there are problems,
>>>> please let me know so that we can find a solution.
>>>
>>> Is it sufficient to change the variable that is being set from
>>> org-export-latex-classes to org-export-latex-default-packages- 
>>> alist? Or
>>> does the format of the list change at all?
>>
>> org-export-latex-default-packages-alist has the same format as
>> org-export-latex-pakcages-alist. And I am filling
>> org-export-latex-default-packages-alist already with the correct  
>> set of
>> default packages, so you should not touch that variable.
>>
>> Only if you have previously customized org-export-latex-classes in  
>> order
>> to add more usepackage statements, then you should remove your
>> customization of that variable and list your set of additional  
>> packages
>> in org-export-latex-packages-alist instead.
>>
>> Am I making sense?
>>
>
> So, org-export-latex-classes will no longer be used to define
> LaTeX_CLASS classes?  Instead these classes will be defined in
> org-export-latex-default-packages-alist?
>
> The problem is mainly nomenclature, I guess, but my LaTeX_CLASS
> definitions are usually a *lot* more than a list of packages.
>
> It seems a little odd, but OK.
>
> Mark
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

OK, this change is now in the master branch.

- Carsten

On Apr 1, 2010, at 8:59 AM, Carsten Dominik wrote:

> Hi Mark,
>
> OK, it seems that I have really overstated this change.  You are of
> course right that your header for a document type can be very long,
> that that defining it in org-export-latex-classes is a viable option
> (other being to put this stuff into a separate file).
>
> So let me restate what I am trying to say in this thread.
>
> ------------------------------------------------------------------------------
> Org-mode contains now a new variable `org-export-latex-default- 
> packages-alist'
> which contains all the LaTeX packages it needs to use for basic Org- 
> mode
> functionality.  The corresponding \usepackage statements used to be  
> part
> of the header definitions in org-export-latex-classes, and they had to
> be repeated for each document class.  This is wasteful, error prone,  
> and
> hard to maintain.
> Therefore, these packages are now collected in the new variable,
> and they will be spliced into the header.
>
> If you have customized the variable org-export-latex-classes, you  
> need to
> remove the following lines from each class definition:
>
> \usepackage[AUTO]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{longtable}
> \usepackage{float}
> \usepackage{wrapfig}
> \usepackage{soul}
> \usepackage{latexsym}
> \usepackage{amssymb}
> \usepackage{hyperref}
>
> If you have other packages you always want to use in all
> classes, you can add them to another variable,
> `org-export-latex-packages-alist'.
> ------------------------------------------------------------------------------
>
>
> I think this makes more sense, thank you for making me clarify this.
>
> - Carsten
>
>
>
> On Mar 31, 2010, at 8:41 PM, Mark Elston wrote:
>
>> On 3/31/2010 5:35 AM, Carsten Dominik wrote:
>>>
>>> On Mar 31, 2010, at 11:00 AM, Chris Gray wrote:
>>>
>>>> Carsten Dominik wrote:
>>>>
>>>>> -----------------------------------------------------------------------------
>>>>>
>>>>> * =org-export-latex-classes= no longer should be customized for  
>>>>> packages
>>>> ...
>>>>> So if you have customized this variable, please remove once more
>>>>> (hopefully for the last time) your customization, so that it can
>>>>> revert to its now much simpler default value. Put all your
>>>>> package definitions into org-export-latex-packages-alist.
>>>>> I hope this works, and we will not get conflicts because of the
>>>>> sequence in which packages are called. If there are problems,
>>>>> please let me know so that we can find a solution.
>>>>
>>>> Is it sufficient to change the variable that is being set from
>>>> org-export-latex-classes to org-export-latex-default-packages- 
>>>> alist? Or
>>>> does the format of the list change at all?
>>>
>>> org-export-latex-default-packages-alist has the same format as
>>> org-export-latex-pakcages-alist. And I am filling
>>> org-export-latex-default-packages-alist already with the correct  
>>> set of
>>> default packages, so you should not touch that variable.
>>>
>>> Only if you have previously customized org-export-latex-classes in  
>>> order
>>> to add more usepackage statements, then you should remove your
>>> customization of that variable and list your set of additional  
>>> packages
>>> in org-export-latex-packages-alist instead.
>>>
>>> Am I making sense?
>>>
>>
>> So, org-export-latex-classes will no longer be used to define
>> LaTeX_CLASS classes?  Instead these classes will be defined in
>> org-export-latex-default-packages-alist?
>>
>> The problem is mainly nomenclature, I guess, but my LaTeX_CLASS
>> definitions are usually a *lot* more than a list of packages.
>>
>> It seems a little odd, but OK.
>>
>> Mark
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> - Carsten
>
>
>

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Thomas S. Dye]

Aloha Carsten,

Packages that aren't used for all classes can still appear in org- 
export-latex-classes, correct?

All the best,
Tom

On Apr 1, 2010, at 1:13 AM, Carsten Dominik wrote:

> OK, this change is now in the master branch.
>
> - Carsten
>
> On Apr 1, 2010, at 8:59 AM, Carsten Dominik wrote:
>
>> Hi Mark,
>>
>> OK, it seems that I have really overstated this change.  You are of
>> course right that your header for a document type can be very long,
>> that that defining it in org-export-latex-classes is a viable option
>> (other being to put this stuff into a separate file).
>>
>> So let me restate what I am trying to say in this thread.
>>
>> ------------------------------------------------------------------------------
>> Org-mode contains now a new variable `org-export-latex-default- 
>> packages-alist'
>> which contains all the LaTeX packages it needs to use for basic Org- 
>> mode
>> functionality.  The corresponding \usepackage statements used to be  
>> part
>> of the header definitions in org-export-latex-classes, and they had  
>> to
>> be repeated for each document class.  This is wasteful, error  
>> prone, and
>> hard to maintain.
>> Therefore, these packages are now collected in the new variable,
>> and they will be spliced into the header.
>>
>> If you have customized the variable org-export-latex-classes, you  
>> need to
>> remove the following lines from each class definition:
>>
>> \usepackage[AUTO]{inputenc}
>> \usepackage[T1]{fontenc}
>> \usepackage{graphicx}
>> \usepackage{longtable}
>> \usepackage{float}
>> \usepackage{wrapfig}
>> \usepackage{soul}
>> \usepackage{latexsym}
>> \usepackage{amssymb}
>> \usepackage{hyperref}
>>
>> If you have other packages you always want to use in all
>> classes, you can add them to another variable,
>> `org-export-latex-packages-alist'.
>> ------------------------------------------------------------------------------
>>
>>
>> I think this makes more sense, thank you for making me clarify this.
>>
>> - Carsten
>>
>>
>>
>> On Mar 31, 2010, at 8:41 PM, Mark Elston wrote:
>>
>>> On 3/31/2010 5:35 AM, Carsten Dominik wrote:
>>>>
>>>> On Mar 31, 2010, at 11:00 AM, Chris Gray wrote:
>>>>
>>>>> Carsten Dominik wrote:
>>>>>
>>>>>> -----------------------------------------------------------------------------
>>>>>>
>>>>>> * =org-export-latex-classes= no longer should be customized for  
>>>>>> packages
>>>>> ...
>>>>>> So if you have customized this variable, please remove once more
>>>>>> (hopefully for the last time) your customization, so that it can
>>>>>> revert to its now much simpler default value. Put all your
>>>>>> package definitions into org-export-latex-packages-alist.
>>>>>> I hope this works, and we will not get conflicts because of the
>>>>>> sequence in which packages are called. If there are problems,
>>>>>> please let me know so that we can find a solution.
>>>>>
>>>>> Is it sufficient to change the variable that is being set from
>>>>> org-export-latex-classes to org-export-latex-default-packages- 
>>>>> alist? Or
>>>>> does the format of the list change at all?
>>>>
>>>> org-export-latex-default-packages-alist has the same format as
>>>> org-export-latex-pakcages-alist. And I am filling
>>>> org-export-latex-default-packages-alist already with the correct  
>>>> set of
>>>> default packages, so you should not touch that variable.
>>>>
>>>> Only if you have previously customized org-export-latex-classes  
>>>> in order
>>>> to add more usepackage statements, then you should remove your
>>>> customization of that variable and list your set of additional  
>>>> packages
>>>> in org-export-latex-packages-alist instead.
>>>>
>>>> Am I making sense?
>>>>
>>>
>>> So, org-export-latex-classes will no longer be used to define
>>> LaTeX_CLASS classes?  Instead these classes will be defined in
>>> org-export-latex-default-packages-alist?
>>>
>>> The problem is mainly nomenclature, I guess, but my LaTeX_CLASS
>>> definitions are usually a *lot* more than a list of packages.
>>>
>>> It seems a little odd, but OK.
>>>
>>> Mark
>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>
>> - Carsten
>>
>>
>>
>
> - Carsten
>
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 1, 2010, at 6:17 PM, Thomas S. Dye wrote:

> Aloha Carsten,
>
> Packages that aren't used for all classes can still appear in org- 
> export-latex-classes, correct?

Aloha Tom,

Anything can appear there.  But you should not have the packages I  
have listed in the new variable org-export-latex-default-packages- 
alist, because these will be used anyway.  If you keep them in org- 
export-latex-classes, they will be called twice (which may or may not  
be a problem....)

- Carsten

>
> All the best,
> Tom
>
> On Apr 1, 2010, at 1:13 AM, Carsten Dominik wrote:
>
>> OK, this change is now in the master branch.
>>
>> - Carsten
>>
>> On Apr 1, 2010, at 8:59 AM, Carsten Dominik wrote:
>>
>>> Hi Mark,
>>>
>>> OK, it seems that I have really overstated this change.  You are of
>>> course right that your header for a document type can be very long,
>>> that that defining it in org-export-latex-classes is a viable option
>>> (other being to put this stuff into a separate file).
>>>
>>> So let me restate what I am trying to say in this thread.
>>>
>>> ------------------------------------------------------------------------------
>>> Org-mode contains now a new variable `org-export-latex-default- 
>>> packages-alist'
>>> which contains all the LaTeX packages it needs to use for basic  
>>> Org-mode
>>> functionality.  The corresponding \usepackage statements used to  
>>> be part
>>> of the header definitions in org-export-latex-classes, and they  
>>> had to
>>> be repeated for each document class.  This is wasteful, error  
>>> prone, and
>>> hard to maintain.
>>> Therefore, these packages are now collected in the new variable,
>>> and they will be spliced into the header.
>>>
>>> If you have customized the variable org-export-latex-classes, you  
>>> need to
>>> remove the following lines from each class definition:
>>>
>>> \usepackage[AUTO]{inputenc}
>>> \usepackage[T1]{fontenc}
>>> \usepackage{graphicx}
>>> \usepackage{longtable}
>>> \usepackage{float}
>>> \usepackage{wrapfig}
>>> \usepackage{soul}
>>> \usepackage{latexsym}
>>> \usepackage{amssymb}
>>> \usepackage{hyperref}
>>>
>>> If you have other packages you always want to use in all
>>> classes, you can add them to another variable,
>>> `org-export-latex-packages-alist'.
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> I think this makes more sense, thank you for making me clarify this.
>>>
>>> - Carsten
>>>
>>>
>>>
>>> On Mar 31, 2010, at 8:41 PM, Mark Elston wrote:
>>>
>>>> On 3/31/2010 5:35 AM, Carsten Dominik wrote:
>>>>>
>>>>> On Mar 31, 2010, at 11:00 AM, Chris Gray wrote:
>>>>>
>>>>>> Carsten Dominik wrote:
>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>>
>>>>>>> * =org-export-latex-classes= no longer should be customized  
>>>>>>> for packages
>>>>>> ...
>>>>>>> So if you have customized this variable, please remove once more
>>>>>>> (hopefully for the last time) your customization, so that it can
>>>>>>> revert to its now much simpler default value. Put all your
>>>>>>> package definitions into org-export-latex-packages-alist.
>>>>>>> I hope this works, and we will not get conflicts because of the
>>>>>>> sequence in which packages are called. If there are problems,
>>>>>>> please let me know so that we can find a solution.
>>>>>>
>>>>>> Is it sufficient to change the variable that is being set from
>>>>>> org-export-latex-classes to org-export-latex-default-packages- 
>>>>>> alist? Or
>>>>>> does the format of the list change at all?
>>>>>
>>>>> org-export-latex-default-packages-alist has the same format as
>>>>> org-export-latex-pakcages-alist. And I am filling
>>>>> org-export-latex-default-packages-alist already with the correct  
>>>>> set of
>>>>> default packages, so you should not touch that variable.
>>>>>
>>>>> Only if you have previously customized org-export-latex-classes  
>>>>> in order
>>>>> to add more usepackage statements, then you should remove your
>>>>> customization of that variable and list your set of additional  
>>>>> packages
>>>>> in org-export-latex-packages-alist instead.
>>>>>
>>>>> Am I making sense?
>>>>>
>>>>
>>>> So, org-export-latex-classes will no longer be used to define
>>>> LaTeX_CLASS classes?  Instead these classes will be defined in
>>>> org-export-latex-default-packages-alist?
>>>>
>>>> The problem is mainly nomenclature, I guess, but my LaTeX_CLASS
>>>> definitions are usually a *lot* more than a list of packages.
>>>>
>>>> It seems a little odd, but OK.
>>>>
>>>> Mark
>>>>
>>>>
>>>> _______________________________________________
>>>> Emacs-orgmode mailing list
>>>> Please use `Reply All' to send replies to the list.
>>>> Emacs-orgmode@gnu.org
>>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>>
>>> - Carsten
>>>
>>>
>>>
>>
>> - Carsten
>>
>>
>>
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Mark Elston]

Carsten,

Thanks for this clarification.  This makes the transition much
simpler than I originally thought.  I can certainly remove the
common package names.

The existing org-export-latex-classes also contains the
documentclass line.  That won't change, will it?  I am
assuming from what you have written that the generated LaTeX code
will be something like:

  <contents of org-export-latex-classes for the selected class>
  <contents of org-export-latex-default-packages-alist>
  <contents of org-export-latex-packages-alist for the selected class>

Is this correct?

Mark

On 3/31/2010 11:59 PM, Carsten Dominik wrote:
> Hi Mark,
>
> OK, it seems that I have really overstated this change. You are of
> course right that your header for a document type can be very long,
> that that defining it in org-export-latex-classes is a viable option
> (other being to put this stuff into a separate file).
>
> So let me restate what I am trying to say in this thread.
>
> ------------------------------------------------------------------------------
>
> Org-mode contains now a new variable
> `org-export-latex-default-packages-alist'
> which contains all the LaTeX packages it needs to use for basic Org-mode
> functionality. The corresponding \usepackage statements used to be part
> of the header definitions in org-export-latex-classes, and they had to
> be repeated for each document class. This is wasteful, error prone, and
> hard to maintain.
> Therefore, these packages are now collected in the new variable,
> and they will be spliced into the header.
>
> If you have customized the variable org-export-latex-classes, you need to
> remove the following lines from each class definition:
>
> \usepackage[AUTO]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{longtable}
> \usepackage{float}
> \usepackage{wrapfig}
> \usepackage{soul}
> \usepackage{latexsym}
> \usepackage{amssymb}
> \usepackage{hyperref}
>
> If you have other packages you always want to use in all
> classes, you can add them to another variable,
> `org-export-latex-packages-alist'.
> ------------------------------------------------------------------------------
>
>
>
> I think this makes more sense, thank you for making me clarify this.
>
> - Carsten
>
>
>

Re: [PATCH] IMPORTANT: (possibly) incompatible Change

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

After updating to the current git head, I have to make the following
changes for latex image generation to work.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: latex-packages-alist-fix.patch --]
[-- Type: text/x-diff, Size: 917 bytes --]

diff --git a/lisp/org.el b/lisp/org.el
index dc45871..443f881 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2936,7 +2936,7 @@ appears on the page."
 ;; when formatting latex fragments.  Originally it was part of the
 ;; LaTeX exporter, which is why the name includes "export".
 (defcustom org-export-latex-default-packages-alist
-  '(("AUTO" . "inputenc")
+  '(("" . "inputenc")
     ("T1"   . "fontenc")
     (""     . "graphicx")
     (""     . "longtable")
@@ -15247,9 +15247,9 @@ Some of the options can be changed using the variable
 		  (concat "\n"
 			  (mapconcat (lambda(p)
 				       (if (equal "" (car p))
-					   (format "\\usepackage{%s}" (cadr p))
+					   (format "\\usepackage{%s}" (cdr p))
 					 (format "\\usepackage[%s]{%s}"
-						 (car p) (cadr p))))
+						 (car p) (cdr p))))
 				     (append
 				      org-export-latex-default-packages-alist
 				      org-export-latex-packages-alist)

[-- Attachment #3: Type: text/plain, Size: 2921 bytes --]


The "AUTO" change is because the AUTO.def file is not present on my
fairly complete Ubuntu texlive latex install

: ERROR: LaTeX Error: File `AUTO.def' not found.

The other change is because `org-export-latex-default-packages-alist' is
now a simple cons cell rather than a list so cadr was throwing errors.

It seems to me these may be general problems, not just specific to my
setup.

Best -- Eric

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Dear all,
>
> I have just checked in an important change - if you use LaTeX
> export, you need to be aware of it.
>
> 1. Org contains now a much better system for handling special entities
>    that are written like LaTeX macros, for example \therefore,
> \emptyset,
>    etc.  I will write more about this in the release notes for 6.35.
> But
>    already now thanks go to Ulf Stegemann without whom this would not
>    have happened.
>
> 2. I could no longer keep the old setup for LaTeX export in
>    org-export-latex-classes.  The disadvantage was that whenever you
>    needed to make changes to the header, you would fix the value of
> this
>    variable so that any changes I'd make in the future would not be
> visible
>    to you.
>
>    The way this is solved now is (excerpt from the upcoming release
> notes)
>
> -----------------------------------------------------------------------------
> * =org-export-latex-classes= no longer should be customized for packages
>
> The HEADER part of this variable should now only contain the
> documentclass macro, nothing else - at least normally.  All the
> package calls via usepackage should go into
> org-export-latex-packages-alist.  I moved all the default packages
> that into a new variable org-export-latex-default-packages-alist.
> This will allow me to add more packages (as needed) in the
> future, withour requiring you to erase and then redo your
> configuration of org-export-latex-classes.
>
> So if you have customized this variable, please remove once more
> (hopefully for the last time) your customization, so that it can
> revert to its now much simpler default value.  Put all your
> package definitions into org-export-latex-packages-alist.
> I hope this works, and we will not get conflicts because of the
> sequence in which packages are called.  If there are problems,
> please let me know so that we can find a solution.
> -----------------------------------------------------------------------------
>
> I have not yet put this onto the master branch, but I will soon.
> If you want to help testing this new setup, please check out the branch
> new-entity-support from the git repo and let me know if you run into any
> problems.
>
> Thanks!
>
> - Carsten (and Ulf)
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[-- Attachment #4: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [PATCH] IMPORTANT: (possibly) incompatible Change

[Mark Elston]

It appears that the cadr -> cdr change is also necessary in org-latex.el
(at least for Emacs 22.3).

Mark

On 4/1/2010 6:29 PM, Eric Schulte wrote:
> After updating to the current git head, I have to make the following
> changes for latex image generation to work.
>
> diff --git a/lisp/org.el b/lisp/org.el
> index dc45871..443f881 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -2936,7 +2936,7 @@ appears on the page."
>  ;; when formatting latex fragments.  Originally it was part of the
>  ;; LaTeX exporter, which is why the name includes "export".
>  (defcustom org-export-latex-default-packages-alist
> -  '(("AUTO" . "inputenc")
> +  '(("" . "inputenc")
>      ("T1"   . "fontenc")
>      (""     . "graphicx")
>      (""     . "longtable")
> @@ -15247,9 +15247,9 @@ Some of the options can be changed using the variable
>  		  (concat "\n"
>  			  (mapconcat (lambda(p)
>  				       (if (equal "" (car p))
> -					   (format "\\usepackage{%s}" (cadr p))
> +					   (format "\\usepackage{%s}" (cdr p))
>  					 (format "\\usepackage[%s]{%s}"
> -						 (car p) (cadr p))))
> +						 (car p) (cdr p))))
>  				     (append
>  				      org-export-latex-default-packages-alist
>  				      org-export-latex-packages-alist)
>
>
>
>
>
>
> The "AUTO" change is because the AUTO.def file is not present on my
> fairly complete Ubuntu texlive latex install
>
> : ERROR: LaTeX Error: File `AUTO.def' not found.
>
> The other change is because `org-export-latex-default-packages-alist' is
> now a simple cons cell rather than a list so cadr was throwing errors.
>
> It seems to me these may be general problems, not just specific to my
> setup.
>
> Best -- Eric
>

Re: [PATCH] IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

Hi Eric,

I have fixed this issue in the definition of the variable value instead
of in the code.  Bastien did define `org-export-latex-packages'
as a list of lists instead of a list of cons cells.  So we should
stick with this structure - which is also better because it is
more easily extended, for example if we later need another parameter
to modify the sequence of some packages.

Thanks.

- Carsten

On Apr 2, 2010, at 3:29 AM, Eric Schulte wrote:

> After updating to the current git head, I have to make the following
> changes for latex image generation to work.
>
> diff --git a/lisp/org.el b/lisp/org.el
> index dc45871..443f881 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -2936,7 +2936,7 @@ appears on the page."
> ;; when formatting latex fragments.  Originally it was part of the
> ;; LaTeX exporter, which is why the name includes "export".
> (defcustom org-export-latex-default-packages-alist
> -  '(("AUTO" . "inputenc")
> +  '(("" . "inputenc")
>     ("T1"   . "fontenc")
>     (""     . "graphicx")
>     (""     . "longtable")
> @@ -15247,9 +15247,9 @@ Some of the options can be changed using the  
> variable
> 		  (concat "\n"
> 			  (mapconcat (lambda(p)
> 				       (if (equal "" (car p))
> -					   (format "\\usepackage{%s}" (cadr p))
> +					   (format "\\usepackage{%s}" (cdr p))
> 					 (format "\\usepackage[%s]{%s}"
> -						 (car p) (cadr p))))
> +						 (car p) (cdr p))))
> 				     (append
> 				      org-export-latex-default-packages-alist
> 				      org-export-latex-packages-alist)
>
> The "AUTO" change is because the AUTO.def file is not present on my
> fairly complete Ubuntu texlive latex install
>
> : ERROR: LaTeX Error: File `AUTO.def' not found.
>
> The other change is because `org-export-latex-default-packages- 
> alist' is
> now a simple cons cell rather than a list so cadr was throwing errors.
>
> It seems to me these may be general problems, not just specific to my
> setup.
>
> Best -- Eric
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Dear all,
>>
>> I have just checked in an important change - if you use LaTeX
>> export, you need to be aware of it.
>>
>> 1. Org contains now a much better system for handling special  
>> entities
>>   that are written like LaTeX macros, for example \therefore,
>> \emptyset,
>>   etc.  I will write more about this in the release notes for 6.35.
>> But
>>   already now thanks go to Ulf Stegemann without whom this would not
>>   have happened.
>>
>> 2. I could no longer keep the old setup for LaTeX export in
>>   org-export-latex-classes.  The disadvantage was that whenever you
>>   needed to make changes to the header, you would fix the value of
>> this
>>   variable so that any changes I'd make in the future would not be
>> visible
>>   to you.
>>
>>   The way this is solved now is (excerpt from the upcoming release
>> notes)
>>
>> -----------------------------------------------------------------------------
>> * =org-export-latex-classes= no longer should be customized for  
>> packages
>>
>> The HEADER part of this variable should now only contain the
>> documentclass macro, nothing else - at least normally.  All the
>> package calls via usepackage should go into
>> org-export-latex-packages-alist.  I moved all the default packages
>> that into a new variable org-export-latex-default-packages-alist.
>> This will allow me to add more packages (as needed) in the
>> future, withour requiring you to erase and then redo your
>> configuration of org-export-latex-classes.
>>
>> So if you have customized this variable, please remove once more
>> (hopefully for the last time) your customization, so that it can
>> revert to its now much simpler default value.  Put all your
>> package definitions into org-export-latex-packages-alist.
>> I hope this works, and we will not get conflicts because of the
>> sequence in which packages are called.  If there are problems,
>> please let me know so that we can find a solution.
>> -----------------------------------------------------------------------------
>>
>> I have not yet put this onto the master branch, but I will soon.
>> If you want to help testing this new setup, please check out the  
>> branch
>> new-entity-support from the git repo and let me know if you run  
>> into any
>> problems.
>>
>> Thanks!
>>
>> - Carsten (and Ulf)
>>
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 2, 2010, at 3:17 AM, Mark Elston wrote:

> Carsten,
>
> Thanks for this clarification.  This makes the transition much
> simpler than I originally thought.  I can certainly remove the
> common package names.
>
> The existing org-export-latex-classes also contains the
> documentclass line.  That won't change, will it?  I am
> assuming from what you have written that the generated LaTeX code
> will be something like:
>
> <contents of org-export-latex-classes for the selected class>
> <contents of org-export-latex-default-packages-alist>
> <contents of org-export-latex-packages-alist for the selected class>

Yes.  But the latter two variables are independent of class.
And after these three components, #+LaTeX_HEADER stuff will be
added as well.

- Carsten

>
> Is this correct?
>
> Mark
>
> On 3/31/2010 11:59 PM, Carsten Dominik wrote:
>> Hi Mark,
>>
>> OK, it seems that I have really overstated this change. You are of
>> course right that your header for a document type can be very long,
>> that that defining it in org-export-latex-classes is a viable option
>> (other being to put this stuff into a separate file).
>>
>> So let me restate what I am trying to say in this thread.
>>
>> ------------------------------------------------------------------------------
>>
>> Org-mode contains now a new variable
>> `org-export-latex-default-packages-alist'
>> which contains all the LaTeX packages it needs to use for basic Org- 
>> mode
>> functionality. The corresponding \usepackage statements used to be  
>> part
>> of the header definitions in org-export-latex-classes, and they had  
>> to
>> be repeated for each document class. This is wasteful, error prone,  
>> and
>> hard to maintain.
>> Therefore, these packages are now collected in the new variable,
>> and they will be spliced into the header.
>>
>> If you have customized the variable org-export-latex-classes, you  
>> need to
>> remove the following lines from each class definition:
>>
>> \usepackage[AUTO]{inputenc}
>> \usepackage[T1]{fontenc}
>> \usepackage{graphicx}
>> \usepackage{longtable}
>> \usepackage{float}
>> \usepackage{wrapfig}
>> \usepackage{soul}
>> \usepackage{latexsym}
>> \usepackage{amssymb}
>> \usepackage{hyperref}
>>
>> If you have other packages you always want to use in all
>> classes, you can add them to another variable,
>> `org-export-latex-packages-alist'.
>> ------------------------------------------------------------------------------
>>
>>
>>
>> I think this makes more sense, thank you for making me clarify this.
>>
>> - Carsten
>>
>>
>>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Thomas S. Dye]

[-- Attachment #1.1: Type: text/plain, Size: 5511 bytes --]

Aloha Carsten and others,

The Worg FAQ on beamer export describes a setup that isn't up-to-date:

http://orgmode.org/worg/org-faq.php#beamer

All the best,
Tom

On Apr 1, 2010, at 6:51 AM, Carsten Dominik wrote:

>
> On Apr 1, 2010, at 6:17 PM, Thomas S. Dye wrote:
>
>> Aloha Carsten,
>>
>> Packages that aren't used for all classes can still appear in org- 
>> export-latex-classes, correct?
>
> Aloha Tom,
>
> Anything can appear there.  But you should not have the packages I  
> have listed in the new variable org-export-latex-default-packages- 
> alist, because these will be used anyway.  If you keep them in org- 
> export-latex-classes, they will be called twice (which may or may  
> not be a problem....)
>
> - Carsten
>
>>
>> All the best,
>> Tom
>>
>> On Apr 1, 2010, at 1:13 AM, Carsten Dominik wrote:
>>
>>> OK, this change is now in the master branch.
>>>
>>> - Carsten
>>>
>>> On Apr 1, 2010, at 8:59 AM, Carsten Dominik wrote:
>>>
>>>> Hi Mark,
>>>>
>>>> OK, it seems that I have really overstated this change.  You are of
>>>> course right that your header for a document type can be very long,
>>>> that that defining it in org-export-latex-classes is a viable  
>>>> option
>>>> (other being to put this stuff into a separate file).
>>>>
>>>> So let me restate what I am trying to say in this thread.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Org-mode contains now a new variable `org-export-latex-default- 
>>>> packages-alist'
>>>> which contains all the LaTeX packages it needs to use for basic  
>>>> Org-mode
>>>> functionality.  The corresponding \usepackage statements used to  
>>>> be part
>>>> of the header definitions in org-export-latex-classes, and they  
>>>> had to
>>>> be repeated for each document class.  This is wasteful, error  
>>>> prone, and
>>>> hard to maintain.
>>>> Therefore, these packages are now collected in the new variable,
>>>> and they will be spliced into the header.
>>>>
>>>> If you have customized the variable org-export-latex-classes, you  
>>>> need to
>>>> remove the following lines from each class definition:
>>>>
>>>> \usepackage[AUTO]{inputenc}
>>>> \usepackage[T1]{fontenc}
>>>> \usepackage{graphicx}
>>>> \usepackage{longtable}
>>>> \usepackage{float}
>>>> \usepackage{wrapfig}
>>>> \usepackage{soul}
>>>> \usepackage{latexsym}
>>>> \usepackage{amssymb}
>>>> \usepackage{hyperref}
>>>>
>>>> If you have other packages you always want to use in all
>>>> classes, you can add them to another variable,
>>>> `org-export-latex-packages-alist'.
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> I think this makes more sense, thank you for making me clarify  
>>>> this.
>>>>
>>>> - Carsten
>>>>
>>>>
>>>>
>>>> On Mar 31, 2010, at 8:41 PM, Mark Elston wrote:
>>>>
>>>>> On 3/31/2010 5:35 AM, Carsten Dominik wrote:
>>>>>>
>>>>>> On Mar 31, 2010, at 11:00 AM, Chris Gray wrote:
>>>>>>
>>>>>>> Carsten Dominik wrote:
>>>>>>>
>>>>>>>> -----------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> * =org-export-latex-classes= no longer should be customized  
>>>>>>>> for packages
>>>>>>> ...
>>>>>>>> So if you have customized this variable, please remove once  
>>>>>>>> more
>>>>>>>> (hopefully for the last time) your customization, so that it  
>>>>>>>> can
>>>>>>>> revert to its now much simpler default value. Put all your
>>>>>>>> package definitions into org-export-latex-packages-alist.
>>>>>>>> I hope this works, and we will not get conflicts because of the
>>>>>>>> sequence in which packages are called. If there are problems,
>>>>>>>> please let me know so that we can find a solution.
>>>>>>>
>>>>>>> Is it sufficient to change the variable that is being set from
>>>>>>> org-export-latex-classes to org-export-latex-default-packages- 
>>>>>>> alist? Or
>>>>>>> does the format of the list change at all?
>>>>>>
>>>>>> org-export-latex-default-packages-alist has the same format as
>>>>>> org-export-latex-pakcages-alist. And I am filling
>>>>>> org-export-latex-default-packages-alist already with the  
>>>>>> correct set of
>>>>>> default packages, so you should not touch that variable.
>>>>>>
>>>>>> Only if you have previously customized org-export-latex-classes  
>>>>>> in order
>>>>>> to add more usepackage statements, then you should remove your
>>>>>> customization of that variable and list your set of additional  
>>>>>> packages
>>>>>> in org-export-latex-packages-alist instead.
>>>>>>
>>>>>> Am I making sense?
>>>>>>
>>>>>
>>>>> So, org-export-latex-classes will no longer be used to define
>>>>> LaTeX_CLASS classes?  Instead these classes will be defined in
>>>>> org-export-latex-default-packages-alist?
>>>>>
>>>>> The problem is mainly nomenclature, I guess, but my LaTeX_CLASS
>>>>> definitions are usually a *lot* more than a list of packages.
>>>>>
>>>>> It seems a little odd, but OK.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Emacs-orgmode mailing list
>>>>> Please use `Reply All' to send replies to the list.
>>>>> Emacs-orgmode@gnu.org
>>>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>>>
>>>> - Carsten
>>>>
>>>>
>>>>
>>>
>>> - Carsten
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>
>
> - Carsten
>
>
>


[-- Attachment #1.2: Type: text/html, Size: 23176 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: IMPORTANT: (possibly) incompatible Change

[Henri-Paul Indiogine]

This is the first time that I try a LaTeX export from my org file after
the change.  Before the change no problems.  I am obviously doing
something wrongly. 

Here is some code from my .emacs:

(setq org-export-latex-packages-alist
      '(("" . "apacite")
	("" . "color")
	("" . "tikz")))

My error message after: C-c C-e l:

Exporting to LaTeX...
mapconcat: Wrong type argument: listp, "apacite"

Thanks,

-- 
Henri-Paul Indiogine
Email: hindiogine@gmail.com
Skype: hindiogine
Website: http://www.coe.tamu.edu/~enrico

Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 3, 2010, at 6:20 PM, Henri-Paul Indiogine wrote:

> This is the first time that I try a LaTeX export from my org file  
> after
> the change.  Before the change no problems.  I am obviously doing
> something wrongly.
>
> Here is some code from my .emacs:
>
> (setq org-export-latex-packages-alist
>      '(("" . "apacite")
> 	("" . "color")
> 	("" . "tikz")))
>


It needs to be:

(setq org-export-latex-packages-alist
      '(("" "apacite")
	("" "color")
	("" "tikz")))

(my mistake)

- Carstern




> My error message after: C-c C-e l:
>
> Exporting to LaTeX...
> mapconcat: Wrong type argument: listp, "apacite"
>
> Thanks,
>
> -- 
> Henri-Paul Indiogine
> Email: hindiogine@gmail.com
> Skype: hindiogine
> Website: http://www.coe.tamu.edu/~enrico
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: IMPORTANT: (possibly) incompatible Change

[Xiao-Yong Jin]

On Sat, 3 Apr 2010 18:55:46 +0200, Carsten Dominik wrote:

> It needs to be:

> (setq org-export-latex-packages-alist
>      '(("" "apacite")
> 	("" "color")
> 	("" "tikz")))

Then it is not an alist.

> (my mistake)

> - Carstern
-- 
J    c/*    __o/*
X    <\     * (__
Y    */\      <

Re: Re: IMPORTANT: (possibly) incompatible Change

[Mark Elston]

Carsten,

Is there a way to *remove* one or more of the packages in
org-export-latex-default-packages-alist?  I find that marvosym
is conflicting with one of the packages I use in my notes and
handouts that I generate from org-mode.  (marvosym and bbding
both provide a Cross - I don't use that symbol but it interferes
with latex processing to have them both defined)

I suppose a way to remove one or more packages in *specific*
export classes would be ideal...

Mark

On 4/2/2010 12:55 AM, Carsten Dominik wrote:
>
> On Apr 2, 2010, at 3:17 AM, Mark Elston wrote:
>
>> Carsten,
>>
>> Thanks for this clarification. This makes the transition much
>> simpler than I originally thought. I can certainly remove the
>> common package names.
>>
>> The existing org-export-latex-classes also contains the
>> documentclass line. That won't change, will it? I am
>> assuming from what you have written that the generated LaTeX code
>> will be something like:
>>
>> <contents of org-export-latex-classes for the selected class>
>> <contents of org-export-latex-default-packages-alist>
>> <contents of org-export-latex-packages-alist for the selected class>
>
> Yes. But the latter two variables are independent of class.
> And after these three components, #+LaTeX_HEADER stuff will be
> added as well.
>
> - Carsten
>
>>
>> Is this correct?
>>
>> Mark
>>
>> On 3/31/2010 11:59 PM, Carsten Dominik wrote:
>>> Hi Mark,
>>>
>>> OK, it seems that I have really overstated this change. You are of
>>> course right that your header for a document type can be very long,
>>> that that defining it in org-export-latex-classes is a viable option
>>> (other being to put this stuff into a separate file).
>>>
>>> So let me restate what I am trying to say in this thread.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Org-mode contains now a new variable
>>> `org-export-latex-default-packages-alist'
>>> which contains all the LaTeX packages it needs to use for basic Org-mode
>>> functionality. The corresponding \usepackage statements used to be part
>>> of the header definitions in org-export-latex-classes, and they had to
>>> be repeated for each document class. This is wasteful, error prone, and
>>> hard to maintain.
>>> Therefore, these packages are now collected in the new variable,
>>> and they will be spliced into the header.
>>>
>>> If you have customized the variable org-export-latex-classes, you
>>> need to
>>> remove the following lines from each class definition:
>>>
>>> \usepackage[AUTO]{inputenc}
>>> \usepackage[T1]{fontenc}
>>> \usepackage{graphicx}
>>> \usepackage{longtable}
>>> \usepackage{float}
>>> \usepackage{wrapfig}
>>> \usepackage{soul}
>>> \usepackage{latexsym}
>>> \usepackage{amssymb}
>>> \usepackage{hyperref}
>>>
>>> If you have other packages you always want to use in all
>>> classes, you can add them to another variable,
>>> `org-export-latex-packages-alist'.
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> I think this makes more sense, thank you for making me clarify this.
>>>
>>> - Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Henri-Paul Indiogine]

Hi!

This is what I have in my .emacs

(setq org-export-latex-packages-alist
      '(("" "apacite")
	("" "color")
	("" "tikz")))

(setq org-export-latex-classes 
    '(("book"
   "\\documentclass[11pt]{book}
    \\definecolor{darkblue}{rgb}{0.0,0.0,0.3}
    \\hypersetup{colorlinks,breaklinks,
            linkcolor=darkblue,urlcolor=darkblue,
            anchorcolor=darkblue,citecolor=darkblue}"
    ("\\chapter{%s}" . "\\chapter*{%s}")
    ("\\section{%s}" . "\\section*{%s}")
    ("\\subsection{%s}" . "\\subsection*{%s}")
    ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
))

When I export to LaTeX the line \definecolor..... comes before 
\usepackage{color}  then it throws an error during compilation.  If I
move the \definecolor... _after_ \usepackage{color} it compiles.  

Is are a way to setup my LaTeX export so that this happens
automagically?

Thanks,



-- 
Henri-Paul Indiogine
Email: hindiogine@gmail.com
Skype: hindiogine
Website: http://www.coe.tamu.edu/~enrico

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 4, 2010, at 12:50 AM, Henri-Paul Indiogine wrote:

> Hi!
>
> This is what I have in my .emacs
>
> (setq org-export-latex-packages-alist
>      '(("" "apacite")
> 	("" "color")
> 	("" "tikz")))
>
> (setq org-export-latex-classes
>    '(("book"
>   "\\documentclass[11pt]{book}
>    \\definecolor{darkblue}{rgb}{0.0,0.0,0.3}
>    \\hypersetup{colorlinks,breaklinks,
>            linkcolor=darkblue,urlcolor=darkblue,
>            anchorcolor=darkblue,citecolor=darkblue}"
>    ("\\chapter{%s}" . "\\chapter*{%s}")
>    ("\\section{%s}" . "\\section*{%s}")
>    ("\\subsection{%s}" . "\\subsection*{%s}")
>    ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
> ))
>
> When I export to LaTeX the line \definecolor..... comes before
> \usepackage{color}  then it throws an error during compilation.  If I
> move the \definecolor... _after_ \usepackage{color} it compiles.
>
> Is are a way to setup my LaTeX export so that this happens
> automagically?

No, I think you need to return to the old way of configuring everything
in org-export-latex-classes.

I hope you can get away with leaving the standard packages
in org-export-latex-default-packages-alist?

- Carsten


>
> Thanks,
>
>
>
> -- 
> Henri-Paul Indiogine
> Email: hindiogine@gmail.com
> Skype: hindiogine
> Website: http://www.coe.tamu.edu/~enrico
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 3, 2010, at 8:49 PM, Mark Elston wrote:

> Carsten,
>
> Is there a way to *remove* one or more of the packages in
> org-export-latex-default-packages-alist?  I find that marvosym
> is conflicting with one of the packages I use in my notes and
> handouts that I generate from org-mode.  (marvosym and bbding
> both provide a Cross - I don't use that symbol but it interferes
> with latex processing to have them both defined)

Hi Mark,

if you read the docstring of that variable, you will see
that you can do this for exactly this kine of problem.  Just remove
it, and the do not use symbols from this oackage.

>
> I suppose a way to remove one or more packages in *specific*
> export classes would be ideal...

You can do this yourself using a hook.

- Carsten

>
> Mark
>
> On 4/2/2010 12:55 AM, Carsten Dominik wrote:
>>
>> On Apr 2, 2010, at 3:17 AM, Mark Elston wrote:
>>
>>> Carsten,
>>>
>>> Thanks for this clarification. This makes the transition much
>>> simpler than I originally thought. I can certainly remove the
>>> common package names.
>>>
>>> The existing org-export-latex-classes also contains the
>>> documentclass line. That won't change, will it? I am
>>> assuming from what you have written that the generated LaTeX code
>>> will be something like:
>>>
>>> <contents of org-export-latex-classes for the selected class>
>>> <contents of org-export-latex-default-packages-alist>
>>> <contents of org-export-latex-packages-alist for the selected class>
>>
>> Yes. But the latter two variables are independent of class.
>> And after these three components, #+LaTeX_HEADER stuff will be
>> added as well.
>>
>> - Carsten
>>
>>>
>>> Is this correct?
>>>
>>> Mark
>>>
>>> On 3/31/2010 11:59 PM, Carsten Dominik wrote:
>>>> Hi Mark,
>>>>
>>>> OK, it seems that I have really overstated this change. You are of
>>>> course right that your header for a document type can be very long,
>>>> that that defining it in org-export-latex-classes is a viable  
>>>> option
>>>> (other being to put this stuff into a separate file).
>>>>
>>>> So let me restate what I am trying to say in this thread.
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> Org-mode contains now a new variable
>>>> `org-export-latex-default-packages-alist'
>>>> which contains all the LaTeX packages it needs to use for basic  
>>>> Org-mode
>>>> functionality. The corresponding \usepackage statements used to  
>>>> be part
>>>> of the header definitions in org-export-latex-classes, and they  
>>>> had to
>>>> be repeated for each document class. This is wasteful, error  
>>>> prone, and
>>>> hard to maintain.
>>>> Therefore, these packages are now collected in the new variable,
>>>> and they will be spliced into the header.
>>>>
>>>> If you have customized the variable org-export-latex-classes, you
>>>> need to
>>>> remove the following lines from each class definition:
>>>>
>>>> \usepackage[AUTO]{inputenc}
>>>> \usepackage[T1]{fontenc}
>>>> \usepackage{graphicx}
>>>> \usepackage{longtable}
>>>> \usepackage{float}
>>>> \usepackage{wrapfig}
>>>> \usepackage{soul}
>>>> \usepackage{latexsym}
>>>> \usepackage{amssymb}
>>>> \usepackage{hyperref}
>>>>
>>>> If you have other packages you always want to use in all
>>>> classes, you can add them to another variable,
>>>> `org-export-latex-packages-alist'.
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> I think this makes more sense, thank you for making me clarify  
>>>> this.
>>>>
>>>> - Carsten
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Mark Elston]

Carsten,

On 4/3/2010 3:57 PM, Carsten Dominik wrote:
>
> On Apr 3, 2010, at 8:49 PM, Mark Elston wrote:
>
>> Carsten,
>>
>> Is there a way to *remove* one or more of the packages in
>> org-export-latex-default-packages-alist? I find that marvosym
>> is conflicting with one of the packages I use in my notes and
>> handouts that I generate from org-mode. (marvosym and bbding
>> both provide a Cross - I don't use that symbol but it interferes
>> with latex processing to have them both defined)
>
> Hi Mark,
>
> if you read the docstring of that variable, you will see
> that you can do this for exactly this kine of problem. Just remove
> it, and the do not use symbols from this oackage.

Yeah, it also says "DON'T CHANGE THIS.  Unless abslutely necessary
that is."

I get a little nervous about changing something with that kind of
warning.. :)

Does anyone know why marvosym is included in this list?  I assume
that there is latex code being generated (under some circumstances)
that require it, but I don't know what those circumstances are...

>>
>> I suppose a way to remove one or more packages in *specific*
>> export classes would be ideal...
>
> You can do this yourself using a hook.

Or, I suppose, I can change my class to not use the conflicting
class...  This seems easier :)

I just did that and will see if the results are acceptable...

Thanks for all the work on this.  It is a really great tool for my
purposes (and a lot of other as well).

Mark

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

Hi Mark,

On Apr 4, 2010, at 1:25 AM, Mark Elston wrote:

> Carsten,
>
> On 4/3/2010 3:57 PM, Carsten Dominik wrote:
>>
>> On Apr 3, 2010, at 8:49 PM, Mark Elston wrote:
>>
>>> Carsten,
>>>
>>> Is there a way to *remove* one or more of the packages in
>>> org-export-latex-default-packages-alist? I find that marvosym
>>> is conflicting with one of the packages I use in my notes and
>>> handouts that I generate from org-mode. (marvosym and bbding
>>> both provide a Cross - I don't use that symbol but it interferes
>>> with latex processing to have them both defined)
>>
>> Hi Mark,
>>
>> if you read the docstring of that variable, you will see
>> that you can do this for exactly this kine of problem. Just remove
>> it, and the do not use symbols from this oackage.
>
> Yeah, it also says "DON'T CHANGE THIS.  Unless abslutely necessary
> that is."
>
> I get a little nervous about changing something with that kind of
> warning.. :)

Yes.  I have just improved this docstring to reflect the real situation.

>
> Does anyone know why marvosym is included in this list?  I assume
> that there is latex code being generated (under some circumstances)
> that require it, but I don't know what those circumstances are...

Some of the symbols in org-entities use it.  Only Ulf knows which.

- Carsten

>
>>>
>>> I suppose a way to remove one or more packages in *specific*
>>> export classes would be ideal...
>>
>> You can do this yourself using a hook.
>
> Or, I suppose, I can change my class to not use the conflicting
> class...  This seems easier :)
>
> I just did that and will see if the results are acceptable...
>
> Thanks for all the work on this.  It is a really great tool for my
> purposes (and a lot of other as well).
>
> Mark
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Nick Dokos]

Carsten Dominik <carsten.dominik@gmail.com> wrote:

> On Apr 4, 2010, at 1:25 AM, Mark Elston wrote:
> ...
> >
> > Does anyone know why marvosym is included in this list?  I assume
> > that there is latex code being generated (under some circumstances)
> > that require it, but I don't know what those circumstances are...
> 
> Some of the symbols in org-entities use it.  Only Ulf knows which.
> 

\EUR and its variations:

\EURdig
\EURhv
\EURcr
\EURtm

Nick

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 4, 2010, at 7:47 AM, Nick Dokos wrote:

> Carsten Dominik <carsten.dominik@gmail.com> wrote:
>
>> On Apr 4, 2010, at 1:25 AM, Mark Elston wrote:
>> ...
>>>
>>> Does anyone know why marvosym is included in this list?  I assume
>>> that there is latex code being generated (under some circumstances)
>>> that require it, but I don't know what those circumstances are...
>>
>> Some of the symbols in org-entities use it.  Only Ulf knows which.
>>
>
> \EUR and its variations:
>
> \EURdig
> \EURhv
> \EURcr
> \EURtm
>
> Nick


OK, not only Ulf.

Thanks!

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Henri-Paul Indiogine]

Carsten Dominik <carsten.dominik@gmail.com> writes:
>
> OK, you can now specify the position where the usepackage definitions
> should appear in your header by putting the string
>
>    [PACKAGES]
>
> into the header definition in org-export-latex-classes.  Default (if
> you do
> not include this placeholder) is at the end.

Sorry, but I am totally confused now.  I want my packages defined in
org-export-latex-classes at the end of the LaTeX file preamble.  So,
according to your instructions, if I understand them correctly, I
should not use this [PACKAGES] string.  But, when I generate the tex
file the packages from org-export-latex-classes are at the top of my
preamble not at the end.

Basically, I would like to have the packages in the following order:

1. org-export-latex-default-packages-alist
2. org-export-latex-packages-alist
3. org-export-latex-classes

Sorry for being so dense, but I am really trying to understand.

Thanks,


-- 
Henri-Paul Indiogine
Email: hindiogine@gmail.com
Skype: hindiogine
Website: http://www.coe.tamu.edu/~enrico

Re: Re: IMPORTANT: (possibly) incompatible Change

[Mark Elston]

Henri,

On 4/4/2010 10:36 AM, Henri-Paul Indiogine wrote:
> Carsten Dominik<carsten.dominik@gmail.com>  writes:
>>
>> OK, you can now specify the position where the usepackage definitions
>> should appear in your header by putting the string
>>
>>     [PACKAGES]
>>
>> into the header definition in org-export-latex-classes.  Default (if
>> you do
>> not include this placeholder) is at the end.
>
> Sorry, but I am totally confused now.  I want my packages defined in
> org-export-latex-classes at the end of the LaTeX file preamble.  So,
> according to your instructions, if I understand them correctly, I
> should not use this [PACKAGES] string.  But, when I generate the tex
> file the packages from org-export-latex-classes are at the top of my
> preamble not at the end.
>
> Basically, I would like to have the packages in the following order:
>
> 1. org-export-latex-default-packages-alist
> 2. org-export-latex-packages-alist
> 3. org-export-latex-classes
>
> Sorry for being so dense, but I am really trying to understand.
>

I didn't see Carsten's notice on this but I think what he is getting at
is that the [PACKAGES] directive will put the items from
org-export-latex-default-packages-alist and
org-export-latex-packages-alist in the output *in place of* the
[PACKAGES] string.  All the things in your org-export-latex-classes
will appear as you have them.

So, say your class looks like this:

"\\documentclass[letter,twoside,openright]{memoir}
\\usepackage{varioref}
\\usepackage{shorttoc}
\\usepackage{color}
...

[PACKAGES]"

What I expect to see is all the stuff from
org-export-latex-default-packages-alist and
org-export-latex-packages-alist at the end of your preamble.

If, OTOH, you put the [PACKAGES] before any of your other usepackage
commands, then you would get the stuff from
org-export-latex-default-packages-alist and
org-export-latex-packages-alist just after the documentclass line.

Does that sound right?

Mark

Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 3, 2010, at 7:19 PM, Xiao-Yong Jin wrote:

> On Sat, 3 Apr 2010 18:55:46 +0200, Carsten Dominik wrote:
>
>> It needs to be:
>
>> (setq org-export-latex-packages-alist
>>     '(("" "apacite")
>> 	("" "color")
>> 	("" "tikz")))
>
> Then it is not an alist.


It sure is, read the Emacs lisp documentation on alists.

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

Hi,

Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Apr 4, 2010, at 12:50 AM, Henri-Paul Indiogine wrote:
>> When I export to LaTeX the line \definecolor..... comes before
>> \usepackage{color}  then it throws an error during compilation.  If I
>> move the \definecolor... _after_ \usepackage{color} it compiles.
>>
>> Is are a way to setup my LaTeX export so that this happens
>> automagically?
>
> No, I think you need to return to the old way of configuring
> everything in org-export-latex-classes.

Suggestion: Would it be hard to add a location marker for the place the
default packages are included? Something like

(setq org-export-latex-classes
   '(("book"
    "\\documentclass[11pt]{book}
    (include-org-standard-packages-here)
     \\definecolor{darkblue}{rgb}{0.0,0.0,0.3}
     \\hypersetup{colorlinks,breaklinks,

If (include-org-standard-packages-here) is missing, the \usepackage
lines are appended to the template. This way one could use the standard
packages and at the same time use commands from the packages in the
preamble.

Yours
Karsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

Hi Carsten,

a small note:

Carsten Dominik <carsten.dominik@gmail.com> writes:
[...]
> If you have customized the variable org-export-latex-classes, you need
> to remove the following lines from each class definition:
>
> \usepackage[AUTO]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{longtable}
> \usepackage{float}
> \usepackage{wrapfig}
> \usepackage{soul}
> \usepackage{latexsym}
> \usepackage{amssymb}
> \usepackage{hyperref}

The following packages should also be safe to add, as they are part of
the standard latex distribution:

textcomp (better Text symbols, for example list bullets not made of math
    chars, are used automatically if package is loaded)
fixltx2e (numerous small slightly backwards incompatible changes, see
    http://ctan.org/tex-archive/help/Catalogue/entries/fixltx2e.html)

Also, I'd recommend \usepackage{microtype} and a gentle increase of the
\tolerance value (less perfectionist text justification) for a much
nicer out-of-the-box experience:

\usepackage{microtype}
\tolerance=1000

Yours
Karsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 6, 2010, at 1:57 PM, Karsten Heymann wrote:

> Hi,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>> On Apr 4, 2010, at 12:50 AM, Henri-Paul Indiogine wrote:
>>> When I export to LaTeX the line \definecolor..... comes before
>>> \usepackage{color}  then it throws an error during compilation.   
>>> If I
>>> move the \definecolor... _after_ \usepackage{color} it compiles.
>>>
>>> Is are a way to setup my LaTeX export so that this happens
>>> automagically?
>>
>> No, I think you need to return to the old way of configuring
>> everything in org-export-latex-classes.
>
> Suggestion: Would it be hard to add a location marker for the place  
> the
> default packages are included? Something like
>
> (setq org-export-latex-classes
>   '(("book"
>    "\\documentclass[11pt]{book}
>    (include-org-standard-packages-here)
>     \\definecolor{darkblue}{rgb}{0.0,0.0,0.3}
>     \\hypersetup{colorlinks,breaklinks,
>
> If (include-org-standard-packages-here) is missing, the \usepackage
> lines are appended to the template. This way one could use the  
> standard
> packages and at the same time use commands from the packages in the
> preamble.

Great idea, so I am proud that I came up with it already.  This is  
just like it works in 6.35, only with different place holders.

- Carsten

>
> Yours
> Karsten
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

Hi Karsten,

On Apr 6, 2010, at 2:30 PM, Karsten Heymann wrote:

> Hi Carsten,
>
> a small note:
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> [...]
>> If you have customized the variable org-export-latex-classes, you  
>> need
>> to remove the following lines from each class definition:
>>
>> \usepackage[AUTO]{inputenc}
>> \usepackage[T1]{fontenc}
>> \usepackage{graphicx}
>> \usepackage{longtable}
>> \usepackage{float}
>> \usepackage{wrapfig}
>> \usepackage{soul}
>> \usepackage{latexsym}
>> \usepackage{amssymb}
>> \usepackage{hyperref}

Do you have any recommendations for the sequence in which these
packages should be called?  Or does that make no difference at all?
Does any of these cause problems if they are called twice (say I
add them, but users have them configured already?)

>
> The following packages should also be safe to add, as they are part of
> the standard latex distribution:
>
> textcomp (better Text symbols, for example list bullets not made of  
> math
>   chars, are used automatically if package is loaded)
> fixltx2e (numerous small slightly backwards incompatible changes, see
>   http://ctan.org/tex-archive/help/Catalogue/entries/fixltx2e.html)
>
> Also, I'd recommend \usepackage{microtype} and a gentle increase of  
> the
> \tolerance value (less perfectionist text justification) for a much
> nicer out-of-the-box experience:

What is is really changing due to these last two
settings (microtype) and tolerance, could you explain in a bit more  
detail?

And: Can I expect fixltx2e to be present in all distributions?

Is \tolerance defined in microtype, or did you put these together just
incidentally?

>
> \usepackage{microtype}
> \tolerance=1000
>
> Yours
> Karsten

I really appreciate expert advice about this.  Thank you.

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

Hi Carsten,

Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Apr 6, 2010, at 2:30 PM, Karsten Heymann wrote:
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>> \usepackage[AUTO]{inputenc}
>>> \usepackage[T1]{fontenc}
>>> \usepackage{graphicx}
>>> \usepackage{longtable}
>>> \usepackage{float}
>>> \usepackage{wrapfig}
>>> \usepackage{soul}
>>> \usepackage{latexsym}
>>> \usepackage{amssymb}
>>> \usepackage{hyperref}
>
> Do you have any recommendations for the sequence in which these
> packages should be called?  Or does that make no difference at all?
> Does any of these cause problems if they are called twice (say I
> add them, but users have them configured already?)

The only critical one is hyperref, which should always be loaded last
(see
http://tug.ctan.org/tex-archive/macros/latex/contrib/hyperref/doc/manual.html#x1-30002).

> What is is really changing due to these last two
> settings (microtype) and tolerance, could you explain in a bit more
> detail?

I will try to explain it in my own poor words. microtype activates
advanced functions of the pdftex compiler (nowadays the standard TeX
compiler used by all distributions) to perform various subtle output
modifications, like shifting letters a tiny bit into the right margin so
that the margin looks *visually* aligned. Also it stretches and pulls
letters for tiny amounts so words fit better into paragraphs without
standing into the margin.

This is also the area where \tolerance takes action. It's a low level
TeX directive that controls how much the whitespace between words may
differ in width when typesetting a justified paragraph (I'm not sure
what the correct translation of the German word "Blocksatz" is). It's a
number in the range between 0 and 9999 (plus the special 10.000 meaning
infinite for TeX ;-) ). The standard value 200 is way much too
perfectionist for normal day-to-day typesetting, especially when writing
in languages where typical words are much longer then in English, like
German for example. Normal Desktop Text processors always operate in
"10.000"-Mode, meaning there's an infinite amount of whitespace allowed
between words, with the result of possibly large holes between the words
to keep the right margin aligned. TeX on the other hand will deny to
typeset paragraphs when it cannot find a solution (for the full
paragraph!) inside it's tolerance limits and write words into the right
margin so the author can manually fix the situation (rephrase, fix
hyphenation, ...). Tolerance values up to 2000 still look much better
than anything from Word/OOo and reduce the need to manually correct
these problems (and to explain this stuff to new users).

> And: Can I expect fixltx2e to be present in all distributions?

Yes, it's part of the latex base packages and thus always available
(given any not really really ancient LaTeX installation, e.g. more than
a decade).

> Is \tolerance defined in microtype, or did you put these together just
> incidentally?

They are completely independent.

>> Karsten
>
> I really appreciate expert advice about this.  Thank you.

I'm more than glad my rusty LaTeX knowledge is of any use, especially to
the awesome org-mode community (and it's even more awesome author). If
you want advice from some *real* experts, ask in the comp.text.tex or
the de.comp.text.tex newsgroup. That's a completely different level, I'm
just some kind of semi-power-user that had too much time on university.

Yours
Karsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 6, 2010, at 6:03 PM, Karsten Heymann wrote:

> Hi Carsten,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>> On Apr 6, 2010, at 2:30 PM, Karsten Heymann wrote:
>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>> \usepackage[AUTO]{inputenc}
>>>> \usepackage[T1]{fontenc}
>>>> \usepackage{graphicx}
>>>> \usepackage{longtable}
>>>> \usepackage{float}
>>>> \usepackage{wrapfig}
>>>> \usepackage{soul}
>>>> \usepackage{latexsym}
>>>> \usepackage{amssymb}
>>>> \usepackage{hyperref}
>>
>> Do you have any recommendations for the sequence in which these
>> packages should be called?  Or does that make no difference at all?
>> Does any of these cause problems if they are called twice (say I
>> add them, but users have them configured already?)
>
> The only critical one is hyperref, which should always be loaded last
> (see
> http://tug.ctan.org/tex-archive/macros/latex/contrib/hyperref/doc/manual.html#x1-30002) 
> .
>
>> What is is really changing due to these last two
>> settings (microtype) and tolerance, could you explain in a bit more
>> detail?
>
> I will try to explain it in my own poor words. microtype activates
> advanced functions of the pdftex compiler (nowadays the standard TeX
> compiler used by all distributions) to perform various subtle output
> modifications, like shifting letters a tiny bit into the right  
> margin so
> that the margin looks *visually* aligned. Also it stretches and pulls
> letters for tiny amounts so words fit better into paragraphs without
> standing into the margin.
>
> This is also the area where \tolerance takes action. It's a low level
> TeX directive that controls how much the whitespace between words may
> differ in width when typesetting a justified paragraph (I'm not sure
> what the correct translation of the German word "Blocksatz" is).  
> It's a
> number in the range between 0 and 9999 (plus the special 10.000  
> meaning
> infinite for TeX ;-) ). The standard value 200 is way much too
> perfectionist for normal day-to-day typesetting, especially when  
> writing
> in languages where typical words are much longer then in English, like
> German for example. Normal Desktop Text processors always operate in
> "10.000"-Mode, meaning there's an infinite amount of whitespace  
> allowed
> between words, with the result of possibly large holes between the  
> words
> to keep the right margin aligned. TeX on the other hand will deny to
> typeset paragraphs when it cannot find a solution (for the full
> paragraph!) inside it's tolerance limits and write words into the  
> right
> margin so the author can manually fix the situation (rephrase, fix
> hyphenation, ...). Tolerance values up to 2000 still look much better
> than anything from Word/OOo and reduce the need to manually correct
> these problems (and to explain this stuff to new users).
>
>> And: Can I expect fixltx2e to be present in all distributions?
>
> Yes, it's part of the latex base packages and thus always available
> (given any not really really ancient LaTeX installation, e.g. more  
> than
> a decade).
>
>> Is \tolerance defined in microtype, or did you put these together  
>> just
>> incidentally?
>
> They are completely independent.

Thanks a lot for all this, I will follow your advice.

One final question:  Will any of these packages spoil the fun
for people who want to process through .dvi instead of directly to pdf?

>
>>> Karsten
>>
>> I really appreciate expert advice about this.  Thank you.
>
> I'm more than glad my rusty LaTeX knowledge is of any use,  
> especially to
> the awesome org-mode community (and it's even more awesome author). If
> you want advice from some *real* experts, ask in the comp.text.tex or
> the de.comp.text.tex newsgroup. That's a completely different level,  
> I'm
> just some kind of semi-power-user that had too much time on  
> university.

That is way more than I know about LaTeX/TeX internals, so fully
appropriate here.  Yes, comp.text.tex and de.comp.text.tex, I used
to hang out there more while writing reftex.el and cdlatex.el, but
always more as a reader than as a contributor.  I loved to read these
groups, that was always a high intensity place to be at.

Thanks again.

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Apr 6, 2010, at 6:03 PM, Karsten Heymann wrote:
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>> On Apr 6, 2010, at 2:30 PM, Karsten Heymann wrote:
>>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>>> \usepackage[AUTO]{inputenc}
>>>>> \usepackage[T1]{fontenc}
>>>>> \usepackage{graphicx}
>>>>> \usepackage{longtable}
>>>>> \usepackage{float}
>>>>> \usepackage{wrapfig}
>>>>> \usepackage{soul}
>>>>> \usepackage{latexsym}
>>>>> \usepackage{amssymb}
>>>>> \usepackage{hyperref}

[...]

>>> What is is really changing due to these last two
>>> settings (microtype) and tolerance, could you explain in a bit more
>>> detail?

[...]

> Thanks a lot for all this, I will follow your advice.
>
> One final question: Will any of these packages spoil the fun for
> people who want to process through .dvi instead of directly to pdf?

Not as far as I know. hyperref and microtype will run with reduced
features, but apart from that, there should be no problem. Regarding
microtype, I do not know what happens when it is used with the old TeX
or eTeX compiler that was used to created dvi's before pdftex was used
for this too, but that should largely be an academic problem as pdftex
is now used anywhere.

Yours
Karsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Robert Klein]

On Tue, 06 Apr 2010 18:50:36 +0200, Karsten Heymann  
<karsten.heymann@blue-cable.net> wrote:

>> Thanks a lot for all this, I will follow your advice.
>>
>> One final question: Will any of these packages spoil the fun for
>> people who want to process through .dvi instead of directly to pdf?
>
> Not as far as I know. hyperref and microtype will run with reduced
> features, but apart from that, there should be no problem. Regarding
> microtype, I do not know what happens when it is used with the old TeX
> or eTeX compiler that was used to created dvi's before pdftex was used
> for this too, but that should largely be an academic problem as pdftex
> is now used anywhere.
>


In a minimal document it runs Ok with pdfeTeX, for both creating dvi and  
pdf.
(The one in teTeX 3.0.)


Best regards
Robert

Re: Re: IMPORTANT: (possibly) incompatible Change

[Thomas S. Dye]

[-- Attachment #1.1: Type: text/plain, Size: 1024 bytes --]

On Apr 6, 2010, at 8:30 AM, Robert Klein wrote:

> On Tue, 06 Apr 2010 18:50:36 +0200, Karsten Heymann <karsten.heymann@blue-cable.net 
> > wrote:
>
>>> Thanks a lot for all this, I will follow your advice.
>>>
>>> One final question: Will any of these packages spoil the fun for
>>> people who want to process through .dvi instead of directly to pdf?
>>
>> Not as far as I know. hyperref and microtype will run with reduced
>> features, but apart from that, there should be no problem. Regarding
>> microtype, I do not know what happens when it is used with the old  
>> TeX
>> or eTeX compiler that was used to created dvi's before pdftex was  
>> used
>> for this too, but that should largely be an academic problem as  
>> pdftex
>> is now used anywhere.
>>
>
>
> In a minimal document it runs Ok with pdfeTeX, for both creating dvi  
> and pdf.
> (The one in teTeX 3.0.)
>
>
> Best regards
> Robert
>

Aloha all,

 From the microtype documentation:

>  The microtype package does not work with XETEX.

All the best,
Tom

[-- Attachment #1.2: Type: text/html, Size: 2295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 6, 2010, at 8:48 PM, Thomas S. Dye wrote:

> On Apr 6, 2010, at 8:30 AM, Robert Klein wrote:
>
>> On Tue, 06 Apr 2010 18:50:36 +0200, Karsten Heymann <karsten.heymann@blue-cable.net 
>> > wrote:
>>
>>>> Thanks a lot for all this, I will follow your advice.
>>>>
>>>> One final question: Will any of these packages spoil the fun for
>>>> people who want to process through .dvi instead of directly to pdf?
>>>
>>> Not as far as I know. hyperref and microtype will run with reduced
>>> features, but apart from that, there should be no problem. Regarding
>>> microtype, I do not know what happens when it is used with the old  
>>> TeX
>>> or eTeX compiler that was used to created dvi's before pdftex was  
>>> used
>>> for this too, but that should largely be an academic problem as  
>>> pdftex
>>> is now used anywhere.
>>>
>>
>>
>> In a minimal document it runs Ok with pdfeTeX, for both creating  
>> dvi and pdf.
>> (The one in teTeX 3.0.)
>>
>>
>> Best regards
>> Robert
>>
>
> Aloha all,
>
> From the microtype documentation:
>
>>  The microtype package does not work with XETEX.

Does that mean it will break running XETEX, or will i just be ignored?

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 6, 2010, at 8:30 PM, Robert Klein wrote:

> On Tue, 06 Apr 2010 18:50:36 +0200, Karsten Heymann <karsten.heymann@blue-cable.net 
> > wrote:
>
>>> Thanks a lot for all this, I will follow your advice.
>>>
>>> One final question: Will any of these packages spoil the fun for
>>> people who want to process through .dvi instead of directly to pdf?
>>
>> Not as far as I know. hyperref and microtype will run with reduced
>> features, but apart from that, there should be no problem. Regarding
>> microtype, I do not know what happens when it is used with the old  
>> TeX
>> or eTeX compiler that was used to created dvi's before pdftex was  
>> used
>> for this too, but that should largely be an academic problem as  
>> pdftex
>> is now used anywhere.
>>
>
>
> In a minimal document it runs Ok with pdfeTeX, for both creating dvi  
> and pdf.
> (The one in teTeX 3.0.)


Thanks for checking this out.

- Carsten
>
>
> Best regards
> Robert
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

"Thomas S. Dye" <tsd@tsdye.com> writes:
> From the microtype documentation:
>
>>  The microtype package does not work with XETEX.

That's true, but supporting xetex requires many other changes too, for
example only utf-8 input encoding is supported, the inputenc, fontspec
and font packages may not be used, special xetex packages should be
loaded and so on. Supporting XeTeX requires additional work anyway.

Yours
Karsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Apr 6, 2010, at 8:48 PM, Thomas S. Dye wrote:
>> From the microtype documentation:
>>
>>>  The microtype package does not work with XETEX.
>
> Does that mean it will break running XETEX, or will i just be ignored?

It only gives a (harmless) warning:

Package microtype Warning: You don't seem to be using pdftex.
(microtype)                All micro-typographic features will be disabled.

But chances are high that most "normal" LaTeX documents will not work
with xelatex anyways due to encoding or font selection issues, so I
think unless org-mode aims at explicitely supporting XeTeX out of the
box this whole topic can (and should) be ignored.

Btw. current microtype does not support current luatex as well AFAIK,
but that can be ignored too.

Yours
Karsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 7, 2010, at 10:22 AM, Karsten Heymann wrote:

>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>> On Apr 6, 2010, at 8:48 PM, Thomas S. Dye wrote:
>>> From the microtype documentation:
>>>
>>>> The microtype package does not work with XETEX.
>>
>> Does that mean it will break running XETEX, or will i just be  
>> ignored?
>
> It only gives a (harmless) warning:
>
> Package microtype Warning: You don't seem to be using pdftex.
> (microtype)                All micro-typographic features will be  
> disabled.
>
> But chances are high that most "normal" LaTeX documents will not work
> with xelatex anyways due to encoding or font selection issues, so I
> think unless org-mode aims at explicitely supporting XeTeX out of the
> box this whole topic can (and should) be ignored.
>
> Btw. current microtype does not support current luatex as well AFAIK,
> but that can be ignored too.

So to summarize:

- I should include the microtype package
- People using XeTeX need to tweak their setup anyway and can be  
expected
   to know about all issues related to it.

Thanks!

- Carsten

Re: IMPORTANT: (possibly) incompatible Change

[Ulf Stegemann]

Karsten Heymann <karsten.heymann@blue-cable.net> wrote:

> Not as far as I know. hyperref and microtype will run with reduced
> features, but apart from that, there should be no problem. Regarding
> microtype, I do not know what happens when it is used with the old TeX
> or eTeX compiler that was used to created dvi's before pdftex was used
> for this too, but that should largely be an academic problem as pdftex
> is now used anywhere.

No problems here, regarding the inclusion of microtype when using latex
compiler.

However, I'd strongly oppose to the claim that compatibility to the
latex compiler (vs. pdftex) is an academic problem. I know about several
LaTeX based systems that have to use the latex compiler simply because
pdftex can't handle eps graphics and converting those images isn't
feasible. So, while in the current case there's no compatibility issue,
I think it's reasonable to support both compilers.

Ulf

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

Hi Ulf,

Ulf Stegemann <ulf-news@zeitform.de> writes:
> However, I'd strongly oppose to the claim that compatibility to the
> latex compiler (vs. pdftex) is an academic problem. I know about
> several LaTeX based systems that have to use the latex compiler simply
> because pdftex can't handle eps graphics and converting those images
> isn't feasible. So, while in the current case there's no compatibility
> issue, I think it's reasonable to support both compilers.

Are there still any systems in the wild that don't use pdftex for
latex/dvi mode? Don't be fooled by the name, when pdftex is called in
latex mode, it behaves exactly like the old tex/etex compiler and
generates the same dvi documents, supports dvips and so on. For example
on my Ubuntu 9.10 system 'latex -version' says:

kheymann@ara:~$ latex -version
pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6)
kpathsea version 3.5.6
Copyright 2007 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
Kpathsea is copyright 2007 Karl Berry and Olaf Weber.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX using libpoppler copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX using libpoppler source.
Primary author of pdfTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
Kpathsea written by Karl Berry, Olaf Weber, and others.

Compiled with libpng 1.2.37; using libpng 1.2.37
Compiled with zlib 1.2.3.3; using zlib 1.2.3.3
Compiled with libpoppler version 0.12.0


Or did I misunderstand your remark?

Yours
Karsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

Hi Carsten,

Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Apr 7, 2010, at 10:22 AM, Karsten Heymann wrote:
>> But chances are high that most "normal" LaTeX documents will not work
>> with xelatex anyways due to encoding or font selection issues, so I
>> think unless org-mode aims at explicitely supporting XeTeX out of the
>> box this whole topic can (and should) be ignored.

> So to summarize:
>
> - I should include the microtype package
> - People using XeTeX need to tweak their setup anyway and can be
>   expected to know about all issues related to it.

Yes.

Yours
Karsten

Re: IMPORTANT: (possibly) incompatible Change

[Ulf Stegemann]

Hi Karsten,

Karsten Heymann <karsten.heymann@blue-cable.net> wrote:

> Hi Ulf,
>
> Ulf Stegemann <ulf-news@zeitform.de> writes:
>> However, I'd strongly oppose to the claim that compatibility to the
>> latex compiler (vs. pdftex) is an academic problem. I know about
>> several LaTeX based systems that have to use the latex compiler simply
>> because pdftex can't handle eps graphics and converting those images
>> isn't feasible. So, while in the current case there's no compatibility
>> issue, I think it's reasonable to support both compilers.
>
> Are there still any systems in the wild that don't use pdftex for
> latex/dvi mode? Don't be fooled by the name, when pdftex is called in
> latex mode, it behaves exactly like the old tex/etex compiler and
> generates the same dvi documents, supports dvips and so on. For example
> on my Ubuntu 9.10 system 'latex -version' says:
>
> kheymann@ara:~$ latex -version
> pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6)
> kpathsea version 3.5.6
> Copyright 2007 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
> Kpathsea is copyright 2007 Karl Berry and Olaf Weber.
> There is NO warranty.  Redistribution of this software is
> covered by the terms of both the pdfTeX using libpoppler copyright and
> the Lesser GNU General Public License.
> For more information about these matters, see the file
> named COPYING and the pdfTeX using libpoppler source.
> Primary author of pdfTeX using libpoppler: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
> Kpathsea written by Karl Berry, Olaf Weber, and others.
>
> Compiled with libpng 1.2.37; using libpng 1.2.37
> Compiled with zlib 1.2.3.3; using zlib 1.2.3.3
> Compiled with libpoppler version 0.12.0
>
> Or did I misunderstand your remark?

no, we probably just misunderstood each other. I had the impression that
the compatibility question was raised because difficulties would
possibly arise when using latex -> dvi, no matter which actual version
is used. You are right, nowadays nearly everyone uses pdflatex for both
latex -> dvi and latex -> pdf. Nevertheless, the very same program
behaves differently depending on the mode. But if that wasn't your
point, just forget about my remark.

Ulf

Re: Re: IMPORTANT: (possibly) incompatible Change

[Karsten Heymann]

Hi,

Ulf Stegemann <ulf-news@zeitform.de> writes:
> But if that wasn't your point, just forget about my remark.

Done :-)

Yours
Karsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Thomas S. Dye]

On Apr 7, 2010, at 12:31 AM, Karsten Heymann wrote:

> Hi Carsten,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>> On Apr 7, 2010, at 10:22 AM, Karsten Heymann wrote:
>>> But chances are high that most "normal" LaTeX documents will not  
>>> work
>>> with xelatex anyways due to encoding or font selection issues, so I
>>> think unless org-mode aims at explicitely supporting XeTeX out of  
>>> the
>>> box this whole topic can (and should) be ignored.
>
>> So to summarize:
>>
>> - I should include the microtype package
>> - People using XeTeX need to tweak their setup anyway and can be
>>  expected to know about all issues related to it.
>
> Yes.
>
> Yours
> Karsten
>

Aloha all,

Forewarned is forearmed: perhaps it would be useful to add a footnote  
to the org manual at 12.6 after "With further processing,[fn:X]"

[fn:X] The default LaTeX output is designed for processing with pdftex  
or latex.  It includes packages that are not compatible with xetex and  
possibly luatex.  See the variables =org-export-latex-default-packages- 
alist= and =org-export-latex-packages-alist=.

All the best,
Tom

Re: Re: IMPORTANT: (possibly) incompatible Change

[Carsten Dominik]

On Apr 7, 2010, at 5:51 PM, Thomas S. Dye wrote:

>
> On Apr 7, 2010, at 12:31 AM, Karsten Heymann wrote:
>
>> Hi Carsten,
>>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>> On Apr 7, 2010, at 10:22 AM, Karsten Heymann wrote:
>>>> But chances are high that most "normal" LaTeX documents will not  
>>>> work
>>>> with xelatex anyways due to encoding or font selection issues, so I
>>>> think unless org-mode aims at explicitely supporting XeTeX out of  
>>>> the
>>>> box this whole topic can (and should) be ignored.
>>
>>> So to summarize:
>>>
>>> - I should include the microtype package
>>> - People using XeTeX need to tweak their setup anyway and can be
>>> expected to know about all issues related to it.
>>
>> Yes.
>>
>> Yours
>> Karsten
>>
>
> Aloha all,
>
> Forewarned is forearmed: perhaps it would be useful to add a  
> footnote to the org manual at 12.6 after "With further processing, 
> [fn:X]"
>
> [fn:X] The default LaTeX output is designed for processing with  
> pdftex or latex.  It includes packages that are not compatible with  
> xetex and possibly luatex.  See the variables =org-export-latex- 
> default-packages-alist= and =org-export-latex-packages-alist=.

OK, done.

- Carsten

Re: Re: IMPORTANT: (possibly) incompatible Change

[Mark Elston]

On 4/7/2010 1:22 AM, Karsten Heymann wrote:
>
> Carsten Dominik<carsten.dominik@gmail.com>  writes:
>> On Apr 6, 2010, at 8:48 PM, Thomas S. Dye wrote:
>>>  From the microtype documentation:
>>>
>>>>   The microtype package does not work with XETEX.
>>
>> Does that mean it will break running XETEX, or will i just be ignored?
>
> It only gives a (harmless) warning:
>
> Package microtype Warning: You don't seem to be using pdftex.
> (microtype)                All micro-typographic features will be disabled.
>
> But chances are high that most "normal" LaTeX documents will not work
> with xelatex anyways due to encoding or font selection issues, so I
> think unless org-mode aims at explicitely supporting XeTeX out of the
> box this whole topic can (and should) be ignored.

I am having problems with microtype, here.  I don't know if it is
happening in all my docs or just the ones I am working with now but
pdf generation fails with the following in the log:

------------------------------------------------------------------
...
(Handouts07.out) (Handouts07.out)
("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\wasysym\uwasy.fd")
("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\base\ulasy.fd")
("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\amsfonts\umsa.fd")
("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\microtype\mt-msa.cfg")
("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\amsfonts\umsb.fd")
("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\microtype\mt-msb.cfg") 
[1{C:/Prog
ramData/MiKTeX/2.7/pdftex/config/pdftex.map}
! pdfTeX error (font expansion): auto expansion is only possible with 
scalable
fonts.
\AtBegShi@Output ...ipout \box \AtBeginShipoutBox
                                                   \fi \fi
l.111     S
            harezer = Babylonian name, sharusur, ``protect the king.''
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on Handouts07.log.
------------------------------------------------------------------

If I comment out the \usepackage{microtype} line then everything works
fine.  I am a casual user of latex so I don't really know what the
comment above about scalable fonts is getting at.  Perhaps I can set
my docs up to do something different in terms of fonts to make this
just work.

Any ideas?

Mark

Re: Re: IMPORTANT: (possibly) incompatible Change

[Thomas S. Dye]

On Apr 10, 2010, at 7:30 AM, Mark Elston wrote:

> On 4/7/2010 1:22 AM, Karsten Heymann wrote:
>>
>> Carsten Dominik<carsten.dominik@gmail.com>  writes:
>>> On Apr 6, 2010, at 8:48 PM, Thomas S. Dye wrote:
>>>> From the microtype documentation:
>>>>
>>>>>  The microtype package does not work with XETEX.
>>>
>>> Does that mean it will break running XETEX, or will i just be  
>>> ignored?
>>
>> It only gives a (harmless) warning:
>>
>> Package microtype Warning: You don't seem to be using pdftex.
>> (microtype)                All micro-typographic features will be  
>> disabled.
>>
>> But chances are high that most "normal" LaTeX documents will not work
>> with xelatex anyways due to encoding or font selection issues, so I
>> think unless org-mode aims at explicitely supporting XeTeX out of the
>> box this whole topic can (and should) be ignored.
>
> I am having problems with microtype, here.  I don't know if it is
> happening in all my docs or just the ones I am working with now but
> pdf generation fails with the following in the log:
>
> ------------------------------------------------------------------
> ...
> (Handouts07.out) (Handouts07.out)
> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\wasysym\uwasy.fd")
> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\base\ulasy.fd")
> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\amsfonts\umsa.fd")
> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\microtype\mt-msa.cfg")
> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\amsfonts\umsb.fd")
> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\microtype\mt-msb.cfg")  
> [1{C:/Prog
> ramData/MiKTeX/2.7/pdftex/config/pdftex.map}
> ! pdfTeX error (font expansion): auto expansion is only possible  
> with scalable
> fonts.
> \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>                                                  \fi \fi
> l.111     S
>           harezer = Babylonian name, sharusur, ``protect the king.''
> !  ==> Fatal error occurred, no output PDF file produced!
> Transcript written on Handouts07.log.
> ------------------------------------------------------------------
>
> If I comment out the \usepackage{microtype} line then everything works
> fine.  I am a casual user of latex so I don't really know what the
> comment above about scalable fonts is getting at.  Perhaps I can set
> my docs up to do something different in terms of fonts to make this
> just work.
>
> Any ideas?
>
> Mark
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Hi Mark,

Removing microtype is probably the easiest solution.  It performs some  
sophisticated micro-typographic adjustments that are typically found  
in published material.  The LaTeX world got on fine without them for  
years and the casual LaTeX user can still do so.  AFAIK, it is not  
necessary for the Org-mode LaTeX exporter.

All the best,
Tom

Re: Re: IMPORTANT: (possibly) incompatible Change

[Mark Elston]

On 4/10/2010 1:01 PM, Thomas S. Dye wrote:
>
> On Apr 10, 2010, at 7:30 AM, Mark Elston wrote:
>
>>
>> I am having problems with microtype, here. I don't know if it is
>> happening in all my docs or just the ones I am working with now but
>> pdf generation fails with the following in the log:
>>
>> ------------------------------------------------------------------
>> ...
>> (Handouts07.out) (Handouts07.out)
>> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\wasysym\uwasy.fd")
>> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\base\ulasy.fd")
>> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\amsfonts\umsa.fd")
>> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\microtype\mt-msa.cfg")
>> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\amsfonts\umsb.fd")
>> ("C:\Program Files (x86)\MiKTeX 2.7\tex\latex\microtype\mt-msb.cfg")
>> [1{C:/Prog
>> ramData/MiKTeX/2.7/pdftex/config/pdftex.map}
>> ! pdfTeX error (font expansion): auto expansion is only possible with
>> scalable
>> fonts.
>> \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>> \fi \fi
>> l.111 S
>> harezer = Babylonian name, sharusur, ``protect the king.''
>> ! ==> Fatal error occurred, no output PDF file produced!
>> Transcript written on Handouts07.log.
>> ------------------------------------------------------------------
>>
>> If I comment out the \usepackage{microtype} line then everything works
>> fine. I am a casual user of latex so I don't really know what the
>> comment above about scalable fonts is getting at. Perhaps I can set
>> my docs up to do something different in terms of fonts to make this
>> just work.
>>
>> Any ideas?
>>
>> Mark
>
> Hi Mark,
>
> Removing microtype is probably the easiest solution. It performs some
> sophisticated micro-typographic adjustments that are typically found in
> published material. The LaTeX world got on fine without them for years
> and the casual LaTeX user can still do so. AFAIK, it is not necessary
> for the Org-mode LaTeX exporter.
>
> All the best,
> Tom
>

Tom,

I did just that and haven't seen any noticeable degradation in quality.
Thanks.

Mark