The regular expression was not optimal, and if there was a horizontal
rule, search would not start from the beginning of the buffer but from
after the rule!
Julien Barnier writes:
> I recntly noticed that in some specific cases, the final '}' was
> esacped when exproting an emphasis element to LaTeX.
>
> For example, the following element :
>
> /aa/
>
> Is exported to :
>
> \emph{aa\}
>
> This does not append if the string begins with a space or if it
> is ASCII-only. For example, the followig strings are exported
> correctly :
>
> /aaa/
> //
>
> I don't understand why the problem only occurs with non-ASCII chars,
> but I think that the regexp to protect added special chars in the
> org-export-latex-fontify function is missing a '?' in the
> beginning. Tha attached patch corrects it.
Francesco Pizzolante writes:
> Exporting multiple references to the same footnote to LaTeX lead to a wrong
> generated code.
>
> The following example:
>
> --8<---------------cut here---------------start------------->8---
> * Title
> This is my text[fn:1:This is my footnote.]. And another one[fn:1].
> --8<---------------cut here---------------end--------------->8---
>
> Will produce the following LaTeX code:
>
> --8<---------------cut here---------------start------------->8---
> \section{Title}
> \label{sec-1}
>
> This is my text\footnote{This is my footnote. }. And another one\$$^{1}$\$.
> --8<---------------cut here---------------end--------------->8---
>
> The correct code should be:
>
> --8<---------------cut here---------------start------------->8---
> \section{Title}
> \label{sec-1}
>
> This is my text\footnote{This is my footnote. }. And another one$^{1}$.
> --8<---------------cut here---------------end--------------->8---
Sebastian Rose writes:
> The following code does not work as expected, when exported to PDF:
>
> => --->8----------------------------->8----------------------------->8---
> * Image basics
>
> Images are inserted into an Org file in a fashion similar to links:
> : [[file:///home/sebastian/develop/org/org-mode-unicorn.png]]
>
> <= ---8<-----------------------------8<-----------------------------8<---
>
> Result:
>
> The last line is exported as:
>
> \href{file:///home/sebastian/develop/org/org-mode-unicorn.png}{nil}
>
>
> Expected result:
>
> I expect the last line to be exported as fixed width text.
>
Eric Fraga sent this test file:
> * Problem with underscore (subscript) in emphasised text.
> 1. Design for CO_2 capture.
> 2. The paper /Design for CO_2 capture/ is very interesting.
> 3. This item is combined with the previous and the previous is
> actually formatted wrongly.
> 4. This item seems to come out just fine.
Martin G. Skjaeveland writes:
> Then I write
>
> some text some text ~<<some_scr_block_name>>~.
>
> because I want "<<some_scr_block_name>>" written as verbatim in my latex
> export, I get, in latex,
>
> \texttt{\textbackslash{}label\{some\_src\_block\_name\}some\_src\_block\_name}.
>
> which gives me the text
>
> \label{some_src_block_name}some_src_block_name
>
> in verbatim.
Brenton Kenkel writes:
> I found an apparent minor bug with links containing quotation marks in
> LaTeX export. If the first character in the name of a link is a
> quotation mark, it is converted to a closing mark rather than an
> opening mark. For example:
>
> ,----
> | * test
> |
> | [[http://www.google.com]["hello"]]
> | [[http://www.google.com]["two" "quotes"]]
> `----
>
> This produces:
>
> ,----
> | \href{http://www.google.com}{''hello''}
> | \href{http://www.google.com}{''two'' ``quotes''}
> `----
Nick Dokos writes:
> I've been running with the following patch for a little while and have
> seen no problems (it does \centering rather than \centerline but I don't
> think it makes a difference for an image - it would make a difference for a
> floating centered paragraph with multiple lines however.)
>
> There is another problem as well: there is a \n added after the
> \end{figure} which leads to spurious paragraphs. The patch fixes
> that too.
Thomas S. Dye writes:
> I'm trying to generate $^{14}$C, or an equivalent, from org-mode
> to represent the isotope of carbon important in archaeological
> dating.
>
> Reading the manual, I tried this:
>
> ** A Brief History of Attempts to Interpret the ^{14}C Dates
> *** The ^{14}C Dates
>
> Which, in my #+LaTeX_CLASS: beamer export, yields
>
> \subsection{A Brief History of Attempts to Interpret the \^{}{14}C Dates}
> ...
> \begin{frame}\frametitle{The \^{}{14}C Dates}
>
> The problem seems to be the space before the ^.
>
> This input:
>
> ** A Brief History of Attempts to Interpret the x^{14}C Dates
> *** The x^{14}C Dates
>
> yields the correct LaTeX:
>
> \subsection{A Brief History of Attempts to Interpret the x$^{\mathrm{14}}$C Dates}
> ...
> \begin{frame}\frametitle{The x$^{\mathrm{14}}$C Dates}
>
> Am I missing something? Or, is the LaTeX export thrown off by
> the space before ^?
Indeed, a space before the caret was not allowed in LaTeX export
Jeff Kowalczyk writes:
> Is there a way to escape backslashes (\) in code and verbatim that
> will export to LaTeX correctly?
>
> When writing =\\host\share= or =C:\path\to=, pdftolatex output is
> incorrect.
Karl Stump writes:
> When exporting a table with a horizontal line the column count is wrong.
>
> Output from pdflatex run:
>
> ! Extra alignment tab has been changed to \cr.
> <template> \endtemplate
>
> l.32 ....\multicolumn{4}{r}{Continued on next page}
> \
> ?
>
> Here's the table in the tex file:
>
> \begin{longtable}{||lll||}
> \caption{This is a long table with lines around and between cells}\\
> Heading1 & Heading2 & Heading3 \\
> \hline
> \endhead
> \hline\multicolumn{4}{r}{Continued on next page}\
> \endfoot
> \endlastfoot
> \hline
> alpha & beta & gamma \\
> & & \\
> \end{longtable}
>
> Here's the org file:
>
> ** table export test
>
> #+CAPTION: This is a long table with lines around and between cells
> #+LATEX_HEADER: \usepackage[landscape]{geometry}
> #+LATEX_HEADER: \geometry{left=0.12in,right=0.12in,top=0.25in,bottom=0.25in}
> #+ATTR_LaTeX: longtable align=||lll||
>
> | / | <30> | <10> | <10> |
> | | Heading1 | Heading2 | Heading3 |
> |---+----------+----------+----------|
> | | alpha | beta | gamma |
> | | | | |
Nick Dokos replies:
> I believe it's because of the dummy "calculation-mark" column,
> which is not exported. However, the variable org-table-last-alignment
> (a list, whose length becomes the value of the \multicolumn argument)
> ends up having the value (nil nil nil nil), i.e. it counts the dummy
> column as well. What the proper place to adjust the value is, I don't
> know, but it should be easy for Carsten to fix it. For the time being,
> you can either get rid of the dummy row and column (e.g. if you don't
> need the widths) or fix it by hand in the LaTeX file.
Indeed, and this commit pops `org-table-last-alignment' if the first
column has been removed by `org-table-clean-before-export'. The same
problem must have caused a one-off error when setting the alignment in
LaTeX tables, bu it seems nobody has noticed this so far. Anyway,
also this is fixed now.
A `save-excursion' around a call to org-table-align make point end up
*before* the table. The reason is that a table align replaces the
entire table, including the newline before it. When the table is
removed in order to be replaced, the marker created by
`save-excursion' slips. `org-table-align' has it's own, built-in
`save-excursion' by remembering the line and column where the cursor
was before the align.
Dan Griswold writes:
> Hi there,
>
> Well, I think this a bug.
>
> Given this org input file:
>
> ,----
> | * Things
> | ** A Heading
> | - some
> | - stuff
> | - in
> | - a
> | - list
> | ** Another heading
> | - another
> | - list
> `----
>
> then if I select the level one heading (titled "Things")
> with C-c @, and export to LaTeX using C-c C-e l, I get this
> output:
>
> ,----
> | % Created 2009-07-29 Wed 20:24
> | \documentclass[12pt]{article}
> | \usepackage[utf8]{inputenc}
> | \usepackage[T1]{fontenc}
> | \usepackage{graphicx}
> | \usepackage{longtable}
> | \usepackage{hyperref}
> |
> |
> | \title{Things}
> | \author{Daniel M. Griswold}
> | \date{July 29, 2009}
> |
> | \begin{document}
> |
> | \maketitle
> |
> | ** A Heading
> | \begin{itemize}
> | \item some
> | \item stuff
> | \item in
> | \item a
> | \item list
> | \end{itemize}
> | ** Another heading
> | \begin{itemize}
> | \item another
> | \item list
> | \end{itemize}
> |
> | \end{document}
> `----
>
> Note that the top level headings ("A Heading" and "Another
> Heading") are not exported as \section, but with the
> asterisks they have in the org file:
>
> ,----
> | ** A Heading
> | \begin{itemize}
> |
> | ... snip ...
> |
> | \end{itemize}
> | ** Another heading
> `----
>
> Exporting the whole file does what it's supposed to do:
> export the headlines as \section and \subsection.
This commit fixes the issue.