[O] Patch: default CSS class for SVG images in HTML export
Greetings.
The attached patch
- adds a default CSS class org-svg to SVG images embedded in exported
HTML if no other class is set for the image using attr_html
- documents the existence of this class.
The second attachment is an org-file that can be used to verify that the
patch works as expected. I have tested that it works in Safari, Firefox
and Chrome (Chromium).
If this patch is ok, then what is missing are the default CSS settings
for the new class org-svg in constant org-html-style-default. I simply
did not know what to put there. The manual says that this constant has
basic settings for _all_ defined CSS entities. Either defaults need to
be set for the new class, or the text in the manual needs to be
changed. Or we have to accept that the manual is not logically
coherent. :-)
Jarmo
>From 087dd280932867b2820f1b87ff2535732615b920 Mon Sep 17 00:00:00 2001
From: Jarmo Hurri
Date: Mon, 25 Jul 2016 08:25:58 +0300
Subject: [PATCH] lisp/ox-html.el: Provide a default CSS class for embedded SVG
images
* lisp/ox-html.el (org-html--svg-image): Set CSS class of embedded SVG
images to be org-svg if no other class is set in attributes.
* doc/org.texi (CSS support): Documentation of default CSS class
org-svg for SVG images embedded into exported HTML.
---
doc/org.texi| 1 +
lisp/ox-html.el | 16
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 1c3868c..75f5eac 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -11750,6 +11750,7 @@ div.footnotes @r{footnote section headline}
p.footnote @r{footnote definition paragraph, containing a footnote}
.footref@r{a footnote reference number (always a )}
.footnum@r{footnote number in footnote definition (always )}
+.org-svg@r{default class for a linked SVG image}
@end example
@vindex org-html-style-default
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index ce4694d..79ac7e8 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1629,16 +1629,24 @@ a communication channel."
(defun org-html--svg-image (source attributes info)
"Return \"object\" appropriate for embedding svg file SOURCE
-with assoicated ATTRIBUTES. INFO is a plist used as a
+with associated ATTRIBUTES. INFO is a plist used as a
communication channel.
The special attribute \"fallback\" can be used to specify a fallback
-image file to use if the object embedding is not supported."
+image file to use if the object embedding is not supported.
+
+CSS class \"org-svg\" is assigned as the class of the object
+unless a different class is specified with an attribute."
(let ((fallback (plist-get attributes :fallback))
+ (css-class (plist-get attributes :class))
(attrs (org-html--make-attribute-string
(plist-put attributes :fallback nil
- (format "\n%s"
- source attrs
+ (format "\n%s"
+ source
+ attrs
+ (if css-class
+ ""
+ "class=\"org-svg\"")
(if fallback
(org-html-close-tag
"img" (format "src=\"%s\" %s" fallback attrs) info)
--
2.4.11
#+HTML_HEAD_EXTRA: .org-svg { width: 20vw; } .my-svg-class { width:
30vw; }
* styling with default class
#+BEGIN_SRC asymptote :file svg-image.svg
size (1cm, 0);
fill (unitsquare, red);
#+END_SRC
#+RESULTS:
[[file:svg-image.svg]]
* styling with class specified with attribute
#+ATTR_HTML: :class my-svg-class
[[file:svg-image.svg]]
* going back to default class
[[file:svg-image.svg]]
[O] error while upgrading to 8.3.5
I did the usual "make up2" in my git repository but got the following error (just pasting the tail of the log): — Ran 634 tests, 633 results as expected, 1 unexpected (2016-07-25 06:07:28+0530) 7 expected failures 1 unexpected results: FAILED test-org-colview/columns-summary mk/targets.mk:103: recipe for target 'test-dirty' failed make[1]: *** [test-dirty] Error 1 make[1]: Leaving directory '/Users/vikas/.emacs.d/src/org-mode' mk/targets.mk:115: recipe for target 'up2' failed make: *** [up2] Error 2 — What do I do? Re-install? Vikas
Re: [O] Request: change SVG embedding in exported HTML
Scott Randby writes: >> #+attr_html: :width 100px >> [[path/to/image.svg]] > > It has been awhile since I tried to scale an SVG image using Org markup, > but I recall trying what you suggest and it didn't work. I will try > again when I have some time and report the results to this list. I think I've been there, too, in the past. But it Works for me with Org 8.3.4 in Firefox, and Jarmo Hurri now reports it working in Chrome (see the thread "Scaling HTML-exported SVG"). It seems I got some details wrong about *how* it works, though. Yours, Christian
Re: [O] Scaling HTML-exported SVG
Jarmo Hurri writes:
> The method you suggested above - setting id - works (all tests done in
> Chrome).
Mine are in Firefox.
> But setting id-values is cumbersome, because you need to do it
> for every file.
> It is also possible to set a CSS class similarly, that is, modifying
> your example above,
>
> #+html_head_extra: .svgfig {width: 200px; }
>
> #+attr_html: :class svgfig
> [[path/to/image.svg]]
>
> This also works and is better, because then it is possible to set a
> common class for all SVG figures, and handle them with a single CSS
> rule.
Sure, if they should mostly be scaled to the same size. I just didn't
make that assumption.
> Better, but not yet perfect, because I still need to add a
> attr_html to every SVG figure.
> But there seems to be a way around this. With the last approach the
> generated HTML looks something like
>
>
Indeed. Now I'm confused, because this example seems to mean I got
several things wrong earlier today. First, it seems one *can* scale an
SVG image by setting attributes on the element, not just by
scaling the container element as I thought. At least in FF and
Chrome. And second, Org passes attributes from #+attr_html to the
element, not to the container as I wrote, though I could
have sworn that was what I saw when I tested today. On that note, I
think I'll go to bed... But first:
> Why don't we just set a common class for all SVG-images in an HTML
> export by default? Then we could still use an to embed it, and
> control its size from CSS.
> It seems to me that this solves the problem, and requires an extremely
> small change.
Me too. At least, I cannot think of any obvious disadvantages, and it
could be helpful if you want all or most of your SVGs to be scaled to
the same size (or otherwise styled the same way). Particularly if you
need to distinguish them from tags embedding other media, like
videos.
(If you're *not* using for anything beside SVGs, or at least
not in environments, you could just style objects,
couldn't you? e.g.:
object { width: 200px; }
or slightly safer
.figure object { width: 200px; }
But I agree that an explicit 'svg' class could be better.)
Yours,
Christian
Re: [O] automatically run code blocks when loading an org-mode document
That's a better solution indeed. On Sun, Jul 24, 2016 at 4:27 AM, Eric S Fraga wrote: > On Friday, 22 Jul 2016 at 22:11, Nick Dokos wrote: > > [...] > > > # -*- find-file-hook: org-babel-execute-buffer -*- > > #+BEGIN_SRC emacs-lisp > > (defun handy-stuff(arg) > > (message arg)) > > #+END_SRC > > > > [[elisp:(handy-stuff "foo")][foo]] > > [[elisp:(handy-stuff "bar")][bar]] > > > > will do that (but you get a question re. "safe" local variables when > > you open the file). It also executes *every* code block in the buffer > > which you might not want to do (although it does not matter in this > > case). > > For the OP, instead of evaluating every code block, it is possible to > evaluate just one code block. I have: > > # Local Variables: > # eval: (esf/execute-startup-block) > # End: > > in my org file with > > #+begin_src emacs-lisp > (defun esf/execute-startup-block () > (interactive) > (org-babel-goto-named-src-block "startup") > (org-babel-execute-src-block)) > #+end_src > > and so only a block named startup will be executed. > > -- > : Eric S Fraga (0xFFFCF67D), Emacs 25.0.94.1, Org > release_8.3.4-1049-g481709 >
Re: [O] Request: change SVG embedding in exported HTML
It looks like we can ignore my suggestion in this thread, and take the (extremely easy) way out suggested in the thread with title "Scaling HTML-exported SVG". Jarmo
Re: [O] Scaling HTML-exported SVG
Jarmo Hurri writes:
> Christian Moe writes:
>> #+html_head_extra: #svgfig {width: 200px; }
>>
>> #+attr_html: :id svgfig
>> [[path/to/image.svg]]
>>
>> For this to work, the SVG needs to be written to be scalable (with
>> viewport set etc.).
>
> (Also addressed this in the other thread; also here for completeness.)
>
> But this means scaling on a file-by-file basis, which is very
> inconvenient for any larger projects.
Did some tests.
The method you suggested above - setting id - works (all tests done in
Chrome). But setting id-values is cumbersome, because you need to do it
for every file.
It is also possible to set a CSS class similarly, that is, modifying
your example above,
#+html_head_extra: .svgfig {width: 200px; }
#+attr_html: :class svgfig
[[path/to/image.svg]]
This also works and is better, because then it is possible to set a
common class for all SVG figures, and handle them with a single CSS
rule. Better, but not yet perfect, because I still need to add a
attr_html to every SVG figure.
But there seems to be a way around this. With the last approach the
generated HTML looks something like
Why don't we just set a common class for all SVG-images in an HTML
export by default? Then we could still use an to embed it, and
control its size from CSS.
It seems to me that this solves the problem, and requires an extremely
small change.
Jarmo
Re: [O] orgmode & pdf-tools
From: AW
Subject: Re: [O] orgmode & pdf-tools
Date: Tue, 19 Apr 2016 21:53:23 +0200
> . . . A N D openSUSE!
>
> Links of the form [[./foo.pdf::3]] still are being opened on p. 1 instead of
> page 3. For description of my issue, see my report from April 3rd below.
>
> Me, being a user, I can't solve this. I'm on openSuse, current Tumbleweed. I
> managed to install PDF-Tools properly, after I found out that you need to
> install Cask before loading down the package via Melpa.
>
> Those lines below from my .emacs work in other installations, as the
> maintainer of org-pdfview.el wrote.
> (https://github.com/markus1189/org-pdfview/issues/10)
>
> I build a short .emacs, only the necessary links and packages, to orgmode and
> PDF-Tools. No success.
>
> IS SOMEBODY READING THIS WHO USES openSUSE ?
>
> I tried but failed to find an error with edebug, but this seems way beyond my
> skills.
>
> Am Sonntag, 3. April 2016, 12:19:33 CEST schrieb AW:
>> Hi!
>>
>> Linux, Orgmode 8.3.4, org-file with many links. Recently I discovered pdf-
>> tools, which can display PDFs inside Emacs, just like docview, but much
>> faster.
>>
>> I'd like to
>>
>> 1. open via a given link from inside the org-file using C-c C-o
>>
>> 2. the PDF with pdf-tools
>>
>> 3. on a given page.
>>
>> Result: PDF is being opened, but always on p. 1 instead of e.g. page 5!
>>
>> .emacs:
>>
>> (eval-after-load 'org '(require 'org-pdfview))
>> (delete '("\\.pdf\\'" . default) org-file-apps)
>> (add-to-list 'org-file-apps '("\\.pdf\\'" . org-pdfview-open))
>> (add-to-list 'org-file-apps '("\\.pdf::\\([[:digit:]]+\\)\\'" . org-pdfview-
>> open))
>>
>> link in org-file:
>>
>> [[./localfile.pdf::5]]
>>
>>
>> Same setup works under windows with other viewer. So probably there is an
>> error in those lines above. Any hints? -- Thank you!
>>
>> Regards,
>>
>> Alexander
After edebugging org-open-file I found a possible solution. The
documentation string for org-file-apps should be modified for the sexp
case to use the link variable instead of file.
#+BEGIN_SRC elisp
(add-to-list 'org-file-apps '("\\.pdf\\'" . (org-pdfview-open link)))
(add-to-list 'org-file-apps '("\\.pdf::\\(\\d+\\)\\'" . (org-pdfview-open
link)))
#+END_SRC
Re: [O] Scaling HTML-exported SVG
Christian Moe writes:
> Jarmo Hurri writes:
>> Does anyone have any idea of how to scale an SVG figure produced by Org
>> (Asymptote)? The exported HTML is
>>
>>
>>
>> Sorry, your browser does not support SVG.
>>
>>
>
> You can scale the SVG by scaling the element's container,
> i.e. the with class "figure". Setting attributes on the image
> link with #+attr_html as usual should work, because they are passed to
> the figure container rather than to the .
>
> Either:
>
> #+attr_html: :width 200px
> [[path/to/image.svg]]
>
>
> or:
>
> #+html_head_extra: #svgfig {width: 200px; }
>
> #+attr_html: :id svgfig
> [[path/to/image.svg]]
>
> For this to work, the SVG needs to be written to be scalable (with
> viewport set etc.).
(Also addressed this in the other thread; also here for completeness.)
But this means scaling on a file-by-file basis, which is very
inconvenient for any larger projects.
Jarmo
Re: [O] Request: change SVG embedding in exported HTML
Christian Moe writes: > I disagree. A switch to for SVG export (1) is not necessary for > scaling, and (2) would disable other useful features that are > presently available out of the box. > > (1) It *is* a bit easier to scale SVG with in HTML. But you > *can* scale SVG with by putting the in a container > and scaling the container width and height. The current version of Org wraps the SVG image in a of class figure, but at least setting the width of this class in a CSS produces no scaling effect (tested with Chrome and Safari). > This is actually simple with Org, which natively wraps the in > a tag, and passes any attributes to the latter. > To scale an arbitrary image.svg e.g. to 100px width, try: > > #+attr_html: :width 100px > [[path/to/image.svg]] > > Alternatively, you can use #+attr_html to set an id on the figure > , and style it with CSS. But if you need to set an id, then you will also have to do scaling on a file-by-file basis. Or? If this is so, then scaling would be a _lot_ easier using . Do we need to / could we add an option to HTML export? Either export all SVG files with or . Jarmo
Re: [O] Request: change SVG embedding in exported HTML
On 07/24/2016 12:50 PM, Christian Moe wrote: > > I disagree. A switch to for SVG export (1) is not necessary for > scaling, and (2) would disable other useful features that are presently > available out of the box. > > (1) It *is* a bit easier to scale SVG with in HTML. But you *can* > scale SVG with by putting the in a container and > scaling the container width and height. > > This is actually simple with Org, which natively wraps the in a > tag, and passes any attributes to the latter. To > scale an arbitrary image.svg e.g. to 100px width, try: > > #+attr_html: :width 100px > [[path/to/image.svg]] It has been awhile since I tried to scale an SVG image using Org markup, but I recall trying what you suggest and it didn't work. I will try again when I have some time and report the results to this list. > > Alternatively, you can use #+attr_html to set an id on the figure , > and style it with CSS. > > (2) You can also do other things with that you cannot with > , like manipulating the SVG with Javascript and styling it with an > external stylesheet (linked from the SVG, not the web page). > > Raw SVG in the exported HTML is a third option that is very plain-texty > and supports all the mentioned features, but it tends to bloat files, > and doesn't encourage caching and re-using of an image across web pages. > > To sum up, makes the most common task simpler (scaling the > graphic), but at the cost of features such as interactive animated > graphics, which are possible with or SVG islands. I do remember a discussion in the past about this issue. Scott
Re: [O] Scaling HTML-exported SVG
Jarmo Hurri writes:
> Greetings.
>
> Does anyone have any idea of how to scale an SVG figure produced by Org
> (Asymptote)? The exported HTML is
>
>
>
> Sorry, your browser does not support SVG.
>
>
(Suggested an answer on another thread. For completeness:)
You can scale the SVG by scaling the element's container,
i.e. the with class "figure". Setting attributes on the image link
with #+attr_html as usual should work, because they are passed to the
figure container rather than to the .
Either:
#+attr_html: :width 200px
[[path/to/image.svg]]
or:
#+html_head_extra: #svgfig {width: 200px; }
#+attr_html: :id svgfig
[[path/to/image.svg]]
For this to work, the SVG needs to be written to be scalable (with
viewport set etc.).
Yours,
Christian
Re: [O] Babel CALL no longer produces HTML output
Jarmo Hurri writes: >> Try: >> >> #+CALL: rekursio-pystyviivat[:noweb yes]() :results export html > > Greetings Christian, > > for some reason that did not improve the end result. Sorry, I had that solution freshly in mind from a different problem (involving #+INCLUDE, not #+CALL), and typed without thinking. I see Charles Berry had the right answer. Yours, Christian
Re: [O] Request: change SVG embedding in exported HTML
I also disagree with myself :-) -- I wrote: > To sum up, makes the most common task simpler (scaling the > graphic), but the Org example I included seems to show that can be just as simple from Org. Forgot to edit the conclusion. cm
Re: [O] Request: change SVG embedding in exported HTML
I disagree. A switch to for SVG export (1) is not necessary for
scaling, and (2) would disable other useful features that are presently
available out of the box.
(1) It *is* a bit easier to scale SVG with in HTML. But you *can*
scale SVG with by putting the in a container and
scaling the container width and height.
This is actually simple with Org, which natively wraps the in a
tag, and passes any attributes to the latter. To
scale an arbitrary image.svg e.g. to 100px width, try:
#+attr_html: :width 100px
[[path/to/image.svg]]
Alternatively, you can use #+attr_html to set an id on the figure ,
and style it with CSS.
(2) You can also do other things with that you cannot with
, like manipulating the SVG with Javascript and styling it with an
external stylesheet (linked from the SVG, not the web page).
Raw SVG in the exported HTML is a third option that is very plain-texty
and supports all the mentioned features, but it tends to bloat files,
and doesn't encourage caching and re-using of an image across web pages.
To sum up, makes the most common task simpler (scaling the
graphic), but at the cost of features such as interactive animated
graphics, which are possible with or SVG islands.
Yours,
Christian
Scott Randby writes:
> On 07/23/2016 08:53 AM, Jarmo Hurri wrote:
>>
>> Greetings.
>>
>> Request: An SVG file embedded in exported HTML should be embedded using
>> the tag instead of .
>
> I second this request. Right now, I use HTML code for SVG images, and
> I'd rather use Org markup instead.
>
> Scott Randby
>
>>
>> Short reasoning: The displayed size of the SVG image can not be
>> controlled from outside the SVG file when embedded using , but
>> size can be controlled when embedded using .
>>
>> Here is the longer explanation.
>>
>> The HTML exporter currently embeds SVG as an object. Here is an example
>> of the HTML produced by the exporter:
>>
>>
>>
>> Sorry, your browser does not support SVG.
>>
>>
>>
>> I have in the past couple of days found out that there is a serious
>> disadvantage to this: the displayed size of the resulting web page image
>> can not be controlled in any reasonable manner; see, for example
>>
>> https://css-tricks.com/scale-svg/
>>
>> However, the size _can_ be controlled if embedding is done with an
>> . For example, the exported code above could be
>>
>>
>>
>>
>>
>> I have included 'class="org-svg"' above so that embedded SVG images can
>> then be distinguished from other images in CSS files. For example, the
>> following CSS then sets the width of SVG images to be 80% of the width
>> of the viewport.
>>
>> .org-svg
>> {
>> width: 80vw;
>> }
>>
>> Current embedding using has a nice textual fallback property
>> for browsers not capable of SVG (I have no idea if this support is
>> necessary nowadays). If need be, such fallback could also be added to
>> embedding using . See
>>
>> http://www.w3schools.com/jsref/event_onerror.asp
>>
>> Jarmo
>>
>>
>>
[O] proposed modification of org-display-inline-images
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. 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. 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? -- 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
Re: [O] #+BEGIN_html/#+END_html tags not exporting literally to html anymore?
Thanks for the comments... very helpful! This is a perfect example of when living on the bleeding edge of a library and searching for solutions can come into conflict. I'll stick to looking at the docs built off the git repo. On Fri, Jul 22, 2016 at 5:15 PM, Nick Dokos wrote: > Adam Aviv writes: > > > On Fri, Jul 22, 2016 at 12:38 PM, Charles C. Berry > wrote: > > > > It is updated. For example, see > > > > (info "(org) Special blocks") > > and > > (info "(org) results") > > > > and in ORG-NEWS. > > > > I see that now, but the online documentation is still out dated: > > > > http://orgmode.org/manual/Quoting-HTML-tags.html > > > > Is there a push cycle to keep the online documents up to date with the > source documentation? Or is that > > controlled differently? > > > > That's because the online docs are for the stable version (the version > you get from the maint branch of the git repo). > > If you are using latest (i.e. the master branch of the git repo), then > you have to build and use the docs that come with it: > > make info > > I do > > --8<---cut here---start->8--- > > INFOPATH=$HOME/src/emacs/org/org-mode/doc:/usr/local/share/info:/usr/share/info > export INFOPATH > --8<---cut here---end--->8--- > > in my login shell initialization file to make sure that I pick the > version I built over any other versions installed on my system. > There are other ways to do that - and even for this one, you will > have to modify the paths appropriately. > > -- > Nick > > > -- Adam J. Aviv, PhD *Asst. Professor* *Computer Science* *U.S. Naval Academy* *(410) 293- 6655 <%28410%29%20293-%206655>*
Re: [O] Best practice for canceled/moved recurring events
And sabrewo...@gmail.com writes:
> What is the best way of dealing with scenarios where (1) the meeting "next
> week" is on the Wednesday and (2) the meeting "two weeks" after that (or
> whatever) is canceled?
Right now, I keep the typical meeting (titled with "Standing: ")
and add exceptions as separate events ("Exception: "). The
version of owncloud I'm using as a sync target for org and my
phone doesn't handle exceptions anyways.
Re: [O] Request: change SVG embedding in exported HTML
Nicolas Goaziou writes:
> Jarmo Hurri writes:
>
>> Request: An SVG file embedded in exported HTML should be embedded using
>> the tag instead of .
>
> Would you like to provide a patch to this effect? It probably boils down
> to modifying `org-html--svg-image'.
Yes indeed. Please find, at the end of this message, a patch and a test
file. The test file assumes you have Asymptote installed, along with
dvisvgm and probably also convert from ImageMagick; the last two are
needed by Asymptote to produce SVG and JPG output.
I have tested that
- if the browser has SVG support (as almost all do)
1. the default behaviour works (embedding an SVG file)
2. the fallback works if the SVG file is missing (you can test this by
first exporting the test file as HTML, and then removing the SVG file)
- if the browser is missing SVG support (this test was done
with the text-based browser 'links')
- if no fallback is set, the browser will display the text "Sorry,
your browser does not support SVG." as before (and as expected)
Now the case I have _not_ been able to test is the one where the browser
is missing SVG support, and the fallback is set. Unfortunately in this
case the 'links' browser displays nothing in the place of the SVG image,
and I don't know of another browser I could use to test the behaviour.
The first line of the test file can be used to verify that the embedded
SVG file now 'responds' to CSS settings.
I also added the new CSS class to the manual.
If this patch is ok, then what is missing are the default CSS settings
for the new class org-svg in constant org-html-style-default. I simply
did not know what to put there. The manual says that this constant has
basic settings for _all_ defined CSS entities. Either defaults need to
be set for the new class, or the text in the manual needs to be
changed. Or we have to accept that the manual is not logically
coherent. :-)
Jarmo
>From 23776bb643354aaaba09289300fc5c79ce747f4c Mon Sep 17 00:00:00 2001
From: Jarmo Hurri
Date: Sun, 24 Jul 2016 16:37:21 +0300
Subject: [PATCH] lisp/ox-html.el: Embed SVG images with tag instead of
* lisp/ox-html.el (org-html--svg-image): Embed SVG file using
tag, providing fallbacks for cases where SVG is not supported or SVG
file is missing. Also provide CSS class org-svg for customizing
presentation of embedded SVG images.
* doc/org.texi (CSS support): Documentation of CSS class org-svg for
SVG images embedded into exported HTML.
---
doc/org.texi| 1 +
lisp/ox-html.el | 18 +-
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 1c3868c..c53d1c6 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -11750,6 +11750,7 @@ div.footnotes @r{footnote section headline}
p.footnote @r{footnote definition paragraph, containing a footnote}
.footref@r{a footnote reference number (always a )}
.footnum@r{footnote number in footnote definition (always )}
+.org-svg@r{linked SVG image}
@end example
@vindex org-html-style-default
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index ce4694d..f5b5497 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1628,21 +1628,21 @@ a communication channel."
info)))
(defun org-html--svg-image (source attributes info)
- "Return \"object\" appropriate for embedding svg file SOURCE
-with assoicated ATTRIBUTES. INFO is a plist used as a
+ "Return \"img\" appropriate for embedding svg file SOURCE
+with associated ATTRIBUTES. INFO is a plist used as a
communication channel.
The special attribute \"fallback\" can be used to specify a fallback
-image file to use if the object embedding is not supported."
+image file to use if svg display is not supported."
(let ((fallback (plist-get attributes :fallback))
(attrs (org-html--make-attribute-string
(plist-put attributes :fallback nil
- (format "\n%s"
- source attrs
- (if fallback
- (org-html-close-tag
- "img" (format "src=\"%s\" %s" fallback attrs) info)
- "Sorry, your browser does not support SVG."
+(format ""
+ source attrs
+ (if fallback
+ (format "onerror=\"this.src='%s'; this.onerror=null;\""
+ fallback)
+ "alt=\"Sorry, your browser does not support SVG.\""
(defun org-html--textarea-block (element)
"Transcode ELEMENT into a textarea block.
--
2.4.11
#+HTML_HEAD_EXTRA: .org-svg { width: 20vw; }
* test case
#+BEGIN_SRC asymptote :file svg-image.svg
size (1cm, 0);
fill (unitsquare, red);
#+END_SRC
#+ATTR_HTML: :fallback fallback-image.jpg
#+RESULTS:
[[file:svg-image.svg]]
* generation of fallback image
#+BEGIN_SRC asymptote :file fallback-image.jpg
size (2cm, 0);
fill (unitcircle, lightblue + opacity (.5));
label ("fallback", (0, 0));
#+END_SRC
Re: [O] how to set a persistent bookmark ...
(require 'saveplace) (setq-default save-place t) On 24 July 2016 at 03:03, Sharon Kimble wrote: > > How can I set a persistent bookmark, showing just the date and time > please? The date and time should be in the form of '-MM-DD HH:MM' - > using the 24-hour clock system - and they should be persistent to > survive if/when emacs crashes please? > > And following on from that request, how can I visually see the bookmark > set in the file, amongst all the text, please? > > Its just that when I've been working on a very long document it would be > nice to go away from the document and know that I could return to the > same place if the computer went down with a powercut. > > Thanks > Sharon. > -- > A taste of linux = http://www.sharons.org.uk > TGmeds = http://www.tgmeds.org.uk > Debian 8.4, fluxbox 1.3.7, emacs 25.0.95 -- Phil Hudson http://hudson-it.ddns.net @UWascalWabbit PGP/GnuPG ID: 0x887DCA63
Re: [O] Apply patch from org document
"Charles C. Berry" writes: > On Sun, 24 Jul 2016, Óscar Fuentes wrote: > >> Is there a method for applying a patch/diff embedded in a code block? >> > > If by `embedded' you mean that the body of a src block is a patch such > as provided by `git format-patch', you could use the language `diff'. > `org-edit-src-code' (typing C-c ') with point in the block will open a > buffer with the body as its contents in Diff mode. You can use the > Diff menu to do various things like apply the patch. When you are done > another C-c ' will close the buffer. Interesting. For some reason the patch can't be applied with a single command (diff-ediff-patch is unable to figure out the target files, but Apply Hunk works fine; that's an issue to be discussed on the emacs ml, though.) Anyway this is more convenient than extracting the patch and applying it from a shell. > With some effort, you can follow ob-template.el[1] as a guide to > crafting ob-diff.el (say) to allow execution of src blocks, if you > think you need to go that far. Precisely, I was expecting to see a Babel module for diffs but writing one for this task is overkill. A function that extracts the current block, creates a patch and runs `patch' on it will do too and seems like an easy one to write. Will go down that route if the issue with diff-ediff-patch can't be fixed. Thank you Chuck.
[O] showing the scheduled/due date in agenda view in the header ?
Hi all i was wondering if there is a way to add the scheduled/due date in agenda view in the header ? so it would look like this: Wednesday 27 July 2016 meet:9:00.. meet zack <2016-01-18 Mon 17:30-18:00> best! Z
Re: [O] automatically run code blocks when loading an org-mode document
On Friday, 22 Jul 2016 at 22:11, Nick Dokos wrote: [...] > # -*- find-file-hook: org-babel-execute-buffer -*- > #+BEGIN_SRC emacs-lisp > (defun handy-stuff(arg) > (message arg)) > #+END_SRC > > [[elisp:(handy-stuff "foo")][foo]] > [[elisp:(handy-stuff "bar")][bar]] > > will do that (but you get a question re. "safe" local variables when > you open the file). It also executes *every* code block in the buffer > which you might not want to do (although it does not matter in this > case). For the OP, instead of evaluating every code block, it is possible to evaluate just one code block. I have: # Local Variables: # eval: (esf/execute-startup-block) # End: in my org file with #+begin_src emacs-lisp (defun esf/execute-startup-block () (interactive) (org-babel-goto-named-src-block "startup") (org-babel-execute-src-block)) #+end_src and so only a block named startup will be executed. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.94.1, Org release_8.3.4-1049-g481709
Re: [O] Request: change SVG embedding in exported HTML
Hello, Jarmo Hurri writes: > Request: An SVG file embedded in exported HTML should be embedded using > the tag instead of . Would you like to provide a patch to this effect? It probably boils down to modifying `org-html--svg-image'. Regards, -- Nicolas Goaziou
