Re: [O] Inline Images Export Bug
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: [O] Inline Images Export Bug
On 08/26/2015 02:06 PM, Rasmus wrote: Hi Scott, Thanks for your bug report. Scott Randby sran...@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: [O] Inline Images Export Bug
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 ras...@gmx.us wrote:
Hi Scott,
Thanks for your bug report.
Scott Randby sran...@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
[O] Inline Images Export Bug
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: [O] Inline Images Export Bug
Hi Scott, Thanks for your bug report. Scott Randby sran...@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: [O] Inline Images Export Bug
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 ras...@gmx.us wrote:
Hi,
Pip Cet pip...@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: [O] Inline Images Export Bug
Scott Randby sran...@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: [O] Inline Images Export Bug
Hi,
Pip Cet pip...@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: [O] Inline Images Export Bug
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 ras...@gmx.us
mailto:ras...@gmx.us wrote:
Hi,
Pip Cet pip...@gmail.com mailto:pip...@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: [O] Inline Images Export Bug
On 08/26/2015 06:35 PM, Rasmus wrote: Scott Randby sran...@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: [O] Inline Images Export Bug
[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 sran...@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 r...@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
