From: Nick Dokos <ndokos@gmail.com>
To: emacs-orgmode@gnu.org
Subject: [RFC] <img> vs <object> in HTML export
Date: Thu, 09 Jan 2014 16:10:53 -0500 [thread overview]
Message-ID: <87vbxsamjm.fsf@alphaville.bos.redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3707 bytes --]
Summary
-------
I'm wondering whether it's a good idea to chnage the HTML exporter's
handling of images: my specific proposal is to use <object> tags instead
of <img> tags.
Rationale
----------
I got data to plot and I wanted to use SVG, rather than PNG,
in order to be able to resize the plots to fit whatever projection
requirements I came up against. I use gnuplot which has a nice svg
terminal that also includes some javascript functions that allow
interactive manipulation of the plot (e.g. you can click on the label
of a dataset in the legend of the plot to toggle its visibility -
that's something I really want.)
I found out that if I opened the SVG file in my browser, I could use
the interactivity features that gnuplot provides, but if I visit
the HTML page that includes all the plots, the interactivity was lost.
Googling a bit, I found out about <object> vs <img>, changed the <img>
tags to <object> tags and presto! interactivity!
Example
-------
Here is a simple example org file:
--8<---------------cut here---------------start------------->8---
* Plots
#+BEGIN_SRC gnuplot :var tbl=foo.tbl :results output :file foo.svg
set terminal svg size 1024,512 dynamic mouse standalone
set xrange [0:5]
set xlabel "x"
set yrange [0:*]
set ylabel "y"
set datafile missing " "
plot tbl using 1:2 title "squares", '' using 1:3 title "cubes", '' using 1:4 title "fourth powers"
#+END_SRC
#+BEGIN_SRC gnuplot :var tbl=foo.tbl :results output :file foo.png
set terminal png size 1024,512
set xrange [0:5]
set xlabel "x"
set yrange [0:*]
set ylabel "y"
set datafile missing " "
plot tbl using 1:2 title "squares", '' using 1:3 title "cubes", '' using 1:4 title "fourth powers"
#+END_SRC
** data :noexport:
#+name: foo.tbl
| 1 | 1 | 1 | 1 |
| 2 | 4 | 8 | 16 |
| 3 | 9 | 27 | 81 |
| 4 | 16 | 64 | 256 |
--8<---------------cut here---------------end--------------->8---
Exporting this to HTML produces <img> tags like this:
,----
| <div class="figure">
| <p><img src="foo.svg" alt="foo.svg" />
| </p>
| </div>
|
|
| <div class="figure">
| <p><img src="foo.png" alt="foo.png" />
| </p>
| </div>
`----
I attach a patch[fn:1] that changes these to <object> tags (the patch is
proof-of-concept only, not meant for integration into org core - it'll
need a fair amount of work before that happens, if it ever happens.)
With the patch, the relevant output is changed to this:
,----
| <div class="figure">
| <p><object data="foo.svg" type="image/svg+xml"> </object>
| </p>
| </div>
|
|
| <div class="figure">
| <p><object data="foo.png" type="image/png"> </object>
| </p>
| </div>
`----
I attach the HTML files for your amusement.[fn:2]
Open questions
--------------
Do I have this right? I'm neither an SVG nor an HTML expert. If there is
another way to do what I want, please let me know.
Do most browsers support <object> tags? Do they do the right thing with
images in <object> tags?
I tested this with Google Chrome (Version 31.0.1650.63) and Firefox
(Version 25.0), both on Linux. I have not tested any other browsers on
Linux and I have not tested *any* browsers on any other OSes. There are
probably compatibility problems which would imply that any change in org
mode would have to be made conditional on some global option
(org-html-accommodate-obsolete-browsers perhaps :-) - default would be t
to leave everything as it is currently i.e. <img> tags.)
BTW, I tried using
<object data="foo.png" type="image/png"/>
at first, but Chrome did not handle it correctly in my testing, whereas
it handles the
<object data="foo.png" type="image/png"> </object>
form correctly. I did not try the first form with FF: there was no point.
So, WDYT?
Footnotes:
[fn:1]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Use <object> tags instead of <img> tags for images in HTML export --]
[-- Type: text/x-patch, Size: 2363 bytes --]
From 0529562b428d421f8aaf398bc604bc8d2f9498e8 Mon Sep 17 00:00:00 2001
From: Nick Dokos <ndokos@redhat.com>
Date: Thu, 9 Jan 2014 15:38:28 -0500
Subject: [PATCH] Use <object> tags instead of <img>
---
lisp/ox-html.el | 28 +++++++++++++++++++---------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 7dbbfc8..b57c97d 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1317,9 +1317,11 @@ CSS classes, then this prefix can be very useful."
(let ((dt (downcase (plist-get info :html-doctype))))
(member dt '("html5" "xhtml5" "<!doctype html>"))))
-(defun org-html-close-tag (tag attr info)
+(defun org-html-close-tag (tag attr info &optional longopt)
(concat "<" tag " " attr
- (if (org-html-xhtml-p info) " />" ">")))
+ (if (not longopt)
+ (if (org-html-xhtml-p info) " />" ">")
+ (concat "> </" tag ">"))))
(defun org-html-doctype (info)
"Return correct html doctype tag from `org-html-doctype-alist',
@@ -1362,6 +1364,12 @@ arguments CAPTION and LABEL are given, use them for caption and
"\n<p>%s</p>")
caption)))))
+(defun org-html-image-type (source info)
+ (let ((suffix (file-name-extension source)))
+ (if (string= suffix "svg")
+ "svg+xml"
+ suffix)))
+
(defun org-html--format-image (source attributes info)
"Return \"img\" tag with given SOURCE and ATTRIBUTES.
SOURCE is a string specifying the location of the image.
@@ -1369,16 +1377,18 @@ ATTRIBUTES is a plist, as returned by
`org-export-read-attribute'. INFO is a plist used as
a communication channel."
(org-html-close-tag
- "img"
+ "object"
(org-html--make-attribute-string
(org-combine-plists
- (list :src source
- :alt (if (string-match-p "^ltxpng/" source)
- (org-html-encode-plain-text
- (org-find-text-property-in-string 'org-latex-src source))
- (file-name-nondirectory source)))
+ (list :data source
+ :type (concat "image/" (org-html-image-type source info))
+ ;; :alt (if (string-match-p "^ltxpng/" source)
+ ;; (org-html-encode-plain-text
+ ;; (org-find-text-property-in-string 'org-latex-src source))
+ ;; (file-name-nondirectory source))
+ )
attributes))
- info))
+ info t))
(defun org-html--textarea-block (element)
"Transcode ELEMENT into a textarea block.
--
1.8.5.rc0
[-- Attachment #3: Type: text/plain, Size: 8 bytes --]
[fn:2]
[-- Attachment #4: HTML file with object tags --]
[-- Type: text/html, Size: 5685 bytes --]
[-- Attachment #5: HTML file with img tags --]
[-- Type: text/html, Size: 5651 bytes --]
[-- Attachment #6: Type: text/plain, Size: 6 bytes --]
Nick
next reply other threads:[~2014-01-09 21:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 21:10 Nick Dokos [this message]
2014-01-10 16:09 ` [RFC] <img> vs <object> in HTML export Rick Frankel
2014-01-10 19:12 ` Nick Dokos
2014-01-11 9:21 ` Bastien
2014-01-16 22:45 ` Rick Frankel
2014-01-16 23:18 ` Nick Dokos
2014-01-17 0:44 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vbxsamjm.fsf@alphaville.bos.redhat.com \
--to=ndokos@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).