Re: bug in new exporter

Re: bug in new exporter

[Marvin Doyley]

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

bug in new exporter

[Marvin Doyley]

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

Re: bug in new exporter

[Rasmus]

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

Re: bug in new exporter

[Nick Dokos]

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

Re: bug in new exporter

[Rasmus]

>>> 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. . .

Re: bug in new exporter

[Nick Dokos]

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

Re: bug in new exporter

[Rasmus]

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!

Re: bug in new exporter

[Nicolas Goaziou]

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

Re: bug in new exporter

[Nick Dokos]

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

Re: bug in new exporter

[Nick Dokos]

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

Re: bug in new exporter

[Nicolas Goaziou]

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

Re: bug in new exporter

[Nick Dokos]

[-- 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

Re: bug in new exporter

[Nicolas Goaziou]

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

Re: bug in new exporter

[Nicolas Goaziou]

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