Three new user-customizable variables:
org-export-latex-listings-options (default nil)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Association list of options for the latex listings package.
These options are supplied as a comma-separated list to the
\\lstset command. Each element of the association list should be
a list containing two strings: the name of the option, and the
value. For example,
(setq org-export-latex-listings-options
'((\"basicstyle\" \"\\small\")
(\"keywordstyle\" \"\\color{black}\\bfseries\\underbar\")))
will typeset the code in a small size font with underlined, bold
black keywords.
Note that the same options will be applied to blocks of all
languages.
See ftp://ftp.tex.ac.uk/tex-archive/macros/latex/contrib/listings/listings.pdf
customization group: org-export-latex
org-export-latex-minted-options (default nil)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Association list of options for the latex minted package.
These options are supplied within square brackets in
\\begin{minted} environments. Each element of the alist should be
a list containing two strings: the name of the option, and the
value. For example,
(setq org-export-latex-minted-options
'((\"bgcolor\" \"bg\") (\"frame\" \"lines\")))
will result in src blocks being exported with
\\begin{minted}[bgcolor=bg,frame=lines]{<LANG>}
as the start of the minted environment. Note that the same
options will be applied to blocks of all languages."
customization group: org-export-latex
See minted.googlecode.com/files/minted.pdf
org-export-latex-custom-lang-environments (default nil)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Association list mapping languages to language-specific latex
environments used during export of src blocks by the listings
and minted latex packages. For example,
(setq org-export-latex-custom-lang-environments
'((python \"pythoncode\")))
* lisp/org-exp.el (org-export-format-source-code-or-example):
Support new user-customizable options
(org-export-latex-custom-lang-environments): Ensure new variable is defined
(org-export-latex-listings-options): Ensure new variable is defined
(org-export-latex-minted-options): Ensure new variable is defined
* lisp/org-latex.el (org-export-latex-listings-options): New variable
(org-export-latex-minted-options): New variable
(org-export-latex-custom-lang-environments): New variable
The LaTeX looks for strings to export before the first headline. Such
strings are defined as "before the first heading", so they normally never
match a heading regexp. However, #+INCLUDE can insert lines before the
first heading matching a heading regexp, causing these lines to appear
twice: as first lines and as normal headings.
The fix is to never include first lines when they match a heading regexp.
This was reported by Rasmus <rasmus.pank@gmail.com>.
* org-latex.el (org-export-latex-emph-format): Don't use
`org-export-latex-use-verb'. Remove this variable.
This variable was introduced by Carsten for testing purpose,
it was not meant to be a user variable.
\protectedtexttt for the =...= emphasis and \verb for the
~...~ emphasis.
(org-export-latex-use-verb): now defaults to t.
(org-export-latex-emph-format): distinguish between =...= and
~...~ emphasis.
---
This patch was submitted by Carsten as a variation on Thomas Dye's
original patch.
* lisp/org-latex.el (org-latex-default-figure-position): New defcustom
for default placement of latex figures.
(org-export-latex-tables): Positioning tables using the new
defcustom variable.
(org-export-latex-format-image): Positioning images using the new
defcustom variable.
`org-export-process-option-filters' is supported for HTML export but not
for latex export. The patch at the bottom fixes that.
I note that there is one other location in the same function where it
seems the same change could be made. I suspect this is not necessary,
but if someone is familiar with the org-latex code they might like to
have a look. (I didn't manage to understand the roles of the several
variables with names like *-opt-plist *-options-plist in that function.)
I'm protecting this patch from patchwork with ^$; it's the patch at the
bottom that I propose.
$ diff --git a/lisp/org-latex.el b/lisp/org-latex.el
$ index 51ee6d2..53d6b40 100644
$ --- a/lisp/org-latex.el
$ +++ b/lisp/org-latex.el
$ @@ -700,7 +700,8 @@ when PUB-DIR is set, use this as the publishing directory."
$ '(:org-license-to-kill nil))))
$ (org-update-radio-target-regexp)
$ (org-export-latex-set-initial-vars ext-plist arg)
$ - (setq org-export-opt-plist org-export-latex-options-plist)
$ + (setq org-export-opt-plist
$ + (org-export-process-option-filters org-export-latex-options-plist))
$ (org-install-letbind)
$ (run-hooks 'org-export-latex-after-initial-vars-hook)
$ (let* ((wcf (current-window-configuration))
$
Support `org-export-process-option-filters' in latex export
* lisp/org-latex.el (org-export-as-latex): Process export property
list with `org-export-process-option-filters' early in latex export
Modified lisp/org-latex.el
Xin Shi <shixin111@gmail.com> wrote:
>
> Shr\"odinger will give the o with two dots on top. Notice that the " is a double quotation mark.
>
> However, when org translate that into LaTeX, it will become two single quotation mark! \'' (it's very hard to see the difference, but the pdf version will
> see the wrong result).
>
> Could someone tell me how to do that?
>
It works correctly in headlines, but not in running text. I think [fn:1]
that it is a bug and that the following patch fixes it:
--8<---------------cut here---------------start------------->8---
--8<---------------cut here---------------end--------------->8---
but I have not tested it extensively and it may do more harm than good:
I'd wait for a more definitive opinion.
Alternatively, you can use UTF-8 in your org file and write Schrödinger
explicitly. This will survive the LaTeX export intact and the
\usepackage[utf8]{inputenc} in the LaTeX file will do the right thing
with it.[fn:2]
Nick
Footnotes:
[fn:1] but I'm really not sure: I've lost track of how things work in
LaTeX export - sigh...
[fn:2] I'm not sure whether it will survive the email trip
though. Here's hoping that it will.
* org-latex.el (org-export-latex-make-header): Export email in
author line if `org-export-email-info' is non-nil.
Previously exporting to LaTeX would not include the document author's
email address when org-export-email-info was set. This patch corrects
this oversight using the \thanks command to add a footnote to the
author line.
* lisp/org-latex.el (org-export-latex-preprocess): Don't convert link
description parts that look like numeric footnote.
Fixes a problem reported by Thomas S. Dye.
* lisp/org-latex.el (org-export-latex-first-lines): Anchor outline
regexp during LaTeX tree export
Jrg Hagmann writes:
> - If you export the (new) minimal example below to latex (C-cC-e l), it works.
> - If you only export a tree (Subtree in the example; C-cC-e 1 l), the first table ends at the horizontal line and everything between it and the next node (Subsubtree) is eliminated. The second (identical) table is exported correctly.
> - If you remove the asterisk(s) in the first table, it works.
>
> This problem crept in in the last days or weeks before 7.4.
>
> It may not be a problem for most of you, but I happen to have a number of files where columns are automatically displayed as tables preceding the first subnode (#+BEGIN: columnview ...). An alternative would be to display %ITEM in column-view without the asterisks.
>
> Emacs 23.2.1 on OS X 10.6.5
> Org-mode version 7.4 (release_7.4.24.g48b11.dirty)
>
> Thanks, Jrg
>
> -------New minimal example------------
> * Subtree
>
>
> | One | Two | Three |
> |--------+------+-------|
> | * Test | text | text |
> | ** One | text | text |
>
>
> Some text
>
> ** Subsubtree
>
> | One | Two | Three |
> |--------+------+-------|
> | * Test | text | text |
> | ** One | text | text |
* lisp/org-latex.el (org-export-latex-lists): do not add an
unnecessary newline character after a list.
* lisp/org-list.el (org-list-bottom-point-with-indent): ensure bottom
point is just after a non blank line.
* lisp/org-latex.el (org-export-latex-make-header): Run the title through
`org-export-latex-fontify-headline'.
(org-export-latex-fontify-headline): Do the protection of math
snippets also here
* lisp/org-latex.el (org-export-as-latex): Sent the section title
through the preprocessor.
Hi all,
This patch fixes the issue I originally described here:
http://article.gmane.org/gmane.emacs.orgmode/32281
It preserves math-mode delimiters (e.g. "$" and "\(") in the document
title when exporting to LaTeX. (That is, it prevents them from being
escaped, by running the title through org-export-preprocess-string,
which marks them with the org-protected property.) It should work
regardless of whether the title is pulled from a headline, from the text
before the first headline, or from an explicit #+TITLE declaration.
(This is my first time contributing a patch to a Free Software project
-- so please, let me know what you think!)
Best,
Richard
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote:
>
>> "Thomas S. Dye" <tsd@tsdye.com> writes:
>>
>>> Aloha Jambunathan K.,
>>>
>>> Yes, thanks for that suggestion. It should work on your example, but
>>> it breaks external links, like this:
>>>
>>> \hyperref[http://www.ctan.org/tex-archive/macros/latex/contrib/koma-script/
>>> ]{KOMA-script}
>>>
>>> External links require the \href{}{} command. It appears the LaTeX
>>> export process no longer distinguishes internal and external links,
>>> as
>>> I believe it used to do.
>>>
>>
>> This is the problematic commit:
>>
>> commit f5918bdcc0
>> parent df5894cdcb
>> Date: Sun Oct 17 08:29:51 2010 +0000
>>
>> LaTeX export: use org-export-latex-hyperref-format
>
> I have just reverted this commit.
>
> - Carsten
>
Looks like time to change the variable name which is actually confusing.
Since href and hyperref are two different things, I renamed the existing
`org-export-latex-hyperref-format' variable as
`org-export-latex-href-format' and introduced a new one
`org-export-latex-hyperref-format'.
* org-latex.el (org-export-latex-hyperref-format): New option.
(org-export-latex-href-format): Renamed the existing variable
`org-export-latex-hyperref-format' as `org-export-latex-href-format'
(org-export-latex-links): Use `org-export-latex-hyperref-format' and
`org-export-latex-href-format'
Thanks and Regards
Noorul
>>
>> * lisp/org-latex.el (org-export-latex-links) : Replaced hard coded
>> hyperref format with custom
>> variable `org-export-latex-hyperref-format'
>>
>> Note that href is not same as hyperref.
>>
>> Jambunthan K.
>>
>>
>>> All the best,
>>> Tom
>>>
>>> On Oct 28, 2010, at 3:30 PM, Jambunathan K wrote:
>>>
>>>>
>>>> Thomas
>>>>
>>>> There was a hint at possible solution (or atleast a partial
>>>> solution) in
>>>> my original post. Did you try it before jumping in to rough waters
>>>> or
>>>> digging deeper?
>>>>
>>>> Do
>>>>
>>>> ,----
>>>> | M-x customize-variable RET org-export-latex-hyperref-format'
>>>> `----
>>>>
>>>> so that your .emacs has an entry like this
>>>>
>>>> ,---- [.emacs]
>>>> |
>>>> | (custom-set-variables
>>>> | '(org-export-latex-hyperref-format "\\hyperref[%s]{%s}"))
>>>> |
>>>> `----
>>>>
>>>> The above setting solves the problem for me with the following
>>>> simple
>>>> Org file.
>>>>
>>>> * Heading1
>>>> Make this section as large as possible so that it fills atleast a
>>>> page.
>>>>
>>>> * Heading2
>>>> Links to [[Heading1]]
>>>>
>>>> Jambunathan K.
>>>>
>>>> "Thomas S. Dye" <tsd@tsdye.com> writes:
>>>>
>>>>> On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote:
>>>>>
>>>>>> Thomas S. Dye <tsd@tsdye.com> wrote:
>>>>>>
>>>>>>> On Oct 28, 2010, at 11:01 AM, Jambunathan K wrote:
>>>>>>>
>>>>>>>
>>>>>>> This is a regression. release-7.01h is good. HEAD is bad. I get
>>>>>>> the
>>>>>>> following line with release-7.01h.<
>>>>>>>
>>>>>>> Links to \hyperref[sec-1]{Heading1}
>>>>>>>
>>>>>>> Jambunathan K.
>>>>>>>
>>>>>>> Aloha Jambunathan K.,
>>>>>>>
>>>>>>> Very many thanks for this information. I have Org-mode version
>>>>>>> 7.01trans
>>>>>>> (release_7.01h.880.g7531f). I take it the problem I'm having is
>>>>>>> due to a relatively recent change
>>>>>>> to Org-mode. If there is anything I can do to help isolate the
>>>>>>> problem, please let me know.
>>>>>>>
>>>>>>
>>>>>> Tom,
>>>>>>
>>>>>> If you have the time and the inclination, you might try bisecting
>>>>>> your
>>>>>> way through. Bisecting org-mode problems is actually a very good
>>>>>> way
>>>>>> to
>>>>>> practice because the turnaround time is very small.
>>>>>>
>>>>>> Prerequisites:
>>>>>>
>>>>>> * you have a clone of the org-mode git repository.
>>>>>>
>>>>>> * you have an org test file.
>>>>>>
>>>>>>
>>>>>> Steps:
>>>>>>
>>>>>> * [optional, but it makes me feel a little safer] create a test
>>>>>> branch
>>>>>> and switch to it:
>>>>>>
>>>>>> git checkout -b test-branch master
>>>>>>
>>>>>> * I clean out all the compiled files while doing a bisection: it's
>>>>>> quicker
>>>>>> than regenerating them every time and I don't have to worry (much)
>>>>>> about
>>>>>> emacs loading a wayward .elc file:
>>>>>>
>>>>>> make clean
>>>>>>
>>>>>> * start the bisection and tell git which commit is known good and
>>>>>> which is known bad:
>>>>>>
>>>>>> git bisect start
>>>>>>
>>>>>> # current version is bad
>>>>>> git bisect bad
>>>>>>
>>>>>> # release_7.01h was good - I got the name with ``git tag''
>>>>>> git bisect good release_7.01h
>>>>>>
>>>>>> That checks out a revision half-way in between the bad and good
>>>>>> commits: since
>>>>>> there are about 900 commits in between, you'll be at approx the
>>>>>> 450-
>>>>>> mark and it
>>>>>> should take about 10 bisections to get it down to a single commit.
>>>>>>
>>>>>> * LOOP Now all you have to do is repeat the following steps:
>>>>>>
>>>>>> # since you did ``make clean'' you don't have to worry about .elc
>>>>>> files
>>>>>> # just reload all the .el files.
>>>>>> M-x org-reload
>>>>>>
>>>>>> visit your org test file, export to LaTeX, check for \href/
>>>>>> \hyperref (or
>>>>>> whatever other telltale sign shows badness/goodness).
>>>>>>
>>>>>> # tell git about it
>>>>>> git bisect good *OR* git bisect bad
>>>>>>
>>>>>> This last step will check out another revision and in about 10
>>>>>> repetitions
>>>>>> of the loop, you are done.
>>>>>>
>>>>>> * Tell git you are done, so it can clean up:
>>>>>>
>>>>>> git bisect reset
>>>>>>
>>>>>> Theoretically, you could do all of this in your master branch
>>>>>> without
>>>>>> creating a test-branch and this last step will reset everything to
>>>>>> the
>>>>>> way it was before ``git start''.
>>>>>>
>>>>>> * Post the offending commit to the list.
>>>>>>
>>>>>> * Get back to your master branch:
>>>>>>
>>>>>> git checkout master
>>>>>>
>>>>>> * If you created a test-branch, clean it out:
>>>>>>
>>>>>> git branch -d test-branch
>>>>>>
>>>>>> * [Optional] Recreate your .elc files and reload them:
>>>>>>
>>>>>> make
>>>>>> M-x org-reload
>>>>>>
>>>>>>
>>>>>> And that's it: a half-hour of fun and games. Unless of course, you
>>>>>> hit upon a revision that is neither good nor bad (in the above
>>>>>> restricted
>>>>>> sense): you might get some other problem that prevents you from
>>>>>> being
>>>>>> able to answer. That might or might not be easy to resolve, so
>>>>>> I'll
>>>>>> leave that as an advanced topic (truth be told, I came up against
>>>>>> this
>>>>>> situation a couple of days ago and I didn't know how to proceed:
>>>>>> so
>>>>>> it's ignorance more than anything else that prevents me from
>>>>>> saying
>>>>>> anything more).
>>>>>>
>>>>>> If you want to try, I'd be happy to answer questions - I might try
>>>>>> the
>>>>>> bisection later on tonight myself in any case. And btw, this is of
>>>>>> course archeology of a different (and much easier) kind, so I
>>>>>> imagine
>>>>>> you'll take to it like a fish in water :-)
>>>>>>
>>>>>> HTH,
>>>>>> Nick
>>>>>
>>>>> Hi Nick,
>>>>>
>>>>> Irresistible hook at the end there. I wish this stuff were as easy
>>>>> as
>>>>> archaeology is for me. Your instructions are terrific, though.
>>>>>
>>>>> I did hit on a revision that was neither good nor bad:
>>>>>
>>>>> commit 8562273b27
>>>>> Author: Eric Schulte <schulte.eric@gmail.com>
>>>>> Date: Sat Oct 16 13:21:47 2010 -0600
>>>>>
>>>>> ob-ref: don't forget arguments to referenced code blocks
>>>>>
>>>>> * lisp/ob-ref.el (org-babel-ref-resolve): bringing the referent
>>>>> arguments back to their params before evaluation
>>>>>
>>>>> This one puts these lines in *Messages* when I export to LaTeX
>>>>>
>>>>> executing Org code block...
>>>>> if: Symbol's value as variable is void: result-type
>>>>>
>>>>> I tried using different commits for the initial git bisect good,
>>>>> hoping that would skip by the problem, but this one appears to have
>>>>> stuck around a while. My other two tries both ended with this same
>>>>> error, but with different commits.
>>>>>
>>>>> I'm not sure what to do next. This problem isn't yielding to my
>>>>> archaeo-logic. :)
>>>>>
>>>>> All the best,
>>>>> Tom
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
* lisp/org-exp.el (org-export-format-source-code-or-example): Use
minted for latex source code export if `org-export-latex-listings' has
the value 'minted
* lisp/org-latex.el (org-export-latex-listings): Document special
value 'minted
* lisp/org-latex.el (org-export-latex-minted): Delete variable
* doc/org.texi: Document the <c> cookie.
* lisp/org-exp.el (org-store-forced-table-alignment):
(org-export-remove-special-table-lines): Allow the "c" cookie for
table alignment.
* lisp/org-html.el (org-export-table-header-tags):
(org-export-table-data-tags): Add another %s format for the alignment.
(org-export-html-table-align-individual-fields): New option.
(org-format-org-table-html): Implement field-by-field alignment and
support centering.
(org-format-table-table-html): Make sure the new table tag formats
don't break this function.
* lisp/org-table.el (org-table-cookie-line-p):
(org-table-align): Allow for the <c> cookie.
* lisp/org.el (org-set-font-lock-defaults): Allow for the <c> cookie.
* lisp/org-compat.el (org-number-sequence): New function.
* lisp/ob-R.el (org-babel-expand-body:R): Use `org-number-sequence'.
* lisp/ob.el (org-babel-where-is-src-block-result): Use `org-number-sequence'.
(org-babel-current-buffer-properties): Fix variable definition.
* lisp/ob-ref.el (org-babel-ref-index-list): Use `org-number-sequence'.
* lisp/ob-latex.el (org-babel-latex-tex-to-pdf): Use the 2-argument version
of `shell-command'.
* lisp/org-latex.el (org-export-as-pdf): Use the 2-argument version
of `shell-command'.
* lisp/org-latex.el (org-export-latex-links) : Replaced hard coded
hyperref format with custom
variable `org-export-latex-hyperref-format'
On Sat, Oct 16, 2010 at 3:32 PM, Guy Wiener <wiener.guy@gmail.com> wrote:
> I found the following weird thing in org-latex, and I think it is a bug:
> The customization option "org-export-latex-hyperref-format" is suppose to
> render links to hyperrefs in the exported tex file. However, in
> org-latex.el, lines 1889 and 1892, the string "\\hyperref[%s]{%s}" is
> hard-coded, so that the link export format is not reallycustomizable. I
> replaced this string with the custom variable and the option works as
> expected - I.e., changing the option chanced the format of exported links.
Looks like commit cae0c63c48 has introduced
new customizable variable org-export-latex-hyperref-format but left
out some places
in the code to be replaced. Attached is the patch.
Log:
Found by Guy Wiener <wiener.guy@gmail.com>
Thanks and Regards
Noorul
* org-exp.el (org-export-format-source-code-or-example): latex
formatting of source code blocks using the minted package
(org-export-plist-vars): Add :latex-minted property
(org-export-latex-minted): Ensure variable is defined
(org-export-latex-minted-langs): Ensure variable is defined
* org-latex.el (org-export-latex-minted): new variable
(org-export-latex-minted-langs): new variable
(org-export-latex-minted-with-line-numbers): new variable
(org-export-latex-minted):
* lisp/org-latex.el (org-latex-to-pdf-process): Add a third pdflatex run.
Hi Carsten,
Carsten Dominik wrote:
> I have just pushed a fix which will use texi2dvi when available. The echo
> area will now also give an indication of the kinds of errors that happened
> during the final pdflatex run.
Thanks to Matthew for the info about texi2dvi!
> This is a big improvement, thanks to Sebastian for kicking off this
> discussion, and to all who contributed.
You're welcome. It was needed for me as well...
> Please test the new processing and let me know if there are problems.
Tested on the document for which I experienced the troubles in the first place
(because my TOC was more than one page long). Works perfect!
Only one comment, after reading your code in org-latex.el: if there is no
texi2dvi executable, please run pdflatex 3 times, as this is the right number
to get the TOC in sync' with the document, when it's more than one page long
(at least, in my above case, with a couple of org-babel sql source blocks).
--8<---------------cut here---------------start------------->8---
Changes in HEAD
Modified lisp/org-latex.el
--8<---------------cut here---------------end--------------->8---
Thanks.
Best regards,
Seb
* lisp/org-latex.el (org-latex-to-pdf-process): Use texi2dvi if available.
(org-export-latex-get-error): New function.
(org-export-as-pdf): Give an indication of the errors that happened
during processing.
Bastien Guerry
Dan Davison
Valentin Wüstholz
Eric Schulte
Nick Dokos
Lawrence Mitchell
David Maus
Carsten Dominik
Nicolas Goaziou
Richard Lawrence
Noorul Islam
Dan Davison
Sébastien Vauban