Org 9.5 broke the rendering of my SVG images
Hi, In Org 9.5, SVG images started being exported by the HTML exporter as rather than . The patch causing that was https://list.orgmode.org/87k0pemj6d@gmail.com/T/ with two arguments: 1) do not have an alt attribute 2) will not render some SVG file correctly if it has no viewBox (I'm assuming that the issue shown in that message is a missing viewBox). The reason I've noticed this change is that it broke my web pages. On my pages, I use SVG to display many automata, and they all share a common stylesheet. That stylesheet is not inlined into the SVG, rather, it is a separate file included in the SVG files with so that the browser only need to download it once. Infortunately, does not allow external stylesheets to be processed, so my stylesheets are now ignored. Note that one can also build SVG images that include other SVG images, or SVG images that have animations that start when you hover on some elements. All those usages would break with . I've seen that very issue was discussed back in 2016 https://list.orgmode.org/871t2iq353@iki.fi/T/ where Christian Moe pointed out exactly this: > (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). So in the interest of allowing users to build documents where SVG files are not static, self-contained images, it seems to me that Org probably needs some way to specify whether SVG images should be exported as or (or maybe even inlined). Also regarding the alt attribute, maybe the code exporting Your browser does not support SVG could be taught to use alt text when such an alt= attribute is given. (I have no clue if that's "accessible" enough.) In the meantime, I'm advicing org-html--format-image as follows to get the original behavior in my project. (I also need to support different Org-mode versions, hence the fboundp check.) ;;; Org-mode 9.5 is now using to render SVG images. ;;; Unfortunately, this breaks SVG images that use external style ;;; sheets as are expected to be self-contained. ;;; ;;; Since we do use such external style-sheets and never had ;;; any issue with , we revert ;;; to the previous behavior. ;;; ;;; The following function is based on org-html--svg-image from ;;; Org-mode 9.4.5, with the addition of the SVG extension test. (defun spot-svg-output-as-object (source attributes info) "If source is an SVG file, return an \"object\" embedding svg file SOURCE with given ATTRIBUTES. INFO is a plist used as a communication channel. Otherwise return nil. The special attribute \"fallback\" can be used to specify a fallback 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." (when (string= "svg" (file-name-extension source)) (let ((fallback (plist-get attributes :fallback)) (attrs (org-html--make-attribute-string (org-combine-plists ;; Remove fallback attribute, which is not meant to ;; appear directly in the attributes string, and ;; provide a default class if none is set. '(:class "org-svg") 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.") ;;; Hack org-html--format-image to call the above first. ;;; (The org-html--svg-image function was removed when the formater code ;;; switched to for SVG.) (unless (fboundp 'org-html--svg-image) (advice-add 'org-html--format-image :before-until 'spot-svg-output-as-object)) -- Alexandre
diagnosing SRC blocks with different output on export
Hi, Is there a way to mark certain SRC blocks such that if evaluating them during export produces a result different from the one stored in the file, then the export process aborts with an error? I'm using org-mode to document an automaton library, and use org-babel block to run some examples and have their output automatically recomputed when the library is improved. However, some examples expect some specific automata to be produced, maybe because I discuss some particularities of that example automaton in the text ; if an update of the library causes this to change, I need to detect that change to adjust all the text around it in the documentation, or find a better exemple. So I'd like org-mode to signal me that my expected result is non-longuer what is produced by causing the export (and therefore my build) to fail. Can this be achieved already? Reading https://orgmode.org/manual/Results-of-Evaluation.html it seems like I'd like I'm asking for a new form of handling. Something like "compare" instead of "replace". Best regards -- Alexandre Duret-Lutz
Re: [O] #+PROPERTY: header-args:C++ will not work
On Mon, Apr 15, 2019 at 2:53 PM Alexandre Duret-Lutz wrote: > Unfortunately, this does not work for C++ blocks. I just noticed that I could change all my C++ blocks into cpp blocks and then use header-args:cpp without any problem. The org-mode manual states that the identifier for the C++ language is "C++" (https://orgmode.org/manual/Languages.html) but the same page links to some babel documentation (https://orgmode.org/worg/org-contrib/babel/languages.html) where it is listed as "cpp". ORG-NEWS has one example using C++, but the test suite only has cpp examples. There is some hint on https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html#orgea7b004 that using cpp might not fully work (?). And clearly while lisp/org-src.el has many functions implemented for both cpp and C++, its not always complete. For instance it defines org-babel-header-args:C++ but there is no org-babel-header-args:cpp, meaning incomplete completion for cpp blocks header-args. >From all that it feels like the documentation wants us to use C++, and that the code is trying to keep cpp for backward compatibility (?), but that each option has different drawbacks. I'll stick to C++ and header-args:C+++... -- Alexandre Duret-Lutz
[O] #+PROPERTY: header-args:C++ will not work
Hi,
I'm currently simplifying some documentation that evaluates a lot of
sh/python/C++ blocks by defining the :results and :exports flags
commonly used in header-args properties like so:
#+PROPERTY: header-args:sh :results verbatim :exports both
#+PROPERTY: header-args:python :results output :exports both
#+PROPERTY: header-args:C++ :results verbatim :exports both
Unfortunately, this does not work for C++ blocks.
Looking at the contents of org-file-properties in a file with the
above lines shows
org-file-properties is a variable defined in ‘org.el’.
Its value is
(("header-args:C+" . ":results verbatim :exports both")
("header-args:python" . ":results output :exports both")
("header-args:sh" . ":results verbatim :exports both"))
Note how C++ is truncated to C+.
The documentation states:
1. Language-specific header arguments are also read from properties
‘header-args:’ where is the language identifier.
(https://orgmode.org/manual/Using-Header-Arguments.html#Code-block-specific-header-arguments)
2. If you want to add to the value of an existing property, append a
‘+’ to the property name.
(https://orgmode.org/manual/Property-Syntax.html#Property-Syntax)
Unfortunately it seems statement 2 breaks statement 1 when LANG ends
with '+', and header-args:C++ is understood as appending
header-args:C+.
I currently work around this problem by using header-args:C+++
instead, but this only works assuming that property header-args:C++
has not been set by other means.
I there other way to assign (not append) some value to the header-args
property from the some org file?
--
Alexandre Duret-Lutz
Re: [O] Bug: regression with :export both :noweb strip-export [9.2 (9.2-elpa @ /home/adl/.emacs.d/elpa/org-20181230/)]
On Tue, Jan 15, 2019 at 11:50 PM Alexandre Duret-Lutz
wrote:
> Since I updated to org 9.2, the following idiom stopped working.
>
> --
> #+NAME: context
> #+BEGIN_SRC C++ :exports none
> #include
> int u = 0;
> #+END_SRC
>
> #+BEGIN_SRC C++ :exports both :noweb strip-export :results verbatim
> <>
> int main()
> {
> std::cout << "bar\n";
> return u;
> }
> #+END_SRC
> --
>
> Upon export to html I'm expecting to see the second block of code with
> <> stripped away, followed by a block of text containing the
> result (bar). With Org 9.2 I don't get the latter, because the
> compilation of this small program fails during the export. Inspection
> of the temporary file passed to the compiler reveals that <>
> has been stripped away from the code passed as input to the compiler,
> not just from the code displayed in html.
FWIW, reverting the change made to org-babel-exp-results in the following
patch seems to fix my issue.
commit 8e54cafeb286ea5eb25565a637b121a2f597c48b
Author: Nicolas Goaziou
Date: Sat Jun 23 23:04:45 2018 +0200
Fix noweb expansion during export
* lisp/ob-core.el (org-babel-sha1-hash): Add optional argument to
specify context.
(org-babel-execute-src-block): Use new argument.
* lisp/ob-exp.el (org-babel-exp-src-block): Use new argument.
(org-babel-exp-results): Fix context.
Reported-by: Ken Mankoff
<http://lists.gnu.org/r/emacs-orgmode/2018-06/msg00117.html>
--
Alexandre Duret-Lutz
[O] Bug: regression with :export both :noweb strip-export [9.2 (9.2-elpa @ /home/adl/.emacs.d/elpa/org-20181230/)]
Hi!
I have some documentation where I use the noweb syntax to include some
common context in some code fragment I want to discuss. On export
I'd like to display the code fragments without the common context,
followed by their output.
Since I updated to org 9.2, the following idiom stopped working.
--
#+NAME: context
#+BEGIN_SRC C++ :exports none
#include
int u = 0;
#+END_SRC
#+BEGIN_SRC C++ :exports both :noweb strip-export :results verbatim
<>
int main()
{
std::cout << "bar\n";
return u;
}
#+END_SRC
--
Upon export to html I'm expecting to see the second block of code with
<> stripped away, followed by a block of text containing the
result (bar). With Org 9.2 I don't get the latter, because the
compilation of this small program fails during the export. Inspection
of the temporary file passed to the compiler reveals that <>
has been stripped away from the code passed as input to the compiler,
not just from the code displayed in html.
Changing ":exports both" to ":exports results" has the same issue.
Evaluating the code block with C-c C-c works correctly. So it seems to
me that the meaning of "strip-export" was changed from "strip noweb
markers before exporting source blocks" to "strip noweb markers for
source blocks before exporting or even when evaluating them via
:export". Was this meant?
One workaround I have found is to evaluate such code fragments via noweb
instead of via :exports.
--
#+NAME: context2
#+BEGIN_SRC C++ :exports none
#include
int u = 0;
#+END_SRC
#+NAME: bar2
#+BEGIN_SRC C++ :exports code :noweb strip-export :results verbatim
<>
int main()
{
std::cout << "bar\n";
return u;
}
#+END_SRC
#+BEGIN_SRC text :noweb yes
<>
#+END_SRC
--
(This is not exactly equivalent from a CSS point of view, but at least
it exports the output.)
Emacs : GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.2)
of 2018-12-18, modified by Debian
Package: Org mode version 9.2 (9.2-elpa @ /home/adl/.emacs.d/elpa/org-20181230/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-latex-listings 'minted
org-babel-after-execute-hook '((lambda nil (org-redisplay-inline-images)))
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-protocol-default-template-key "w"
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-src-tab-acts-natively t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-special-ctrl-a/e t
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-startup-with-inline-images t
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-file-apps '(("\\.pdf::\\([[:digit:]]+\\)\\'" . org-pdfview-open)
("\\.pdf\\'" . org-pdfview-open)
(auto-mode . emacs) ("\\.mm\\'" . default) ("\\.x?html?\\'" .
default)
("\\.pdf\\'" . default))
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-babel-load-languages '((shell . t) (python . t) (plantuml . t) (dot . t)
(R . t) (C . t))
org-babel-python-command "/usr/bin/python3"
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php)
("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer" . latex)
("calc" . fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot" . fundamental)
("elisp" . emacs-lisp)
("ocaml" . tuareg) ("screen" . shell-script) ("shell" .
sh) ("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-babel-tangle-lang-exts '(("D" . "d") ("C++" . "cpp") ("python" . "py")
("emacs-lisp" . "el")
("elisp" . "el"))
org-return-follows-link t
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open) ("eww" :follow eww :store
org-eww-store-link)
("rmail" :follow org-rmail-open :store
[O] Bug: using :flags for C source block produce invalid html [8.2.1 (8.2.1-15-ge5cecc-elpa)]
Hi, Passing flags to following two blocks differs only by their :flags option #+BEGIN_SRC C :export code :include stdio.h int a = 2; int b = 3; printf(%d, a + b); #+END_SRC #+BEGIN_SRC C :export code :include stdio.h :flags -I. int a = 2; int b = 3; printf(%d, a + b); #+END_SRC When I export them with with C-x C-e h h, I get the following HTML (excerpt): div class=org-src-container pre class=src src-Cspan style=color: #7CB8BB;int/span span style=color: #DFAF8F;a/span = 2; span style=color: #7CB8BB;int/span span style=color: #DFAF8F;b/span = 3; printf(span style=color: #CC9393;%d/span, a + b); /pre /div div class=org-src-container pre class=src src-C-I.int a = 2; int b = 3; printf(%d, a + b); /pre /div Notice how the second block has class=src src-C-I. and no color? Emacs : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2) of 2013-06-25 on sochi, modified by Debian Package: Org-mode version 8.2.1 (8.2.1-15-ge5cecc-elpa @ /home/adl/.emacs.d/elpa/org-20131021/) current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-log-done 'time org-confirm-shell-link-function 'yes-or-no-p org-latex-format-headline-function 'org-latex-format-headline-default-function org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) ) -- Alexandre Duret-Lutz
