Inline Images Export Bug

Inline Images Export Bug

[Scott Randby]

When did Org start using the <object> tag for inline image HTML export? 
This is a horrible bug.

I use many SVG images in my documents. Here is a sample bit of Org code:

#+ATTR_HTML: :width 50% :style display: block; margin-right: auto; 
margin-left: auto;
[[./graphic-1.svg]]

I used to get this when exporting:

<img src="./graphic-1.svg" alt="graphic-1.svg" width="50%" 
style="display: block; margin-right: auto; margin-left: auto;" />

Now I get this:

<object type="image/svg+xml" data="./graphic-1.svg" width="50%" 
style="display: block; margin-right: auto; margin-left: auto;">Sorry, 
your browser does not support SVG.</object>

The problems with the second bit of exported code is that it doesn't 
scale the image to fit the block with 50% width (only a small part of 
the image is visible), and you when you right click on the image, you 
can't view it, save it or anything.

The documentation for 8.3.1 says this about org-html-inline-images:

    Non-nil means inline images into exported HTML pages.  This is done
    using an <img> tag.  When nil, an anchor with href is used to link
    to the image.

Clearly, Org 8.3 is not using an <img> tag when exporting SVG images to 
HTML, something which is a major issue for me. It essentially makes Org 
unusable for HTML export. I really would appreciate a fix for this bug.

Scott Randby

Re: Inline Images Export Bug

[Rasmus]

Hi Scott,

Thanks for your bug report.

Scott Randby <srandby@gmail.com> writes:

> When did Org start using the <object> tag for inline image HTML
> export?

You should use git-blame to find out if you care.


> The problems with the second bit of exported code is that it doesn't
> scale the image to fit the block with 50% width (only a small part of
> the image is visible), and you when you right click on the image, you
> can't view it, save it or anything.
>
> [...]
> 
> Clearly, Org 8.3 is not using an <img> tag when exporting SVG images
> to HTML, something which is a major issue for me. It essentially makes
> Org unusable for HTML export. I really would appreciate a fix for this
> bug.

I'm not sure it's a bug.  It's IS clearly a quite complicated issue, e.g.:

    http://stackoverflow.com/questions/4476526/do-i-use-img-object-or-embed-for-svg-files

Perhaps it should be configurable, perhaps even as a default and a
per-image basis (via #+attr_html).

If you can provide a (html) solution that takes into consideration the
issues mentioned on SO that would of course be great.  In the age of d3.js
interactivity COULD be an issue (I would always load "interactive svgs"
via JS, but I'm a pretty naïve svg user so I don't know what's possible).

Rasmus

-- 
Together we'll stand, divided we'll fall

Re: Inline Images Export Bug

[Scott Randby]

On 08/26/2015 02:06 PM, Rasmus wrote:
> Hi Scott,
>
> Thanks for your bug report.
>
> Scott Randby <srandby@gmail.com> writes:
>
>> When did Org start using the <object> tag for inline image HTML
>> export?
>
> You should use git-blame to find out if you care.

I don't use the git repository for Org, so I'll just have to leave that 
question unanswered.

>
>
>> The problems with the second bit of exported code is that it doesn't
>> scale the image to fit the block with 50% width (only a small part of
>> the image is visible), and you when you right click on the image, you
>> can't view it, save it or anything.
>>
>> [...]
>>
>> Clearly, Org 8.3 is not using an <img> tag when exporting SVG images
>> to HTML, something which is a major issue for me. It essentially makes
>> Org unusable for HTML export. I really would appreciate a fix for this
>> bug.
>
> I'm not sure it's a bug.  It's IS clearly a quite complicated issue, e.g.:
>
>      http://stackoverflow.com/questions/4476526/do-i-use-img-object-or-embed-for-svg-files
>
> Perhaps it should be configurable, perhaps even as a default and a
> per-image basis (via #+attr_html).
>
> If you can provide a (html) solution that takes into consideration the
> issues mentioned on SO that would of course be great.  In the age of d3.js
> interactivity COULD be an issue (I would always load "interactive svgs"
> via JS, but I'm a pretty naïve svg user so I don't know what's possible).

I don't really have the technical knowledge required to address the 
issue. The configuration option is the best option in my view. One 
option allows SVGs to be handled the old way and the other the new way. 
Perhaps something like this:

#+ATTR_HTML: :svg img

or

#+ATTR_HTML: :svg object

In my view, the default should be img, but I intend for my pages to be 
viewed by browsers which support SVG images. I direct my students to 
those browsers. Also, the W3C draft document states that support for SVG 
via the <img> tag is the desired solution.

I will experiment a bit to see if I can get the <object> tag solution 
working for me. But given the short amount of time I have to get my 
pages up (by Sunday), I will probably put the desired HTML code into the 
Org file directly until the issue is resolved.

Scott

Re: Inline Images Export Bug

[Pip Cet]

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

I've used interactive SVGs with ox-html output quite a lot, and I found it
necessary to add the following horrible code; I'm not sure it's still
required:

----
    let svgdoc = object.contentDocument;
    let svgid = object.id;

    if (!svgdoc) {
        if (object.parentNode /* XXX why is this necessary */)
            object.parentNode.innerHTML = "";
        return;
    }

    let found = false;
    for (let el of svgdoc.getElementsByTagName("svg")) {
        let width = el.getAttribute("width");
        let height = el.getAttribute("height");

        let width_pt = width.match(/^([0-9]*)pt$/)[1];
        let height_pt = height.match(/^([0-9]*)pt$/)[1];

        let width_px = 5/4 * width_pt;
        let height_px = 5/4 * height_pt;

        object.setAttribute("width", width_px + "px");
        object.setAttribute("height", height_px + "px");
        found = true;
    }
----

In my case, the SVG was produced by graphviz, so it always has the width
and height attributes.

This is a minor issue, but I also think the fallback message ("Sorry, your
browser does not support SVG.") is really horrible and misleading. It's
very unlikely to be a browser issue today, and much more likely to be a
missing file or a user deliberately disabling SVG. In that case, software
shouldn't say it's sorry :-)

"Cannot load SVG file." would be a better message, I think.


On Wed, Aug 26, 2015 at 6:06 PM, Rasmus <rasmus@gmx.us> wrote:

> Hi Scott,
>
> Thanks for your bug report.
>
> Scott Randby <srandby@gmail.com> writes:
>
> > When did Org start using the <object> tag for inline image HTML
> > export?
>
> You should use git-blame to find out if you care.
>
>
> > The problems with the second bit of exported code is that it doesn't
> > scale the image to fit the block with 50% width (only a small part of
> > the image is visible), and you when you right click on the image, you
> > can't view it, save it or anything.
> >
> > [...]
> >
> > Clearly, Org 8.3 is not using an <img> tag when exporting SVG images
> > to HTML, something which is a major issue for me. It essentially makes
> > Org unusable for HTML export. I really would appreciate a fix for this
> > bug.
>
> I'm not sure it's a bug.  It's IS clearly a quite complicated issue, e.g.:
>
>
> http://stackoverflow.com/questions/4476526/do-i-use-img-object-or-embed-for-svg-files
>
> Perhaps it should be configurable, perhaps even as a default and a
> per-image basis (via #+attr_html).
>
> If you can provide a (html) solution that takes into consideration the
> issues mentioned on SO that would of course be great.  In the age of d3.js
> interactivity COULD be an issue (I would always load "interactive svgs"
> via JS, but I'm a pretty naïve svg user so I don't know what's possible).
>
> Rasmus
>
> --
> Together we'll stand, divided we'll fall
>
>
>

[-- Attachment #2: Type: text/html, Size: 4079 bytes --]

Re: Inline Images Export Bug

[Scott Randby]

On 08/26/2015 02:06 PM, Rasmus wrote:
>
> If you can provide a (html) solution that takes into consideration the
> issues mentioned on SO that would of course be great.  In the age of d3.js
> interactivity COULD be an issue (I would always load "interactive svgs"
> via JS, but I'm a pretty naïve svg user so I don't know what's possible).

My SVGs aren't interactive. I have no idea how to deal with interactive 
SVGs.

Scott

>
> Rasmus
>

Re: Inline Images Export Bug

[Rasmus]

Hi,

Pip Cet <pipcet@gmail.com> writes:

>     let found = false;
>     for (let el of svgdoc.getElementsByTagName("svg")) {
>         let width = el.getAttribute("width");
>         let height = el.getAttribute("height");
>
>         let width_pt = width.match(/^([0-9]*)pt$/)[1];
>         let height_pt = height.match(/^([0-9]*)pt$/)[1];
>
>         let width_px = 5/4 * width_pt;
>         let height_px = 5/4 * height_pt;
>
>         object.setAttribute("width", width_px + "px");
>         object.setAttribute("height", height_px + "px");
>         found = true;

So are you saying that Org is changing the size from px to pt?  Can you
try to explain the problem you observe in words?

Thanks,
Rasmus

-- 
The second rule of Fight Club is: You do not talk about Fight Club

Re: Inline Images Export Bug

[Rasmus]

Scott Randby <srandby@gmail.com> writes:

> I will experiment a bit to see if I can get the <object> tag solution
> working for me. But given the short amount of time I have to get my
> pages up (by Sunday), I will probably put the desired HTML code into
> the Org file directly until the issue is resolved.

Since time is of essence and you don't use the development version, would
you be able to use org 8.2.10?  It's bundled with Emacs 24.5.

Rasmus

-- 
I almost cut my hair, it happened just the other day

Re: Inline Images Export Bug

[Pip Cet]

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

Okay, I just checked (sorry, had to regenerate the files and that took some
time), and with the current version of Firefox the code I pasted is
unnecessary.

The problem I had with previous Firefox versions is that those decided on a
scale for displaying the SVG that differed from its preferred resolution,
but only if an object tag was used for inclusion; img tags would use the
preferred resolution and everything was fine.

The reason for the pt-to-px arithmetic is that graphviz outputs (or used
to) SVGs with a preferred size specified in pt only, not in px. I'm not
sure, but I think HTML pt and SVG pt don't necessarily agree.

Org mode is generating this tag:

<object type="image/svg+xml" data="org/op-prec.svg" >
Sorry, your browser does not support SVG.</object>

Which looks okay to me. It's browser support that's the issue.

> The problems with the second bit of exported code is that it doesn't
scale the image to fit the block with 50% width (only a small part of the
image is visible)

Is it possible you're using an old browser? I'm on Iceweasel (Firefox)
38.1.0. (The bug was there a year or two ago, so by my standards it's a
recent fix that we shouldn't rely on yet.)

> and you when you right click on the image, you can't view it, save it or
anything.

Again, I can, using the "This Frame" popup menu.

But clearly that menu name is misleading and confusing in this case! And I
think that is reason enough to stick with the img tag for now: Firefox
users can't save the image unless they telepathically know that "frame"
means "image". "This Object" might be okay, I guess.

My suggestion is to use img for images; that also appears to be the
consensus on Stack Overflow. Let's find a good syntax for including
interactive objects in Org mode, though.

On Wed, Aug 26, 2015 at 9:56 PM, Rasmus <rasmus@gmx.us> wrote:

> Hi,
>
> Pip Cet <pipcet@gmail.com> writes:
>
> >     let found = false;
> >     for (let el of svgdoc.getElementsByTagName("svg")) {
> >         let width = el.getAttribute("width");
> >         let height = el.getAttribute("height");
> >
> >         let width_pt = width.match(/^([0-9]*)pt$/)[1];
> >         let height_pt = height.match(/^([0-9]*)pt$/)[1];
> >
> >         let width_px = 5/4 * width_pt;
> >         let height_px = 5/4 * height_pt;
> >
> >         object.setAttribute("width", width_px + "px");
> >         object.setAttribute("height", height_px + "px");
> >         found = true;
>
> So are you saying that Org is changing the size from px to pt?  Can you
> try to explain the problem you observe in words?
>
> Thanks,
> Rasmus
>
> --
> The second rule of Fight Club is: You do not talk about Fight Club
>

[-- Attachment #2: Type: text/html, Size: 3633 bytes --]

Re: Inline Images Export Bug

[Scott Randby]

On 08/26/2015 06:35 PM, Rasmus wrote:
> Scott Randby <srandby@gmail.com> writes:
>
>> I will experiment a bit to see if I can get the <object> tag solution
>> working for me. But given the short amount of time I have to get my
>> pages up (by Sunday), I will probably put the desired HTML code into
>> the Org file directly until the issue is resolved.
>
> Since time is of essence and you don't use the development version, would
> you be able to use org 8.2.10?  It's bundled with Emacs 24.5.

I can stay with 8.3.1. It really isn't a problem for me to put the 
needed HTML code directly into the Org file. I'll just do something like 
this:


#+BEGIN_HTML
<p>
<img src="./graphic-1.svg" alt="Cannot load SVG file." width="75%" 
style="display: block; margin-right: auto; margin-left: auto;" />
</p>
#+END_HTML

Scott

Re: Inline Images Export Bug

[Scott Randby]

On 08/26/2015 06:40 PM, Pip Cet wrote:
> Okay, I just checked (sorry, had to regenerate the files and that took
> some time), and with the current version of Firefox the code I pasted is
> unnecessary.
>
> The problem I had with previous Firefox versions is that those decided
> on a scale for displaying the SVG that differed from its preferred
> resolution, but only if an object tag was used for inclusion; img tags
> would use the preferred resolution and everything was fine.
>
> The reason for the pt-to-px arithmetic is that graphviz outputs (or used
> to) SVGs with a preferred size specified in pt only, not in px. I'm not
> sure, but I think HTML pt and SVG pt don't necessarily agree.
>
> Org mode is generating this tag:
>
> <object type="image/svg+xml" data="org/op-prec.svg" >
> Sorry, your browser does not support SVG.</object>
>
> Which looks okay to me. It's browser support that's the issue.
>
>> The problems with the second bit of exported code is that it doesn'tscale the image to fit the block with 50% width (only a small part of
> the image is visible)
>
> Is it possible you're using an old browser? I'm on Iceweasel (Firefox)
> 38.1.0. (The bug was there a year or two ago, so by my standards it's a
> recent fix that we shouldn't rely on yet.)

I'm using Firefox 40.0. I get the same behavior on Google Chrome 44.0 too.

>
>> and you when you right click on the image, youcan't view it, save it or anything.
>
> Again, I can, using the "This Frame" popup menu.

Okay, that works.

>
> But clearly that menu name is misleading and confusing in this case! And
> I think that is reason enough to stick with the img tag for now: Firefox
> users can't save the image unless they telepathically know that "frame"
> means "image". "This Object" might be okay, I guess.
>
> My suggestion is to use img for images; that also appears to be the
> consensus on Stack Overflow. Let's find a good syntax for including
> interactive objects in Org mode, though.

This sounds reasonable.

>
> On Wed, Aug 26, 2015 at 9:56 PM, Rasmus <rasmus@gmx.us
> <mailto:rasmus@gmx.us>> wrote:
>
>     Hi,
>
>     Pip Cet <pipcet@gmail.com <mailto:pipcet@gmail.com>> writes:
>
>     >     let found = false;
>     >     for (let el of svgdoc.getElementsByTagName("svg")) {
>     >         let width = el.getAttribute("width");
>     >         let height = el.getAttribute("height");
>     >
>     >         let width_pt = width.match(/^([0-9]*)pt$/)[1];
>     >         let height_pt = height.match(/^([0-9]*)pt$/)[1];
>     >
>     >         let width_px = 5/4 * width_pt;
>     >         let height_px = 5/4 * height_pt;
>     >
>     >         object.setAttribute("width", width_px + "px");
>     >         object.setAttribute("height", height_px + "px");
>     >         found = true;
>
>     So are you saying that Org is changing the size from px to pt?  Can you
>     try to explain the problem you observe in words?
>
>     Thanks,
>     Rasmus
>
>     --
>     The second rule of Fight Club is: You do not talk about Fight Club
>
>

Re: Inline Images Export Bug

[Nick Dokos]

[OT and unrelated but it struck me, so I thought I'd share:
if you visit http://dir.gmane.org/index.php?prefix=gmane.emacs
you will see (well, you are probably going to see something larger
than this when you visit):

100093	gmane.emacs.orgmode	Org-Mode for GNU Emacs

That's the fourth largest number of messages among emacs-related lists,
after emacs.devel, emacs.diffs and emacs.help and is somewhat bigger
than emacs.bugs.]


Scott Randby <srandby@gmail.com> writes:

> When did Org start using the <object> tag for inline image HTML
> export? This is a horrible bug.
>

I believe I was the instigator for this change: see the thread at

  http://thread.gmane.org/gmane.emacs.orgmode/80668

I had my own "horrible" bug that I was trying to work around and the
research I did at the time pointed towards <object> as the right way to
go, but I was (and still am) no expert on the subject. Rick Frankel
pushed a change to that effect in

commit e955be903a5cf29f173972ab18f851f8553ddd89
Author: Rick Frankel <rick@rickster.com>
Date:   Thu Jan 16 11:08:06 2014 -0500

    Add better svg support to html exporter.
    
    * lisp/ox-html.el (org-html--format-image): If image is an svg file,
      format as "object" using new function `org-html--svg-image' instead
      of "img".

-- 
Nick