* bug in new exporter
@ 2013-06-03 15:50 Marvin Doyley
2013-06-03 16:25 ` Rasmus
0 siblings, 1 reply; 14+ messages in thread
From: Marvin Doyley @ 2013-06-03 15:50 UTC (permalink / raw)
To: emacs-orgmode@gnu.org
Hi there,
When I include the following in my org file
#+attr_latex: scale=1.5, placement =[htb!]
[[file:img/figure2.eps]]
This was exported as
\begin{figure}[htb]
\centering
\includegraphcis[width=0.9\linewidth]{img/figure2.eps}
\end{figure}
rather than
\begin{figure}[htb!]
\centering
\includegraphcis[scale=1.5]{img/figure2.eps}
\end{figure}
I think there is a bug.
Thanks,
M
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: bug in new exporter
2013-06-03 15:50 bug in new exporter Marvin Doyley
@ 2013-06-03 16:25 ` Rasmus
2013-06-03 17:42 ` Nick Dokos
0 siblings, 1 reply; 14+ messages in thread
From: Rasmus @ 2013-06-03 16:25 UTC (permalink / raw)
To: emacs-orgmode
Hi Marvin,
Marvin Doyley <m.doyley@rochester.edu> writes:
> Hi there,
>
> When I include the following in my org file
>
> #+attr_latex: scale=1.5, placement =[htb!]
> [[file:img/figure2.eps]]
The syntax changes. Something like this might give you what you want.
#+ATTR_LATEX: :placement [htb!] :options scale=1.5
#+CAPTION: a float needs a caption
[[file:fig.pdf]]
do check out:
http://orgmode.org/org.html#LaTeX-specific-attributes
From the source code, ox-latex.el, you should be able to get it to
accept placement without square brackets. It should also be possible
to set something like htb! as the default value of floats, if you so
desire. Check the variable org-latex-default-figure-position.
–Rasmus
--
In theory, practice and theory are the same. In practice they are not
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug in new exporter
2013-06-03 16:25 ` Rasmus
@ 2013-06-03 17:42 ` Nick Dokos
2013-06-03 20:23 ` Rasmus
0 siblings, 1 reply; 14+ messages in thread
From: Nick Dokos @ 2013-06-03 17:42 UTC (permalink / raw)
To: emacs-orgmode
Rasmus <rasmus@gmx.us> writes:
> Hi Marvin,
>
> Marvin Doyley <m.doyley@rochester.edu> writes:
>
>> Hi there,
>>
>> When I include the following in my org file
>>
>> #+attr_latex: scale=1.5, placement =[htb!]
>> [[file:img/figure2.eps]]
>
> The syntax changes. Something like this might give you what you want.
>
> #+ATTR_LATEX: :placement [htb!] :options scale=1.5
> #+CAPTION: a float needs a caption
> [[file:fig.pdf]]
>
One thing that I couldn't figure out is how to get rid of the width
specification altogether. I can change the default
[...,width=0.9\textwidth] with something like
:width 10cm
but if I scale the image (presumably by trial and error until
it looks good to my eye), then I want to turn off the width
option altogether (afaict, latex treats [scale=1.5,width=10cm]
as [width=10cm] - scale is not considered at all, hence my desire
to turn off width.)
I tried
:width nil
and
:width
In these cases, I get the default. The code looks like this
--8<---------------cut here---------------start------------->8---
(width (cond ((plist-get attr :width))
((plist-get attr :height) "")
((eq float 'wrap) "0.48\\textwidth")
(t org-latex-image-default-width)))
--8<---------------cut here---------------end--------------->8---
and in these cases the plist-get returns nil, so the t clause
triggers.
I also tried
:width ""
which fails with a
Wrong type argument: stringp, nil
in this call (and I haven't chased it further):
--8<---------------cut here---------------start------------->8---
(attr (org-export-read-attribute :attr_latex parent))
--8<---------------cut here---------------end--------------->8---
Is it possible to eliminate ``width'' from the options?
> do check out:
>
> http://orgmode.org/org.html#LaTeX-specific-attributes
>
> From the source code, ox-latex.el, you should be able to get it to
> accept placement without square brackets.
I don't understand: what do you mean? AFAICT, you *have* to say
:placement [htb!]
*including* the square brackets, because the first clause of the cond
triggers and that does not include the square brackets:
--8<---------------cut here---------------start------------->8---
(cond (place (format "%s" place))
((eq float 'wrap) "{l}{0.5\\textwidth}")
((eq float 'figure)
(format "[%s]" org-latex-default-figure-position))
(t ""))))
--8<---------------cut here---------------end--------------->8---
> It should also be possible
> to set something like htb! as the default value of floats, if you so
> desire. Check the variable org-latex-default-figure-position.
>
OTOH, here you don't want to include the square brackets because the
format *does* add them. That seems to be a slight inconsistency.
Org-mode version 8.0.3 (release_8.0.3-173-gd200d0 @ /home/nick/elisp/org-mode/lisp/)
--
Nick
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: bug in new exporter
2013-06-03 17:42 ` Nick Dokos
@ 2013-06-03 20:23 ` Rasmus
2013-06-03 21:03 ` Nick Dokos
0 siblings, 1 reply; 14+ messages in thread
From: Rasmus @ 2013-06-03 20:23 UTC (permalink / raw)
To: emacs-orgmode
>>> When I include the following in my org file
>>>
>>> #+attr_latex: scale=1.5, placement =[htb!]
>>> [[file:img/figure2.eps]]
>>
>> The syntax changes. Something like this might give you what you want.
>>
>> #+ATTR_LATEX: :placement [htb!] :options scale=1.5
>> #+CAPTION: a float needs a caption
>> [[file:fig.pdf]]
>>
>
> One thing that I couldn't figure out is how to get rid of the width
> specification altogether.
It's a feature. We had a lengthy discussion about it a while ago
(myself, Nicholas and Aaron, I believe)
You can turn it permanently off by issuing
(setq org-latex-image-default-width nil)
I tested the code in my "own" Emacs and not emacs -q. To get no width
I do
#+NAME: name
#+ATTR_LATEX: :placement [htb!] :options scale=1.5 :width ""
#+CAPTION: a float needs a caption
[[file:signature.pdf]]
becomes:
\begin{figure}[htb!]
\centering
\includegraphics[scale=1.5]{signature.pdf}
\caption{\label{name}a float needs a caption}
\end{figure}
Org-mode version 8.0.3 (release_8.0.3-183-gca9937 @
/usr/share/emacs/site-lisp/org/).
> I also tried
>
> :width ""
>
> which fails with a
This should work, though, also given the earlier discussion. At least
it does for me using the version above and emacs -q.
>> From the source code, ox-latex.el, you should be able to get it to
>> accept placement without square brackets.
>
> I don't understand: what do you mean? AFAICT, you *have* to say
>
> :placement [htb!]
>
> *including* the square brackets, because the first clause of the cond
> triggers and that does not include the square brackets:
> OTOH, here you don't want to include the square brackets because the
> format *does* add them. That seems to be a slight inconsistency.
Right; thanks I missed that. Thanks! This is inconsistent. It also
seems wrapfig needs {} tho I've never used it.
Perhaps it could be made more consistent? At least the variable and
the local arguments should be similar. . .
–Rasmus
--
Need more coffee. . .
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: bug in new exporter
2013-06-03 20:23 ` Rasmus
@ 2013-06-03 21:03 ` Nick Dokos
2013-06-03 22:12 ` Rasmus
0 siblings, 1 reply; 14+ messages in thread
From: Nick Dokos @ 2013-06-03 21:03 UTC (permalink / raw)
To: emacs-orgmode
Rasmus <rasmus@gmx.us> writes:
>> One thing that I couldn't figure out is how to get rid of the width
>> specification altogether.
>
> It's a feature. We had a lengthy discussion about it a while ago
> (myself, Nicholas and Aaron, I believe)
>
Count me confused again: what's the feature? I'll go looking for the
discussion I guess.
> You can turn it permanently off by issuing
>
> (setq org-latex-image-default-width nil)
>
> I tested the code in my "own" Emacs and not emacs -q. To get no width
> I do
>
> #+NAME: name
> #+ATTR_LATEX: :placement [htb!] :options scale=1.5 :width ""
> #+CAPTION: a float needs a caption
> [[file:signature.pdf]]
>
OK, I just did an update, did emacs -q with a minimal .emacs and the
ATTR_LATEX line above works. Presumably it would also work with my
previous org-version, but I was trying things in a different order:
if I rearrange the line to
#+ATTR_LATEX: :width "" :placement [htb!] :options scale=1.5
I get the "Wrong argument type" error in the current version as well. So
I guess :width has to be after the :options ?!? I don't quite understand the
rules I guess.
Org-mode version 8.0.3 (release_8.0.3-193-g334581 @ /home/nick/elisp/org-mode/lisp/)
>> I also tried
>>
>> :width ""
>>
>> which fails with a
>
> This should work, though, also given the earlier discussion. At least
> it does for me using the version above and emacs -q.
>
Very helpful: thanks for the elucidation!
--
Nick
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug in new exporter
2013-06-03 21:03 ` Nick Dokos
@ 2013-06-03 22:12 ` Rasmus
2013-06-05 12:26 ` Nicolas Goaziou
0 siblings, 1 reply; 14+ messages in thread
From: Rasmus @ 2013-06-03 22:12 UTC (permalink / raw)
To: emacs-orgmode
Nick Dokos <ndokos@gmail.com> writes:
>>> One thing that I couldn't figure out is how to get rid of the width
>>> specification altogether.
>>
>> It's a feature. We had a lengthy discussion about it a while ago
>> (myself, Nicholas and Aaron, I believe)
>>
>
> Count me confused again: what's the feature? I'll go looking for the
> discussion I guess.
including .9\textwidth when you least expect it is a feature.
See this thread
http://comments.gmane.org/gmane.emacs.orgmode/69963
> if I rearrange the line to
>
> #+ATTR_LATEX: :width "" :placement [htb!] :options scale=1.5
>
> I get the "Wrong argument type" error in the current version as
> well.
I can reproduce this here.
> I guess :width has to be after the :options ?!? I don't quite
> understand the rules I guess.
Neither do I in this case. I'm guessing it has do with the "escaping"
of "" 'cause it also fails if you :placement behind width.
With
#+ATTR_LATEX: :options scale=1.5 :width "" :placement [htb!]
it fails here
(attr (org-export-read-attribute :attr_latex parent))
which evalues to something like
Result: (:options "scale=1.5" :placement "[htb!]" :width "")
when it doesn't crash.
Perhaps, I'll have time to look at it later, but probably Nicolas is
the right guy for the job.
> Very helpful: thanks for the elucidation!
Thanks you to you too!
–Rasmus
--
Enough with the bla bla!
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: bug in new exporter
2013-06-03 22:12 ` Rasmus
@ 2013-06-05 12:26 ` Nicolas Goaziou
2013-06-05 16:28 ` Nick Dokos
0 siblings, 1 reply; 14+ messages in thread
From: Nicolas Goaziou @ 2013-06-05 12:26 UTC (permalink / raw)
To: Rasmus; +Cc: emacs-orgmode
Hello,
Rasmus <rasmus@gmx.us> writes:
> Nick Dokos <ndokos@gmail.com> writes:
>> if I rearrange the line to
>>
>> #+ATTR_LATEX: :width "" :placement [htb!] :options scale=1.5
>>
>> I get the "Wrong argument type" error in the current version as
>> well.
>
> I can reproduce this here.
>
>> I guess :width has to be after the :options ?!? I don't quite
>> understand the rules I guess.
>
> Neither do I in this case. I'm guessing it has do with the "escaping"
> of "" 'cause it also fails if you :placement behind width.
>
> With
>
> #+ATTR_LATEX: :options scale=1.5 :width "" :placement [htb!]
> it fails here
> (attr (org-export-read-attribute :attr_latex parent))
>
> which evalues to something like
>
> Result: (:options "scale=1.5" :placement "[htb!]" :width "")
>
> when it doesn't crash.
This bug should be fixed in maint. Thanks to both of you for identifying
it.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug in new exporter
2013-06-05 12:26 ` Nicolas Goaziou
@ 2013-06-05 16:28 ` Nick Dokos
2013-06-05 21:45 ` Nick Dokos
2013-06-11 12:05 ` Nicolas Goaziou
0 siblings, 2 replies; 14+ messages in thread
From: Nick Dokos @ 2013-06-05 16:28 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> With
>>
>> #+ATTR_LATEX: :options scale=1.5 :width "" :placement [htb!]
>> it fails here
>> (attr (org-export-read-attribute :attr_latex parent))
>>
>> which evalues to something like
>>
>> Result: (:options "scale=1.5" :placement "[htb!]" :width "")
>>
>> when it doesn't crash.
>
> This bug should be fixed in maint. Thanks to both of you for identifying
> it.
>
And also in master, correct? I can never remember who goes first.
In any case, I updated from master and checked: it works with the :width
option anywhere in the sequence of options, so it does seem to be fixed.
In all cases, there is no width specification, just the scale, on the
\includegraphics - and no error.
Just a heads-up: As part of testing this, I stumbled on an unrelated
current-working-directory problem, where on exporting to pdf, the
pdflatex of the produced tex file fails to find an image file specified
with a relative pathname (it works fine with an absolute path name). The
tex file looks OK and I can process it from the command line. I'll try
to pin this down more precisely, but do I understand correctly that the
processing of the tex file should take place with the current working
directory set to the directory of the org file?
Thanks!
--
Nick
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug in new exporter
2013-06-05 16:28 ` Nick Dokos
@ 2013-06-05 21:45 ` Nick Dokos
2013-06-11 12:08 ` Nicolas Goaziou
2013-06-11 12:05 ` Nicolas Goaziou
1 sibling, 1 reply; 14+ messages in thread
From: Nick Dokos @ 2013-06-05 21:45 UTC (permalink / raw)
To: emacs-orgmode
Nick Dokos <ndokos@gmail.com> writes:
> Just a heads-up: As part of testing this, I stumbled on an unrelated
> current-working-directory problem, where on exporting to pdf, the
> pdflatex of the produced tex file fails to find an image file specified
> with a relative pathname (it works fine with an absolute path name). The
> tex file looks OK and I can process it from the command line. I'll try
> to pin this down more precisely, but do I understand correctly that the
> processing of the tex file should take place with the current working
> directory set to the directory of the org file?
>
The problem was that I had customized my org-latex-pdf-process to the
texi2dvi recommended value:
texi2dvi -p -b -c -V %f
The -c (equivalently: --clean or --build=clean) breaks relative paths
because texi2dvi executes in a different directory. The *Org PDF LaTeX
Output* buffer shows
/usr/bin/texi2dvi: cd /home/nick/src/org/latex/foo.t2d/pdf/build
whereas the org file was in /home/nick/src/org/latex.
If you use texi2dvi, beware of -c (and also --tidy I presume).
So nothing to do with org, but maybe the customization option should not
include the -c.
--
Nick
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: bug in new exporter
2013-06-05 21:45 ` Nick Dokos
@ 2013-06-11 12:08 ` Nicolas Goaziou
2013-06-11 17:09 ` Nick Dokos
0 siblings, 1 reply; 14+ messages in thread
From: Nicolas Goaziou @ 2013-06-11 12:08 UTC (permalink / raw)
To: Nick Dokos; +Cc: emacs-orgmode
Nick Dokos <ndokos@gmail.com> writes:
> Nick Dokos <ndokos@gmail.com> writes:
>
>> Just a heads-up: As part of testing this, I stumbled on an unrelated
>> current-working-directory problem, where on exporting to pdf, the
>> pdflatex of the produced tex file fails to find an image file specified
>> with a relative pathname (it works fine with an absolute path name). The
>> tex file looks OK and I can process it from the command line. I'll try
>> to pin this down more precisely, but do I understand correctly that the
>> processing of the tex file should take place with the current working
>> directory set to the directory of the org file?
>>
>
> The problem was that I had customized my org-latex-pdf-process to the
> texi2dvi recommended value:
>
> texi2dvi -p -b -c -V %f
>
> The -c (equivalently: --clean or --build=clean) breaks relative paths
> because texi2dvi executes in a different directory. The *Org PDF LaTeX
> Output* buffer shows
>
> /usr/bin/texi2dvi: cd /home/nick/src/org/latex/foo.t2d/pdf/build
>
> whereas the org file was in /home/nick/src/org/latex.
>
> If you use texi2dvi, beware of -c (and also --tidy I presume).
>
> So nothing to do with org, but maybe the customization option should not
> include the -c.
I also use texi2dvi, but I don't have any compilation problem with
images, even with a relative path.
Would you mind providing an ECM for that?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug in new exporter
2013-06-11 12:08 ` Nicolas Goaziou
@ 2013-06-11 17:09 ` Nick Dokos
2013-06-16 20:53 ` Nicolas Goaziou
0 siblings, 1 reply; 14+ messages in thread
From: Nick Dokos @ 2013-06-11 17:09 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Nick Dokos <ndokos@gmail.com> writes:
>
>> Nick Dokos <ndokos@gmail.com> writes:
>>
>>> Just a heads-up: As part of testing this, I stumbled on an unrelated
>>> current-working-directory problem, where on exporting to pdf, the
>>> pdflatex of the produced tex file fails to find an image file specified
>>> with a relative pathname (it works fine with an absolute path name). The
>>> tex file looks OK and I can process it from the command line. I'll try
>>> to pin this down more precisely, but do I understand correctly that the
>>> processing of the tex file should take place with the current working
>>> directory set to the directory of the org file?
>>>
>>
>> The problem was that I had customized my org-latex-pdf-process to the
>> texi2dvi recommended value:
>>
>> texi2dvi -p -b -c -V %f
>>
>> The -c (equivalently: --clean or --build=clean) breaks relative paths
>> because texi2dvi executes in a different directory. The *Org PDF LaTeX
>> Output* buffer shows
>>
>> /usr/bin/texi2dvi: cd /home/nick/src/org/latex/foo.t2d/pdf/build
>>
>> whereas the org file was in /home/nick/src/org/latex.
>>
>> If you use texi2dvi, beware of -c (and also --tidy I presume).
>>
>> So nothing to do with org, but maybe the customization option should not
>> include the -c.
>
> I also use texi2dvi, but I don't have any compilation problem with
> images, even with a relative path.
>
> Would you mind providing an ECM for that?
>
Please find an org file and the corresponding tex file attached. The
directory structure is as follows:
~/src/org--images--foo.png
|
|--latex--example.{org,tex}
|
|--example.t2d/pdf/build
Just executing
--8<---------------cut here---------------start------------->8---
texi2dvi -p -b -c -V example.tex
--8<---------------cut here---------------end--------------->8---
from the command line produces the error:
,----
| /usr/bin/texi2dvi: cd /home/nick/src/org/latex/example.t2d/pdf/build
| ...
| LaTeX Warning: File `../images/foo.png' not found on input line 37.
|
|
| /home/nick/src/org/latex/./example.tex:37: Package pdftex.def Error: File
| `../images/foo.png' not found.
|
| See the pdftex.def package documentation for explanation.
| Type H <return> for immediate help.
| ...
|
| l.37 ...ludegraphics[scale=1.5]{../images/foo.png}
| ...
`----
Note the top line in the excerpt above. Taking out the -c gets rid of
the error (at the price of leaving all the toc/aux/log/etc files around
of course). --tidy exhibits the same symptom.
Org-mode version 8.0.3 (release_8.0.3-197-g221768 @
/home/nick/elisp/org-mode/lisp/)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: example.org --]
[-- Type: text/x-org, Size: 139 bytes --]
#+OPTIONS: timestamp:nil
* foo
#+caption: foo
#+attr_latex: :placement [htb!] :options scale=1.5 :width ""
[[file:../images/foo.png]]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: example.tex --]
[-- Type: text/x-tex, Size: 787 bytes --]
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage[nointegrals]{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{amstext}
\usepackage{hyperref}
\tolerance=1000
\usepackage{minted}
\author{Nick Dokos}
\date{\today}
\title{example}
\hypersetup{
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 24.3.50.1 (Org mode 8.0.3)}}
\begin{document}
\maketitle
\tableofcontents
\section{foo}
\label{sec-1}
\begin{figure}[htb!]
\centering
\includegraphics[scale=1.5]{../images/foo.png}
\caption{foo}
\end{figure}
% Emacs 24.3.50.1 (Org mode 8.0.3)
\end{document}
[-- Attachment #4: Type: text/plain, Size: 19 bytes --]
--
Nick
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: bug in new exporter
2013-06-11 17:09 ` Nick Dokos
@ 2013-06-16 20:53 ` Nicolas Goaziou
0 siblings, 0 replies; 14+ messages in thread
From: Nicolas Goaziou @ 2013-06-16 20:53 UTC (permalink / raw)
To: Nick Dokos; +Cc: emacs-orgmode
Hello,
Nick Dokos <ndokos@gmail.com> writes:
> Please find an org file and the corresponding tex file attached. The
> directory structure is as follows:
>
> ~/src/org--images--foo.png
> |
> |--latex--example.{org,tex}
> |
> |--example.t2d/pdf/build
>
> Just executing
>
> texi2dvi -p -b -c -V example.tex
>
> from the command line produces the error:
>
> ,----
> | /usr/bin/texi2dvi: cd /home/nick/src/org/latex/example.t2d/pdf/build
> | ...
> | LaTeX Warning: File `../images/foo.png' not found on input line 37.
> |
> |
> | /home/nick/src/org/latex/./example.tex:37: Package pdftex.def Error: File
> | `../images/foo.png' not found.n
> |
> | See the pdftex.def package documentation for explanation.
> | Type H <return> for immediate help.
> | ...
> |
> | l.37 ...ludegraphics[scale=1.5]{../images/foo.png}
> | ...
> `----
>
> Note the top line in the excerpt above. Taking out the -c gets rid of
> the error (at the price of leaving all the toc/aux/log/etc files around
> of course). --tidy exhibits the same symptom.
I removed "-c" argument from "texi2dvi" command. Thank you for the
detailed report.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug in new exporter
2013-06-05 16:28 ` Nick Dokos
2013-06-05 21:45 ` Nick Dokos
@ 2013-06-11 12:05 ` Nicolas Goaziou
1 sibling, 0 replies; 14+ messages in thread
From: Nicolas Goaziou @ 2013-06-11 12:05 UTC (permalink / raw)
To: Nick Dokos; +Cc: emacs-orgmode
Hello,
Nick Dokos <ndokos@gmail.com> writes:
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>>> With
>>>
>>> #+ATTR_LATEX: :options scale=1.5 :width "" :placement [htb!]
>>> it fails here
>>> (attr (org-export-read-attribute :attr_latex parent))
>>>
>>> which evalues to something like
>>>
>>> Result: (:options "scale=1.5" :placement "[htb!]" :width "")
>>>
>>> when it doesn't crash.
>>
>> This bug should be fixed in maint. Thanks to both of you for identifying
>> it.
>>
>
> And also in master, correct? I can never remember who goes first.
Correct.
Basically, if current version is "a.b.c", a change in maint will appear
in "a.b.c+1" whereas a change in master will appear in "a.b+1".
> Just a heads-up: As part of testing this, I stumbled on an unrelated
> current-working-directory problem, where on exporting to pdf, the
> pdflatex of the produced tex file fails to find an image file
> specified with a relative pathname (it works fine with an absolute
> path name). The tex file looks OK and I can process it from the
> command line. I'll try to pin this down more precisely,
Problem probably comes from `org-latex-compile'.
> but do I understand correctly that the processing of the tex file
> should take place with the current working directory set to the
> directory of the org file?
Yes.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug in new exporter
@ 2013-06-03 17:22 Marvin Doyley
0 siblings, 0 replies; 14+ messages in thread
From: Marvin Doyley @ 2013-06-03 17:22 UTC (permalink / raw)
To: rasmus; +Cc: emacs-orgmode@gnu.org
Hi Rasmus,
It is still not behaving properly
#+ATTR_LATEX: :options scale=2
[[file:fig.pdf]]
yields
\begin{figure}[htb]
\centering
\includegraphics[scale=2,width=.9\linewidth]{fig.pdf}
\end{figure}
which is still not quite right, including option, this still doesn't remove the extra width =0.9\linewidth :(
cheers
M
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-06-16 20:53 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-03 15:50 bug in new exporter Marvin Doyley
2013-06-03 16:25 ` Rasmus
2013-06-03 17:42 ` Nick Dokos
2013-06-03 20:23 ` Rasmus
2013-06-03 21:03 ` Nick Dokos
2013-06-03 22:12 ` Rasmus
2013-06-05 12:26 ` Nicolas Goaziou
2013-06-05 16:28 ` Nick Dokos
2013-06-05 21:45 ` Nick Dokos
2013-06-11 12:08 ` Nicolas Goaziou
2013-06-11 17:09 ` Nick Dokos
2013-06-16 20:53 ` Nicolas Goaziou
2013-06-11 12:05 ` Nicolas Goaziou
-- strict thread matches above, loose matches on Subject: below --
2013-06-03 17:22 Marvin Doyley
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).