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.
* org-capture.el (org-capture-place-item): use `org-search-forward-unenclosed'
and `org-search-backward-unenclosed' and new variable `org-item-beginning-re'.
* org-list.el (org-item-beginning-re): regexp matching beginning of an item.
* org-list.el (org-search-backward-unenclosed): Do not stop in
protected places.
* org-list.el (org-search-forward-unenclosed): Do not stop in
protected places.
* org-latex.el (org-export-latex-lists): Use the fact that
org-search-forward do not stop anymore at protected places.
