org-image-actual-width has no effect

org-image-actual-width has no effect

[Claudius Mueller]

Hello,

I have trouble getting org-mode to scale inline images. Using (setq 
org-image-actual-width 100) in my .emacs file has no effect on image size.

I am using emacs 24.3 in openSUSE 13.1. I have not compiled emacs 
myself, but the core imagemagick libraries are part of the dependencies, 
which makes me assume that it's been compiled with imagemagick support. 
I can display inline images of several file types just fine (tif, png, 
gif, ...).

Any idea what I'm missing? How can I make sure imagemagick support is 
enabled?

Thank you for any hints,
Claudius

Re: org-image-actual-width has no effect

[Charles Philip Chan]

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

On 28 Aug 2014, claudius.mueller@gmail.com wrote:

> I am using emacs 24.3 in openSUSE 13.1. I have not compiled emacs
> myself, but the core imagemagick libraries are part of the
> dependencies, which makes me assume that it's been compiled with
> imagemagick support.

No, the Emacs in OpenSuSE 13.1 is not compiled with Image Magick
support- "ldd /usr/bin/emacs | grep Magick" produces nothing. Where as,
this is the output of my self-compiled version.

,----[ ldd /usr/local/bin/emacs | grep Magick ]
| libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 (0x00007fe7e8072000)
| libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 (0x00007fe7e7bd3000
`----

> I can display inline images of several file types just fine (tif, png,
> gif, ...).

This is because Emacs is using libtiff, libjpeg, libpng, libxpm etc.

Charles

-- 
"I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you."
(By Vance Petree, Virginia Power)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: org-image-actual-width has no effect

[Claudius Mueller]

Thank you for pointing this out. I compiled emacs 24.3 with imagemagick 
support:

"ldd /usr/local/bin/emacs | grep Magick" ====>
libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 
(0x00007f3946278000)
libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 
(0x00007f3945dd9000)

However, inline images are still not scaled at all if I include:

(setq org-image-actual-width 50)

in my .emacs file.

Any other ideas of what I am doing wrong?

Thank you very much for your help!
Claudius

On 08/28/2014 07:50 PM, Charles Philip Chan wrote:
> On 28 Aug 2014, claudius.mueller@gmail.com wrote:
>
>> I am using emacs 24.3 in openSUSE 13.1. I have not compiled emacs
>> myself, but the core imagemagick libraries are part of the
>> dependencies, which makes me assume that it's been compiled with
>> imagemagick support.
> No, the Emacs in OpenSuSE 13.1 is not compiled with Image Magick
> support- "ldd /usr/bin/emacs | grep Magick" produces nothing. Where as,
> this is the output of my self-compiled version.
>
> ,----[ ldd /usr/local/bin/emacs | grep Magick ]
> | libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 (0x00007fe7e8072000)
> | libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 (0x00007fe7e7bd3000
> `----
>
>> I can display inline images of several file types just fine (tif, png,
>> gif, ...).
> This is because Emacs is using libtiff, libjpeg, libpng, libxpm etc.
>
> Charles
>

Re: org-image-actual-width has no effect

[Nick Dokos]

Claudius Mueller <claudius.mueller@gmail.com> writes:

> Thank you for pointing this out. I compiled emacs 24.3 with
> imagemagick support:
>
> "ldd /usr/local/bin/emacs | grep Magick" ====>
> libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1
> (0x00007f3946278000)
> libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1
> (0x00007f3945dd9000)
>
> However, inline images are still not scaled at all if I include:
>
> (setq org-image-actual-width 50)
>
> in my .emacs file.
>
> Any other ideas of what I am doing wrong?
>

Maybe check your *Messages* buffer for errors?

FWIW, it works fine here with the following file:

--8<---------------cut here---------------start------------->8---

* Inline images

This is a test: [[file:hello-world.png]]

#+BEGIN_SRC ditaa :file hello-world.png :cmdline -r
+--------------+
|              |
| Hello World! |
|              |
+--------------+
#+END_SRC

#+RESULTS:
[[file:hello-world.png]]


* image width

#+BEGIN_SRC emacs-lisp
(setq org-image-actual-width 50)
#+END_SRC

#+BEGIN_SRC emacs-lisp
(setq org-image-actual-width 500)
#+END_SRC


--8<---------------cut here---------------end--------------->8---

Depending on which emacs-lisp source block I evaluate, when I do C-c C-x
C-v afterwards, I get small images or large images.

Version info:
Fedora 20
GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.9) of 2014-08-11
Org-mode version 8.3beta (release_8.3beta-270-g4dd9f3.dirty @ /home/nick/elisp/org-mode/lisp/)

Nick

> Thank you very much for your help!
> Claudius
>
> On 08/28/2014 07:50 PM, Charles Philip Chan wrote:
>> On 28 Aug 2014, claudius.mueller@gmail.com wrote:
>>
>>> I am using emacs 24.3 in openSUSE 13.1. I have not compiled emacs
>>> myself, but the core imagemagick libraries are part of the
>>> dependencies, which makes me assume that it's been compiled with
>>> imagemagick support.
>> No, the Emacs in OpenSuSE 13.1 is not compiled with Image Magick
>> support- "ldd /usr/bin/emacs | grep Magick" produces nothing. Where as,
>> this is the output of my self-compiled version.
>>
>> ,----[ ldd /usr/local/bin/emacs | grep Magick ]
>> | libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 (0x00007fe7e8072000)
>> | libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 (0x00007fe7e7bd3000
>> `----
>>
>>> I can display inline images of several file types just fine (tif, png,
>>> gif, ...).
>> This is because Emacs is using libtiff, libjpeg, libpng, libxpm etc.
>>
>> Charles
>>
>
>
>

-- 
Nick

Re: org-image-actual-width has no effect

[Claudius Mueller]

I tried your file - but whatever I do the images are shown the same 
size. I also had to manually paste in ditaa.jar because my compiled 
emacs version (24.3) that includes org does not include the contributed 
org scripts.

I guess I'm at my wits end.

Thank you,
Claudius


On 08/29/2014 10:43 AM, Nick Dokos wrote:
> Claudius Mueller <claudius.mueller@gmail.com> writes:
>
>> Thank you for pointing this out. I compiled emacs 24.3 with
>> imagemagick support:
>>
>> "ldd /usr/local/bin/emacs | grep Magick" ====>
>> libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1
>> (0x00007f3946278000)
>> libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1
>> (0x00007f3945dd9000)
>>
>> However, inline images are still not scaled at all if I include:
>>
>> (setq org-image-actual-width 50)
>>
>> in my .emacs file.
>>
>> Any other ideas of what I am doing wrong?
>>
> Maybe check your *Messages* buffer for errors?
>
> FWIW, it works fine here with the following file:
>
> --8<---------------cut here---------------start------------->8---
>
> * Inline images
>
> This is a test: [[file:hello-world.png]]
>
> #+BEGIN_SRC ditaa :file hello-world.png :cmdline -r
> +--------------+
> |              |
> | Hello World! |
> |              |
> +--------------+
> #+END_SRC
>
> #+RESULTS:
> [[file:hello-world.png]]
>
>
> * image width
>
> #+BEGIN_SRC emacs-lisp
> (setq org-image-actual-width 50)
> #+END_SRC
>
> #+BEGIN_SRC emacs-lisp
> (setq org-image-actual-width 500)
> #+END_SRC
>
>
> --8<---------------cut here---------------end--------------->8---
>
> Depending on which emacs-lisp source block I evaluate, when I do C-c C-x
> C-v afterwards, I get small images or large images.
>
> Version info:
> Fedora 20
> GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.9) of 2014-08-11
> Org-mode version 8.3beta (release_8.3beta-270-g4dd9f3.dirty @ /home/nick/elisp/org-mode/lisp/)
>
> Nick
>
>> Thank you very much for your help!
>> Claudius
>>
>> On 08/28/2014 07:50 PM, Charles Philip Chan wrote:
>>> On 28 Aug 2014, claudius.mueller@gmail.com wrote:
>>>
>>>> I am using emacs 24.3 in openSUSE 13.1. I have not compiled emacs
>>>> myself, but the core imagemagick libraries are part of the
>>>> dependencies, which makes me assume that it's been compiled with
>>>> imagemagick support.
>>> No, the Emacs in OpenSuSE 13.1 is not compiled with Image Magick
>>> support- "ldd /usr/bin/emacs | grep Magick" produces nothing. Where as,
>>> this is the output of my self-compiled version.
>>>
>>> ,----[ ldd /usr/local/bin/emacs | grep Magick ]
>>> | libMagickWand-6.Q16.so.1 => /usr/lib64/libMagickWand-6.Q16.so.1 (0x00007fe7e8072000)
>>> | libMagickCore-6.Q16.so.1 => /usr/lib64/libMagickCore-6.Q16.so.1 (0x00007fe7e7bd3000
>>> `----
>>>
>>>> I can display inline images of several file types just fine (tif, png,
>>>> gif, ...).
>>> This is because Emacs is using libtiff, libjpeg, libpng, libxpm etc.
>>>
>>> Charles
>>>
>>
>>

Re: org-image-actual-width has no effect

[Nick Dokos]

Claudius Mueller <claudius.mueller@gmail.com> writes:

> I tried your file - but whatever I do the images are shown the same
> size. I also had to manually paste in ditaa.jar because my compiled
> emacs version (24.3) that includes org does not include the
> contributed org scripts.
>

ditaa was just a quick way for me to get an image. It does not matter
how you get the image, as long as you have one.

> I guess I'm at my wits end.
>

Don't give up yet!

Can you evaluate this and post the result?

  (image-type-available-p 'imagemagick)

C-x C-e at the end of the line will evaluate the
expression. Also evaluate

  org-image-actual-width

just to make sure that the value is correct.

--
Nick

Re: org-image-actual-width has no effect

[Claudius Mueller]

Thanks for trying to help! I really appreciate that!

(image-type-available-p 'imagemagick) ==> output: "t"
org-image-actual-width ==> output: "10"

I had set org-image-actual-width to 10 in the .emacs file to make sure I 
really notice the difference once the problem is solved.

Claudius


On 08/29/2014 06:27 PM, Nick Dokos wrote:
> Claudius Mueller <claudius.mueller@gmail.com> writes:
>
>> I tried your file - but whatever I do the images are shown the same
>> size. I also had to manually paste in ditaa.jar because my compiled
>> emacs version (24.3) that includes org does not include the
>> contributed org scripts.
>>
> ditaa was just a quick way for me to get an image. It does not matter
> how you get the image, as long as you have one.
>
>> I guess I'm at my wits end.
>>
> Don't give up yet!
>
> Can you evaluate this and post the result?
>
>    (image-type-available-p 'imagemagick)
>
> C-x C-e at the end of the line will evaluate the
> expression. Also evaluate
>
>    org-image-actual-width
>
> just to make sure that the value is correct.
>
> --
> Nick
>
>
>

Re: org-image-actual-width has no effect

[Nick Dokos]

Claudius Mueller <claudius.mueller@gmail.com> writes:

> Thanks for trying to help! I really appreciate that!
>
> (image-type-available-p 'imagemagick) ==> output: "t"
> org-image-actual-width ==> output: "10"
>
> I had set org-image-actual-width to 10 in the .emacs file to make sure
> I really notice the difference once the problem is solved.
>

OK - this looks correct.

Inline images work by creating an overlay on a portion of a text, and
then giving the overlay a property (a key-value pair) where the key is
'display and the value is an image. The following is a minimal example
(you'll have to change the path to the image of course to suit your
situation).

If you execute the first code block with C-c C-c, you should see the
image replacing the word "foo"; executing the second code block should
get rid of the overlay and let you see "foo" again. Changing the width
(but not too much: from 50 to 100 and back should work, but larger
overlays tend to make the buffer visually a mess because the code is not
robust enough - you can always recover by killing the buffer and
revisiting the file) and reexecuting the first code block should give
you an image with the new width:

--8<---------------cut here---------------start------------->8---
foo

















#+BEGIN_SRC emacs-lisp :results none
(setq ov (make-overlay 1 4))
(overlay-put ov 'display (create-image "/home/nick/src/org/inline/hello-world.png" 'imagemagick nil :width 50))
#+END_SRC


#+BEGIN_SRC emacs-lisp :results none
(delete-overlay ov)
#+END_SRC
--8<---------------cut here---------------end--------------->8---


In any case, the experiment takes org out of the picture, so if it works
by itself then there is probably a problem with your org-mode. If it
doesn't work, then there is something more basic that's busted.

-- 
Nick

Re: org-image-actual-width has no effect

[Claudius Mueller]

Nick, your code worked! My example image was small and I could change 
the size by altering the width variable. The same image in a regular org 
file is huge.

That means something is wrong with my org-mode install? I have not 
changed or done anything to org-mode that came with the compiled emacs 
24.3 version. Any  tests I can do?

Thank you - this process has already taught me a lot.

Claudius


On 08/29/2014 10:54 PM, Nick Dokos wrote:
> Claudius Mueller <claudius.mueller@gmail.com> writes:
>
>> Thanks for trying to help! I really appreciate that!
>>
>> (image-type-available-p 'imagemagick) ==> output: "t"
>> org-image-actual-width ==> output: "10"
>>
>> I had set org-image-actual-width to 10 in the .emacs file to make sure
>> I really notice the difference once the problem is solved.
>>
> OK - this looks correct.
>
> Inline images work by creating an overlay on a portion of a text, and
> then giving the overlay a property (a key-value pair) where the key is
> 'display and the value is an image. The following is a minimal example
> (you'll have to change the path to the image of course to suit your
> situation).
>
> If you execute the first code block with C-c C-c, you should see the
> image replacing the word "foo"; executing the second code block should
> get rid of the overlay and let you see "foo" again. Changing the width
> (but not too much: from 50 to 100 and back should work, but larger
> overlays tend to make the buffer visually a mess because the code is not
> robust enough - you can always recover by killing the buffer and
> revisiting the file) and reexecuting the first code block should give
> you an image with the new width:
>
> --8<---------------cut here---------------start------------->8---
> foo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> #+BEGIN_SRC emacs-lisp :results none
> (setq ov (make-overlay 1 4))
> (overlay-put ov 'display (create-image "/home/nick/src/org/inline/hello-world.png" 'imagemagick nil :width 50))
> #+END_SRC
>
>
> #+BEGIN_SRC emacs-lisp :results none
> (delete-overlay ov)
> #+END_SRC
> --8<---------------cut here---------------end--------------->8---
>
>
> In any case, the experiment takes org out of the picture, so if it works
> by itself then there is probably a problem with your org-mode. If it
> doesn't work, then there is something more basic that's busted.
>

Re: org-image-actual-width has no effect

[Claudius Mueller]

I got it to work! Thanks to Nick's code pointing to org-mode as the 
culprit, I re-installed org on top of a fresh compile of emacs (24.3.1). 
Using the org version that came with the freshly compiled emacs, inline 
images did not scale. Installing the latest version of org (8.2.7c) and 
org-plus-contrib on top of the fresh emacs compile (via emacs packaging 
system) did the trick.

Thank you for your help!!!

Claudius

On 08/29/2014 10:54 PM, Nick Dokos wrote:
> Claudius Mueller <claudius.mueller@gmail.com> writes:
>
>> Thanks for trying to help! I really appreciate that!
>>
>> (image-type-available-p 'imagemagick) ==> output: "t"
>> org-image-actual-width ==> output: "10"
>>
>> I had set org-image-actual-width to 10 in the .emacs file to make sure
>> I really notice the difference once the problem is solved.
>>
> OK - this looks correct.
>
> Inline images work by creating an overlay on a portion of a text, and
> then giving the overlay a property (a key-value pair) where the key is
> 'display and the value is an image. The following is a minimal example
> (you'll have to change the path to the image of course to suit your
> situation).
>
> If you execute the first code block with C-c C-c, you should see the
> image replacing the word "foo"; executing the second code block should
> get rid of the overlay and let you see "foo" again. Changing the width
> (but not too much: from 50 to 100 and back should work, but larger
> overlays tend to make the buffer visually a mess because the code is not
> robust enough - you can always recover by killing the buffer and
> revisiting the file) and reexecuting the first code block should give
> you an image with the new width:
>
> --8<---------------cut here---------------start------------->8---
> foo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> #+BEGIN_SRC emacs-lisp :results none
> (setq ov (make-overlay 1 4))
> (overlay-put ov 'display (create-image "/home/nick/src/org/inline/hello-world.png" 'imagemagick nil :width 50))
> #+END_SRC
>
>
> #+BEGIN_SRC emacs-lisp :results none
> (delete-overlay ov)
> #+END_SRC
> --8<---------------cut here---------------end--------------->8---
>
>
> In any case, the experiment takes org out of the picture, so if it works
> by itself then there is probably a problem with your org-mode. If it
> doesn't work, then there is something more basic that's busted.
>