From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: LaTeX export of images Date: Tue, 29 Sep 2009 15:32:42 -0400 Message-ID: <8809.1254252762@alphaville.usa.hp.com> References: <87pr9jf68i.fsf@missioncriticalit.com> <10AD8929-948F-4985-8E26-F49C0DF525A7@gmail.com> Reply-To: nicholas.dokos@hp.com Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsiSC-0005DY-F2 for emacs-orgmode@gnu.org; Tue, 29 Sep 2009 15:33:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsiS7-0005Bn-T9 for emacs-orgmode@gnu.org; Tue, 29 Sep 2009 15:33:40 -0400 Received: from [199.232.76.173] (port=55679 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsiS7-0005Bj-E4 for emacs-orgmode@gnu.org; Tue, 29 Sep 2009 15:33:35 -0400 Received: from g4t0015.houston.hp.com ([15.201.24.18]:42384) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MsiS6-00067e-Ui for emacs-orgmode@gnu.org; Tue, 29 Sep 2009 15:33:35 -0400 In-Reply-To: Message from Carsten Dominik of "Tue, 29 Sep 2009 11:28:59 +0200." <10AD8929-948F-4985-8E26-F49C0DF525A7@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: mailing-list-org-mode Carsten Dominik wrote: > > 1) Images in the middle of the text > > > > If I have the following example: > > > > ,---- > > | For this example, I will use this image [[myimage.png]] which > > is a very good one. > > `---- > > > > Then, when exported, it produces the following LaTeX code: > > > > ,---- > > | For this example, I will the use this image > > | \centerline{\includegraphics{myimage}} which is a very good one. > > `---- > > > > Which produces weird layout when compiled to PDF. > > > > In this case, we should just generate \includegraphics{myimage} > > without the > > centerline command. > > Agree. > > > > 2) Images in floats > > > > In the case of floats, the correct generated code should be > > something like: > > > > \begin{figure}[htb] > > \centering > > \includegraphics{myimage} > > \label{LABEL} > > \caption{CAPTION} > > \end{figure} > > > > and not > > > > \begin{figure}[htb] > > \centerline{\includegraphics{myimage}} > > \label{LABEL} > > \caption{CAPTION} > > \end{figure} > > > > This can also be fixed quickly I think. > > Yes sure, but what is wrong with \centerline? does the \centering > lead to a different result? > 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. diff --git a/lisp/org-latex.el b/lisp/org-latex.el index 4058891..248d653 100644 --- a/lisp/org-latex.el +++ b/lisp/org-latex.el @@ -1553,8 +1585,8 @@ The conversion is made depending of STRING-BEFORE and STRING-AFTER." (cond ((and imgp (plist-get org-export-latex-options-plist :inline-images)) (insert (concat - (if floatp "\\begin{figure}[htb]\n") - (format "\\centerline{\\includegraphics[%s]{%s}}\n" + (if floatp "\\begin{figure}[htb]\n\\centering\n") + (format "\\includegraphics[%s]{%s}\n" attr (if (file-name-absolute-p raw-path) (expand-file-name raw-path) @@ -1563,7 +1595,7 @@ The conversion is made depending of STRING-BEFORE and STRING-AFTER." (format "\\caption{%s%s}\n" (if label (concat "\\label{" label "}") "") (or caption ""))) - (if floatp "\\end{figure}\n")))) + (if floatp "\\end{figure}")))) (coderefp (insert (format (org-export-get-coderef-format path desc) But there is the additional question that's raised in the thread: Carsten Dominik wrote: > > On Sep 23, 2009, at 11:09 PM, S=E9bastien Vauban wrote: > > > Jeff Kowalczyk wrote: > >> S=E9bastien Vauban writes: > >>> Francesco Pizzolante wrote: > >>>> In this case, we should just generate \includegraphics{myimage} =20 > >>>> without > >>>> the centerline command. > >>> > >>> Given the output of the `\centerline' command, I guess that the =20 > >>> inlining of > >>> an image inside a line of text is not supported as is by Org. I =20 > >>> can second > >>> such a choice. > >> > >> +1 for default to inline graphics. When using Org for How-To and =20 > >> project > >> documentation delivered as PDF, floating screenshot-size images =20 > >> typically > >> situate far from the descriptive text. > > > > My point was mainly that, IMHO, floating or not should not be tied =20 > > to the > > presence or absence of caption/label. > > > > Your problem with screenshots far away should be solved by putting =20 > > the H > > specifier to the float environment and loading the `float' package. > > > > > >> I would prefer inline images by default (or option), and a file/=20 > >> subtree > >> level option to use LaTeX floating layout. > > > > That'd be a great way to be able to specify which type of "inlining" =20= > > > we want. > > On a per file basis seems sufficient for me. > > Hi Sebastien, > > how about working out a detailed proposal how this should work? > > - Carsten > > Currently, specifying either a #+CAPTION or a #+LABEL (or both) floats the image. Absent both of these the image is inlined (although without the above patch, it's inlined badly). LaTeX implicitly assumes that a floating figure has a caption: that's where the figure number is incremented for example. Given that, it does not seem productive to have a separate indicator for floats. Of course, if one is willing to forego the incrementing of the counter, then a float without a caption is possible in LaTeX - but is it useful? If it is, then using the #+LABEL specifier alone is enough to float the image (but currently, there is a problem in org-latex in that a \caption is always output - but that is a minor problem, easily fixed, if so desired). To summarize: org-latex currently always produces a \caption which causes LaTeX to increment the figure counter, but also to produce a "Figure :" caption, even if the caption is empty. We could change org-latex not to produce a \caption if #+CAPTION is absent, but that would mean that the figure counter does not get incremented. I'm not sure that a saparate specifier is needed (it might be desirable only on readability grounds: saying #+FLOAT, rather than #+CAPTION or #+LABEL makes it a bit more obvious). These specifiers are per-image, afaict, not per-file/subtree. For my part, I don't see the need for the coarser kind of control: per-image is enough. But if desired, then maybe #+FLOAT: t (default nil) or perhaps better #+OPTIONS: float:t can be used for the coarser control. I hope this is clear but if there are questions, let me know. What do you think? Thanks, Nick