[ODT] image scaling overridden by long caption

[ODT] image scaling overridden by long caption

[Andreas Leha]

Hi all,

I experience unexpected behaviour with the excellent odt exporter in case of
included images.
When I add a #+caption the text width of that caption overrides the
specified image width (#ATTR_ODT: :witdh X), which I use to downscale
the image in the odt.
Especially if that caption will span across multiple lines, that effect
is visible.

Here is the example:

-----------------------------------------------------------------------
* odt image test
  #+caption: foo
  #+ATTR_ODT: :width 8
  #+header: :file foo.png
  #+header: :width 3600 :height 3600 :res 600
  #+begin_src R :exports results :results graphics
    plot(1:100, 1:100)
  #+end_src

  #+caption: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
  #+ATTR_ODT: :width 8
  #+header: :file foo.png
  #+header: :width 3600 :height 3600 :res 600
  #+begin_src R :exports results :results graphics
    plot(1:100, 1:100)
  #+end_src
-------------------------------------------------------------------------


I'd expect the image scaling to take place in either case.  Maybe even
the caption should wrap at the specified width.

On a related note:  Could I place two (correctly scaled) images
side-by-side?

Regards,
Andreas

Re: [ODT] image scaling overridden by long caption

[Jambunathan K]

Hello Andreas

> Hi all,
>
> I experience unexpected behaviour with the excellent odt exporter in case of
> included images.
> When I add a #+caption the text width of that caption overrides the
> specified image width (#ATTR_ODT: :witdh X), which I use to downscale
> the image in the odt.
> Especially if that caption will span across multiple lines, that effect
> is visible.
>
> Here is the example:
>
> -----------------------------------------------------------------------
> * odt image test
>   #+caption: foo
>   #+ATTR_ODT: :width 8
>   #+header: :file foo.png
>   #+header: :width 3600 :height 3600 :res 600
>   #+begin_src R :exports results :results graphics
>     plot(1:100, 1:100)
>   #+end_src
>   #+caption: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
>   #+ATTR_ODT: :width 8
>   #+header: :file foo.png
>   #+header: :width 3600 :height 3600 :res 600
>   #+begin_src R :exports results :results graphics
>     plot(1:100, 1:100)
>   #+end_src
> -------------------------------------------------------------------------
>
>
> I'd expect the image scaling to take place in either case.  Maybe even
> the caption should wrap at the specified width.

I have pushed a fix for this. Hope the new behaviour is according to
your expectation.

> On a related note:  Could I place two (correctly scaled) images
> side-by-side?

For the sake of record, your request is much similar to what is
discussed here
http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00780.html -
save for (dynamically-generated) images taking the place of src blocks.

Try something like this:

#+begin_list-table
- [[./foo1.png]]
  - [[./foo2.png]]
#+end_list-table

Make sure that the images are "small" images. If you replace the image
links above with R srcblocks or attach caption/attr_odt to the above
above images, the results are less than satisfactory. So the answer to
your question is a "soft" no.

Notes to self:

There are multiple ways to achieve side-by-side effect.
- use tables (aka "list tables")
- use 2-Column sections 
- 2-column frames (what is this?)

"side-by-side" has surfaced in the list for the second time, I think it
deserves to be supported "out of the box".

Jambunathan K.

Re: [ODT] image scaling overridden by long caption

[Andreas Leha]

Jambunathan K <kjambunathan@gmail.com> writes:

> Hello Andreas
>
>> Hi all,
>>
>> I experience unexpected behaviour with the excellent odt exporter in case of
>> included images.
>> When I add a #+caption the text width of that caption overrides the
>> specified image width (#ATTR_ODT: :witdh X), which I use to downscale
>> the image in the odt.
>> Especially if that caption will span across multiple lines, that effect
>> is visible.
>>
>> Here is the example:
>>
>> -----------------------------------------------------------------------
>> * odt image test
>>   #+caption: foo
>>   #+ATTR_ODT: :width 8
>>   #+header: :file foo.png
>>   #+header: :width 3600 :height 3600 :res 600
>>   #+begin_src R :exports results :results graphics
>>     plot(1:100, 1:100)
>>   #+end_src
>>   #+caption: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
>>   #+ATTR_ODT: :width 8
>>   #+header: :file foo.png
>>   #+header: :width 3600 :height 3600 :res 600
>>   #+begin_src R :exports results :results graphics
>>     plot(1:100, 1:100)
>>   #+end_src
>> -------------------------------------------------------------------------
>>
>>
>> I'd expect the image scaling to take place in either case.  Maybe even
>> the caption should wrap at the specified width.
>
> I have pushed a fix for this. Hope the new behaviour is according to
> your expectation.
>

Thanks a lot, this works fine now!

But I experienced another issue with respect to images scaling in the odt
export:

This subtree:

======== test.org ==========================
* Test image scaling in odt
#+caption: bar
#+label: fig:bar
#+name: bar
#+attr_odt: :width 8
#+header: :file bar.png
#+header: :width 7200 :height 3600 :res 600
#+begin_src R :exports results :results graphics
  plot(1:10, 1:10)
#+end_src

#+caption: baz
#+label: fig:baz
#+name: baz
#+attr_odt: :scale 0.5
#+header: :file baz.png
#+header: :width 7200 :height 3600 :res 600
#+begin_src R :exports results :results graphics
  plot(1:10, 1:10)
#+end_src
======================================

exports to this: http://i.imgur.com/sUHQi.png on my system.


>> On a related note:  Could I place two (correctly scaled) images
>> side-by-side?
>
> For the sake of record, your request is much similar to what is
> discussed here
> http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00780.html -
> save for (dynamically-generated) images taking the place of src blocks.
>
> Try something like this:
>
> #+begin_list-table
> - [[./foo1.png]]
>   - [[./foo2.png]]
> #+end_list-table
>
> Make sure that the images are "small" images. If you replace the image
> links above with R srcblocks or attach caption/attr_odt to the above
> above images, the results are less than satisfactory. So the answer to
> your question is a "soft" no.

Thanks for this.  For two reasons that does not work for me:
(1) I want to use captions on my images
(2) it is odt-export specific

>
> Notes to self:
>
> There are multiple ways to achieve side-by-side effect.
> - use tables (aka "list tables")
> - use 2-Column sections 
> - 2-column frames (what is this?)
>
> "side-by-side" has surfaced in the list for the second time, I think it
> deserves to be supported "out of the box".

+1.  And ideally generic enough, s.t. also the LaTeX supports it.
Beamer has the concept of columns, which is nicely supported in org
mode.  Maybe that could be a general concept supported by all (or, most)
exporters?

- Andreas


>
> Jambunathan K.

Side-by-side support (was:Re: [ODT] image scaling overridden by long caption)

[Christian Wittern]

On 2012-01-20 05:03, Jambunathan K wrote:
> "side-by-side" has surfaced in the list for the second time, I think it
> deserves to be supported "out of the box".
I strongly support this, since I have a lot of files with side-by-side 
content.  The first question is of course how does the org source look 
like.  In my case, I have simply separated the columns by a <tab> character 
and set the tab-width to a sensible value for nice on-screen display.  These 
are 'text' and 'translation of that text' side-by-side, sometimes 
interrupted by section headers, notes and so on.  Therefore I end up with 
multiple 'tables', which will need to have the same width throughout the 
document.  Therefore for this use-case, I would like to see a global setting 
for the relative width of these columns.

All the best,

Christian

Christian Wittern, Kyoto

Re: Side-by-side support

[Jambunathan K]

Hello Christian

Christian Wittern <cwittern@gmail.com> writes:

> On 2012-01-20 05:03, Jambunathan K wrote:
>> "side-by-side" has surfaced in the list for the second time, I think it
>> deserves to be supported "out of the box".

> I strongly support this, since I have a lot of files with side-by-side
> content.  The first question is of course how does the org source look
> like.

I think laying out tables either "list tables" (or for that matter, it's
"beamer equivalent") will become particularly "inconvenient" to edit. In
both the cases, the two-dimensional structure is laid out along the
single-dimension and it would become difficult to "remember" which
column or row when one is editing at a given point in time.

> In my case, I have simply separated the columns by a <tab> character
> and set the tab-width to a sensible value for nice on-screen display.
> These are 'text' and 'translation of that text' side-by-side,

When you are saying on-screen display, I presume you are referring to
the Emacs screen? I have a strong feeling that you are using two column
editing. Otherwise, it would be extremely difficult to keep one's
sanity.

See 

C-h k C-x 6 2 
(info "(emacs) Two-Column").

I have a wild-thought. Why not use use 2C editing for creating
multi-paragraph Org tables.

I am Ccing Nicolas (who is likely to have thought more about this stuff)
since the last conversation.

> sometimes interrupted by section headers, notes and so on. Therefore I
> end up with multiple 'tables', which will need to have the same width
> throughout the document.  Therefore for this use-case, I would like to
> see a global setting for the relative width of these columns.

-- 

Re: [ODT] image scaling overridden by long caption

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

Hello Andreas

I have added support for character anchored images as part of the
following commit release_7.8.03-201-g1d99fd7.

I am attaching a sample Org file and the associated ODT output.

Nicolas/Eric
Don't be surprised. Please Read on ...

--8<---------------cut here---------------start------------->8---
#+TITLE:     side-by-side.org
#+AUTHOR:    Jambunathan K
#+EMAIL:     kjambunathan@gmail.com
#+DATE:      2012-01-23 Mon
#+DESCRIPTION:
#+KEYWORDS:
#+LANGUAGE:  en
#+OPTIONS:   H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:dvipng skip:nil d:nil todo:t pri:nil tags:not-in-toc

#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+LINK_UP:   
#+LINK_HOME: 
#+XSLT:

Nicolas, 

Does the existing behaviour as captured in [[Side-by-Side images laid
out by hand]] be preserved with new export driver?

Eric, 

1. can the extraneous parbreaks in [[Side-by-Side images using Babel]] be
   removed?
2. Can [[http://lists.gnu.org/archive/html/emacs-orgmode/2012-01/msg00678.html][this issue with #+header lines ]] be fixed?

* Side-by-Side images using Babel

Creating side-by-side images with Babel is problematic.

#+caption: foo
#+ATTR_ODT: :width 7 :height 7 :anchor as-char
#+header: :file foo.png
#+begin_src R :exports results :results graphics
  plot(1:100, 1:100)
#+end_src
#+caption: foo
#+ATTR_ODT: :width 7 :height 7 :anchor as-char
#+header: :file foo.png
#+begin_src R :exports results :results graphics
  plot(1:100, 1:100)
#+end_src

The images are vertically stacked because Babel introduces extraneous
parbreaks. This forces the images to be anchored as character, but to
*successive* paragraphs.

Here is a segment of Org buffer as seen by the ODT exporter at the end
of =org-export-preprocess-string=.

#+BEGIN_SRC org
  ,Creating side-by-side images with Babel is problematic.
  
  
  
  ,[[file:foo.png][file:foo.png]]
  
  
  
  ,[[file:foo.png][file:foo.png]]
  
  ,The images are vertically stacked because Babel introduces extraneous
  ,parbreaks. This forces the images to be anchored as character, but to
  ,*successive* paragraphs.
  
#+END_SRC

* Side-by-Side images laid out by hand

To create side-by-side images flank them with paragraph boundaries.

#+BEGIN_CENTER
#+caption: foo
#+ATTR_ODT: :width 7 :height 7 :anchor as-char
#+header: :file foo.png
[[./foo.png]]
#+caption: bar
#+ATTR_ODT: :width 7 :height 7 :anchor as-char
#+header: :file bar.png
[[./bar.png]]
#+END_CENTER

You should be seeing side-by-side images.
--8<---------------cut here---------------end--------------->8---


[-- Attachment #2: side-by-side.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 24202 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1382 bytes --]



>>> On a related note:  Could I place two (correctly scaled) images
>>> side-by-side?
>>
>> For the sake of record, your request is much similar to what is
>> discussed here
>> http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00780.html -
>> save for (dynamically-generated) images taking the place of src blocks.
>>
>> Try something like this:
>>
>> #+begin_list-table
>> - [[./foo1.png]]
>>   - [[./foo2.png]]
>> #+end_list-table
>>
>> Make sure that the images are "small" images. If you replace the image
>> links above with R srcblocks or attach caption/attr_odt to the above
>> above images, the results are less than satisfactory. So the answer to
>> your question is a "soft" no.
>
> Thanks for this.  For two reasons that does not work for me:
> (1) I want to use captions on my images
> (2) it is odt-export specific
>
>>
>> Notes to self:
>>
>> There are multiple ways to achieve side-by-side effect.
>> - use tables (aka "list tables")
>> - use 2-Column sections 
>> - 2-column frames (what is this?)
>>
>> "side-by-side" has surfaced in the list for the second time, I think it
>> deserves to be supported "out of the box".
>
> +1.  And ideally generic enough, s.t. also the LaTeX supports it.
> Beamer has the concept of columns, which is nicely supported in org
> mode.  Maybe that could be a general concept supported by all (or, most)
> exporters?

-- 

Re: [ODT] image scaling overridden by long caption

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> Does the existing behaviour as captured in [[Side-by-Side images laid
> out by hand]] be preserved with new export driver?

I'm not sure to get the syntax right, but in the new exporter, you can
see what is the next or previous element, along with its
properties. Thus, you can detect when two paragraphs are back to back,
if they have appropriate :attr_latex properties and if they are enclosed
in a parent center-block element.

The check could be done at the paragraph level, and, if positive,
org-odt-paragraph could return the <draw:fram
draw:style....>...</draw:frame> string.

Am I missing something?


Regards,

-- 
Nicolas Goaziou

Re: Side-by-side support

[Christian Wittern]

Hi Jambunathan,

On 2012-01-24 01:34, Jambunathan K wrote:
>
>> In my case, I have simply separated the columns by a<tab>  character
>> and set the tab-width to a sensible value for nice on-screen display.
>> These are 'text' and 'translation of that text' side-by-side,
> When you are saying on-screen display, I presume you are referring to
> the Emacs screen? I have a strong feeling that you are using two column
> editing. Otherwise, it would be extremely difficult to keep one's
> sanity.
Actually I started out using 2C editing for this, but it came constantly in 
my way, so currently what I am doing is:
(1) use a tab character to separate the two columns and
(2) set the tab-width to 30 (in most cases), so that most of the columns are 
nicely separated.

This works very well for editing in Emacs.  However, at the moment I do not 
have an easy way to export this to ODT as it s.  Now I have given further 
thought to this, maybe the following will work:
(1) consecutive lines with 1 or more <tab> characters and the *same* number 
of such <tab>s will be considered as a table and the exporter will work with 
this as if it were a org-table. (Note that I usually only have two columns 
and as you said, with more columns one is probably better off using proper 
tables)
(2) This option is switched on or off through a variable or a OPTION line in 
the header of the file.
(3) as I mentioned earlier, it would be good to be also able to globally set 
the proportions (maybe this can already be done with column properties?)

All the best,

Christian

-- 
Christian Wittern, Kyoto

Re: [ODT] image scaling overridden by long caption

[Jambunathan K]

Hello Andreas

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
> But I experienced another issue with respect to images scaling in the odt
> export:
>
> This subtree:
>
> ======== test.org ==========================
> * Test image scaling in odt
> #+caption: bar
> #+label: fig:bar
> #+name: bar
> #+attr_odt: :width 8
> #+header: :file bar.png
> #+header: :width 7200 :height 3600 :res 600
> #+begin_src R :exports results :results graphics
>   plot(1:10, 1:10)
> #+end_src
> #+caption: baz
> #+label: fig:baz
> #+name: baz
> #+attr_odt: :scale 0.5
> #+header: :file baz.png
> #+header: :width 7200 :height 3600 :res 600
> #+begin_src R :exports results :results graphics
>   plot(1:10, 1:10)
> #+end_src
> ======================================
>
> exports to this: http://i.imgur.com/sUHQi.png on my system.

I am on a Netbook and I am unable to create "big" images. This is the
following error I get when export the above snippet.

,---- "*Org-Babel Error Output*"
| Error in png(filename = "baz.png", height = 3600, res = 600, width = 7200) : 
|   unable to start device
| Calls: <Anonymous> -> <Anonymous> -> png -> .External
| In addition: Warning messages:
| 1: In png(filename = "baz.png", height = 3600, res = 600, width = 7200) :
|   Unable to allocate bitmap
| 2: In png(filename = "baz.png", height = 3600, res = 600, width = 7200) :
|   opening device failed
| Execution halted
`----

If I reduce the dimensions of the above images, I see that the ODT
output is along expected lines.

I imagine that for some reasons, the ODT exporter has trouble figuring
out the image dimensions of the second image.

Btw, can you post the outputs of the following forms:

#+begin_src emacs-lisp
  (list (* max-image-size (frame-pixel-width)) 
        (* max-image-size (frame-pixel-height)))
#+end_src

#+begin_src emacs-lisp
    (message "%S" (ignore-errors 
                    (image-size (create-image "bar.png") 'pixels)))
    (message "%S" (ignore-errors 
                    (image-size (create-image "baz.png") 'pixels)))
#+end_src

If you can also post the output of the XML created in your machines, I
would be able to infer what could be happening. 

You can access the XML with:

open odt file in archive-mode: C-x b test.odt or C-x C-f test.odt
open content.xml	     : ENTER on content.xml
search for .png              : C-s .png

Post the snippets for both 001.png and 002.png

-- 

Re: [ODT] image scaling overridden by long caption

[Andreas Leha]

Jambunathan K <kjambunathan@gmail.com> writes:

Hi Jambunathan,

thanks for looking into this.  Answer to your questions below

> Hello Andreas
>
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>> But I experienced another issue with respect to images scaling in the odt
>> export:
>>
>> This subtree:
>>
>> ======== test.org ==========================
>> * Test image scaling in odt
>> #+caption: bar
>> #+label: fig:bar
>> #+name: bar
>> #+attr_odt: :width 8
>> #+header: :file bar.png
>> #+header: :width 7200 :height 3600 :res 600
>> #+begin_src R :exports results :results graphics
>>   plot(1:10, 1:10)
>> #+end_src
>> #+caption: baz
>> #+label: fig:baz
>> #+name: baz
>> #+attr_odt: :scale 0.5
>> #+header: :file baz.png
>> #+header: :width 7200 :height 3600 :res 600
>> #+begin_src R :exports results :results graphics
>>   plot(1:10, 1:10)
>> #+end_src
>> ======================================
>>
>> exports to this: http://i.imgur.com/sUHQi.png on my system.
>
> I am on a Netbook and I am unable to create "big" images. This is the
> following error I get when export the above snippet.
>
> ,---- "*Org-Babel Error Output*"
> | Error in png(filename = "baz.png", height = 3600, res = 600, width = 7200) : 
> |   unable to start device
> | Calls: <Anonymous> -> <Anonymous> -> png -> .External
> | In addition: Warning messages:
> | 1: In png(filename = "baz.png", height = 3600, res = 600, width = 7200) :
> |   Unable to allocate bitmap
> | 2: In png(filename = "baz.png", height = 3600, res = 600, width = 7200) :
> |   opening device failed
> | Execution halted
> `----
>
> If I reduce the dimensions of the above images, I see that the ODT
> output is along expected lines.
>
> I imagine that for some reasons, the ODT exporter has trouble figuring
> out the image dimensions of the second image.
>
> Btw, can you post the outputs of the following forms:
>
> #+begin_src emacs-lisp
>   (list (* max-image-size (frame-pixel-width)) 
>         (* max-image-size (frame-pixel-height)))
> #+end_src

#+results:
| 3648.0 | 4320.0 |

> #+begin_src emacs-lisp
>     (message "%S" (ignore-errors 
>                     (image-size (create-image "bar.png") 'pixels)))
>     (message "%S" (ignore-errors 
>                     (image-size (create-image "baz.png") 'pixels)))
> #+end_src

#+results:
: (30 . 30)

>
> If you can also post the output of the XML created in your machines, I
> would be able to infer what could be happening. 
>
> You can access the XML with:
>
> open odt file in archive-mode: C-x b test.odt or C-x C-f test.odt
> open content.xml	     : ENTER on content.xml
> search for .png              : C-s .png
>
> Post the snippets for both 001.png and 002.png

#+begin_html
<text:p text:style-name="Text_20_body">

<draw:frame draw:style-name="OrgImageCaptionFrame" svg:width="8.00cm" text:anchor-type="paragraph"><draw:text-box  fo:min-height="8.00cm"><text:p text:style-name="Illustration"><draw:frame draw:style-name="OrgCaptionedImage" svg:width="8.00cm" svg:height="8.00cm" style:rel-width="100%" style:rel-height="scale" text:anchor-type="paragraph"><draw:image xlink:href="Images/0001.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/></draw:frame>Figure <text:sequence text:ref-name="fig:bar" text:name="Figure" text:formula="ooow:Figure+1" style:num-format="1">1</text:sequence>: bar</text:p></draw:text-box></draw:frame>

</text:p>





<text:p text:style-name="Text_20_body">

<draw:frame draw:style-name="OrgImageCaptionFrame" svg:width="0.53cm" text:anchor-type="paragraph"><draw:text-box  fo:min-height="0.53cm"><text:p text:style-name="Illustration"><draw:frame draw:style-name="OrgCaptionedImage" svg:width="0.53cm" svg:height="0.53cm" style:rel-width="100%" style:rel-height="scale" text:anchor-type="paragraph"><draw:image xlink:href="Images/0002.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/></draw:frame>Figure <text:sequence text:ref-name="fig:baz" text:name="Figure" text:formula="ooow:Figure+1" style:num-format="1">2</text:sequence>: baz</text:p></draw:text-box></draw:frame>

</text:p>

#+end_html


Best,
Andreas

Re: [ODT] image scaling overridden by long caption

[Jambunathan K]

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:


>>> #+label: fig:baz
>>> #+name: baz
>>> #+attr_odt: :scale 0.5
>>> #+header: :file baz.png
>>> #+header: :width 7200 :height 3600 :res 600
>>> #+begin_src R :exports results :results graphics
>>>   plot(1:10, 1:10)
>>> #+end_src

Image that R outputs is 7200-by-3600.

>> #+begin_src emacs-lisp
>>   (list (* max-image-size (frame-pixel-width)) 
>>         (* max-image-size (frame-pixel-height)))
>> #+end_src
>
> #+results:
> | 3648.0 | 4320.0 |

Emacs will "refuse to load" images that cannot fit in 3640-by-4320
area. Note that max-image dimensions is "tightly coupled" with the frame
size.

>> #+begin_src emacs-lisp
>>     (message "%S" (ignore-errors 
>>                     (image-size (create-image "baz.png") 'pixels)))
>> #+end_src
>
> #+results:
> : (30 . 30)

Instead of loading a large image, Emacs tries to create a "safe"
30-by-30 pixel area (whatver it is).

The solution is to instruct Emacs to handle higher image sizes. Just
bump the value of max-image-size. For example, add this to init file.

#+begin_src emacs-lisp
  (setq max-image-size (* 2 max-image-size)) ;; modify scale 
#+end_src

Side note:
==========

If you have imagemagick on your machine(s) and "identify" program is in
your load path,

#+begin_src emacs-lisp
  (executable-find "identify")
#+end_src

you can configure ODT export to use imagemagick as primary source for
 probing image dimensions. This you can do by adding the following to
 your .emacs.

#+begin_src emacs-lisp
  (setq org-export-odt-image-size-probe-method '(imagemagick force))
#+end_src

Ps: If you happen to try out imagemagick-only setting, let me know if
you run in to any issues. You will be the first person (that I know of)
to try it out.
-- 

comments and attributes

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Does the existing behaviour as captured in [[Side-by-Side images laid
>> out by hand]] be preserved with new export driver?
>
> I'm not sure to get the syntax right, but in the new exporter, you can
> see what is the next or previous element, along with its
> properties. Thus, you can detect when two paragraphs are back to back,
> if they have appropriate :attr_latex properties and if they are enclosed
> in a parent center-block element.
>
> The check could be done at the paragraph level, and, if positive,
> org-odt-paragraph could return the <draw:fram
> draw:style....>...</draw:frame> string.
>
> Am I missing something?

On a related note,

--8<---------------cut here---------------start------------->8---
* Example

This 
is 
a
single
# some comment
paragraph.


This 
is 
another
#+attr_odt: t
paragraph.
--8<---------------cut here---------------end--------------->8---

if I parse the above buffer, I get

#+begin_src emacs-lisp
  (paragraph
   (:begin 412 :end 431 :contents-begin 412 :contents-end 430 :post-blank 0)
   "This \nis \na\nsingle")
  (comment
   (:begin 431 :end 446 :value "# some comment\n" :post-blank 0))
  (paragraph
   (:begin 446 :end 459 :contents-begin 446 :contents-end 456 :post-blank 2)
   "paragraph.")
  (paragraph
   (:begin 459 :end 477 :contents-begin 459 :contents-end 476 :post-blank 0)
   "This \nis \nanother")
  (paragraph
   (:begin 477 :end 502 :contents-begin 491 :contents-end 501 :post-blank 0 :attr_odt
              ("t"))
   "paragraph.")
#+end_src

I see that the new export engine treats comment and control lines as par
breakers. The backends that are in production treats the first paragraph
as but a single paragraph.

There is already a way by which parbreaks can be introduced. Do you
think there could be some useful behaviour achieved - side by side
export of images came up in this thread - by not having commented
elements introduce parbreaks.

I am only brainstorming here. I hope the examples and use-case taken up
here help steer our discussion in a meaningful manner.

> Regards,

Re: comments and attributes

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> On a related note,
>
> * Example
>
> This 
> is 
> a
> single
> # some comment
> paragraph.
>
>
> This 
> is 
> another
> #+attr_odt: t
> paragraph.
>
> if I parse the above buffer, I get
>
> #+begin_src emacs-lisp
>   (paragraph
>    (:begin 412 :end 431 :contents-begin 412 :contents-end 430 :post-blank 0)
>    "This \nis \na\nsingle")
>   (comment
>    (:begin 431 :end 446 :value "# some comment\n" :post-blank 0))
>   (paragraph
>    (:begin 446 :end 459 :contents-begin 446 :contents-end 456 :post-blank 2)
>    "paragraph.")
>   (paragraph
>    (:begin 459 :end 477 :contents-begin 459 :contents-end 476 :post-blank 0)
>    "This \nis \nanother")
>   (paragraph
>    (:begin 477 :end 502 :contents-begin 491 :contents-end 501 :post-blank 0 :attr_odt
>               ("t"))
>    "paragraph.")
> #+end_src
>
> I see that the new export engine treats comment and control lines as par
> breakers. The backends that are in production treats the first paragraph
> as but a single paragraph.

Not the export engine, but the parser. Comment is an element type, as is
Paragraph. Beginning an element ends the previous one.

This has always been true in Org. For example, you may look at
`paragraph-start' and `paragraph-separate' values in an Org buffer:
comments (and many other things) are clearly separating and ending
paragraphs.

Also, it is consistent with other elements. Indeed, consider the
following example:

--8<---------------cut here---------------start------------->8---
: fixed-width line 1
# Commented line
: fixed-width line 2
--8<---------------cut here---------------end--------------->8---

If you use C-c ' on the first fixed-width line, you won't be offered to
edit also the second one.

Though, you're right, current exporter indeed ignores that Org feature.

> There is already a way by which parbreaks can be introduced. Do you
> think there could be some useful behaviour achieved - side by side
> export of images came up in this thread - by not having commented
> elements introduce parbreaks.

I think that it's a mistake to rely on comments to define semantics.

Anyway, I suggested something already about the problem of side by side
paragraphs. What was wrong with it? If it wasn't clear, I'll try to
provide an example. If it was flawed, we may try to improve it.


Regards,

-- 
Nicolas Goaziou

Re: [ODT] image scaling overridden by long caption

[Andreas Leha]

Jambunathan K <kjambunathan@gmail.com> writes:

> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>
>>>> #+label: fig:baz
>>>> #+name: baz
>>>> #+attr_odt: :scale 0.5
>>>> #+header: :file baz.png
>>>> #+header: :width 7200 :height 3600 :res 600
>>>> #+begin_src R :exports results :results graphics
>>>>   plot(1:10, 1:10)
>>>> #+end_src
>
> Image that R outputs is 7200-by-3600.
>
>>> #+begin_src emacs-lisp
>>>   (list (* max-image-size (frame-pixel-width)) 
>>>         (* max-image-size (frame-pixel-height)))
>>> #+end_src
>>
>> #+results:
>> | 3648.0 | 4320.0 |
>
> Emacs will "refuse to load" images that cannot fit in 3640-by-4320
> area. Note that max-image dimensions is "tightly coupled" with the frame
> size.
>
>>> #+begin_src emacs-lisp
>>>     (message "%S" (ignore-errors 
>>>                     (image-size (create-image "baz.png") 'pixels)))
>>> #+end_src
>>
>> #+results:
>> : (30 . 30)
>
> Instead of loading a large image, Emacs tries to create a "safe"
> 30-by-30 pixel area (whatver it is).
>
> The solution is to instruct Emacs to handle higher image sizes. Just
> bump the value of max-image-size. For example, add this to init file.
>
> #+begin_src emacs-lisp
>   (setq max-image-size (* 2 max-image-size)) ;; modify scale 
> #+end_src
>
> Side note:
> ==========
>
> If you have imagemagick on your machine(s) and "identify" program is in
> your load path,
>
> #+begin_src emacs-lisp
>   (executable-find "identify")
> #+end_src
>
> you can configure ODT export to use imagemagick as primary source for
>  probing image dimensions. This you can do by adding the following to
>  your .emacs.
>
> #+begin_src emacs-lisp
>   (setq org-export-odt-image-size-probe-method '(imagemagick force))
> #+end_src
>
> Ps: If you happen to try out imagemagick-only setting, let me know if
> you run in to any issues. You will be the first person (that I know of)
> to try it out.

Hi Jambunathan,

thanks for digging into this not-so-straight-forward issue.  And for the
detailed explanation.

I do indeed have imagemagick in my load path and the imagemagick-only
solution works fine in the cases I tried.  Thanks.

- Andreas

Re: [ODT] image scaling overridden by long caption

[Andreas Leha]

Jambunathan K <kjambunathan@gmail.com> writes:

> Hello Andreas
>
> I have added support for character anchored images as part of the
> following commit release_7.8.03-201-g1d99fd7.
>
> I am attaching a sample Org file and the associated ODT output.
>
> #+TITLE:     side-by-side.org
> #+AUTHOR:    Jambunathan K
> #+EMAIL:     kjambunathan@gmail.com
> #+DATE:      2012-01-23 Mon
> #+DESCRIPTION:
> #+KEYWORDS:
> #+LANGUAGE:  en
> #+OPTIONS:   H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
> #+OPTIONS:   TeX:t LaTeX:dvipng skip:nil d:nil todo:t pri:nil tags:not-in-toc
>
> #+EXPORT_SELECT_TAGS: export
> #+EXPORT_EXCLUDE_TAGS: noexport
> #+LINK_UP:   
> #+LINK_HOME: 
> #+XSLT:
>
> * Side-by-Side images using Babel
>
> Creating side-by-side images with Babel is problematic.
>
> #+caption: foo
> #+ATTR_ODT: :width 7 :height 7 :anchor as-char
> #+header: :file foo.png
> #+begin_src R :exports results :results graphics
>   plot(1:100, 1:100)
> #+end_src
> #+caption: foo
> #+ATTR_ODT: :width 7 :height 7 :anchor as-char
> #+header: :file foo.png
> #+begin_src R :exports results :results graphics
>   plot(1:100, 1:100)
> #+end_src
>

[...]

Hi Jambunathan,

thanks a lot for this.  This side-by-side placement is finally
something, that is better in the odt exporter than in the latex/pdf
route!

As I am not an office user, I have one question, though:  Is it
possible to change the alignment of the boxes such that they get
top-aligned?

See the included example to show why that is interesting to me.

(BTW: If exported to .doc, this .doc does it as expected...)

Regards,
Andreas

PS: The example:

,----[ test-side-by-side.org ]
| * Side-by-Side
| #+name: l_image
| #+header: :file limage.png
| #+begin_src R :exports results :results graphics
|   plot(1:10, 1:10)
| #+end_src
| 
| 
| #+name: r_image
| #+header: :file rimage.png
| #+begin_src R :exports results :results graphics
|   plot(1:10, 1:10)
| #+end_src
| 
| 
| #+caption: short caption
| #+attr_odt: :width 7 :anchor as-char
| #+results: l_image
[[| file:limage.png]]
| #+caption: longer caption that needs more lines then the other one to be printed on screen which causes not nice "bottom alignment".
| #+attr_odt: :width 7 :anchor as-char
| #+results: r_image
[[| file:rimage.png]]
`----