bug in latex export tutorial?

bug in latex export tutorial?

[Robert Goldman]

The document http://orgmode.org/worg/org-tutorials/org-latex-export.html
claims

"The Org-mode LaTeX exporter uses several packages to support special
characters used by org-entities. One of these, amsmath, conflicts with
several LaTeX fonts. If you want finer control over which packages are
loaded, then it makes sense to define an export class like this in .emacs:"

But I just checked the results of exporting one of my org files, and it
does /not/ use amsmath.

Is this a bug in the tutorial?

Re: bug in latex export tutorial?

[Thomas S. Dye]

Aloha Robert,

Yep.  It should be "One of these, amssymb, requires amsmath, which  
conflicts with several LaTeX fonts."

Thanks for pointing this out.

All the best,
Tom

On Apr 29, 2011, at 6:26 AM, Robert Goldman wrote:

> The document http://orgmode.org/worg/org-tutorials/org-latex-export.html
> claims
>
> "The Org-mode LaTeX exporter uses several packages to support special
> characters used by org-entities. One of these, amsmath, conflicts with
> several LaTeX fonts. If you want finer control over which packages are
> loaded, then it makes sense to define an export class like this  
> in .emacs:"
>
> But I just checked the results of exporting one of my org files, and  
> it
> does /not/ use amsmath.
>
> Is this a bug in the tutorial?
>
>

Re: bug in latex export tutorial?

[Robert Goldman]

On 4/29/11 Apr 29 -11:44 AM, Thomas S. Dye wrote:
> Aloha Robert,
> 
> Yep.  It should be "One of these, amssymb, requires amsmath, which
> conflicts with several LaTeX fonts."

I don't /believe/ amssymb requires amsmath.  I have been working on a
document where I wanted to use some of the stuff in amsmath (e.g.,
\text, align environment).  That document did /not/ parse, even though
amssymb *is* in the preamble of the exported file.  I looked, and the
preamble has amssymb, but not amsmath.

It would be *great* if someone could provide tutorial information that
would tell us:

1.  How do we configure a file so that it *can* use amsmath?
2.  What happens to the parallel HTML export if we use amsmath
constructs in an org file?

thanks!
r

> 
> Thanks for pointing this out.
> 
> All the best,
> Tom
> 
> On Apr 29, 2011, at 6:26 AM, Robert Goldman wrote:
> 
>> The document http://orgmode.org/worg/org-tutorials/org-latex-export.html
>> claims
>>
>> "The Org-mode LaTeX exporter uses several packages to support special
>> characters used by org-entities. One of these, amsmath, conflicts with
>> several LaTeX fonts. If you want finer control over which packages are
>> loaded, then it makes sense to define an export class like this in
>> .emacs:"
>>
>> But I just checked the results of exporting one of my org files, and it
>> does /not/ use amsmath.
>>
>> Is this a bug in the tutorial?
>>
>>
> 

Re: bug in latex export tutorial?

[Thomas S. Dye]

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

Aloha Robert,

You're right again.  Sorry for the noise.  The amssymb package is the  
source of the font conflicts.

Thanks for pointing this out.

I don't use amsmath, so can't help with your queries.  When you've  
sorted them out, please consider adding the solution to the LaTeX  
export tutorial.

All the best,
Tom

On Apr 29, 2011, at 6:51 AM, Robert Goldman wrote:

> On 4/29/11 Apr 29 -11:44 AM, Thomas S. Dye wrote:
>> Aloha Robert,
>>
>> Yep.  It should be "One of these, amssymb, requires amsmath, which
>> conflicts with several LaTeX fonts."
>
> I don't /believe/ amssymb requires amsmath.  I have been working on a
> document where I wanted to use some of the stuff in amsmath (e.g.,
> \text, align environment).  That document did /not/ parse, even though
> amssymb *is* in the preamble of the exported file.  I looked, and the
> preamble has amssymb, but not amsmath.
>
> It would be *great* if someone could provide tutorial information that
> would tell us:
>
> 1.  How do we configure a file so that it *can* use amsmath?
> 2.  What happens to the parallel HTML export if we use amsmath
> constructs in an org file?
>
> thanks!
> r
>
>>
>> Thanks for pointing this out.
>>
>> All the best,
>> Tom
>>
>> On Apr 29, 2011, at 6:26 AM, Robert Goldman wrote:
>>
>>> The document http://orgmode.org/worg/org-tutorials/org-latex-export.html
>>> claims
>>>
>>> "The Org-mode LaTeX exporter uses several packages to support  
>>> special
>>> characters used by org-entities. One of these, amsmath, conflicts  
>>> with
>>> several LaTeX fonts. If you want finer control over which packages  
>>> are
>>> loaded, then it makes sense to define an export class like this in
>>> .emacs:"
>>>
>>> But I just checked the results of exporting one of my org files,  
>>> and it
>>> does /not/ use amsmath.
>>>
>>> Is this a bug in the tutorial?
>>>
>>>
>>
>


[-- Attachment #2: Type: text/html, Size: 5631 bytes --]

Re: bug in latex export tutorial?

[Nick Dokos]

Robert Goldman <rpgoldman@sift.info> wrote:

> On 4/29/11 Apr 29 -11:44 AM, Thomas S. Dye wrote:
> > Aloha Robert,
> > 
> > Yep.  It should be "One of these, amssymb, requires amsmath, which
> > conflicts with several LaTeX fonts."
> 
> I don't /believe/ amssymb requires amsmath.  I have been working on a
> document where I wanted to use some of the stuff in amsmath (e.g.,
> \text, align environment).  That document did /not/ parse, even though
> amssymb *is* in the preamble of the exported file.  I looked, and the
> preamble has amssymb, but not amsmath.
> 
> It would be *great* if someone could provide tutorial information that
> would tell us:
> 
> 1.  How do we configure a file so that it *can* use amsmath?

amsmath conflicts with wasysym (redefines \iint), so you have to
redefine your headers to omit wasysym or include amsmath *first*: for
some reason, if you \usepackage{amsmath} *before* you
\usepackage{wasysym}, the error does not arise -- presumably, amsmath
assumes that \iint is not defined beforehand, whereas wasysym does not
make that assumption.

> 2.  What happens to the parallel HTML export if we use amsmath
> constructs in an org file?
> 

It would depend on whether you use the dvipng mechanism or the mathjax mechanism
for math visualization. In the first case, amsmath is automatically included by
org mode (before wasysym, so no problems). In the second case, I wouldn't be able
to tell you: I've had problems with mathjax that I've wanted to investigate for ages
and never had the time - one of these centuries I'll get around to it...

Nick

Re: bug in latex export tutorial?

[Robert Goldman]

On 4/29/11 Apr 29 -1:21 PM, Nick Dokos wrote:
> Robert Goldman <rpgoldman@sift.info> wrote:
> 
>> On 4/29/11 Apr 29 -11:44 AM, Thomas S. Dye wrote:
>>> Aloha Robert,
>>>
>>> Yep.  It should be "One of these, amssymb, requires amsmath, which
>>> conflicts with several LaTeX fonts."
>>
>> I don't /believe/ amssymb requires amsmath.  I have been working on a
>> document where I wanted to use some of the stuff in amsmath (e.g.,
>> \text, align environment).  That document did /not/ parse, even though
>> amssymb *is* in the preamble of the exported file.  I looked, and the
>> preamble has amssymb, but not amsmath.
>>
>> It would be *great* if someone could provide tutorial information that
>> would tell us:
>>
>> 1.  How do we configure a file so that it *can* use amsmath?
> 
> amsmath conflicts with wasysym (redefines \iint), so you have to
> redefine your headers to omit wasysym or include amsmath *first*: for
> some reason, if you \usepackage{amsmath} *before* you
> \usepackage{wasysym}, the error does not arise -- presumably, amsmath
> assumes that \iint is not defined beforehand, whereas wasysym does not
> make that assumption.

The not-very-tasty solution I came up with was to put the following into
the local variables list at the foot of my file:

# org-export-latex-default-packages-alist: (("AUTO" "inputenc" t) ("T1"
"fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t) ("" "longtable" nil)
("" "float" nil) ("" "wrapfig" nil) ("" "soul" t) ("" "t1enc" t) (""
"textcomp" t) ("" "marvosym" t) ("" "amsmath" t) ("" "wasysym" t) (""
"latexsym" t) ("" "amssymb" t)
("colorlinks=true,pdfstartview=FitV,linkcolor=blue,citecolor=blue,urlcolor=blue"
"hyperref" nil) "\\tolerance=1000")

I put this in the file, rather than in my configuration, because it is
specific to the formatting of this file, and because I share this
document with others, who need to be able to export from it w/o having
to reconfigure their org-mode installations.

I figure that someone can probably suggest a solution that is nicer than
that!

Best,
r

Re: bug in latex export tutorial?

[Eric S Fraga]

Robert Goldman <rpgoldman@sift.info> writes:

> On 4/29/11 Apr 29 -1:21 PM, Nick Dokos wrote:

[...]

>> amsmath conflicts with wasysym (redefines \iint), so you have to
>> redefine your headers to omit wasysym or include amsmath *first*: for
>> some reason, if you \usepackage{amsmath} *before* you
>> \usepackage{wasysym}, the error does not arise -- presumably, amsmath
>> assumes that \iint is not defined beforehand, whereas wasysym does not
>> make that assumption.
>
> The not-very-tasty solution I came up with was to put the following into
> the local variables list at the foot of my file:
>
> # org-export-latex-default-packages-alist: (("AUTO" "inputenc" t) ("T1"
> "fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t) ("" "longtable" nil)
> ("" "float" nil) ("" "wrapfig" nil) ("" "soul" t) ("" "t1enc" t) (""
> "textcomp" t) ("" "marvosym" t) ("" "amsmath" t) ("" "wasysym" t) (""
> "latexsym" t) ("" "amssymb" t)
> ("colorlinks=true,pdfstartview=FitV,linkcolor=blue,citecolor=blue,urlcolor=blue"
> "hyperref" nil) "\\tolerance=1000")
>
> I put this in the file, rather than in my configuration, because it is
> specific to the formatting of this file, and because I share this
> document with others, who need to be able to export from it w/o having
> to reconfigure their org-mode installations.
>
> I figure that someone can probably suggest a solution that is nicer than
> that!
>
> Best,
> r

From earlier this year on the mailing list, below is a solution
which works if you more often than not want amsmath; i.e. it's not a
solution for the use case you specify in which you want to share a
single file etc.  However, it's worth repeating this solution for other
use cases.

--8<---------------cut here---------------start------------->8---
;; to fix problems with amsmath conflicting with wasysym:
;;
;; From: Lawrence Mitchell <wence@gmx.li>
;; Subject: [Orgmode] Re: [bug] latex export ignores org-export-latex-default-packages-alist?
;; To: emacs-orgmode@gnu.org
;; Date: Wed, 26 Jan 2011 16:01:52 +0000
(add-to-list 'org-export-latex-packages-alist '("" "amsmath" t))
(setcar (rassoc '("wasysym" t) org-export-latex-default-packages-alist)	"integrals")
--8<---------------cut here---------------end--------------->8---

HTH,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.226.gc7ed6.dirty)

Collaboration and settings --- was Re: bug in latex export tutorial?

[Robert Goldman]

On 4/30/11 Apr 30 -5:14 PM, Eric S Fraga wrote:
> Robert Goldman <rpgoldman@sift.info> writes:
> 
>> On 4/29/11 Apr 29 -1:21 PM, Nick Dokos wrote:
> 
> [...]
> 
>>> amsmath conflicts with wasysym (redefines \iint), so you have to
>>> redefine your headers to omit wasysym or include amsmath *first*: for
>>> some reason, if you \usepackage{amsmath} *before* you
>>> \usepackage{wasysym}, the error does not arise -- presumably, amsmath
>>> assumes that \iint is not defined beforehand, whereas wasysym does not
>>> make that assumption.
>>
>> The not-very-tasty solution I came up with was to put the following into
>> the local variables list at the foot of my file:
>>
>> # org-export-latex-default-packages-alist: (("AUTO" "inputenc" t) ("T1"
>> "fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t) ("" "longtable" nil)
>> ("" "float" nil) ("" "wrapfig" nil) ("" "soul" t) ("" "t1enc" t) (""
>> "textcomp" t) ("" "marvosym" t) ("" "amsmath" t) ("" "wasysym" t) (""
>> "latexsym" t) ("" "amssymb" t)
>> ("colorlinks=true,pdfstartview=FitV,linkcolor=blue,citecolor=blue,urlcolor=blue"
>> "hyperref" nil) "\\tolerance=1000")
>>
>> I put this in the file, rather than in my configuration, because it is
>> specific to the formatting of this file, and because I share this
>> document with others, who need to be able to export from it w/o having
>> to reconfigure their org-mode installations.
>>
>> I figure that someone can probably suggest a solution that is nicer than
>> that!
>>
>> Best,
>> r
> 
> From earlier this year on the mailing list, below is a solution
> which works if you more often than not want amsmath; i.e. it's not a
> solution for the use case you specify in which you want to share a
> single file etc.  However, it's worth repeating this solution for other
> use cases.

Is there any documentation any where about how people use Org-mode in
collaborative authoring?  I find myself not on solid ground
understanding how to ensure that my colleagues have the same
configuration.  For now, I resort to entries in the local variables
list, but this may not be the best solution....

One could hijack the directory locals, but that seems like The Wrong
Thing --- we should leave that to the individual user for his/her
preferences.  Possibly set up something that would be layered, so that
there are dir-locals that optionally load user-specific settings /after/
the dir-locals (i.e., a second layer of dir-locals)?

Is anyone else trying to do stuff like this?

best,
r

Re: Collaboration and settings --- was Re: bug in latex export tutorial?

[Thomas S. Dye]

Aloha Robert,

I think this is an important issue.  I haven't seen it addressed fully.

There was a discussion on the mailing list a while back on how the  
complexity of configuration made org-mode difficult to adopt.  This  
resulted in the short version of the manual, but not much in the way  
of configuration strategies, IIRC.

Something similar came up in the context of using buffer local  
variables to configure export parameters on a per-document basis.  I'm  
not a programmer, but your solution looks similar to me.

Programmers on the list might have a different take on this, but my  
sense is that the complexity of configuration has so far frustrated  
attempts to bring it under firmer control.

All the best,
Tom

On May 1, 2011, at 6:12 AM, Robert Goldman wrote:

> On 4/30/11 Apr 30 -5:14 PM, Eric S Fraga wrote:
>> Robert Goldman <rpgoldman@sift.info> writes:
>>
>>> On 4/29/11 Apr 29 -1:21 PM, Nick Dokos wrote:
>>
>> [...]
>>
>>>> amsmath conflicts with wasysym (redefines \iint), so you have to
>>>> redefine your headers to omit wasysym or include amsmath *first*:  
>>>> for
>>>> some reason, if you \usepackage{amsmath} *before* you
>>>> \usepackage{wasysym}, the error does not arise -- presumably,  
>>>> amsmath
>>>> assumes that \iint is not defined beforehand, whereas wasysym  
>>>> does not
>>>> make that assumption.
>>>
>>> The not-very-tasty solution I came up with was to put the  
>>> following into
>>> the local variables list at the foot of my file:
>>>
>>> # org-export-latex-default-packages-alist: (("AUTO" "inputenc" t)  
>>> ("T1"
>>> "fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t) ("" "longtable"  
>>> nil)
>>> ("" "float" nil) ("" "wrapfig" nil) ("" "soul" t) ("" "t1enc" t) (""
>>> "textcomp" t) ("" "marvosym" t) ("" "amsmath" t) ("" "wasysym" t)  
>>> (""
>>> "latexsym" t) ("" "amssymb" t)
>>> ("colorlinks 
>>> =true,pdfstartview=FitV,linkcolor=blue,citecolor=blue,urlcolor=blue"
>>> "hyperref" nil) "\\tolerance=1000")
>>>
>>> I put this in the file, rather than in my configuration, because  
>>> it is
>>> specific to the formatting of this file, and because I share this
>>> document with others, who need to be able to export from it w/o  
>>> having
>>> to reconfigure their org-mode installations.
>>>
>>> I figure that someone can probably suggest a solution that is  
>>> nicer than
>>> that!
>>>
>>> Best,
>>> r
>>
>> From earlier this year on the mailing list, below is a solution
>> which works if you more often than not want amsmath; i.e. it's not a
>> solution for the use case you specify in which you want to share a
>> single file etc.  However, it's worth repeating this solution for  
>> other
>> use cases.
>
> Is there any documentation any where about how people use Org-mode in
> collaborative authoring?  I find myself not on solid ground
> understanding how to ensure that my colleagues have the same
> configuration.  For now, I resort to entries in the local variables
> list, but this may not be the best solution....
>
> One could hijack the directory locals, but that seems like The Wrong
> Thing --- we should leave that to the individual user for his/her
> preferences.  Possibly set up something that would be layered, so that
> there are dir-locals that optionally load user-specific settings / 
> after/
> the dir-locals (i.e., a second layer of dir-locals)?
>
> Is anyone else trying to do stuff like this?
>
> best,
> r
>