Re: proposed modification of org-display-inline-images

[John Kitchin <jkitchin@andrew.cmu.edu>]

Rasmus writes:

> Hi,
>
> Thanks for the proposal.
>
> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> I would like to propose a change to org-display-inline-images so it can
>> rescale images even if imagemagick is not built in to emacs. There is
>> currently no way to rescale images when they are displayed in that case
>> AFAICS. This is particularly a problem on Windows, as we have never
>> found a binary linked to imagemagick for that platform.
>
> This sounds like an Emacs problem.  There was some talk about the
> rescaling issue here:
>
>     http://thread.gmane.org/gmane.emacs.devel/174318/
>
> And maybe here:
>
>     http://thread.gmane.org/gmane.emacs.devel/200568/focus=203024

It is related to those two issues, especially on Windows. AFAICS, there
is still no resolution on those. But it is also an issue in org-mode,
because we create overlay images to display them inline.

>
>> I propose we define a new customizable variable called something like
>> org-inline-image-resize-function, and a function that takes a filename
>> and the resize options, and returns a path to a resized function (in the
>> temporary directory). The variable isn't technically necessary, but if
>> someone wanted to use an alternative function, it would enable it.
>>
>> This function would use the "convert" program from imagemagick to do the
>> resizing.  This program can be installed independently on all the
>> platforms I think.
>
> Why limit this to Org?  A solution should be implemented in image.el.

It doesn't need to be limited to org. image.el seems solely focused on
compiled in image libraries. There isn't anything in there that uses an
external executable that I can see. 

I am not opposed to fixing this in emacs, but I need a solution sooner
than that is likely to happen. I will have 45 students in August with
Windows laptops using org-mode in Emacs in a class ;)

>
>> Since this is just for display in org, I suggest that we use a syntax like:
>>
>> #+attr_org: :resize resize-options
>> [[./file.png]]
>>
>> the resize-options could be anything here:
>> http://www.imagemagick.org/script/command-line-processing.php#geometry
>>
>> It would enable things like:
>>
>> reduce size by 50%
>> #+attr_org: :resize 50%
>>
>> set width to 300, preserving aspect ratio
>> #+attr_org: :resize 300
>>
>> set height to 200, and preserve aspect ratio
>> #+attr_org: :resize x200
>>
>> set size to 200x300 and change aspect ratio
>> #+attr_org: :resize 200x300!
>>
>> Any thoughts on this proposal?
>
> This is misusing attr_org, isn’t it?  Don’t particularly care for this
> "API"...  All is IMO, of course.

We already misuse this api with inline scaling and :width, but the
current implmentation is tricky and uses a regexp to find the first line
containing #+attr_... :width ...

and uses it. So you have to make sure the one that scales the inline
image comes first, and the number has to be in pixels I think.

e.g. on emacs with imagemagick, this will get resized into a 2 pixel
wide image that is nearly invisible.

#+attr_latex: :width 2in
[[./file.png]]

While this will get rescaled to a width of 200.

#+attr_html: :width 200
#+attr_latex: :width 2in
[[./file.png]]

The order matters. I don't mind the attr_org syntax, as it affects
something like a real-time export of org for my eyes. I am open to
something else too though, e.g. attr_display? Preferrably something that
would show up in the plist of the paragraph containing the caption and
attributes. Thoughts?

>
> Rasmus


-- 
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu