Is there a way to set options *programatically* ?
Dear list,
I'd like to create a function able to set some options, namely
- `#+options: tex:`{t|dvipng|imagemagick}
- `#+export-file-name:`
I have been unable to find a *documented* way to do that from `elacs-lisp`.
I *think* that an `org` source block could place those options in the buffer,
but I can't find a way to reliably trigger a "setup refreshment" of these
options from `emacs-lisp`.
Any ideas ?
Sincerely yours,
--
Emmanuel Charpentier
Re: [BUG] LaTeX preview should use a subdirectory in /tmp
Le mercredi 17 avril 2024 à 22:41 +0200, Emmanuel Charpentier a écrit : [ Snip... ] A couple more data points : * The problem I described happens when I run `emacs` on files belonging in a Windows tree, symlinked to the Linux tree. Running `emacs` on files outside this symlinked tree works OK. This suggests that it might be worth testing trhese exports from network directories. * Trying this with the current Org from the git directory succesfully builds the images but fails at inserting them in the `.odt` file (Org mistakenly inserts the "file:" string in the name of the needed image file). * Trying `dvisvgm` fails because Org does not recognize this as a valid format and insists on `verbatim`. HTH,
Re: [BUG] LaTeX preview should use a subdirectory in /tmp
Le mercredi 17 avril 2024 à 20:18 +, Ihor Radchenko a écrit :
> Emmanuel Charpentier writes:
[ Snip... ]
> What if you do M-x trace-function org-compile-file-commands
No such function : I just have org-compile-file , which I traced.
>
> and run the preview.
> Then, a buffer should appear listing the command expansions used
> during
> the preview process. May you then share that buffer?
Here it comes :
Buffer "Trace output" :
*
==
1 -> (org-compile-file "/tmp/orgtexD0afvR.tex" ("latex -interaction
nonstopmode -output-directory %o %f") "dvi" "Please adjust `dvipng'
part of `org-preview-latex-process-alist'." #)
1 <- org-compile-file: "/tmp/orgtexD0afvR.dvi"
==
1 -> (org-compile-file "/tmp/orgtexD0afvR.dvi" ("dvipng -D %D -T tight
-bg Transparent -o %O %f") "png" "Please adjust `dvipng' part of `org-
preview-latex-process-alist'." #
((68 . "140.0") (83 . "1.0")))
1 <- org-compile-file: !non-local\ exit!
*
Buffer "*Org Preview LaTeX Output*" :
*
../../../../../tmp/orgtexD0afvR.dvi: No such file or directory
This is dvipng 1.15 Copyright 2002-2015 Jan-Ake Larsson
*
HTH,
Re: [BUG] LaTeX preview should use a subdirectory in /tmp
Le mercredi 17 avril 2024 à 16:48 +, Ihor Radchenko a écrit :
> Emmanuel Charpentier writes:
>
> > I have a case where the current way of forcing the temporary
> > directory
> > to me `/tmp` is wrong. Running emacs on Ubuntu **under WSL2**,,
> > exporting latex snippets to ODT *as images* fails : the `.dvi`
> > files
> > are correctly compiled and placed in `/tmp{, but the convert
> > program
> > tries to read them in `../../../../tmp/`, which is indeed `/tmp` in
> > a
> > "normal" filesystem but **is not** in WSL, where the root (`/`) is
> > in
> > fact a mounted tree.
> >
> > Admittedly, this is a corner case, but it turned out to be
> > necessary
> > (exporting via mathml gave unsatisfying results).
>
> It looks like is a different bug. (probably even in Emacs, when
> calculating relative path)
That might also be an idiosyncratic bug of WSL2' implementation of the
virtual machine filesystem...
>
> Assuming that your `org-preview-latex-default-process' is using the
> default value of 'dvipng, does it help if you change the image
> convertor
> command to use absolute path?
I didn't know that one could do that : the placeholders are not well
documented...
>
> (plist-put (alist-get 'dvipng org-preview-latex-process-alist)
> :image-converter
> '("dvipng -D %D -T tight -o %O %F"))
Nope, same problem : the *Org Preview LaTeX Output* buffer says :
../../../../../tmp/orgtexSyy18r.dvi: No such file or directory
This is dvipng 1.15 Copyright 2002-2015 Jan-Ake Larsson
If I understand it correctly, the %F placeholder should be an
*absolute* filename. It is not...
Couldn't the output directory of the :latex-compiler element being
hardcoded to, say, the curerent directory or a subdirectory thereof,
and ditto for the input directory of :image-converter ?
Sincerely,
Re: [BUG] LaTeX preview should use a subdirectory in /tmp
On 25/03/2024 19:49, Max Nikulin wrote:
> > (defun org-ensure-tmp-dir (dir-symbol prefix)
> > (let ((dir (symbol-value dir-symbol)))
> > ;; Temporary directory has not been cleaned.
> > (or (and dir (file-directory-p dir) dir)
>
>
>`if' should be used instead of `or' here.
>
>
>
>>
>> (setf (symbol-value dir-symbol)
>> (make-temp-file (or prefix "orgtmp-") 'dir)
>>
>> (defvar org-tex-tmpdir nil)
>>
>> Usage example: (org-ensure-tmp-dir 'org-tex-tmpdir "orgtex-")
> I do not like that the function may be called with
different `temporary-file-directory' and I can not figure out how to
adjust API to handle such case. On the other hand I am unsure if it is
a realistic case when this function is called with
alternating `temporary-file-directory'.
I have a case where the current way of forcing the temporary directory
to me `/tmp` is wrong. Running emacs on Ubuntu **under WSL2**,,
exporting latex snippets to ODT *as images* fails : the `.dvi` files
are correctly compiled and placed in `/tmp{, but the convert program
tries to read them in `../../../../tmp/`, which is indeed `/tmp` in a
"normal" filesystem but **is not** in WSL, where the root (`/`) is in
fact a mounted tree.
Admittedly, this is a corner case, but it turned out to be necessary
(exporting via mathml gave unsatisfying results).
How to convert an HTML export bloc to a normal Org Babel output ?
Dear list,
I stumbled on the conversion of an HTML Babel export block to a "normal" Babel
output. What follows is the *verbatim* transcript of an org file explaining and
demonstrating the problem :
```
# Attempt to use emacs-jupyter to insert Dyalog APL org-src blocks.
#+options: author:nil toc:nil
#+latex_compiler: lualatex
#+latex_header: \usepackage{minted}
#+latex_header: \usepackage{fontspec}
#+latex_header: \setmonofont{Unifont}
#+property: header-args:jupyter-apl :kernel dyalog-kernel :session pa
I want to use APL `src` blocks in an Org document. This can be done by using
[[https://www.dyalog.com/][Dyalog APL]] interpreter though
[[https://github.com/emacs-jupyter/jupyter][jupyter-emacs]] and the Dyalog
[[https://github.com/Dyalog/dyalog-jupyter-kernel][jupyter kernel]].
This apparently works :
#+begin_src jupyter-apl :exports both :results replace
⍳7
#+end_src
#+RESULTS:
#+begin_export html
1 2 3 4 5 6 7
#+end_export
But, no matter what I try to use as parameters, Dyalog's kernel returns an HTML
block, which exports to HTML
successfully (of course) but /not/ to LaTeX nor `.odt`/`docx` or even `Unicode
text`. A glimpse at the
kernel's source code (partially in APL, beware !) suggests that's a /feature/
of this kernel, which returns
either HTML or graphics (which I didn't (yet) attempt to use).
I then attempted to work around this (mis)feature by converting the HTML block
to text, using this
Stackoverflow
[[https://stackoverflow.com/questions/64796235/html-to-text-conversion-in-emacs][suggestion]]
:
#+name: html2text
#+begin_src emacs-lisp :var data="" :exports code :results silent
(with-temp-buffer
(insert data)
(shr-render-region (point-min) (point-max))
(buffer-substring-no-properties (point-min) (point-max)))
#+end_src
#+RESULTS: html2text
The conversion works fine :
#+begin_src jupyter-apl :exports both :results raw :post html2text(data=*this*)
⍳7
#+end_src
#+RESULTS:
#+begin_export html
1 2 3 4 5 6 7
#+end_export
but what /enrages/ me is that the (correct) result is still wrapped in an HTML
block ; again, I have been
unable to obtain a "normal" output.
Can someone suggest a way to transform an HTML export block to a normal output ?
```
Source file and various exports enclosed (HTML is correct, the other ones not).
The question still holds...
DyalogAttempt.html
Description: application/xhtml
DyalogAttempt.odt
Description: application/vnd.oasis.opendocument.text
# Attempt to use emacs-jupyter to insert Dyalog APL org-src blocks.
#+options: author:nil toc:nil
#+latex_compiler: lualatex
#+latex_header: \usepackage{minted}
#+latex_header: \usepackage{fontspec}
#+latex_header: \setmonofont{Unifont}
#+property: header-args:jupyter-apl :kernel dyalog-kernel :session pa
I want to use APL `src` blocks in an Org document. This can be done by using [[https://www.dyalog.com/][Dyalog APL]] interpreter though [[https://github.com/emacs-jupyter/jupyter][jupyter-emacs]] and the Dyalog [[https://github.com/Dyalog/dyalog-jupyter-kernel][jupyter kernel]].
This apparently works :
#+begin_src jupyter-apl :exports both :results replace
⍳7
#+end_src
#+RESULTS:
#+begin_export html
1 2 3 4 5 6 7
#+end_export
But, no matter what I try to use as parameters, Dyalog's kernel returns an HTML block, which exports to HTML successfully (of course) but /not/ to LaTeX nor `.odt`/`docx` or even `Unicode text`. A glimpse at the kernel's source code (partially in APL, beware !) suggests that's a /feature/ of this kernel, which returns either HTML or graphics (which I didn't (yet) attempt to use).
I then attempted to work around this (mis)feature by converting the HTML block to text, using this Stackoverflow [[https://stackoverflow.com/questions/64796235/html-to-text-conversion-in-emacs][suggestion]] :
#+name: html2text
#+begin_src emacs-lisp :var data="" :exports code :results silent
(with-temp-buffer
(insert data)
(shr-render-region (point-min) (point-max))
(buffer-substring-no-properties (point-min) (point-max)))
#+end_src
#+RESULTS: html2text
The conversion works fine :
#+begin_src jupyter-apl :exports both :results raw :post html2text(data=*this*)
⍳7
#+end_src
#+RESULTS:
#+begin_export html
1 2 3 4 5 6 7
#+end_export
but what /enrages/ me is that the (correct) result is still wrapped in an HTML block ; again, I have been unable to obtain a "normal" output.
Can someone suggest a way to transform an HTML export block to a normal output ?
DyalogAttempt.pdf
Description: Adobe PDF document
% Created 2023-05-24 mer. 11:50
% Intended LaTeX compiler: lualatex
\documentclass[11pt]{article}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage{minted}
\usepackage{fontspec}
\setmonofont{Unifont}
\date{\today}
\title{}
\hypers
Re: [BUG](?) Export to beamet recently stopped working.
Le jeudi 11 août 2022 à 12:32 +, Fraga, Eric a écrit : > On Thursday, 11 Aug 2022 at 13:51, Emmanuel Charpentier wrote: [ Snip... ] > > Why locally ? > > In case you have different configurations. Nice idea ! I was (still am) aiming at a "default configuration" I could slap on my .init.el. But your idea of local configuration might go on document templates. > But if you are happy with > this as a global value, just use setq instead. I tend to configure > each > (large) org document with local settings so that they don't interfere > with each other. What about emacs' "custom" interface ? Do you use it ? Thanks again !
Re: [BUG](?) Export to beamet recently stopped working.
Le jeudi 11 août 2022 à 09:48 +, Fraga, Eric a écrit :
> On Thursday, 11 Aug 2022 at 10:00, Emmanuel Charpentier wrote:
> > Since about a week, exporting directly to Beamer ceased to work.
> > See
> > the attached Minimal.org file :
> > Debugger entered--Lisp error: (wrong-type-argument sequencep 108)
>
> org-latex-pdf-process should be a list of strings, not a string.
Aaaarghhh... You're right. This works perfectly.
Old age is a wreckage...
> Also,
> I would not use custom-set-variables but simply set the value
> locally:
>
> #+begin_src emacs-lisp :exports none :results silent
> (require 'ox-beamer)
> (setq-local org-latex-pdf-process
> '("latexmk -shell-escape -f -pdf -%latex -
> interaction=nonstopmode -output-directory=%o %f"))
> #+end_src
Why locally ?
What's the point ?
I don't doubt that it exists, but I don't see it.
Anyway, thank you very much !
--
Emmanuel Charpentier
Now, where is that wakisashi ?...
[BUG](?) Export to beamet recently stopped working.
Dear list,
Since about a week, exporting directly to Beamer ceased to work. See
the attached Minimal.org file :
- This file exports perfectly to a LaTeX file (via C-c C-e l b).
- The resulting Minimal.tex exports perfectly to Minimal.pdf.
- Trying to export directly to PDF via C-c C-e l P fails ; content of
the *Messages* buffer :
-
Saving file /home/charpent/Boulot/Cellule
Innovation/BayesDec/Minimal.tex...
Wrote /home/charpent/Boulot/Cellule Innovation/BayesDec/Minimal.tex
Processing LaTeX file Minimal.tex...
Wrong type argument: sequencep, 108
-
- Ditto when exporting to PDF via C-c C-e l p (= export to PDF withot
making frames at header level 2).
Retrying Beamer PDF export with debug-on-error set to t gives me the
following backtrace :
-
Debugger entered--Lisp error: (wrong-type-argument sequencep 108)
replace-regexp-in-string("%\\(?:\\(?:bib\\|la\\)tex\\|bib\\)\\>"
#f(compiled-function (m) #) 108)
#f(compiled-function (command) #)(108)
mapcar(#f(compiled-function (command) #)
"latexmk -shell-escape -f -pdf -%latex -interaction...")
org-latex-compile("Minimal.tex")
org-export-to-file(beamer "Minimal.tex" nil nil nil nil nil org-
latex-compile)
org-beamer-export-to-pdf(nil nil nil nil)
org-export-dispatch(nil)
funcall-interactively(org-export-dispatch nil)
call-interactively(org-export-dispatch nil nil)
command-execute(org-export-dispatch)
-
which isn't very helpful... Any hint would be welcome.
Sincerely yours,
--
Emmanuel Charpentier
PS : CC me would be appreciated : I'm not on the list, and read it via
the archive...
# Pour débugguer l'exportation Beamer
#+begin_src emacs-lisp :exports none :results silent
(require 'ox-beamer)
(custom-set-variables
'(org-latex-pdf-process
"latexmk -shell-escape -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f"))
#+end_src
#+language: fr
#+options: tex:t toc:nil H:2
# #+latex_compiler: lualatex
#+latex_compiler: latexmk
#+PANDOC_OPTIONS: pdf-engine:latexmk
#+PANDOC_OPTIONS: pdf-engine-opt=-shell-escape
#+PANDOC_OPTIONS: standalone:t
#+property: header-args:sage :session
#+latex_compiler: lualatex
#+latex_class: beamer
#+latex_class_options: [french]
#+latex-header: \usetheme{AnnArbor}
#+latex-header: \usefonttheme{professionalfonts}
#+Latex_header: \usepackage{fontspec}
#+latex_header: \usepackage{unicode-math}
#+latex_header: \setsansfont{Fira Sans}
#+latex_header: \setmathfont{Fira Math}
#+latex_header: \usepackage{babel}
#+latex_header: \usepackage[newfloat]{minted}
#+title: Essais ~beamer~ de ~org~.
#+subtitle: Un orteil dans l'Arctique...
Re: [PATCH] c-csl : accept relative CSL filenames
Quintus' example illustrates why I think my proposed patch is useful (or, rather, will be when corrected :-)), and why the order of research should be from most-specific to less-specific. If a finename is not absolute, search : 1. relatively to the buffer's default directory 2. if 1. unsuccessfull, relatively to`org-cite-csl-styles-dir' 3. if 2. unsuccessfull, relatively to emacs' default directory (BTW : what is this ? How to retrieve it ?) 4. if 3. unsuccessfull, fail. BTW : my current code does *not* work, and I do not understand why my test used to succeed... A better patch will follow ( but not tonight...). HTH, -- Emmanuel Charpentier
Re: [PATCH] c-csl : accept relative CSL filenames
Le mercredi 03 novembre 2021 à 17:19 +0100, Nicolas Goaziou a écrit : > Hello, > > Emmanuel Charpentier writes: > > > This (minuscule) patch allows to pass a relative (to the buffer's > > default directory) file name to denote the CSL style file. > > Thank you. However, I'm not sure to understand the purpose of the > patch. > > > Rationale : this allows the use of "one-of" styles for "one-of" > > projects without overloading a defailt CSL style directory (which may > > or may not exist on a given system : think JabRef users...). Also > > useful for hacked CSL files specific to a given project. > > If we expand every relative file name from `default-directory', what > happens to `org-cite-csl-styles-dir'? Your patch makes this variable > useless, doesn't it? This can be useful to be able, for example, to use a one-off style for a given exporter while keeping a standard one for another exporter (e. g. a one-off exporter for a journal with complicated bibliographic requirement and anorher for a preprint archive of the same paper). > What about using a local `org-cite-csl-styles-dir' instead, using > file-local variables? IMHO, `org-cite-csl-styles-dir' is deemed to be a more-or-less permanent setting (possibly in `.emacs'), whereas allowing a relative filename doesn't need any initial setup. > > + ((and (pred (lambda (x) > > + (let ((fn (expand-file-name x default-directory))) > > + (if (file-exists-p fn) fn nil file) file) > > This pattern returns the relative file name, not the expanded one. It > may not be what you want. >From `expand-file-name' docstring : "expand-file-name is a built-in function in ‘C source code’. (expand-file-name NAME DEFAULT-DIRECTORY) Probably introduced at or before Emacs version 1.6. Convert filename NAME to absolute, and canonicalize it. [ Abridged.. ]" My tests confirmed that. I do not understand how you managed to reach your conclusions... Sincerely, -- Emmanuel Charpentier > > > Regards,
A quick LaTeX reference guide in Org
"A quick LaTeX reference guide"... Nice oxymoron ! -- Emmanuel Charpentier
when does :cache not cache?
Workaround : cache the computations,not the plotting itself (which should be fast,and must be made on every table, anyway...) : #+options: toc:nil author:nil * Main text Use of a static table: #+call: timeit() #+call: testplot[:file test0.pdf](data=table0) #+call: timeit() Use of a slow function: #+call: timeit() #+call: testplot[:file test1.pdf](data=table1) #+call: timeit() Use of a /cached/ slow function: #+call: timeit() #+call: testplot[:file test2.pdf](data=table2) #+call: timeit() * Annexes :noexport: This is not exported, but computes results. #+name: timeit #+begin_src emacs-lisp (format-time-string "%Hh %Mm %Ss") #+end_src #+name: table0 | Val | Square | |-+| | 0 | 0 | | 1 | 1 | | 2 | 4 | | 3 | 9 | | 4 | 16 | #+TBLFM: $2=$1^2 #+name: table1 #+begin_src emacs-lisp (sleep-for 5) (setq s ( list (list "x" "x^2") 'hline)) (dotimes (i 5 s) (setq s (append s (list (cons i (list (* i i))) s #+end_src #+RESULTS[46320b31c46cef901580bad78aee7032d97ffe64]: table1 | x | x^2 | |---+-| | 0 | 0 | | 1 | 1 | | 2 | 4 | | 3 | 9 | | 4 | 16 | #+name: table2 #+begin_src emacs-lisp :cache yes (sleep-for 5) (setq s ( list (list "x" "x^2") 'hline)) (dotimes (i 5 s) (setq s (append s (list (cons i (list (* i i))) s #+end_src #+name: tf | festfile.pdf ] #+RESULTS[46320b31c46cef901580bad78aee7032d97ffe64]: table2 | x | x^2 | |---+-| | 0 | 0 | | 1 | 1 | | 2 | 4 | | 3 | 9 | | 4 | 16 | #+name: testplot #+begin_src gnuplot :var data=table0 :exports results reset plot data with linespoints #+end_src HTH, -- Emmanuel Charpentier
when does :cache not cache?
You may find this John Kitchin's blog post illuminating. HTH, -- Emmanuel Charpentier
[PATCH] c-csl : accept relative CSL filenames
This (minuscule) patch allows to pass a relative (to the buffer's
default directory) file name to denote the CSL style file.
Rationale : this allows the use of "one-of" styles for "one-of"
projects without overloading a defailt CSL style directory (which may
or may not exist on a given system : think JabRef users...). Also
useful for hacked CSL files specific to a given project.
For the same reasons, when the named filename exists both in the
central CSL file and the buffer's default directory, the latter is
retained.
HTH,
PS : Note that I have already transferred my rights to GNU for emacs-
related works.
--
Emmanuel Charpentier
From 80e4121f8a74aec1e5638713ce7af8e041404e44 Mon Sep 17 00:00:00 2001
From: Emmanuel Charpentier
Date: Tue, 19 Oct 2021 19:57:17 +0200
Subject: [PATCH] oc-csl : accept relative CSL filenames
---
lisp/oc-csl.el | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 94de97e33..ab75db85b 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -364,15 +364,19 @@ corresponding to one of the output formats supported by Citeproc: `html',
INFO is the export state, as a property list.
-When file name is relative, expand it according to `org-cite-csl-styles-dir',
+When file name is relative, expand it according to the buffer's default
+directory, failing that according to `org-cite-csl-styles-dir',
or raise an error if the variable is unset."
(pcase (org-cite-bibliography-style info)
('nil org-cite-csl--fallback-style-file)
((and (pred file-name-absolute-p) file) file)
+((and (pred (lambda (x)
+ (let ((fn (expand-file-name x default-directory)))
+ (if (file-exists-p fn) fn nil file) file)
((and (guard org-cite-csl-styles-dir) file)
(expand-file-name file org-cite-csl-styles-dir))
(other
- (user-error "Cannot handle relative style file name: %S" other
+ (user-error "CSL style file not found: %S" other
(defun org-cite-csl--locale-getter ()
"Return a locale getter.
--
2.33.0
How to retrieve ALL the information of an Org table ?
Dear list,
I have problems with exploiting programatically the structure of an Org
table :
I want to write function acting on complex tables, where the original
information is presented along various statistics. My idea is to
isolate the original information in a range delimited (by convention)
by the first and second hlines and by the first and last columns ; the
function should accept the whole table and retrieve the original
data. The point is that the function should accept a variable number of
lines in both the "original data" range and the summary information.
Let ttest such a table with hlines :
#+name: ttest
| ttest | c1 | c2 | rSum |
|---+++--|
| 3 | 3 | 5 | 8 |
| 8 | 8 | 12 | 20 |
|---+++--|
| cSum | 11 | 17 | 28 |
#+TBLFM: @>$2..@>$>=vsum(@I..@II)::@2..@>>$4=vsum($<<..$>>)
ttestc1c2rSum3358881220cSum111728
Passing this table as an argument to source code loses the hlines :
#+begin_src emacs-lisp :exports results :results drawer :var foo=ttest
foo
#+end_src
((ttest c1 c2 rSum) (3 3 5 8) (8 8 12 20) (cSum 11 17 28))
The structure allowing to retrieve the original data is lost.
The point is that the source code can't exploit the hlines to find
relevant information (in the present case, the lines between the
hlines).
Alternatively, one may try and pass the relevant range, using foo=(org-
table-get-remote-range "ttest" "@I$<<..@II$>>") as an argument. This
fails for a different reason :
#+begin_src emacs-lisp :exports results :results drawer :var foo=(org-
table-get-remote-range "ttest" "@I$<<..@II$>>")
foo
#+end_src
(3 5 8 12)
Again, the structure is lost : this time, foo is a "flattened" vector,
whose matricial shape is lost to the processing function.
I am looking for explanations and/or hints.
Attached : the source of the present mail.
Thanks in advance...
--
Emmanuel Charpentier
#+options: author:nil toc:nil
#+property: header-args:python :session
# #+latex_header: \usepackage{minted}
#+begin_src emacs-lisp :exports none
(setq org-odt-preferred-output-format "docx"
org-latex-to-mathml-convert-command
"latexmlmath \"%i\" --presentationmathml=%o"
;; org-latex-listings 'minted
org-latex-listings nil
org-latex-pdf-process
(list "latexmk -pdf -pdflatex='%latex -interaction=nonstopmode
-shell-escape' -bibtex -f %f"))
#+end_src
#+RESULTS:
| latexmk -pdf -pdflatex='%latex -interaction=nonstopmode -shell-escape'
-bibtex -f %f |
Dear list,
I have problems with exploiting /programatically/ the structure of an Org table
:
I want to write function acting on complex tables, where the original
information is presented along various statistics. My idea is to isolate the
original information in a range delimited (by convention) by the first and
second hlines and by the first and last columns ; the function should accept
the whole table and retrieve the original data. /The point is that the function
should accept a variable number of lines in both the "original data" range and
the summary information./
Let =ttest= such a table with =hlines= :
#+begin_src org :eval yes :exports both :results replace
,#+name: ttest
| ttest | c1 | c2 | rSum |
|---+++--|
| 3 | 3 | 5 |8 |
| 8 | 8 | 12 | 20 |
|---+++--|
| cSum | 11 | 17 | 28 |
,#+TBLFM: @>$2..@>$>=vsum(@I..@II)::@2..@>>$4=vsum($<<..$>>)
#+end_src
#+RESULTS:
#+name: ttest
| ttest | c1 | c2 | rSum |
|---+++--|
| 3 | 3 | 5 |8 |
| 8 | 8 | 12 | 20 |
|---+++--|
| cSum | 11 | 17 | 28 |
#+TBLFM: @>$2..@>$>=vsum(@I..@II)::@2..@>>$4=vsum($<<..$>>)
Passing this table as an argument to source code loses the hlines :
#+begin_src org :eval yes :exports both :results replace
,#+begin_src emacs-lisp :exports results :results drawer :var foo=ttest
foo
,#+end_src
#+end_src
The structure allowing to retrieve the original data is lost.
The point is that the source code can't exploit the hlines to find relevant
information (in the present case, the lines between the hlines).
Alternatively, one may try and pass the relevant range, using
=foo=(org-table-get-remote-range "ttest" "@I$<<..@II$>>")= as an argument. This
fails for a different reason :
#+begin_src org :eval yes :exports both :results replace
,#+begin_src emacs-lisp :exports results :results drawer :var
foo=(org-table-get-remote-range "ttest" "@I$<<..@II$>>")
foo
,#+end_src
#+end_src
Again, the structure is lost : this time, =foo= is a "flattened" vector, whose
matricial shape is lost to the processing function.
I am looking for explanations and/or hints.
# Local Variables:
# org-latex_listings: nil
# End:
Chiming in [Re: org-cite not mentioned in ORG-NEWS for 9.5]
As reported by Bastien, I started a documentation for the current state of the citation engine(s). I intended to complete it, but got "a little" sidetracked. Enclosed is a patch of where I was in August. Bastien made the following remarks, which I mostly intended to follow : === Je pense qu'à ce stade, le mieux est de soumettre ce document sur la liste de diffusion. En attendant, j'ai quelques remarques, en vrac : - Je pense que le titre "Working with…" n'est pas assez explicite. Par ailleurs, le chapitre précédent commence aussi par "Working with…". Par conséquent, je propose d'intervertir la description et le titre : * Citations and references :PROPERTIES: :DESCRIPTION: Working with other people's work :END: - Il faut penser à mettre deux espaces entre deux phrases. - =Org= -> Org - J'enlèverais la partie introductive expliquant pourquoi il est utile de citer le travail d'autrui. Ceci dit, il vaut mieux attendre l'avis d'autres personnes concernées par la fonctionnalité. [ Emmanuel Charpentier : I think that this justification may be helpful to a lot of non-scholar org users, who could benefit from org-cite. Advice sollicited... ] - Je pense qu'il faut éviter de parler ce "citation link", car cela peut engendrer de la confusion avec "link" qui est une structure proche, mais différent. Peut-être faut-il parler de "citation object". - Dans Texinfo, les phrases doivent être séparées par deux espaces. === What still lacks : * an explanation of the four possible functions of an engine ; * current functionalities of the currently available engines ; * an org-guide sized summary. Anyone is welcome to propose modifications. Someone should take the task of collating the propositions and consolidate a final text ; I am reluctant to take this task, given my RL tasks... Comments, remarks, criticisms, lazzi, etc... all welcome. -- Emmanuel Charpentier From f4d5b9f7d2a57a588fd72c4074a6b1ed018cf29f Mon Sep 17 00:00:00 2001 From: Emmanuel Charpentier Date: Mon, 27 Sep 2021 15:46:51 +0200 Subject: [PATCH] Embryo of a doc for the citation engine(s). --- doc/org-manual.org | 239 + 1 file changed, 239 insertions(+) diff --git a/doc/org-manual.org b/doc/org-manual.org index d34d33561..265d5f33a 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -18622,6 +18622,245 @@ emacs -Q --batch --eval " " "$@" #+end_example +* Working with other people's work +:PROPERTIES: +:DESCRIPTION: Manage citations and references +:END: +#+cindex: other people's work, working with + +Citations and references are a crucial part of almost any writing +(scholarly or otherwise): citing previous works relieves you from the +burden of discussing or defending what you cite. This relief comes at +a price: referring your reader to your source (thus transferring the +burden to check your statements in the original source to +him/her). This is usually done by separing a brief indication of the +work you use (a /citation/), part of the text, from the detailed +description of this work and of the means to retrieve it (the +/reference/), given out of the text (in footnotes and/or at the end of +the text). + +In everyday writing, citations and references may be vague, often +reduced to a handwave. In many domains, however, and most notably in +academic writing, precision in citing and referring is crucial. Citing +and referring conventions have therefore evolved since the beginnings +of writing, and are highly formalized in many domains. + +These conventions, answering different needs in different domains, are +different from domain to domain. For various reasons, they also vary +according to the intended use of the writing (academic work, +scientific paper, report, journal article, book or book chapter, +etc...). Following these sets of conventions (aka /styles/) can be +highly labor intensive. + +=Org= bibliographic tools use sets of reference informations and +formatting directives to easily insert succinct indications of a work +and forat theminto style-compliant citation and reference and insert +them in the correct place in the text. + +** Overview +:PROPERTIES: +:DESCRIPTION: Basic concepts of citation handling +:END: +#+cindex: bibliography +#+cindex: citation +#+cindex: reference +#+cindex: style + +A few definitions are in order : + + * Bibliography :: Conceptually, it is the set of /all/ previous +works supporting one's work, /whether you cite them explicitly or +not/. It might also denote a list of all such work, possibly with +notes related to each of them. + +This word also denotes a bibliography list referring /all/ the +works (cited or not) used in the development of one's work ; this +is a requirement of some (mostly scholarly) styles.
Re: org-cite: how to include a cite with no key?
Le mardi 20 juillet 2021 à 02:55 -0400, Matt Price a écrit : > Certainly citation of personal communications is common in the fields > of history and philosophy of science, where it represents an effort > to responsibly represent the source of ideas owed to other persons. I don't dispute that. > It's not really a question of whether you personally would do it; > it's a question of whether org will support a practice that exists in > some real-world contexts. What I dispute is that such "non-citations" are dangling pointers, better replaced by incises or footnotes ... or proper citations. -- Emmanuel Charpentier
Re: org-cite: how to include a cite with no key?
Le lundi 19 juillet 2021 à 20:47 -0400, John Kitchin a écrit :
[ Snip... ]
> It is also possible to use \nocite{*} as a cite, which includes all
> references from a bibliography, and yet contains no key.
Hence your reluctance to work from a set of larger databases, which
would include irrelevant reference. AFAIUI, your workflow is based on
the creation of a per-publication database.
> Even funnier in a way is \nocite{key} which just adds entries to the
> bibliography, but does not cite them in the body of a document.
Do you mean that thes empty entries will be added to the original .bib
database ??? Or simply that these entries will be added to the (unseen)
list of \bibitem entries that will be typeset as the reference list ?
> Footnotes are not always allowed in publications, and for various
> reasons not worth defending, in proposals one might want to put this
> in the references because of space limitations.
FWIW, \citetext will not add anything to the reference list (see
enclosed example...). BTW : what should it add ?
> I count at least 10 examples of such personal communications in the
> references in my library of ~1800 pdfs, so they aren't very common,
> but certainly they exist in the wild. Whether people should do it or
> not, they do.
I certainly agree with that (I have used such unpublished information
myself). My point is rather that, since there is nothing to refer to,
they have no place in a reference list ; unless someone creates
something to refer to (i. e. an entry in the bibliography database...).
> > ISTR that at least CSL and BibLaTeX have types appropriates for a
> > manuscript or a letter. You may also consider your own notes as
> > documents and reference them (properly).
> >
> > > I don't see a way to get something like that in org-cite, since
> > it
> > > seems that a key is always required.
> >
> > Indeed : the key is, in relational algebra terms, the primary key
> > of
> > the bibliographic relation...
> >
>
>
> I think of it more like a lambda function, but for a cite reference,
> where you
> define what you want inline.
The fly in the ointment being that you have to "create on the fly" what
will be in the text and what will be in the reference list...
> It is pretty common in scientific papers
> and proposals to see that.
>
> It may not make sense to make an @misc bibtex entry for that purpose,
> since it is a one time citation for that document, and is like a
> lambda reference.
The problem with that approach is that the reader has to somehow
reverse your function (which is by no way guranteed to be
bijective...).
--
Emmanuel Charpentier
TstNatBib.tar.gz
Description: application/compressed-tar
org-cite: how to include a cite with no key?
> In natbib there is \citetext{priv.\ comm.} which is used to add a
> textual citation to the bibliography that doesn't have a key
> associated with it.
Hmmm... why should you bother to reference a personal communication ?
Such private communications may be mentionned in the text (possibly by
a footnote) but can't be properly referenced (since there is nothing to
refer to). If you feel that this communication must be referred to, you
should give it some (written) support and (properly) reference this
support.
ISTR that at least CSL and BibLaTeX have types appropriates for a
manuscript or a letter. You may also consider your own notes as
documents and reference them (properly).
> I don't see a way to get something like that in org-cite, since it
> seems that a key is always required.
Indeed : the key is, in relational algebra terms, the primary key of
the bibliographic relation...
> This isn't currently recognized as a cite, but something like this
> seems like a reasonable solution to me.
> [cite/text:@ private communication]
Such special casing is probably a bugs' nest... err.. hive. And
pointless, as explained /supra/.
HTH,
--
Emmanuel Charpentier
> John
Re: Suggestion : Option enabling LaTeX blocks to non-latex exporters.
Well... this :
#+begin_src sage :exports both :results output raw
a, b = var("a, b");
print("\\begin{equation*}\n%s\n\\end{equation*}"%latex(sin(a+b)==sin(a+b).trig_expand()))
# print("\\(%s\n\\)"%latex(sin(a+b)==sin(a+b).trig_expand()))
#+end_src
#+RESULTS:
\begin{equation*}
\sin\left(a + b\right) = \cos\left(b\right) \sin\left(a\right) +
\cos\left(a\right) \sin\left(b\right)
\end{equation*}
will get you the expected result, in ODT as in PDF. But this might be
happenstance : the slightly simpler
#+begin_src sage :exports both :results output raw
a, b = var("a, b");
#
print("\\begin{equation*}\n%s\n\\end{equation*}"%latex(sin(a+b)==sin(a+b).trig_expand()))
print("\\(%s\n\\)"%latex(sin(a+b)==sin(a+b).trig_expand()))
#+end_src
#+RESULTS:
\(\sin\left(a + b\right) = \cos\left(b\right) \sin\left(a\right) +
\cos\left(a\right) \sin\left(b\right)
\)
will print the expected results *twice* (in ODT and in PDF).
The more straightforward)
#+begin_src sage :exports both :results value latex
var("a, b")
latex(cos(a+b)==cos(a+b).trig_expand())
#+end_src
#+RESULTS:
#+begin_export latex
\cos\left(a + b\right) = \cos\left(a\right) \cos\left(b\right) -
\sin\left(a\right) \sin\left(b\right)
#+end_export
gives the expected result in PDF (i. e. results *once*,whether the code
has #+results: or not), but not in ODT.
The "Kitchin's workaround" :
#+begin_src sage :exports both :results drawer
print("\\(\\displaystyle{%s}\\)"%latex(tan(a+b)==tan(a+b).trig_expand()))
#+end_src
#+RESULTS:
:results:
\(\displaystyle{\tan\left(a + b\right) = -\frac{\tan\left(a\right) +
\tan\left(b\right)}{\tan\left(a\right) \tan\left(b\right) - 1}}\)
:end:
works as (un)expected, but is still less straightforward. I'd rather
have a documented, understood way to export LaTeX snippets/ blocks
marked as such explicitly exported to ODT...
Hope this is clearer,
--
Emmanuel Charpentier
Le dimanche 18 juillet 2021 à 22:25 +0800, Timothy a écrit :
>
> Hi Emmanuel,
>
> It may interest you to hear that I submitted a patch a month or two
> ago
> (which was merged) to support LaTeX environments as results.
>
> That means that this is now possible:
>
>
> #+begin_src something
> ...stuff...
> #+end_src
>
> #+results:
> \begin{equation*}
> some latex which will be exported nicely
> \end{equation*}
>
>
> All the best,
>
> Timothy
Suggestion : Option enabling LaTeX blocks to non-latex exporters.
Dear list,
"raw" LaTeX can already be successfully exported by some exporters :
both html and odt exporters can translate (a limited subset of) such
latex expressions in something palatable to their respective targets
(Mathjax and representation MathML respectively).
This does *not* apply to LaTeX marked as such. To be clear :
babble babble $\int_a^b f(x) dx$ noise noise
will export the math expression to html and odt (if tex:t or
tex:dvipng or tex:dvisvgm) ; on the other hand
babble babble @@latex:$\int_a^b f(x) dx$@@ noise noise
will not. Neither will :
#+latex: \[\Phi_{\mu, \sigma}(x) =
\frac{e^-{\frac{(x-\mu)^2}{2\sigma^2}}}{\sigma\sqrt{2\pi}}\,.\]
nor :
#+begin_export latex
\[\Phi_{\mu, \sigma}(x) =
\frac{e^-{\frac{(x-\mu)^2}{2\sigma^2}}}{\sigma\sqrt{2\pi}}\,.\]
#+end_export
This has an annoying consequence : a function cannot (easily) return a
LaTeX block. One can return a raw result, but this loses the link
between the function and its result(s).
John Kitchin has suggested
(https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00099.html)
to wrap raw latex code in a drawer ; this works, but I am unable to
understand how, and I do not know what are the consequences.
Having an option allowing latex code marked as such to be passed to
other exporters (possibly with conversion) would allow a "cleaner"
solution.
What do you think ?
--
Emmanuel Charpentier
Re: LaTeX-producing code : how to export results to HTML/ODT ?
"Raw" LaTeX code export to ODT always worked if =tex= (and possibly
=org-latex-to-mathml-convert-command=) were correctly set.
The problem is that "raw" output is no longer recognized as the
function result. If the function is reran, the result will be output
twice : once by the function execution and once by the "#+results:"
paragraph.
John's black magic with drawers allows to keep the link between
function and results.
HTH,
--
Emmanuel Charpentier
Le mercredi 14 juillet 2021 à 14:41 +0800, Timothy a écrit :
>
> John Kitchin writes:
>
> > #+RESULTS: foo
> > :results:
> > \[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
> > :end:
> >
> > the key is the drawer I think.
>
> FYI as of
> https://code.orgmode.org/bzg/org-mode/commit/b90b850ae8be46a1ebe7d13b05ad79869e8d1032
> a LaTeX environment will "just work". i.e.
>
> #+RESULTS:
> \begin{equation*}
> \displaystyle{\sin\left(\frac{a}{b}\right)}
> \end{equation*}
>
> This is currently made use of in the new ob-julia (WIP).
>
> --
> Timothy
Re: LaTeX-producing code : how to export results to HTML/ODT ?
Yes, this works, indeed.
If I could just figure why
... and how to use it with captions, labels and cross-references.
But I still don't "get" drawers, I thonk.
Thanks a lot ! You gave me somethong to think about.
Le dimanche 04 juillet 2021 à 15:04 -0400, John Kitchin a écrit :
> This incantation worked for me:
> #+name: foo
> #+begin_src emacs-lisp :exports both :results drawer
> "Pseudo-function returning a LaTeX pseudo-result."
> "\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
> #+end_src
>
> #+RESULTS: foo
> :results:
> \[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
> :end:
>
> the key is the drawer I think.
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Sun, Jul 4, 2021 at 2:51 PM Emmanuel Charpentier
> wrote:
> > I tried this :
> >
> > #+property: header-args:sage :session
> > #+options: tex:t toc:nil author:nil
> > #+begin_src emacs-lisp :exports none
> > ;; (customize-set-variable
> > ;; 'org-latex-to-mathml-convert-command
> > ;; "latexmlmath \"%i\" --presentationmathml=%o")
> > (custom-set-variables
> > '(org-latex-to-mathml-convert-command
> > "java -jar %j -unicode -force -df %o %I")
> > '(org-latex-to-mathml-jar-file
> > "/usr/local/bin/mathtoweb.jar"))
> > #+end_src
> >
> > A "normal" function call with org result...
> >
> > #+name: foo
> > #+begin_src emacs-lisp :exports both :results org
> > "Pseudo-function returning a LaTeX pseudo-result."
> > "\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
> > #+end_src
> >
> > #+RESULTS: foo
> > #+begin_src org
> > \[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
> > #+end_src
> >
> > Which exports the LaTeX *source* (uncompiled) in PDF, HTML and ODT.
> >
> > I'm currently lookin into a =:post= workaround. But an option to
> > export =latex= blocks to selected exporters (ODT, HTML, possibly
> > Morkdown via pandoc).
> >
> > I'll keep you posted.
> >
> > Le dimanche 04 juillet 2021 à 14:10 -0400, John Kitchin a écrit :
> > Can you declare the output as org so they will just be latex
> > snippets?
> >
> > On Sun, Jul 4, 2021 at 3:46 AM Emmanuel Charpentier
> > wrote:
> > > Dear list,
> > >
> > > Org-mode offers the ability to create functions returning LaTeX
> > > results : such occurrences are frequent with Sagemath, Maxima,
> > > Mathematica, R, and even emacs's Calc...
> > >
> > > Such functions can be declared has having LaTeX output, and the
> > > resulting =#+begin_export latex ... #+end_export latex= block
> > > is exported as LaTeX and end up in the PDF versin.
> > >
> > > But such blocks seem to export *only* to LaTeX/PDF ; more
> > > specically, they do not export to HTML nor ODT. In order to
> > > insert those results at export, one *has* to print them *raw*.
> > > See the attached examples, and compare PDF, HTML and ODT outputs
> > > of the enclosed zip archive (necessary to avoid the wrath of the
> > > spam filter of my provider ;-)...)..
> > >
> > > Unless I am mistaken, this is the *only* way to export LaTeX
> > > exports to HTML/ODT ; I am not aware of any option allowing to
> > > force such exports. So a couple questions :
> > > * Am I mistaken ?
> > > * Are there more steamlined ways to get LaTeX in
> > > HTML/ODF/whatever-
> > > but-not-LaTeX ?
> > > * Wouldn't an option to allow these exports be a welcome addition
> > > to
> > > the export structure (or possibly to the various exporters) ?
> > >
> > > Thanks in advance,
> >
Re: LaTeX-producing code : how to export results to HTML/ODT ?
The following does what I want : export ln a LaTeX block to latex and
beamer, export as a raw LaTeX snippet in HTML and ODT, no export
otherwise :
#+property: header-args:sage :session
#+options: tex:t toc:nil author:nil
#+begin_src emacs-lisp :exports none
;; (customize-set-variable
;; 'org-latex-to-mathml-convert-command
;; "latexmlmath \"%i\" --presentationmathml=%o")
(custom-set-variables
'(org-latex-to-mathml-convert-command
"java -jar %j -unicode -force -df %o %I")
'(org-latex-to-mathml-jar-file
"/usr/local/bin/mathtoweb.jar"))
#+end_src
#+RESULTS:
Current exporter src_emacs-lisp[:results raw]{org-export-current-backend}.
A printing auxilliary :
#+name: printme
#+begin_src emacs-lisp :exports both :var data=()
(if data
(cond ((memq org-export-current-backend '(latex beamer))
(format "#+begin_export latex\n%s\n#+end_export" data))
((memq org-export-current-backend '(odt html))
data)
(t data))
"")
#+end_src
A "normal" function call with filtered result...
#+name: foo
#+begin_src emacs-lisp :exports both :results value raw :post
printme(data=*this*)
"Pseudo-function returning a LaTeX pseudo-result."
"\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
#+end_src
Real-life test :
#+name: gee
#+begin_src sage :exports both :results raw :post printme(data=*this*)
a, b = var("a, b")
R = str(LatexExpr("\\[\\displaystyle{%s}\\]"%latex(tan(a+b) ==
tan(a+b).trig_expand(
R += "\n\n"
R += str(LatexExpr("\\[\\displaystyle{%s}\\]"%latex(tan(a-b) ==
tan(a-b).trig_expand(
LatexExpr(R)
#+end_src
But this still has snags : you must not have evaluated results in the
buffer. Which is problematic if you want to use caching... Exporting
LaTeX blocks to ODT/HTML would be a better solution...
Ideas ?
Le dimanche 04 juillet 2021 à 14:10 -0400, John Kitchin a écrit :
> Can you declare the output as org so they will just be latex
> snippets?
>
> On Sun, Jul 4, 2021 at 3:46 AM Emmanuel Charpentier
> wrote:
> > Dear list,
> >
> > Org-mode offers the ability to create functions returning LaTeX
> > results : such occurrences are frequent with Sagemath, Maxima,
> > Mathematica, R, and even emacs's Calc...
> >
> > Such functions can be declared has having LaTeX output, and the
> > resulting =#+begin_export latex ... #+end_export latex= block is
> > exported as LaTeX and end up in the PDF versin.
> >
> > But such blocks seem to export *only* to LaTeX/PDF ; more
> > specically, they do not export to HTML nor ODT. In order to insert
> > those results at export, one *has* to print them *raw*. See the
> > attached examples, and compare PDF, HTML and ODT outputs of the
> > enclosed zip archive (necessary to avoid the wrath of the spam
> > filter of my provider ;-)...)..
> >
> > Unless I am mistaken, this is the *only* way to export LaTeX
> > exports to HTML/ODT ; I am not aware of any option allowing to
> > force such exports. So a couple questions :
> > * Am I mistaken ?
> > * Are there more steamlined ways to get LaTeX in HTML/ODF/whatever-
> > but-not-LaTeX ?
> > * Wouldn't an option to allow these exports be a welcome addition
> > to
> > the export structure (or possibly to the various exporters) ?
> >
> > Thanks in advance,
Re: LaTeX-producing code : how to export results to HTML/ODT ?
I tried this :
#+property: header-args:sage :session
#+options: tex:t toc:nil author:nil
#+begin_src emacs-lisp :exports none
;; (customize-set-variable
;; 'org-latex-to-mathml-convert-command
;; "latexmlmath \"%i\" --presentationmathml=%o")
(custom-set-variables
'(org-latex-to-mathml-convert-command
"java -jar %j -unicode -force -df %o %I")
'(org-latex-to-mathml-jar-file
"/usr/local/bin/mathtoweb.jar"))
#+end_src
A "normal" function call with org result...
#+name: foo
#+begin_src emacs-lisp :exports both :results org
"Pseudo-function returning a LaTeX pseudo-result."
"\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
#+end_src
#+RESULTS: foo
#+begin_src org
\[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
#+end_src
Which exports the LaTeX *source* (uncompiled) in PDF, HTML and ODT.
I'm currently lookin into a =:post= workaround. But an option to export
=latex= blocks to selected exporters (ODT, HTML, possibly Morkdown via
pandoc).
I'll keep you posted.
Le dimanche 04 juillet 2021 à 14:10 -0400, John Kitchin a écrit :
Can you declare the output as org so they will just be latex snippets?
On Sun, Jul 4, 2021 at 3:46 AM Emmanuel Charpentier
wrote:
> Dear list,
>
> Org-mode offers the ability to create functions returning LaTeX
> results : such occurrences are frequent with Sagemath, Maxima,
> Mathematica, R, and even emacs's Calc...
>
> Such functions can be declared has having LaTeX output, and the
> resulting =#+begin_export latex ... #+end_export latex= block is
> exported as LaTeX and end up in the PDF versin.
>
> But such blocks seem to export *only* to LaTeX/PDF ; more specically,
> they do not export to HTML nor ODT. In order to insert those results
> at export, one *has* to print them *raw*. See the attached examples,
> and compare PDF, HTML and ODT outputs of the enclosed zip archive
> (necessary to avoid the wrath of the spam filter of my provider ;-
> )...)..
>
> Unless I am mistaken, this is the *only* way to export LaTeX exports
> to HTML/ODT ; I am not aware of any option allowing to force such
> exports. So a couple questions :
> * Am I mistaken ?
> * Are there more steamlined ways to get LaTeX in HTML/ODF/whatever-
> but-not-LaTeX ?
> * Wouldn't an option to allow these exports be a welcome addition to
> the export structure (or possibly to the various exporters) ?
>
> Thanks in advance,
LaTeX-producing code : how to export results to HTML/ODT ?
Dear list, Org-mode offers the ability to create functions returning LaTeX results : such occurrences are frequent with Sagemath, Maxima, Mathematica, R, and even emacs's Calc... Such functions can be declared has having LaTeX output, and the resulting =#+begin_export latex ... #+end_export latex= block is exported as LaTeX and end up in the PDF versin. But such blocks seem to export *only* to LaTeX/PDF ; more specically, they do not export to HTML nor ODT. In order to insert those results at export, one *has* to print them *raw*. See the attached examples, and compare PDF, HTML and ODT outputs of the enclosed zip archive (necessary to avoid the wrath of the spam filter of my provider ;- )...).. Unless I am mistaken, this is the *only* way to export LaTeX exports to HTML/ODT ; I am not aware of any option allowing to force such exports. So a couple questions : * Am I mistaken ? * Are there more steamlined ways to get LaTeX in HTML/ODF/whatever- but-not-LaTeX ? * Wouldn't an option to allow these exports be a welcome addition to the export structure (or possibly to the various exporters) ? Thanks in advance, <>
Re: [wip-cite-new] Where is the development branch ?
Le samedi 26 juin 2021 à 10:35 +0200, Nicolas Goaziou a écrit : [ Snip... ] > > Where should I get this code ? > > For example, here: > > https://code.orgmode.org/bzg/org-mode/src/wip-cite-new Thank you very much ! Is there a similar repository for the futire org-contrib package ? I depend very much o some libraries currently in (or using) org-plus- contrib... [ Re-snip.. ] > Please let me know how it goes! I will certainly do : citations andcross-reference are crucuial features of academic/scientific writing, which is the whole point of my use of org-mode... Sincerely yours, -- Emmanuel Charpentier
[wip-cite-new] Where is the development branch ?
I wanted to test the (new|future) citation abilities of =Org= ; I tested what is available in =citeproc-org= with the =org-ref} syntax the latter supports. However, I also wanted to test what is available with the "new" syntax planned for introduction in =Org=. According to https://github.com/andras-simonyi/citeproc-org#org-mode-citations-and-bibliography-using-the-wip-cite-syntax , this is only available on the =wip-cite= development branch. However, my freshly updated git clone (of https://code.orgmode.org/bzg/org-mode.git ) doesn't have such a branch. Where should I get this code ? Related question : is there an ETA of these new abilities in =Org= ? -- Emmanuel Charpentier
Re: [O] org-mode vs pandoc export
I suppose that you need org-mode to use Babel features (code and/or code execution results intermixed with your paper's text). I have had trouble with .dot exporting using the builtin .dot exporter, but can't, for the life of me, remembering if my troubles were cross- reference or citations-related (an academic paper usually needs both...). I noted that the references done via John Kitchin's excellent org-ref didn't export to .dot. As far as I can tell, ox-pandoc does its own numbering (generating an intermediate temporary file that I never managed to catch) and does not use pandoc-crossref. ISTR that a "clever" use of org-ref allows to number equations... in LaTeX output. I also STR that it doesn't work in .docx output. John Kitchin (the org-ref author) thinks that the key is to generate a correct \LaTeX file and to export that to .docx via pandoc. At this point, writing a \LaTeX file with pandoc export in mind is probably your best bet. There exist (limited) alternatives to the Babel features of org-mode: - knitr (supports R and Python code in "session"mode, i. e. continuity between code chunks), - SageTeX (post-processing in a single Sagemath run ; can include code for a variety of math software, including R), - Pythontex (postprocessor, supports Python, Sage, Octave and a couple other, but not R ; a clever use of knitr and Pythontex is possible). Possible alternative: Markdown + Codebraid (supports a hanful of langiages, including R and (development branch) Sage). This should accept pandoc-crossref numbering. But it's Markdown, with limited formatting abilities... So, we have an array of partial solutions, none universal. Pick your poison... Out of curiosity: in which domain still exist journal publishers not accepting \LaTeX ? I suspect medicine... HTH, -- Emmanuel Charpentier
[O] Feature suggestion: #+toc figures
Currently, org-mode is able to produce (among other) tables, figures and listings, recognized and captioned/numbered as such. It can also produce a list of tables and a list of listings of a document. However, it currently /cannot/ produce a list of figures. Is that an oversight ? Or is there a more fundamental problem with this useful potential feature ? I am aware that I can get this in the \LaTeX export of the document by inserting ~\listoffigures~ at the right place. Bit this won't export to other formats. Thoughts ? -- Emmanuel Charpentier
[O] BUG (smallish) The exemple of the documentation of the LaTeX LANGUAGE option is incorrect
The current (org-version=9.2.4) documentation of the LANGUAGE option
for LaTeX export gives this example :
#+begin_example
(add-to-list org-latex-package-alist
'("AUTO" "babel" t ("pdflatex")))
(add-to-list org-latex-package-alist
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
#+end_example
It should be:
#+begin_example
#+bensert the example in agin_src emacs-lisp :exports none :results
none
(add-to-list 'org-latex-packages-alist
'("AUTO" "babel" t ("pdflatex")))
(add-to-list 'org-latex-packages-alist
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
#+end_src
#+end_example
i. e.:
* The name of the list has to be quoted.
* The exact list name has as "s" after "package".
* I'd give a full ~emacs-lisp~ snippet (but I agree that this is
disputable...).
Care fo a formal patch ?
HTH,
--
Emmanuel Charpentier
Re: [O] [PATCH] Feature proposal : support "scale=" includegraphics option in the builtin latex exporter.
Le dimanche 16 juin 2019 à 10:35 +0200, Nicolas Goaziou a écrit : [ Snip... ] > New features are applied to master branch. maint branch is for > bugfixes > only. Okay. I missed that... > Since your patch is a new feature, it went into master branch. It > will > be available in Org 9.3. Hopefully, it should not be long, even > though It's clear now. Thanks ! -- Emmanuel Charpentier > I have no ETA. I'm Cc'ing Bastien as he may know. > > Regards, >
Re: [O] [PATCH] Feature proposal : support "scale=" includegraphics option in the builtin latex exporter.
Le mardi 23 avril 2019 à 10:26 +0200, Nicolas Goaziou a écrit : > Hello, > > Emmanuel Charpentier writes: > > > Le lundi 22 avril 2019 à 15:26 +0200, Nicolas Goaziou a écrit : > > > Emmanuel Charpentier writes: > > > > > > > Do you want a direct answer or a partch against /etc/ORG-NEWS ? > > > > > > Anything that suits you. > > > > A patch it is (enclosed). > > Applied. Thank you. We are now on June 16. The ELPA-distributed org-plus-contrib still does not carry these patches (re-attached, FWIW). I have checked that they are present in the ~master~ branch of the source tree, but not its ~maint~ branch. Am I misunderstanding anything ? -- Emmanuel Charpentier > > > If this documentation is customaty, this should be mentioned in the > > "Contribute" page of Worg (which, IMHO, should be pointed to by > > the > > "Feedback" section of the manual). > > Feel free to edit Worg, it is user-maintained. OTOH, I don' think the > manual should rely on the wiki. We could, instead, augment > "README_contribute". > > Regards, > From 2526a06e4f77a2fdae615a95365f557c40b6d968 Mon Sep 17 00:00:00 2001 From: Emmanuel Charpentier Date: Sat, 20 Apr 2019 10:25:24 +0200 Subject: [PATCH 1/2] Support a :scale parameter in org-latex-export-to-latex and friends * lisp/ox-latex.el: introduce a :scale #+ATTR_LATEX parameter, as well as a "" default value for it. When present, it overrides :width and :height parameters (as it does for ODT export and in ox-pandoc exporters) ; therefore, setting a default value for :scale should be exceptional. Implementation: uses \scalebox for tikz/pgf images, "scale=" parameter of \includegraphics in other cases. * doc/org-manual.org: document the new :scale #+ATTR_LATEX parameter, --- doc/org-manual.org | 8 ++-- lisp/ox-latex.el | 49 ++ 2 files changed, 42 insertions(+), 15 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index a8f4a45ea..a9114184a 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -13277,14 +13277,18 @@ insert the image. But for TikZ (http://sourceforge.net/projects/pgf/) images, the back-end uses an ~\input~ macro wrapped within a ~tikzpicture~ environment. -For specifying image =:width=, =:height=, and other =:options=, use -this syntax: +For specifying image =:width=, =:height=, =:scale= and other =:options=, +use this syntax: #+begin_example ,#+ATTR_LATEX: :width 5cm :options angle=90 [[./img/sed-hr4049.pdf]] #+end_example +A =:scale= parameter overrides both =:width= and =:height= parameters ; +therefore, setting its default value should be done only in exceptional +circumstances. + For custom commands for captions, use the =:caption= attribute. It overrides the default =#+CAPTION= value: diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index cdcb07aca..60b8773b0 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -127,6 +127,7 @@ (:latex-format-headline-function nil nil org-latex-format-headline-function) (:latex-format-inlinetask-function nil nil org-latex-format-inlinetask-function) (:latex-hyperref-template nil nil org-latex-hyperref-template t) +(:latex-image-default-scale nil nil org-latex-image-default-scale) (:latex-image-default-height nil nil org-latex-image-default-height) (:latex-image-default-option nil nil org-latex-image-default-option) (:latex-image-default-width nil nil org-latex-image-default-width) @@ -708,6 +709,17 @@ This value will not be used if a height is provided." :package-version '(Org . "8.0") :type 'string) +(defcustom org-latex-image-default-scale "" + "Default scale for images. +This value will not be used if a width or a scale is provided, +or if the image is wrapped within a \"wrapfigure\",environment. +Since scale overrides width and height, setting its default +value should be done only in exceptional circumstances." + :group 'org-export-latex + :version "25.1" + :package-version '(Org . "9.2") + :type 'string) + (defcustom org-latex-image-default-height "" "Default height for images. This value will not be used if a width is provided, or if the @@ -2374,13 +2386,18 @@ used as a communication channel." (if (plist-member attr :center) (plist-get attr :center) (plist-get info :latex-images-centered))) (comment-include (if (plist-get attr :comment-include) "%" "")) - ;; It is possible to specify width and height in the - ;; ATTR_LATEX line, and also via default variables. - (width (cond ((plist-get attr :width)) + ;; It is possible to specify scale or width and height in + ;; the ATTR_LATEX line, and also via default variables. + (scale (cond ((eq float 'wrap) "&quo
Re: [O] Possible BUG : table.el tables export incotrrectly
Dear Nicolas, Thanks for the clarification. I misread the documentation. Sorry for the noise... -- Emmanuel Charpentier Le samedi 04 mai 2019 à 23:00 +0200, Nicolas Goaziou a écrit : > Hello, > > Emmanuel Charpentier writes: > > > Org-mode tables do export with their #+caption: and a usable > > #+name:, > > whereas table.el tables export their content but ignore #+name:, > > > > #+caption: and #+latex_attr:. > > Org mode does /not/ handle table.el tables. It merely recognizes > them, > and send them to "table.el" for translation into HTML or LaTeX code. > And > "table.el" doesn't recognize Org syntax, e.g., #+captions and > #+names. > > Regards, >
[O] Possible BUG : table.el tables export incotrrectly
Org-mode tables do export with their #+caption: and a usable #+name:,
whereas table.el tables export their content but ignore #+name:,
#+caption: and #+latex_attr:.
Minimal (non-)working example :
=
# tables.el tables ?
#+options: toc:nil author:nil date:nil
#+latex_header: \usepackage{booktabs}
The table [[Table1]] , manual conversion and rough approxomation of
[[Table2]], erports correcly, while the orginal one doesn't (no
caption,
no usable label).
#+ATTR_LATEX: :rmlines
#+NAME: Table2
#+CAPTION: Second table
+-+-+-+
| A |B|C|
+-+-+-+
|1|231a |3|
| |x| |
+-+-+-+
|4|5|6|
+-+-+-+
#+name: Table1
#+caption: First table
| A | B| C |
|---+--+---|
| 1 | 231a | 3 |
| | x| |
| 4 | 5| 6 |
=
Export to a LaTeX buffer :
=
% Created 2019-05-04 sam. 13:15
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage{booktabs}
\date{}
\title{}
\hypersetup{
pdfauthor={Emmanuel Charpentier},
pdftitle={},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 26.1 (Org mode 9.2.3)},
pdflang={English}}
\begin{document}
The table \ref{tab:orge528190} , manual conversion and rough
approxomation of
\ref{tab:orgb3737d9}, erports correcly, while the orginal one doesn't
(no caption,
no usable label).
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
A & B & C \\
\hline
1 & 231a & 3 \\
& x & \\
\hline
4 & 5 & 6 \\
\hline
\end{tabular}
\end{center}
\begin{table}[htbp]
\caption{\label{tab:orge528190}
First table}
\centering
\begin{tabular}{rlr}
A & B & C\\
\hline
1 & 231a & 3\\
& x & \\
4 & 5 & 6\\
\end{tabular}
\end{table}
\end{document}
=
Export to an HTML buffer :
=
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="en" xml:lang="en">
<!--/*--><![CDATA[/*><!--*/
.title { text-align: center;
margin-bottom: .2em; }
.subtitle { text-align: center;
font-size: medium;
font-weight: bold;
margin-top:0; }
.todo { font-family: monospace; color: red; }
.done { font-family: monospace; color: green; }
.priority { font-family: monospace; color: orange; }
.tag{ background-color: #eee; font-family: monospace;
padding: 2px; font-size: 80%; font-weight: normal; }
.timestamp { color: #bebebe; }
.timestamp-kwd { color: #5f9ea0; }
.org-right { margin-left: auto; margin-right: 0px; text-align:
right; }
.org-left { margin-left: 0px; margin-right: auto; text-align:
left; }
.org-center { margin-left: auto; margin-right: auto; text-align:
center; }
.underline { text-decoration: underline; }
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
p.verse { margin-left: 3%; }
pre {
border: 1px solid #ccc;
box-shadow: 3px 3px 3px #eee;
padding: 8pt;
font-family: monospace;
overflow: auto;
margin: 1.2em;
}
pre.src {
position: relative;
overflow: visible;
padding-top: 1.2em;
}
pre.src:before {
display: none;
position: absolute;
background-color: white;
top: -10px;
right: 10px;
padding: 3px;
border: 1px solid black;
}
pre.src:hover:before { display: inline;}
/* Languages per Org manual */
pre.src-asymptote:before { content: 'Asymptote'; }
pre.src-awk:before { content: 'Awk'; }
pre.src-C:before { content: 'C'; }
/* pre.src-C++ doesn't work in CSS */
pre.src-clojure:before { content: 'Clojure'; }
pre.src-css:before { content: 'CSS'; }
pre.src-D:before { content: 'D'; }
pre.src-ditaa:before { content: 'ditaa'; }
pre.src-dot:before { content: 'Graphviz'; }
pre.src-calc:before { content: 'Emacs Calc'; }
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
pre.src-fortran:before { content: 'Fortran'; }
pre.src-gnuplot:before { content: 'gnuplot'; }
pre.src-haskell:before { content: 'Haskell'; }
pre.src-hledger:before { content: 'hledger'; }
pre.src-java:before { content: 'Java'; }
pre.src-js:before { content: 'Javascript'; }
pre.src-latex:before { content: 'LaTeX'; }
pre.src-ledger:before { content: 'Ledger'; }
pre.src-lisp:before { content: 'Lisp'; }
pre.src-lilypond:before { content: 'Lilypond'; }
pre.src-lua:be
[O] Correction and addition [Re: BUG: the builtin LaTeX/P DF exporter mislabels source blocks as figures.]
I reported incorrectly that the bug Ireported was also present when
using the "minted" package to format source blocks.
This is incorrect : I re-checked my trials, and re-wrote another test,
which gives the ecpected result. See attached files.
This might help pinpointing the problem happening when minted is *NOT*
used.
HTH,
--
Emmanuel Charpentier
[ Previous posts : Snip... ]
Title: Test of source block exports
The Python block 1 generates the figure 1
Figure 1: Figure generated by python
Listing 1: Python code generating a figureimport matplotlib, numpy
matplotlib.use('Agg')
import matplotlib.pyplot as plt
fig=plt.figure(figsize=(4,2))
x=numpy.linspace(-15,15)
plt.plot(numpy.sin(x)/x)
fig.tight_layout()
plt.savefig('Fig2.png')
return 'Fig2.png'
Problem: whereas the HTML export labels the source listing as "Listing 1" and is correctly refers to 1, the PDF export labels it "Figure 2" (and points to it) when the default verbatim method is used. When one bothers to use minted, the result is correct.
Created: 2019-04-30 mar. 23:15
Validate
# An archi-minimal test of source blocks labelling,
# using only the built-in tools.
#+options: tex:t title:nil author:nil date:nil toc:nil
#+title: Test of source block exports
#+begin_src emacs-lisp :exports none :results none
(setq
org-latex-pdf-process
(list "latexmk -pdf -pdflatex='%latex -interaction=nonstopmode
-shell-escape' -bibtex -f %f")
org-latex-listings 'minted)
(add-to-list 'org-latex-packages-alist '("newfloat" "minted" t))
#+end_src
# #+latex_header: \usepackage[newfloat]{minted}
# #+latex_header: \usepackage{listings}
The Python block [[lst:DoFig]] generates the figure [[fig:DoFig]]
#+name: DoFig
#+begin_src python :results file :exports none
import matplotlib, numpy
matplotlib.use('Agg')
import matplotlib.pyplot as plt
fig=plt.figure(figsize=(4,2))
x=numpy.linspace(-15,15)
plt.plot(numpy.sin(x)/x)
fig.tight_layout()
plt.savefig('Fig2.png')
return 'Fig2.png'
#+end_src
#+RESULTS: DoFig
[[file:Fig2.png]]
#+name: fig:DoFig
#+caption: Figure generated by python
#+ATTR_LATEX: :height 2.5in
[[file:Fig2.png]]
# #+name: fig:DoFig
# #+caption: Figure generated by python
# #+RESULTS: DoFig
# [[file:Fig2.png]]
#+name: lst:DoFig
#+caption: Python code generating a figure
#+begin_src python :eval no :exports code :noweb yes
<>
#+end_src
Problem: whereas the HTML export labels the source listing as "Listing 1" and
is correctly refers to 1, the PDF export labels it "Figure 2" (and points to
it) *when the default ~verbatim~ method is used.* When one bothers to use
~minted~, the result is correct.
C4.pdf
Description: Adobe PDF document
% Created 2019-04-30 mar. 23:15
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage[newfloat]{minted}
\date{}
\title{Test of source block exports}
\hypersetup{
pdfauthor={Emmanuel Charpentier},
pdftitle={Test of source block exports},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 26.1 (Org mode 9.2.3)},
pdflang={English}}
\begin{document}
The Python block \ref{org471e7a4} generates the figure \ref{fig:orgb0ae5e3}
\begin{figure}[htbp]
\centering
\includegraphics[height=2.5in]{Fig2.png}
\caption{\label{fig:orgb0ae5e3}
Figure generated by python}
\end{figure}
\begin{listing}[htbp]
\begin{minted}[]{python}
import matplotlib, numpy
matplotlib.use('Agg')
import matplotlib.pyplot as plt
fig=plt.figure(figsize=(4,2))
x=numpy.linspace(-15,15)
plt.plot(numpy.sin(x)/x)
fig.tight_layout()
plt.savefig('Fig2.png')
return 'Fig2.png'
\end{minted}
\caption{\label{org471e7a4}
Python code generating a figure}
\end{listing}
Problem: whereas the HTML export labels the source listing as "Listing 1" and is correctly refers to 1, the PDF export labels it "Figure 2" (and points to it) \textbf{when the default \texttt{verbatim} method is used.} When one bothers to use \texttt{minted}, the result is correct.
\end{document}
Re: [O] BUG: the builtin LaTeX/P DF exporter mislabels source blocks as figures.
Dear John,
This does *not* work for me. See the attached files.
I begin to suspect a very recent bug : I'm following MELPA, which
updates about once a week. My org-version says: Org mode version 9.2.3
(9.2.3-11-g42abf5-elpaplus @ /home/charpent/.emacs.d/elpa/org-plus-
contrib-20190429/).
Cordially,
--Emmanuel Charpentier
Le mardi 30 avril 2019 à 13:46 -0400, John Kitchin a écrit :
> This works as expected in LaTeX for me with org-ref (you could
> probably use raw latex if you wanted):
> #+caption: The first source block. label:src-1#+BEGIN_SRC
> ipythonprint('Hello world')#+END_SRC
>
> Later we refer to the code in Listing ref:src-1 or ref:src-2. That is
> different than Figure ref:fig-1.
> #+caption: My figure. label:fig-1[[./test.png]]
>
> #+caption: The first source block. label:src-2#+BEGIN_SRC
> ipythonprint('Hello world')#+END_SRC
> The downside is that for html the src-block links are not numbered. I
> don't know how easy that would be to fix in the export functions.
> John
>
> ---
> 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
>
>
>
> On Tue, Apr 30, 2019 at 1:40 PM Emmanuel Charpentier <
> emm.charpent...@free.fr> wrote:
> > Hi, Nicolas !
> >
> >
> >
> > Le mardi 30 avril 2019 à 19:05 +0200, Nicolas Goaziou a écrit :
> >
> > > Hello,
> >
> > >
> >
> > > Emmanuel Charpentier writes:
> >
> > >
> >
> > > > Whereas the HTML exporter correctly recognize a source block as
> >
> > > > such,
> >
> > > > the LaTeX/PDF exporter does not.
> >
> > > >
> >
> > > > This can be demonstrated in a (minimal) org file using *only*
> > the
> >
> > > > built-in tools (no external packages), where a source block is
> >
> > > > labelled
> >
> > > > as such by the HTML exporter but as a figure by the LaTeX
> >
> > > > exporter.The
> >
> > > > generated LaTeX source shows a suspicious
> >
> > > > "\captionof{figure}{\label{orgf2d4160}" in the export of the
> > source
> >
> > > > block.
> >
> > > >
> >
> > > > Further tests (not shown) show that the proble persists when
> > org-
> >
> > > > mode
> >
> > > > is set up to use the minted package for LaTeX export of source
> >
> > > > blocks
> >
> > > > (minted is indeed used, but the block is s still mislabeled).
> >
> > >
> >
> > > What LaTeX code do you suggest instead?
> >
> >
> >
> > Dunno. Maybe \captionof{listing} ? Or let minted do its thing ?
> > Anyway,
> >
> > in most cases, the code excerpts will be too long for a float ; the
> >
> > idea is to send them (unfloated but labeled/captioned) in an
> > appendix
> >
> > and point to them via a link.
> >
> >
> >
> > [ BTW : we should stop suggesting to use listings, which is
> > problematic
> >
> > for anything not strictly ASCII, bloody likely to occur at least on
> > a
> >
> > comment/prompt for most of mankind... Listingsutf8 is but a patch
> >
> > working only for (a subset of) European languages. Arabic, Hebrew,
> >
> > Asian languages : nope. Minted in (xe|lua)tex is probably more
> > usable
> >
> > (but needs --shell-escape, which can justifiably frowned upon... ].
> >
> >
> >
> > > > The org source and resulting pdf and html files are available
> > here
> >
> > > > :
> >
> > > >
> > https://drive.google.com/drive/folders/1bQmaefiztW9ZDRNLcjOD_WbEmTg4d8dG?usp=sharing
> >
> > >
> >
> > > Could you send your ECM in the ML without requiring to access
> > Google
> >
> > > Drive?
> >
> >
> >
> > Attached.
> >
> >
> >
> > But please coordinate with Bastien, who asked me just yesterday to
> >
> > avoid posting fat attachments to a message going to a lot of
> > people.
> >
> > Which I did (to no avail : the "heavy" mail went through anyway. Go
> >
> > figure ;-).
> >
> >
> >
> >
> >
> > > Thank you.
> >
> >
> >
> > You're welcome ;-). Thank
Re: [O] BUG: the builtin LaTeX/P DF exporter mislabels source blocks as figures.
Hi, Nicolas !
Le mardi 30 avril 2019 à 19:05 +0200, Nicolas Goaziou a écrit :
> Hello,
>
> Emmanuel Charpentier writes:
>
> > Whereas the HTML exporter correctly recognize a source block as
> > such,
> > the LaTeX/PDF exporter does not.
> >
> > This can be demonstrated in a (minimal) org file using *only* the
> > built-in tools (no external packages), where a source block is
> > labelled
> > as such by the HTML exporter but as a figure by the LaTeX
> > exporter.The
> > generated LaTeX source shows a suspicious
> > "\captionof{figure}{\label{orgf2d4160}" in the export of the source
> > block.
> >
> > Further tests (not shown) show that the proble persists when org-
> > mode
> > is set up to use the minted package for LaTeX export of source
> > blocks
> > (minted is indeed used, but the block is s still mislabeled).
>
> What LaTeX code do you suggest instead?
Dunno. Maybe \captionof{listing} ? Or let minted do its thing ? Anyway,
in most cases, the code excerpts will be too long for a float ; the
idea is to send them (unfloated but labeled/captioned) in an appendix
and point to them via a link.
[ BTW : we should stop suggesting to use listings, which is problematic
for anything not strictly ASCII, bloody likely to occur at least on a
comment/prompt for most of mankind... Listingsutf8 is but a patch
working only for (a subset of) European languages. Arabic, Hebrew,
Asian languages : nope. Minted in (xe|lua)tex is probably more usable
(but needs --shell-escape, which can justifiably frowned upon... ].
> > The org source and resulting pdf and html files are available here
> > :
> > https://drive.google.com/drive/folders/1bQmaefiztW9ZDRNLcjOD_WbEmTg4d8dG?usp=sharing
>
> Could you send your ECM in the ML without requiring to access Google
> Drive?
Attached.
But please coordinate with Bastien, who asked me just yesterday to
avoid posting fat attachments to a message going to a lot of people.
Which I did (to no avail : the "heavy" mail went through anyway. Go
figure ;-).
> Thank you.
You're welcome ;-). Thank YOU for considering scratching *MY* itch...
--
Emmanuel Charpentier
Title: Test of source block exports
The R block 1 generates the figure 1:
Figure 1: Figure generated by R
Listing 1: R code generating a figurecurve(sin(x),from=-pi, to=pi)
Problem: whereas the HTML export labels the source listing as "Listing 1" and is correctly refers to 1, the PDF export labels it "Figure 2" (and points to it).
Created: 2019-04-30 mar. 08:53
Validate
# An archi-minimal test of source blocks labelling,
# using only the built-in tools.
#+options: tex:t title:nil author:nil date:nil toc:nil
#+property: header-args:R :session
#+title: Test of source block exports
The R block [[lst:DoFig]] generates the figure [[fig:DoFig]]:
#+name: DoFig
#+begin_src R :exports results :results output graphics :file Fig.png
curve(sin(x),from=-pi, to=pi)
#+end_src
#+name: fig:DoFig
#+caption: Figure generated by R
#+RESULTS: DoFig
[[file:Fig.png]]
#+name: lst:DoFig
#+caption: R code generating a figure
#+begin_src R :eval no :exports code :noweb yes
<>
#+end_src
Problem: whereas the HTML export labels the source listing as "Listing 1" and
is correctly refers to 1, the PDF export labels it "Figure 2" (and points to
it).
C1.pdf
Description: Adobe PDF document
% Created 2019-04-30 mar. 09:10
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\date{}
\title{Test of source block exports}
\hypersetup{
pdfauthor={Emmanuel Charpentier},
pdftitle={Test of source block exports},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 26.1 (Org mode 9.2.3)},
pdflang={English}}
\begin{document}
The R block \ref{orgf2d4160} generates the figure \ref{fig:org1c384b0}:
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{Fig.png}
\caption{\label{fig:org1c384b0}
Figure generated by R}
\end{figure}
\begin{verbatim}
curve(sin(x),from=-pi, to=pi)
\end{verbatim}
\captionof{figure}{\label{orgf2d4160}
R code generating a figure}
Problem: whereas the HTML export labels the source listing as "Listing 1" and is correctly refers to 1, the PDF export labels it "Figure 2" (and points to it).
\end{document}
Re: [O] Slight problems with links
Le mardi 30 avril 2019 à 04:43 -0200, Ken Mankoff a écrit :
> Hi Emmanuel,
>
> I have looked into PDF and DOCX export repeatedly over the years with
> different versions of Org and Pandoc and Google Docs and keep finding
> that the best method is Org -> LaTeX, and then LaTeX -> DOCX with
> Pandoc.
That's also basically the advice given by John Kitchin.
> I use this babel block to achieve this:
>
> #+BEGIN_SRC sh :results verbatim :var fn=(file-name-sans-extension
> (buffer-name))
> bibexport -o ${fn}.bib ${fn}.aux
> pandoc -f latex -i ${fn}.tex -t DOCX -o ${fn}.docx --bibliography
> ./${fn}.bib
> #+END_SRC
>
> The first line may not be needed. That extracts the references used
> in this document from my single massive (3500 element) bib file.
Whew ! How do you manage this ?
I gave up using JabRef fo a large collection, and use Zotero (which
allows me to share my bibliographic base with Wordheads co-workers.1
have about 14 000 references dispatched in one (small) personal library
and three (large: academic physicians are (have to be) chatty...)
shared libraries.
I create a problem specific collection to collect the relevant
references, and export that. I found GetterBibtex's auto-export feature
to be very useful.
> The advantage of this Org -> LaTeX -> Pandoc -> DOCX method is that
> if you need to patch something for Pandoc (e.g. to fix your code
> captions or something) you could insert a NoWeb < pandoc>> block before the pandoc line that generates a second,
> corrected, LaTeX file.
Hmmm... this way lies madness : it multiplies the possible sources for
a bug. I'd rather avoid that, and fight for a *correct* LaTeX source,
which is not the case at the moment.
>
> Note that I don't use org-ref, just the standard Org referencing
> code, but I don't see why this would change anything, if you're able
> to generate PDFs that meet your requirements.
Org-ref has its points : it offers the ability to create/update and
maintain a document-specific .bib file, ythanks to a set of interfaces
to PubMed/DOI/etc I don't give up on the idea of suggesting to John
Kitchin an interface to Zotero : a very crude interface r(Totxt)
exists, that can be used to communicate with a local Zotero process.
But this is now too rough (remaining bugs, etc..) to prepare a patch-
request (I'm not much of a programmer...).
Back to the problem at hand : I'm still bugged by the fact that ox-
pandoc does the right thing in the present case (as well as the built-
in HTML exporter, by the way), and that the built-in LaTeX exporter is
buggy. I just posted a formal bug report limited to this.
Cordially yours,
--
Emmanuel Charpentier
[O] BUG: the builtin LaTeX/P DF exporter mislabels source blocks as figures.
I shall report formally the problems mentioned in
http://lists.gnu.org/archive/html/emacs-orgmode/2019-04/msg00240.html,
trying to isolate them as much as possible. I'll start with the
simplest (and, IMHO, the most annoying).
Whereas the HTML exporter correctly recognize a source block as such,
the LaTeX/PDF exporter does not.
This can be demonstrated in a (minimal) org file using *only* the
built-in tools (no external packages), where a source block is labelled
as such by the HTML exporter but as a figure by the LaTeX exporter.The
generated LaTeX source shows a suspicious
"\captionof{figure}{\label{orgf2d4160}" in the export of the source
block.
Further tests (not shown) show that the proble persists when org-mode
is set up to use the minted package for LaTeX export of source blocks
(minted is indeed used, but the block is s still mislabeled).
This example also exhibits some cosmetic problems (spacing) that will
be ignored for now.
The org source and resulting pdf and html files are available here :
https://drive.google.com/drive/folders/1bQmaefiztW9ZDRNLcjOD_WbEmTg4d8dG?usp=sharing
Re: [O] Slight problems with links
Dear John, Indeed, I missed your point. I'll have to bet back to you after reading, understanding the code (org-mode is a tall order...) and *thinking*. However, the troubling fact that ox-latex manages to export org's labelling correctly shows that its author might be up to somethong. Indeed I just checked that its exported docx can be converted by pandoc into a "correct" docx (correct here meaning that my captions are correctly labelled and numbered). Have to think again... --Emmanuel Charpentier Le lundi 29 avril 2019 à 17:23 -0400, John Kitchin a écrit : > I think you have missed the main point. My point was first to find > some format that pandoc faithfully converts to docx with all the > features you need, and then we can figure out how to turn org-ref/org > into that format. So, if you can write a LaTeX document that is > correctly converted to docx (correct bibliography, figure labels, and > cross-references, correct code, etc), then we can probably get org to > output the right latex. But if LaTeX isn't converted to docx > correctly in pandoc, it does not seem likely that org will either > with any simple exporter. > John > > --- > 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 > > > > On Mon, Apr 29, 2019 at 5:19 PM Emmanuel Charpentier < > emm.charpent...@free.fr> wrote: > > Dear John, > > Le lundi 29 avril 2019 à 16:57 -0400, John Kitchin a écrit : > > > For org-ref, there isn't much magic on what happens on export. > > > LaTeX is certainly the most well supported, and it seems like org > > > -> latex -> pandoc is the only way that makes sense to get to > > > docx to me. Using pandoc on org files directly is probably > > > hopeless unless you can get pandoc to include some definitions > > > for the org-ref links. > > > > This might be difficult : the development of ox-pandoc seems to not > > be very active at the moment... > > > Some of the link types in org-ref have some exports defined for > > > org, html, latex, sometimes ascii. If one of these works well > > > with pandoc we could try to make them output something useful for > > > them, or at least make sure that org->org export turns them into > > > something useful. > > > > I'm currently looking at the ox-latex exporter in order to > > understand what it does for source blocks with org's names and > > captions (and try to fix the fact that they are labeled and nubered > > as figures...). Theis understanding might help me to go in the > > direction you suggest. > > > Getting figure/table numbers has always been tricky; I don't > > > think this worked well with pandoc, and handling it on the org > > > side requires some preprocessing to add numbers. For now, the ox- > > > word exporter in scimax comes closest, but it isn't a feature I > > > use a lot, so it hasn't been improved in a while. > > > > Again, looking at what ox-latex does for org's names and captions > > might be helpful. Ox-pandoc seems to do a decent job on docx > > output. > > > John > > > > > > --- > > > 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 > > > > > > > > > > > > On Mon, Apr 29, 2019 at 1:06 PM Emmanuel Charpentier < > > > emm.charpent...@free.fr> wrote: > > > > Dear list, > > > > > > > > > > > > > > > > one of my uses od org-mode is to prepare documents wrapping R > > > > (and > > > > > > > > sometimes Sagemath) call results in interpretation text. My > > > > reference > > > > > > > > output is .pdf documents, but I *have* to prepare a .docx > > > > version (for > > > > > > > > use in managerial spheres, where computer literacy is *very* > > > > low. > > > > > > > > Cross-references and citations are a sine qua non, maths are > > > > useful. > > > > > > > > > > > > > > > > I have been annoyed by a couple of deficiencies and > > > > inconsistencies > > > > > > > > between
Re: [O] Slight problems with links
Dear John, Le lundi 29 avril 2019 à 16:57 -0400, John Kitchin a écrit : > For org-ref, there isn't much magic on what happens on export. LaTeX > is certainly the most well supported, and it seems like org -> latex > -> pandoc is the only way that makes sense to get to docx to me. > Using pandoc on org files directly is probably hopeless unless you > can get pandoc to include some definitions for the org-ref links. This might be difficult : the development of ox-pandoc seems to not be very active at the moment... > Some of the link types in org-ref have some exports defined for org, > html, latex, sometimes ascii. If one of these works well with pandoc > we could try to make them output something useful for them, or at > least make sure that org->org export turns them into something > useful. I'm currently looking at the ox-latex exporter in order to understand what it does for source blocks with org's names and captions (and try to fix the fact that they are labeled and nubered as figures...). Theis understanding might help me to go in the direction you suggest. > Getting figure/table numbers has always been tricky; I don't think > this worked well with pandoc, and handling it on the org side > requires some preprocessing to add numbers. For now, the ox-word > exporter in scimax comes closest, but it isn't a feature I use a lot, > so it hasn't been improved in a while. Again, looking at what ox-latex does for org's names and captions might be helpful. Ox-pandoc seems to do a decent job on docx output. > John > > --- > 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 > > > > On Mon, Apr 29, 2019 at 1:06 PM Emmanuel Charpentier < > emm.charpent...@free.fr> wrote: > > Dear list, > > > > > > > > one of my uses od org-mode is to prepare documents wrapping R (and > > > > sometimes Sagemath) call results in interpretation text. My > > reference > > > > output is .pdf documents, but I *have* to prepare a .docx version > > (for > > > > use in managerial spheres, where computer literacy is *very* low. > > > > Cross-references and citations are a sine qua non, maths are > > useful. > > > > > > > > I have been annoyed by a couple of deficiencies and inconsistencies > > > > between exporters, so I prepared a test document testing various > > cases. > > > > This documents and some exports are attached (NE = Native exporter, > > PE > > > > = ox-pandoc exporter). > > > > > > > > TL;DR : > > > > > > > > * I tested the built-in latex/pdf exporter as well as ox-pandoc, > > the > > > > latter both for .pdf and .docx export. The built-in ODT exporter > > > > doesn't export citations ; therefore, I didn't test it further. > > > > > > > > > > > > * org-ref's :labels and :refs do not export to anything but the > > > > built-in latex exporter. The native system of #+NAME:s and > > #+CAPTION:s, > > > > a bit on the heavy side, seems not to fail (except that they do not > > > > expand in a caption...). > > > > > > > > * Maths, tables, figures are unproblematic. > > > > > > > > * The requirements of org-reftex, the built-in latex exporter and > > ox- > > > > pandoc being mutually incompatible, and some ingenuity is required. > > see > > > > the attached org source. Org-ref's requirements do not simplify the > > > > situation... > > > > > > > > * Code snippets (i. e. source blocks exporting code) have a > > > > captioning/numbering problem : > > > > > > > > - With the built-in latex exporter, they are numbered and > > labeled > > > > as figures. > > > > > > > > - The pandoc latex exporter numbers them separately (as seen by > > > > referencing them), but do not output this number (nor the category) > > > > before the caption. > > > > > > > > - The pandoc .docx exporter works as advertised. > > > > > > > > So I have a couple of questions: > > > > > > > > * What can be done to reconcile org-ref's, latex-exporter's and > > ox- > > > > pandoc's requirements for bibliographies ? > > > > > > > > * How to fix the pdf exporters' quirks with code snippets ? > > > > > > > > HTH, > > > > > > > > -- > > > > Emmanuel Charpentier > >
[O] Slight problems with links
Dear list, one of my uses od org-mode is to prepare documents wrapping R (and sometimes Sagemath) call results in interpretation text. My reference output is .pdf documents, but I *have* to prepare a .docx version (for use in managerial spheres, where computer literacy is *very* low. Cross-references and citations are a sine qua non, maths are useful. I have been annoyed by a couple of deficiencies and inconsistencies between exporters, so I prepared a test document testing various cases. This documents and some exports are too big to be atached but can be downloaded from https://drive.google.com/open?id=1T6N_-WwphlnL2mB4f6BgX0u1K5mLnz4i (NE = Native exporter, PE= ox-pandoc exporter). TL;DR : * I tested the built-in latex/pdf exporter as well as ox-pandoc, the latter both for .pdf and .docx export. The built-in ODT exporter doesn't export citations ; therefore, I didn't test it further. * org-ref's :labels and :refs do not export to anything but the built-in latex exporter. The native system of #+NAME:s and #+CAPTION:s, a bit on the heavy side, seems not to fail (except that they do not expand in a caption...). * Maths, tables, figures are unproblematic. * The requirements of org-reftex, the built-in latex exporter and ox- pandoc being mutually incompatible, and some ingenuity is required. see the org source. Org-ref's requirements do not simplify the situation... * Code snippets (i. e. source blocks exporting code) have a captioning/numbering problem : - With the built-in latex exporter, they are numbered and labeled as figures. - The pandoc latex exporter numbers them separately (as seen by referencing them), but do not output this number (nor the category) before the caption. - The pandoc .docx exporter works as advertised. So I have a couple of questions: * What can be done to reconcile org-ref's, latex-exporter's and ox- pandoc's requirements for bibliographies ? * How to fix the pdf exporters' quirks with code snippets ? HTH, -- Emmanuel Charpentier
Re: [O] [PATCH] Feature proposal : support "scale=" includegraphics option in the builtin latex exporter.
Le lundi 22 avril 2019 à 15:26 +0200, Nicolas Goaziou a écrit : > Emmanuel Charpentier writes: > > > Do you want a direct answer or a partch against /etc/ORG-NEWS ? > > Anything that suits you. A patch it is (enclosed). If this documentation is customaty, this should be mentioned in the "Contribute" page of Worg (which, IMHO, should be pointed to by the "Feedback" section of the manual). -- Emmanuel Charpentier From 99d503bb11ef7923393c7bbd0dd5cdc07e3fca6d Mon Sep 17 00:00:00 2001 From: Emmanuel Charpentier Date: Mon, 22 Apr 2019 16:56:00 +0200 Subject: [PATCH 2/2] Document the LATEX_ATTR :scale parameter in ORG-NEWS * etc/ORG-NEWS: document the new builtin LaTeX exporters' LATEX_ATTR :scale parameter --- etc/ORG-NEWS | 25 + 1 file changed, 25 insertions(+) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 79659ea50..3285c91d9 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -192,6 +192,31 @@ This is a function for convenience. The new paramater ~:dbconnection~ allows to specify a connection name in a SQL block header: this name is used to look up connection parameters in ~sql-connection-alist~. + +*** New ~LATEX_ATTR~ ~:scale~ supported by the built-in LaTeX exporters + +The builtin ~org-latex-export*~ exporters now accept and use a +~:scale~ attribute, which scales an image by a given factor. + +This attribute is wrapped adound the ~scale=~ parameter of LaTeX's +~\\includegraphics~ (bitmap images) or a ~TiKZ~'s +~\\scalebox~. Therefore, its value should be some string palatable to +LaTeX as a positive float Its default value is an empty string +(i.e. disabled). + +This attribute *overrides* the ~:width~ and ~:height~ attributes ; +therefore, while it can be given a default value, this should be done +only under exceptional circumstances. + +#+begin_example + +#+name: Beastie +#+caption: I think I saw this curious horse already, but where ? +#+LATEX_ATTR: :scale 2 +[[https://orgmode.org/img/org-mode-unicorn-logo.png]] + +#+end_example + ** New functions *** ~org-dynamic-block-insert-dblock~ -- 2.20.1
Re: [O] [PATCH] Feature proposal : support "scale=" includegraphics option in the builtin latex exporter.
Possible duplicate answer (my email provider isn't very reliable at the moment...). Le lundi 22 avril 2019 à 14:04 +0200, Nicolas Goaziou a écrit : > Hello, > > Emmanuel Charpentier writes: > > > Attached is my proposal for the feature I suggested. My quick tests > > pass[1]. Better tests by someone knowledgeable in graphics would > > be > > useful, as well as a test in the test suite. > > Applied, with some slight fixes. Thank you ! > Could you provide an entry in ORG-NEWS? Do you want some free text or a patch against etc/ORG-NEWS ? -- Emmanuel Charpentier
[O] [PATCH] Feature proposal : support "scale=" includegraphics option in the builtin latex exporter.
Attached is my proposal for the feature I suggested. My quick tests pass[1]. Better tests by someone knowledgeable in graphics would be useful, as well as a test in the test suite. HTH, -- Emmanuel Charpentier [1] I get unrelated failures from "make test" : 4 unexpected results: FAILED test-org-clock/clocktable/extend-today-until FAILED test-org-clock/clocktable/step FAILED test-org/timestamp-from-string FAILED test-org/timestamp-from-time I can't see any link with my proposal. BTW, I get the same failures from the unmodified master branch (fetched this morning...). Le vendredi 19 avril 2019 à 09:27 +0200, Emmanuel Charpentier a écrit : > Dear list, > > Most graphics-able exporters support some form of a scale parameter, > sizing the resultant image as a function of the original graphics > file > (intended) size. > > This is true for: > * built-in ODT exporter > * ox-pandoc Latex/ODT/DOCX exporters. > > This possibility comes handy to avoid (or at least master) the side > effects of scaling (fonts amplification, /reduction, bitmap > fuzinness, > etc...). > > It should be supported on the native LaTeX exporter (and possibly > "scale: 1" may become the default...). > > In addition (but this is probably a different problem), some > scaling/sizing mechanism may be implemented for the HTML exporter. > > -- > Emmanuel Charpentier > From 2526a06e4f77a2fdae615a95365f557c40b6d968 Mon Sep 17 00:00:00 2001 From: Emmanuel Charpentier Date: Sat, 20 Apr 2019 10:25:24 +0200 Subject: [PATCH] Support a :scale parameter in org-latex-export-to-latex and friends * lisp/ox-latex.el: introduce a :scale #+ATTR_LATEX parameter, as well as a "" default value for it. When present, it overrides :width and :height parameters (as it does for ODT export and in ox-pandoc exporters) ; therefore, setting a default value for :scale should be exceptional. Implementation: uses \scalebox for tikz/pgf images, "scale=" parameter of \includegraphics in other cases. * doc/org-manual.org: document the new :scale #+ATTR_LATEX parameter, --- doc/org-manual.org | 8 ++-- lisp/ox-latex.el | 49 ++ 2 files changed, 42 insertions(+), 15 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index a8f4a45ea..a9114184a 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -13277,14 +13277,18 @@ insert the image. But for TikZ (http://sourceforge.net/projects/pgf/) images, the back-end uses an ~\input~ macro wrapped within a ~tikzpicture~ environment. -For specifying image =:width=, =:height=, and other =:options=, use -this syntax: +For specifying image =:width=, =:height=, =:scale= and other =:options=, +use this syntax: #+begin_example ,#+ATTR_LATEX: :width 5cm :options angle=90 [[./img/sed-hr4049.pdf]] #+end_example +A =:scale= parameter overrides both =:width= and =:height= parameters ; +therefore, setting its default value should be done only in exceptional +circumstances. + For custom commands for captions, use the =:caption= attribute. It overrides the default =#+CAPTION= value: diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index cdcb07aca..60b8773b0 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -127,6 +127,7 @@ (:latex-format-headline-function nil nil org-latex-format-headline-function) (:latex-format-inlinetask-function nil nil org-latex-format-inlinetask-function) (:latex-hyperref-template nil nil org-latex-hyperref-template t) +(:latex-image-default-scale nil nil org-latex-image-default-scale) (:latex-image-default-height nil nil org-latex-image-default-height) (:latex-image-default-option nil nil org-latex-image-default-option) (:latex-image-default-width nil nil org-latex-image-default-width) @@ -708,6 +709,17 @@ This value will not be used if a height is provided." :package-version '(Org . "8.0") :type 'string) +(defcustom org-latex-image-default-scale "" + "Default scale for images. +This value will not be used if a width or a scale is provided, +or if the image is wrapped within a \"wrapfigure\",environment. +Since scale overrides width and height, setting its default +value should be done only in exceptional circumstances." + :group 'org-export-latex + :version "25.1" + :package-version '(Org . "9.2") + :type 'string) + (defcustom org-latex-image-default-height "" "Default height for images. This value will not be used if a width is provided, or if the @@ -2374,13 +2386,18 @@ used as a communication channel." (if (plist-member attr :center) (plist-get attr :center) (plist-get info :latex-images-centered))) (comment-include (if (plist-get attr :comment-include) "%" "")) - ;; It is possible to specify width and height in
[O] Feature suggestion: support "scale=" includegraphics option in the builtin latex exporter.
Dear list, Most graphics-able exporters support some form of a scale parameter, sizing the resultant image as a function of the original graphics file (intended) size. This is true for: * built-in ODT exporter * ox-pandoc Latex/ODT/DOCX exporters. This possibility comes handy to avoid (or at least master) the side effects of scaling (fonts amplification, /reduction, bitmap fuzinness, etc...). It should be supported on the native LaTeX exporter (and possibly "scale: 1" may become the default...). In addition (but this is probably a different problem), some scaling/sizing mechanism may be implemented for the HTML exporter. -- Emmanuel Charpentier
Re: [O] Possible bug (?): :noweb doesn't respect indentations (at least i R/BUGS/JAGS).
Thanks ! Ths switch excaped my attention, probably because it is buried
in a "literal example" section, which I didn't connect to noweb care
and feeding...
Maybe the "noweb" section might benefit of a discrete recall of
relevant switches ?
Thanks again !
--
Emmanuel Charpentier
Le mardi 09 avril 2019 à 16:19 +, Berry, Charles a écrit :
> > On Apr 8, 2019, at 4:01 PM, Emmanuel Charpentier <
> > emm.charpent...@free.fr> wrote:
> >
> > Compare this org source:
> >
> > ===
> > # A small :noweb mystery: indentation
> >
> > #+property: header-args:R :session
> > #+options: toc:nil
> > #+author:
> > #+date:
> >
> > The structure of a probablity proble can be represented by a ~JAGS~
> > code snippet:
> > #+name: Struct
> > #+begin_src R :eval never :exports code
> > for (i in 1:nObs) {
> >for (j in 1:nZ) {
> > Z[i,j] ~ dbern(P[i,j])
> > logit(P[i,j]) <- alpha + beta[j]*X[i]
> >}
> > }
> > #+end_src
> >
> > The same code snippet can be used for simulation:
> >
>
> See Org Manual (org) Literal Examples for information about the -i
> switch
>
> Try:
>
> #+begin_src R -i :exports code :results none :noweb yes
>
> instead of this:
>
> > #+begin_src R :exports code :results none :noweb yes
> > library(rjags)
> > library(coda)
> > ## Reproducibility ?
> > set.seed(813)
> > Params <- local({
> >nObs <- 500
> >nZ <- 5
> >X <- rnorm(nObs)
> >alpha <- rnorm(1,0,3)
> >beta <- rnorm(nZ,-1,2)
> >list(
> > nObs=nObs,
> > nZ=nZ,
> > X=X,
> > alpha=alpha,
> > beta=beta)
> > })
> > ## Wrap model code
> > M <-
> >"model {
> > <>
> > }"
> > ## Compilation
> > JM <- jags.model(textConnection(M), data=Params, n.adapt=1,
> > n.chains=1)
> > ## Forward sampling
> > JS <- coda.samples(JM, "Z", n.iter=1)
> > #+end_src
> >
> > and for inference, after adding priors of parameters:
> >
> > #+name: Priors
> > #+begin_src R :eval never :exports code
> > ## Priors
> > alpha ~ dt(0, 1e-2, 3)
> > for (j in 1:nZ) {
> >beta[j] ~ dt(0,1e-2, 3)
> > }
> > #+end_src
> >
>
> And again here:
>
>
> > #+name: Inference
> > #+begin_src R :noweb yes :exports code
> > Data <- list(
> >nObs=Params$nObs,
> >nZ=Params$nZ,
> >X=Params$X,
> >Z=matrix(as.matrix(JS), ncol=Params$nZ, byrow=FALSE))
> > ## Wrap inference model
> > MI <-
> >"model {
> > <>
> > <>
> > }"
> > ## Compilation
> > JMI <- jags.model(textConnection(MI), Data, n.chains=4)
> > ## Inference sampling
> > JMS <- coda.samples(JMI, c("alpha", "beta"), n.iter=1000)
> > #+end_src
> >
> > #+RESULTS: Inference
> > ===
> >
> > With the result of its export to Ascii:
> >
>
> [snip]
>
>
> > The indentation is not respected in the included JAGS snippets.
> > Further
> > attempts with exporting to PDF (both the built-in exporter and ox-
> > pandoc) and DOCX (ox-pandoc) show that the problem remains the
> > same,
> > but, IIRC, with slight variations in whitespace.
> >
> > That's not serious (just ugly) for R/JAGS ; but it might be serious
> > for
> > Python/Sage, where whitespace is syntaxic.
> >
> > Thoughts ?
> >
>
> Try the switch.
>
> HTH,
>
> Chuck
[O] Possible bug (?): :noweb doesn't respect indentations (at least i R/BUGS/JAGS).
Compare this org source:
===
# A small :noweb mystery: indentation
#+property: header-args:R :session
#+options: toc:nil
#+author:
#+date:
The structure of a probablity proble can be represented by a ~JAGS~
code snippet:
#+name: Struct
#+begin_src R :eval never :exports code
for (i in 1:nObs) {
for (j in 1:nZ) {
Z[i,j] ~ dbern(P[i,j])
logit(P[i,j]) <- alpha + beta[j]*X[i]
}
}
#+end_src
The same code snippet can be used for simulation:
#+begin_src R :exports code :results none :noweb yes
library(rjags)
library(coda)
## Reproducibility ?
set.seed(813)
Params <- local({
nObs <- 500
nZ <- 5
X <- rnorm(nObs)
alpha <- rnorm(1,0,3)
beta <- rnorm(nZ,-1,2)
list(
nObs=nObs,
nZ=nZ,
X=X,
alpha=alpha,
beta=beta)
})
## Wrap model code
M <-
"model {
<>
}"
## Compilation
JM <- jags.model(textConnection(M), data=Params, n.adapt=1,
n.chains=1)
## Forward sampling
JS <- coda.samples(JM, "Z", n.iter=1)
#+end_src
and for inference, after adding priors of parameters:
#+name: Priors
#+begin_src R :eval never :exports code
## Priors
alpha ~ dt(0, 1e-2, 3)
for (j in 1:nZ) {
beta[j] ~ dt(0,1e-2, 3)
}
#+end_src
#+name: Inference
#+begin_src R :noweb yes :exports code
Data <- list(
nObs=Params$nObs,
nZ=Params$nZ,
X=Params$X,
Z=matrix(as.matrix(JS), ncol=Params$nZ, byrow=FALSE))
## Wrap inference model
MI <-
"model {
<>
<>
}"
## Compilation
JMI <- jags.model(textConnection(MI), Data, n.chains=4)
## Inference sampling
JMS <- coda.samples(JMI, c("alpha", "beta"), n.iter=1000)
#+end_src
#+RESULTS: Inference
===
With the result of its export to Ascii:
===
The structure of a probablity proble can be represented by a `JAGS'
code
snippet:
,
| for (i in 1:nObs) {
| for (j in 1:nZ) {
| Z[i,j] ~ dbern(P[i,j])
| logit(P[i,j]) <- alpha + beta[j]*X[i]
| }
| }
`
The same code snippet can be used for simulation:
,
| library(rjags)
| library(coda)
| ## Reproducibility ?
| set.seed(813)
| Params <- local({
| nObs <- 500
| nZ <- 5
| X <- rnorm(nObs)
| alpha <- rnorm(1,0,3)
| beta <- rnorm(nZ,-1,2)
| list(
| nObs=nObs,
| nZ=nZ,
| X=X,
| alpha=alpha,
| beta=beta)
| })
| ## Wrap model code
| M <-
| "model {
|for (i in 1:nObs) {
|for (j in 1:nZ) {
| Z[i,j] ~ dbern(P[i,j])
| logit(P[i,j]) <- alpha + beta[j]*X[i]
|}
|}
| }"
| ## Compilation
| JM <- jags.model(textConnection(M), data=Params, n.adapt=1,
n.chains=1)
| ## Forward sampling
| JS <- coda.samples(JM, "Z", n.iter=1)
`
and for inference, after adding priors of parameters:
,
| ## Priors
| alpha ~ dt(0, 1e-2, 3)
| for (j in 1:nZ) {
| beta[j] ~ dt(0,1e-2, 3)
| }
`
,
| Data <- list(
| nObs=Params$nObs,
| nZ=Params$nZ,
| X=Params$X,
| Z=matrix(as.matrix(JS), ncol=Params$nZ, byrow=FALSE))
| ## Wrap inference model
| MI <-
| "model {
|for (i in 1:nObs) {
|for (j in 1:nZ) {
| Z[i,j] ~ dbern(P[i,j])
| logit(P[i,j]) <- alpha + beta[j]*X[i]
|}
|}
|## Priors
|alpha ~ dt(0, 1e-2, 3)
|for (j in 1:nZ) {
|beta[j] ~ dt(0,1e-2, 3)
|}
| }"
| ## Compilation
| JMI <- jags.model(textConnection(MI), Data, n.chains=4)
| ## Inference sampling
| JMS <- coda.samples(JMI, c("alpha", "beta"), n.iter=1000)
`
===
The indentation is not respected in the included JAGS snippets. Further
attempts with exporting to PDF (both the built-in exporter and ox-
pandoc) and DOCX (ox-pandoc) show that the problem remains the same,
but, IIRC, with slight variations in whitespace.
That's not serious (just ugly) for R/JAGS ; but it might be serious for
Python/Sage, where whitespace is syntaxic.
Thoughts ?
--
Emmanuel Charpentier
[O] Possible proble with Python block edition, or pilot error ?
The following python snippet does execute normally from a Python (2.7)
temporary buffer
Source : =
print "Start of block called from a Python temporary buffer"
print NomDeFichier
try:
FN=NomDeFichier
except:
FN="Chose.txt"
finally:
print FN
print "**"+FN+"**"
print "End of block called from a Python temporary buffer"
=
Execution result: =
>>> Start of block called from a Python temporary buffer
Bidule.txt
Bidule.txt
**Bidule.txt**
End of block called from a Python temporary buffer
>>> Start of block called from a Python temporary buffer
Bidule.txt
Bidule.txt
**Bidule.txt**
End of block called from a Python temporary buffer
=
But the following Babel Python block, from which the previous snippet
derives, fails to run :
Block : =
#+begin_src python :var NomDeFichier="Bidule.txt" :exports both
:results file :preamble "# -*- coding: utf-8 -*-"
print "Start of block called from an Org Python block"
print NomDeFichier
try:
FN=NomDeFichier
except:
FN="Chose.txt"
finally:
print FN
# Irrelevant for now:
# F1=file(FN,"w")
# F1.write("Tagada\n")
# F1.write("tsoin-tsoin...\n")
# F1.close()
print "End of block called from an Org Python block"
# Kept to pacify Org...
FN
#+end_src
=
Execution result : =
>>> print "Start of block called from an Org Python block"
Start of block called from an Org Python block
>>> print NomDeFichier
Bidule.txt
>>> try:
... FN=NomDeFichier
...
File "", line 3
^
SyntaxError: invalid syntax
>>> except:
File "", line 1
except:
^
SyntaxError: invalid syntax
>>> FN="Chose.txt"
File "", line 1
FN="Chose.txt"
^
IndentationError: unexpected indent
>>>
>>> finally:
File "", line 1
finally:
^
SyntaxError: invalid syntax
>>> print FN
File "", line 1
print FN
^
IndentationError: unexpected indent
>>>
>>> # Irrelevant for now:
... # F1=file(FN,"w")
... # F1.write("Tagada\n")
... # F1.write("tsoin-tsoin...\n")
... # F1.close()
... print "End of block called from an Org Python block"
End of block called from an Org Python block
>>> # Kept to pacify Org...
... FN
'Bidule.txt'
>>>
>>> open('/tmp/babel-2gEcoQ/python-r1nkjR', 'w').write(str(_))
>>>
>>>
>>> 'org_babel_python_eoe'
'org_babel_python_eoe'
>>>
=
Possibly relevant : from (packages-list-packages) :
python-mode20181223.1933 installed Python major
mode
Also posibly relevant : a very similar Sage block, whose edit mode is
sage-shell-mode, runs without problem.
I'm lost. Suggestions ?
--
Emmanuel Charpentier
Re: [O] Babel: how to get rid of the quotes wraping the result of a Sagemath code block ?
Ahem... It turns out that this was (partly) a pilot error, bound to the specifics of ob-sagemath. I still do not understand the impact of the raw and verbatim options of :results, but I'll come back later if the behaviou I got is indeed *really* buggy. Sorry for the noise... -- Emmanuel Charpentier Le samedi 02 mars 2019 à 22:11 +0100, Emmanuel Charpentier a écrit : > Dear list, > > I would like to use Sage to build the text of a Graphviz program to > display some graph, then pass this program body to a dot code block. > > The first step is easy. But I'm unable to accomplish the second one > becausethe program text (which is correct !) is wrapped in a pair of > quotes, on which Graphviz (dot) chokes. I-ve tried > * passing it as an argument (:var=myblock()) > * calling the Sage code block in a noweb call (<>) > to no avail. > > I've tried the "verbatim" and "raw" options to :results of my Sage > block. Again without success. > > It [[ > https://emacs.stackexchange.com/questions/20652/org-babels-call-functionality-wraps-all-results-in-quotes > ][seems]] > that a similar problem exists for Python code... > > Any suggestions ? > > -- > Emmanuel Charpentier
[O] Babel: how to get rid of the quotes wraping the result of a Sagemath code block ?
Dear list, I would like to use Sage to build the text of a Graphviz program to display some graph, then pass this program body to a dot code block. The first step is easy. But I'm unable to accomplish the second one becausethe program text (which is correct !) is wrapped in a pair of quotes, on which Graphviz (dot) chokes. I-ve tried * passing it as an argument (:var=myblock()) * calling the Sage code block in a noweb call (<>) to no avail. I've tried the "verbatim" and "raw" options to :results of my Sage block. Again without success. It [[ https://emacs.stackexchange.com/questions/20652/org-babels-call-functionality-wraps-all-results-in-quotes ][seems]] that a similar problem exists for Python code... Any suggestions ? -- Emmanuel Charpentier
Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...
as of today's (20190118) org-plus-contrib, this seems fixed. Quick check : === # Noweb syntax check #+property: header-args:python :session #+property: header-args:sage :session #+name: A #+begin_src sage L.append(i) #+end_src #+name: B #+begin_src sage :noweb yes :exports both L=[] for i in range(1,6): <> L #+end_src #+name: C #+begin_src python L.append(i) #+end_src #+name: D #+begin_src python :noweb yes :exports both L=[] for i in range(1,6): <> L #+end_src === Thanks a lot ! -- Emmanuel Charpentier Le lundi 04 février 2019 à 18:03 +0100, Nicolas Goaziou a écrit : > Hello, > > Robert Pluim writes: > > > John Kitchin writes: > > > > > #+RESULTS: > > > : <<\([^ > > > : ].+?[^ ]\|[^ > > > : ]\)>> > > > > That regex looks malformed, and will only match strings with 1 or 3 > > or > > more characters between << and >>. If someone knows what itʼs > > supposed > > to be matching we can fix it. eg it looks like it wants to allow > > > > < > > > Is that something that should be accepted? > > I fixed the regexp. Thank you. > > Regards, >
Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...
Le lundi 04 février 2019 à 08:11 -0500, John Kitchin a écrit :
> The problem may be the name is only two characters long. Try Ahh
> instead. That works for me.
Indeed. Nice catch ; how did you find this ?
Since this doesn't happen with emacs-lisp or Sage, and since nothing in
the docs I've read so far suggests anything about the length of a block
identifier, I consider this a bug in the Python language support code.
What do you think ? Any hint ?
Thanks a lot !
--Emmanuel Charpentier
> John
>
> ---
> 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
>
>
>
> On Mon, Feb 4, 2019 at 7:00 AM Emmanuel Charpentier <
> emm.charpent...@free.fr> wrote:
> > Seen in `org-mode' version `9.2'.
> >
> >
> >
> > Using `noweb' syntax works OK with `emacs-lisp':
> >
> >
> >
> > ┌
> >
> > │ #+name: a
> >
> > │ #+begin_src emacs-lisp
> >
> > │ (setq L (append L (list i)))
> >
> > │ #+end_src
> >
> > │
> >
> > │ #+name: b
> >
> > │ #+begin_src emacs-lisp :noweb yes :exports both
> >
> > │ ;; Lisp version
> >
> > │ (setq L nil)
> >
> > │ (dotimes (i 5) <>)
> >
> > │ L
> >
> > │ #+end_src
> >
> > └
> >
> >
> >
> > This gives :
> >
> >
> >
> > ┌
> >
> > │ (setq L (append L (list i)))
> >
> > └
> >
> >
> >
> > ┌
> >
> > │ ;; Lisp version
> >
> > │ (setq L nil)
> >
> > │ (dotimes (i 5) )
> >
> > │ L
> >
> > └
> >
> >
> >
> > The `noweb' syntax also works with `Sage' (a symbolic maths
> > oriented
> >
> > Python derivative):
> >
> >
> >
> > ┌
> >
> > │ #+name: Aaarghhh
> >
> > │ #+begin_src sage
> >
> > │ L.append(i)
> >
> > │ #+end_src
> >
> > │
> >
> > │ #+name: Berde
> >
> > │ #+begin_src sage :noweb yes :exports both
> >
> > │ ## Python version
> >
> > │ L=[]
> >
> > │ for i in range(1,6):
> >
> > │ <>
> >
> > │ L
> >
> > │ #+end_src
> >
> > └
> >
> >
> >
> > wich gives :
> >
> >
> >
> > ┌
> >
> > │ L.append(i)
> >
> > └
> >
> >
> >
> > ┌
> >
> > │ ## Sage version
> >
> > │ L=[]
> >
> > │ for i in range(1,6):
> >
> > │
> >
> > │ L
> >
> > └
> >
> >
> >
> > But using the same syntax in Python fails miserably:
> >
> >
> >
> > ┌
> >
> > │ #+name: Ah
> >
> > │ #+begin_src python
> >
> > │ L.append(i)
> >
> > │ #+end_src
> >
> > │
> >
> > │ #+name: Beee
> >
> > │ #+begin_src python :noweb yes :exports both
> >
> > │ ## Python version
> >
> > │ L=[]
> >
> > │ for i in range(1,6):
> >
> > │ <>
> >
> > │ L
> >
> > │ #+end_src
> >
> > └
> >
> >
> >
> > ┌
> >
> > │ L.append(i)
> >
> > └
> >
> >
> >
> > ┌
> >
> > │ ## Python version
> >
> > │ L=[]
> >
> > │ for i in range(1,6):
> >
> > │ <>
> >
> > │ L
> >
> > └
> >
> >
> >
> > ┌
> >
> > │ []
> >
> > └
> >
> >
> >
> >
> >
> > It *seems* that the "Ah" block is not expanded.
> >
> >
> >
> > The code itself should be sound *if* it expanded:
> >
> >
> >
> > ┌
> >
> > │ #+name: B0
> >
> > │ #+begin_src python :exports both
> >
> > │ L=[]
> >
> > │ for i in range(1,6):
> >
> > │ L.append(i)
> >
> > │ L
> >
> > │ #+end_src
> >
> > └
> >
> >
> >
> > ┌
> >
> > │ L=[]
> >
> > │ for i in range(1,6):
> >
> > │ L.append(i)
> >
> > │ L
> >
> > └
> >
> >
> >
> > ━━━
> >
> > 1 2 3 4 5
> >
> > ━━━
> >
> >
> >
> > During the compilation of the source of this mail, the following is
> >
> > printed in the `*Python*' buffer:
> >
> >
> >
> > ┌
> >
> > │ >>> L.append(i)
> >
> > │ >>>
> >
> > │ >>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
> >
> > │ >>>
> >
> > │ >>>
> >
> > │ >>> 'org_babel_python_eoe'
> >
> > │ 'org_babel_python_eoe'
> >
> > │ >>> ## Python version
> >
> > │ ... L=[]
> >
> > │ >>> for i in range(1,6):
> >
> > │ ... <>
> >
> > │ File "", line 2
> >
> > │ <>
> >
> > │ ^
> >
> > │ SyntaxError: invalid syntax
> >
> > │ >>>
> >
> > │ >>> L
> >
> > │ []
> >
> > │ >>>
> >
> > │ >>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
> >
> > │ >>>
> >
> > │ >>>
> >
> > │ >>> 'org_babel_python_eoe'
> >
> > │ 'org_babel_python_eoe'
> >
> > │ >>> L=[]
> >
> > │ >>> for i in range(1,6):
> >
> > │ ... L.append(i)
> >
> > │ ...
> >
> > │ >>> L
> >
> > │ [1, 2, 3, 4, 5]
> >
> > │ >>>
> >
> > │ >>> open('/tmp/babel-OJSsxf/python-fW5gK0', 'w').write(str(_))
> >
> > │ >>>
> >
> > │ >>>
> >
> > │ >>> 'org_babel_python_eoe'
> >
> > │ 'org_babel_python_eoe'
> >
> > │ >>>
> >
> > └
> >
> >
> >
> > The source code of this mail is attached.
> >
> >
> >
> > --
> >
> > Emmanuel Charpentier
> >
[O] (9.2) Noweb blocks not expanded in Python blocks.
Seen in `org-mode' version `9.2'.
Using `noweb' syntax works OK with `emacs-lisp':
┌
│ #+name: a
│ #+begin_src emacs-lisp
│ (setq L (append L (list i)))
│ #+end_src
│
│ #+name: b
│ #+begin_src emacs-lisp :noweb yes :exports both
│ ;; Lisp version
│ (setq L nil)
│ (dotimes (i 5) <>)
│ L
│ #+end_src
└
This gives :
┌
│ (setq L (append L (list i)))
└
┌
│ ;; Lisp version
│ (setq L nil)
│ (dotimes (i 5) )
│ L
└
The `noweb' syntax also works with `Sage' (a symbolic maths oriented
Python derivative):
┌
│ #+name: Aaarghhh
│ #+begin_src sage
│ L.append(i)
│ #+end_src
│
│ #+name: Berde
│ #+begin_src sage :noweb yes :exports both
│ ## Python version
│ L=[]
│ for i in range(1,6):
│ <>
│ L
│ #+end_src
└
wich gives :
┌
│ L.append(i)
└
┌
│ ## Sage version
│ L=[]
│ for i in range(1,6):
│
│ L
└
But using the same syntax in Python fails miserably:
┌
│ #+name: Ah
│ #+begin_src python
│ L.append(i)
│ #+end_src
│
│ #+name: Beee
│ #+begin_src python :noweb yes :exports both
│ ## Python version
│ L=[]
│ for i in range(1,6):
│ <>
│ L
│ #+end_src
└
┌
│ L.append(i)
└
┌
│ ## Python version
│ L=[]
│ for i in range(1,6):
│ <>
│ L
└
┌
│ []
└
It *seems* that the "Ah" block is not expanded.
The code itself should be sound *if* it expanded:
┌
│ #+name: B0
│ #+begin_src python :exports both
│ L=[]
│ for i in range(1,6):
│ L.append(i)
│ L
│ #+end_src
└
┌
│ L=[]
│ for i in range(1,6):
│ L.append(i)
│ L
└
━━━
1 2 3 4 5
━━━
During the compilation of the source of this mail, the following is
printed in the `*Python*' buffer:
┌
│ >>> L.append(i)
│ >>>
│ >>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
│ >>>
│ >>>
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> ## Python version
│ ... L=[]
│ >>> for i in range(1,6):
│ ... <>
│ File "", line 2
│ <>
│ ^
│ SyntaxError: invalid syntax
│ >>>
│ >>> L
│ []
│ >>>
│ >>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
│ >>>
│ >>>
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> L=[]
│ >>> for i in range(1,6):
│ ... L.append(i)
│ ...
│ >>> L
│ [1, 2, 3, 4, 5]
│ >>>
│ >>> open('/tmp/babel-OJSsxf/python-fW5gK0', 'w').write(str(_))
│ >>>
│ >>>
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>>
└
The source code of this mail is attached.
--
Emmanuel Charpentier
# Syntaxe noweb ?
#+title:
#+date:
#+author:
#+options: toc:nil
#+property: header-args:python :session
#+property: header-args:sage :session
Seen in ~org-mode~ version src_emacs-lisp{org-version}.
Using ~noweb~ syntax works OK with ~emacs-lisp~:
#+begin_example
#+name: a
#+begin_src emacs-lisp
(setq L (append L (list i)))
#+end_src
#+name: b
#+begin_src emacs-lisp :noweb yes :exports both
;; Lisp version
(setq L nil)
(dotimes (i 5) <>)
L
#+end_src
#+end_example
This gives :
#+name: a
#+begin_src emacs-lisp
(setq L (append L (list i)))
#+end_src
#+name: b
#+begin_src emacs-lisp :noweb yes :exports both
;; Lisp version
(setq L nil)
(dotimes (i 5) <>)
L
#+end_src
The ~noweb~ syntax also works with ~Sage~ (a symbolic maths oriented
Python derivative):
#+begin_example
#+name: Aaarghhh
#+begin_src sage
L.append(i)
#+end_src
#+name: Berde
#+begin_src sage :noweb yes :exports both
## Python version
L=[]
for i in range(1,6):
<>
L
#+end_src
#+end_example
wich gives :
#+name: Aaarghhh
#+begin_src sage
L.append(i)
#+end_src
#+name: Berde
#+begin_src sage :noweb yes :exports both
## Sage version
L=[]
for i in range(1,6):
<>
L
#+end_src
But using the same syntax in Python fails miserably:
#+begin_example
#+name: Ah
#+begin_src python
L.append(i)
#+end_src
#+name: Beee
#+begin_src python :noweb yes :exports both
## Python version
L=[]
for i in range(1,6):
<>
L
#+end_src
#+end_example
#+name: Ah
#+begin_src python
L.append(i)
#+end_src
#+name: Beee
#+begin_src python :noweb yes :exports both
## Python version
L=[]
for i in range(1,6):
<>
L
#+end_src
It *seems* that the "Ah" block is not expanded.
The code itself should be sound *if* it expanded:
#+begin_example
#+name: B0
#+begin_src python :exports both
L=[]
for i in range(1,6):
L.append(i)
L
#+end_src
#+end_example
#+name: B0
#+begin_src python :exports both
L=[]
for i in range(1,6):
L.append(i)
L
#+end_src
During the compilation of the source of this mail, the following is
printed in the ~*Python*~ buffer:
#+begin_example
>>> L.append(i)
>&
[O] (9.2) Noweb syntax not understood in Python blocks
Seen in `org-mode' version `9.2'.
Using `noweb' syntax works OK with `emacs-lisp':
┌
│ #+name: a
│ #+begin_src emacs-lisp
│ (setq L (append L (list i)))
│ #+end_src
│
│ #+name: b
│ #+begin_src emacs-lisp :noweb yes :exports both
│ ;; Lisp version
│ (setq L nil)
│ (dotimes (i 5) <>)
│ L
│ #+end_src
└
This gives :
┌
│ (setq L (append L (list i)))
└
┌
│ ;; Lisp version
│ (setq L nil)
│ (dotimes (i 5) )
│ L
└
The `noweb' syntax also works with `Sage' (a symbolic maths oriented
Python derivative):
┌
│ #+name: Aaarghhh
│ #+begin_src sage
│ L.append(i)
│ #+end_src
│
│ #+name: Berde
│ #+begin_src sage :noweb yes :exports both
│ ## Python version
│ L=[]
│ for i in range(1,6):
│ <>
│ L
│ #+end_src
└
wich gives :
┌
│ L.append(i)
└
┌
│ ## Sage version
│ L=[]
│ for i in range(1,6):
│
│ L
└
But using the same syntax in Python fails miserably:
┌
│ #+name: Ah
│ #+begin_src python
│ L.append(i)
│ #+end_src
│
│ #+name: Beee
│ #+begin_src python :noweb yes :exports both
│ ## Python version
│ L=[]
│ for i in range(1,6):
│ <>
│ L
│ #+end_src
└
┌
│ L.append(i)
└
┌
│ ## Python version
│ L=[]
│ for i in range(1,6):
│ <>
│ L
└
┌
│ []
└
It *seems* that the "Ah" block is not expanded.
The code itself should be sound *if* it expanded:
┌
│ #+name: B0
│ #+begin_src python :exports both
│ L=[]
│ for i in range(1,6):
│ L.append(i)
│ L
│ #+end_src
└
┌
│ L=[]
│ for i in range(1,6):
│ L.append(i)
│ L
└
━━━
1 2 3 4 5
━━━
During the compilation of the source of this mail, the following is
printed in the `*Python*' buffer:
┌
│ >>> L.append(i)
│ >>>
│ >>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
│ >>>
│ >>>
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> ## Python version
│ ... L=[]
│ >>> for i in range(1,6):
│ ... <>
│ File "", line 2
│ <>
│ ^
│ SyntaxError: invalid syntax
│ >>>
│ >>> L
│ []
│ >>>
│ >>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
│ >>>
│ >>>
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> L=[]
│ >>> for i in range(1,6):
│ ... L.append(i)
│ ...
│ >>> L
│ [1, 2, 3, 4, 5]
│ >>>
│ >>> open('/tmp/babel-OJSsxf/python-fW5gK0', 'w').write(str(_))
│ >>>
│ >>>
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>>
└
The source code of this mail is attached.
--
Emmanuel Charpentier
# Syntaxe noweb ?
#+title:
#+date:
#+author:
#+options: toc:nil
#+property: header-args:python :session
#+property: header-args:sage :session
Seen in ~org-mode~ version src_emacs-lisp{org-version}.
Using ~noweb~ syntax works OK with ~emacs-lisp~:
#+begin_example
#+name: a
#+begin_src emacs-lisp
(setq L (append L (list i)))
#+end_src
#+name: b
#+begin_src emacs-lisp :noweb yes :exports both
;; Lisp version
(setq L nil)
(dotimes (i 5) <>)
L
#+end_src
#+end_example
This gives :
#+name: a
#+begin_src emacs-lisp
(setq L (append L (list i)))
#+end_src
#+name: b
#+begin_src emacs-lisp :noweb yes :exports both
;; Lisp version
(setq L nil)
(dotimes (i 5) <>)
L
#+end_src
The ~noweb~ syntax also works with ~Sage~ (a symbolic maths oriented
Python derivative):
#+begin_example
#+name: Aaarghhh
#+begin_src sage
L.append(i)
#+end_src
#+name: Berde
#+begin_src sage :noweb yes :exports both
## Python version
L=[]
for i in range(1,6):
<>
L
#+end_src
#+end_example
wich gives :
#+name: Aaarghhh
#+begin_src sage
L.append(i)
#+end_src
#+name: Berde
#+begin_src sage :noweb yes :exports both
## Sage version
L=[]
for i in range(1,6):
<>
L
#+end_src
But using the same syntax in Python fails miserably:
#+begin_example
#+name: Ah
#+begin_src python
L.append(i)
#+end_src
#+name: Beee
#+begin_src python :noweb yes :exports both
## Python version
L=[]
for i in range(1,6):
<>
L
#+end_src
#+end_example
#+name: Ah
#+begin_src python
L.append(i)
#+end_src
#+name: Beee
#+begin_src python :noweb yes :exports both
## Python version
L=[]
for i in range(1,6):
<>
L
#+end_src
It *seems* that the "Ah" block is not expanded.
The code itself should be sound *if* it expanded:
#+begin_example
#+name: B0
#+begin_src python :exports both
L=[]
for i in range(1,6):
L.append(i)
L
#+end_src
#+end_example
#+name: B0
#+begin_src python :exports both
L=[]
for i in range(1,6):
L.append(i)
L
#+end_src
During the compilation of the source of this mail, the following is
printed in the ~*Python*~ buffer:
#+begin_example
>>> L.append(i)
>&
Re: [O] Possible bug(s) in MathML handling in ODT export
Sorry for the noise : the bugs do exist, but my previous analysis was false (one paren too much). More data points : * I installed also MathToWeb, and configured it in emacs (via file-local-variables), with the same problematic result. * The error message "LaTeX to MathML converter not configured" appears exactly twice in org.el: + In org-format-latex + In org-create-math-formula * In both cases, the call has the form : = (unless (org-format-latex-mathml-available-p) (user-error "LaTeX to MathML converter not configured"))) = * When evaluated from M-: (org-format-latex-mathml-available-p) returns t (as it should...). * I have been so far unable to trace the origin of the faulty evaluations. I'll probably have to run an uncompiled org for this, and I don't (yet) know how to do that. Interim hypothesis : the relevant variables (org-latex-to-mathml-jar-file and org-latex-to-mathml-convert-command) may be inadvertently shadowed somewhere upstream in the call tree. I'm afraid to be a bit out of my depth here... Suggestions ? -- Emmanuel Charpentier Le lundi 24 décembre 2018 à 01:24 +0100, Emmanuel Charpentier a écrit : > Dear list, > > I have a couple of gripes about LaTeX handling in ODT export when one > needs MathML conversion, and therefore a couple of questions: > > The first one is possibly a gripe with the ox-pandoc exporters. The > doc > (info manual) states : > > "Add this line to the Org file. This option is activated on a per- > file > basis. > > #+OPTIONS: LaTeX:t" > > It seems that this option is *NOT* handled by the ox-pandoc exporters > : > when using one of these, the text "LaTeX:t" appears at the top of the > output. > > Hence my first question : what should be responsible for handling > this > option : org mode or ox-pandoc ? > > The second one is that I can't get org to acknowledge the > configuration > of org-latex-to-mathml-convert-command. A bit of peeking int the > source > leads to this function, responsible for testing it : > = > == > (defun org-format-latex-mathml-available-p () > "Return t if `org-latex-to-mathml-convert-command' is usable." > (save-match-data > (when (and (boundp 'org-latex-to-mathml-convert-command) > org-latex-to-mathml-convert-command) > (let ((executable (car (split-string > org-latex-to-mathml-convert-command > (when (executable-find executable) > (if (string-match > "%j" org-latex-to-mathml-convert-command) > (file-readable-p org-latex-to-mathml-jar-file) > t)) > = > == > > As written, I can't see how one can use latexmlmath WITHOUT having > ALSO > the MathToWeb jar file somewhere : the test for it is systematic ; > therefore, it fails if the jarfile isn't configured/available. > > The value of executable should be tested, and the test for the > jarfile > should be done *only* if executable is "java" (or, better, belongs to > a > list of "reasonable" java executables or scripts...). > > So my second question is : what do you think ? > > HTH, > > -- > Emmanuel Charpentier > >
[O] Possible bug(s) in MathML handling in ODT export
Dear list, I have a couple of gripes about LaTeX handling in ODT export when one needs MathML conversion, and therefore a couple of questions: The first one is possibly a gripe with the ox-pandoc exporters. The doc (info manual) states : "Add this line to the Org file. This option is activated on a per-file basis. #+OPTIONS: LaTeX:t" It seems that this option is *NOT* handled by the ox-pandoc exporters : when using one of these, the text "LaTeX:t" appears at the top of the output. Hence my first question : what should be responsible for handling this option : org mode or ox-pandoc ? The second one is that I can't get org to acknowledge the configuration of org-latex-to-mathml-convert-command. A bit of peeking int the source leads to this function, responsible for testing it : === (defun org-format-latex-mathml-available-p () "Return t if `org-latex-to-mathml-convert-command' is usable." (save-match-data (when (and (boundp 'org-latex-to-mathml-convert-command) org-latex-to-mathml-convert-command) (let ((executable (car (split-string org-latex-to-mathml-convert-command (when (executable-find executable) (if (string-match "%j" org-latex-to-mathml-convert-command) (file-readable-p org-latex-to-mathml-jar-file) t)) === As written, I can't see how one can use latexmlmath WITHOUT having ALSO the MathToWeb jar file somewhere : the test for it is systematic ; therefore, it fails if the jarfile isn't configured/available. The value of executable should be tested, and the test for the jarfile should be done *only* if executable is "java" (or, better, belongs to a list of "reasonable" java executables or scripts...). So my second question is : what do you think ? HTH, -- Emmanuel Charpentier
Re: [O] Problem with references to babel source blocks (possible bug).
Dear John, dear list,
Indeed using minted works (at least when using labels. I have not yet
tried to use #+NAME:s). See a few remarks below.
Le jeu. 20 déc. 2018 à 21:47, John Kitchin a écrit :
>
> I guess there is some subtle point missing. For the source blocks I
> usually use the minted package, which I think makes code blocks as a
> listing float. In your tex file, they are verbatim environments, and you
> have \captionof{figure} under them which is presumably why they are
> labeled as figures.
>
> Try adding ("" "minted" nil) to # org-latex-packages-alist:
>
> and add this to an init file: (setq org-latex-listings 'minted).
The mistery starts with the "Src blocks" part of ox-latex (starting
line 895 in today's version of this file). In the default case (i. e.
when org-latex-listing is not set), this modules exports a verbatim
environment ... and a \labelof{figure} label !!!
Another part of the mystery is explained in the function
org-latex-keyword (starting at line 2218 of today's version of
org-latex.el). This function is, among others, in charge of
determining the environment of a table of contents for code snippets.
This tests org-latex-listings and switches :
nil --> listoffigures
minted --> listoflistings
otherwise --> lstlistoflitings
BTW, reading this code also allows to understand why org-mode complies
to #+TOC: headings, #+TOC: tables, #+TOC: listings, but NOT #+TOC:
figures.
I wonder why this choice has been made. Probably because this avoids
the need for a latex package for source code listings. hich is indeed
a bit of a quandary :
* listings is obsolete, unmaintained and has serious issues with
anything not strict ASCII (plays fast and loose with TeX catcodes...).
* minted needs to write and read intermediate file, which is a bt of a
security risk, hence not enabled by default.
The choice of figures as a default environment for code snippets has a
couple consequences :
* Problems at exporting anywhere but latex
* No way to have simultaneously a list of figures and list of listings
* No list of figures bt by direct use of "\listoffigures" in LaTeX.
Shouldn't we consider this a bit of a misdesign ? I dont (yet) seem a
way to en hance this.
Suggestions ?
--
Emmanuel Charpentier
> Best wishes,
>
> Emmanuel Charpentier writes:
>
> > I wish to be able to reference (i. e cross-references, lists) both some
> > tables or figures AND the code producing the objects.
> >
> > To this effect, I added (distinct) #+caption:s to the source blocks AND
> > to the results, adorned with (distinct) org-ref's labels. An example (
> > Min-Ref.org) is included in this Google Drive directory*:
> > https://drive.google.com/drive/folders/1T6N_-WwphlnL2mB4f6BgX0u1K5mLnz4i?usp=sharing
> > .
> >
> > The comparison of this source, the LaTeX code obtained by org-latex
> > export-to latex (Min-Ref.tex) and the resultant PDF (Min-Ref exported
> > by org-latex-export-to-pdf.pdf) show that the labels attributed to
> > source blocks are mislabeled as figures. Furthermore, while the org
> > source requests a list of figure, a list of table and a list of
> > listings (in that order), the list of figures appears *after* the list
> > of tables.
> >
> > I am tempted to conclude that there is some confusion between figures
> > and listings. Further attempts tend to show that the problem may live n
> > the core org's code, rather than any specific exporter :
> >
> > The ODT "native" exporter (org-odt-export-to-odt) is much less capable,
> > as shown in Min-Ref exported by org-odt-export-to-odt.odt.
> >
> > Attempts to export via Pandoc to PDF (Min-Ref exported by org-pandoc-
> > export-to-latex-pdf.pdf), ODT (Min-Ref exported by org-pandoc-export-
> > to-odt.odt) and DOCX (Min-Ref.docx) show that these exporters may need
> > some specific configurations in order to be even vaguely usable.
> >
> > Previous trials, using #+names: rather than org-ref's labels, gave
> > similar failures. If needed, I can reproduce these trials.
> >
> > So I have a couple questions :
> >
> > 1) Is the confusion of source blocks and figures a bug, or do I miss a
> > subtle point ?
> >
> > 2) Is there some introductory material to the care and feeding of ox-
> > pandoc demonstrating the use of this exporter's options to enable the
> > addition of the needed features (figure inclusion, tables of tables /
> > figures / listings, etc...) ? The "manual" available as a README is way
> > too terse to be usable without diving in the source code and pandoc's
> > documentation.
> >
> > Sincerely,
>
>
> --
> 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
[O] Problem with references to babel source blocks (possible bug).
I wish to be able to reference (i. e cross-references, lists) both some tables or figures AND the code producing the objects. To this effect, I added (distinct) #+caption:s to the source blocks AND to the results, adorned with (distinct) org-ref's labels. An example ( Min-Ref.org) is included in this Google Drive directory*: https://drive.google.com/drive/folders/1T6N_-WwphlnL2mB4f6BgX0u1K5mLnz4i?usp=sharing . The comparison of this source, the LaTeX code obtained by org-latex export-to latex (Min-Ref.tex) and the resultant PDF (Min-Ref exported by org-latex-export-to-pdf.pdf) show that the labels attributed to source blocks are mislabeled as figures. Furthermore, while the org source requests a list of figure, a list of table and a list of listings (in that order), the list of figures appears *after* the list of tables. I am tempted to conclude that there is some confusion between figures and listings. Further attempts tend to show that the problem may live n the core org's code, rather than any specific exporter : The ODT "native" exporter (org-odt-export-to-odt) is much less capable, as shown in Min-Ref exported by org-odt-export-to-odt.odt. Attempts to export via Pandoc to PDF (Min-Ref exported by org-pandoc- export-to-latex-pdf.pdf), ODT (Min-Ref exported by org-pandoc-export- to-odt.odt) and DOCX (Min-Ref.docx) show that these exporters may need some specific configurations in order to be even vaguely usable. Previous trials, using #+names: rather than org-ref's labels, gave similar failures. If needed, I can reproduce these trials. So I have a couple questions : 1) Is the confusion of source blocks and figures a bug, or do I miss a subtle point ? 2) Is there some introductory material to the care and feeding of ox- pandoc demonstrating the use of this exporter's options to enable the addition of the needed features (figure inclusion, tables of tables / figures / listings, etc...) ? The "manual" available as a README is way too terse to be usable without diving in the source code and pandoc's documentation. Sincerely, -- Emmanuel Charpentier * Six attempts at posting those files attached to the present mail have convinced me that the list manager rejects at least the messages containing some attachments (docx ? dot ?) ; I'm a little bit fed up with this...
Re: [O] Meta : what can be sent to this mailing list ?
Thanks ! I'll make a sixth attempt... -- Emmanuel Charpentier Le mer. 19 déc. 2018 à 16:04, Eric S Fraga a écrit : > On Wednesday, 19 Dec 2018 at 15:39, Emmanuel Charpentier wrote: > > Could you let me know if some attachments are blocked by the list manager > > or mail server ? > > Not that I have seen. > > This email obviously got through. > > -- > Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1035-gfeb442 >
[O] Meta : what can be sent to this mailing list ?
Dear list, I have made five attempts in three days to post a question to this list. Three of them may have failed due to the use of an SMTP server flagged on one site as possible spam source. The other two has been sent via gmai. So far, none of these message have appeared on the list, and I received no error message. I know tha *some* attachments are accepted (a previous question of mine included .tex, .pdf and .org files). However, I waonder if my mails may have been blocked by .docx and .odt attachments. Could you let me know if some attachments are blocked by the list manager or mail server ? Tkanks in advance, -- Emmanuel Charpentier
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Rights transferred to FSF (scanned signed copy of the form set to ass...@fsf.org). HTH, -- Emmanuel Charpentier Le dim. 2 déc. 2018 à 21:26, a écrit : > Dear all, > > Please find enclosed a proposed patch (against master) to document the > need for babel/polyglossia in order to honor #+language in LaTeX > export. > > This is purely a documentation patch. A better solution would be to > detect the use of a non-default #+language: and act accordingly. > Nicolas notes (rightly) that babel (and polyglossia, BTW) are too > "invasive" to be default, and is shy of auto-loading the necessary > package(s) "automagically. > > I do not (yet) know how ti reconcile these imperative, hence the > present interim atch (which should disappear if/when a better solution > is created). > > HTH, > > -- > Emmanuel Charpentier > > > Le jeudi 29 novembre 2018 à 20:12 +0100, Nicolas Goaziou a écrit : > > Emmanuel Charpentier writes: > > > > > This is *not* *documented* (not even in the `org-latex-packages- > > > alist''s > > > docstring). > > > > I know. I fixed `org-latex-packages-alist''s docstring two days ago. > > > > > Also agreed, with the reservation that "invasive" didn't mean the > > > same > > > thing in the 1980s (when the core size of computers was measured in > > > kilobytes) and in the 2010s (the current core measurement unit is > > > the > > > /giga/byte...). > > > > Not invasive by its sheer size, but by the number of alterations it > > generates in the LaTeX default behaviour, and the incompatibilities > > it > > may introduce. For example there used to be issues between frenchb > > and > > KOMA-Script. > > > > > Again, I think that the end user should *not* have to worry with > > > this only > > > when exporting to LaTeX (or beamer or PDF). > > > > Ideally, that would be nice. > > > > > If this can be handled silently when exporting to ODT, HTML or > > > plain > > > text, it should be handled silently when exporting to LaTeX. > > > > I disagree. Packages should not be loaded /silently/. > > > > > I do not know how to handle this. My *hunch* is that the Latex > > > Export > > > function generating the preamble should check for language > > > > It does already, in `org-latex-guess-babel-language'. > > > > > and if not default, add the relevant package(s) to the preamble. > > > > Don't. Anything that is in the header should be declared. > > > > We could try and see if Babel causes trouble by adding it to default > > packages in "next" branch. I'd rather do that than inserting it > > magically. >
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Dear Nicolas,
Thanks a lot for bearing with my nitpicking. A couple remarks below
Le jeudi 29 novembre 2018 à 15:07 +0100, Nicolas Goaziou a écrit :
> Hello,
>
> emanuel.charpent...@gmail.com writes:
>
> > AFAICT, polyglossia is to be preferred to babel for use with
> > xelatex or
> > lualatex. I'll see if this can be accomodated.
>
> What I mean is that you can also add compiler dependant packages in
> `org-latex-packages-alist'.
This is *not* *documented* (not even in the `org-latex-packages-alist''s
docstring).
I *checked* that one can add 4-element "cells" to this list (i. e. (list
argument package, snippet-flag, list-of-compilers)), but could not *guess*
it : I'm still running /H sapiens sapiens L./ v 1.0, no telepathic
interface, no oracular coprocessor. The only way would have been to read
the source code : not exactly the first reflex of the average end-user.
> No need to change the default package list.
I dispute that, since this "special configuration" is needed for LaTeX
export *only* , and *only* with non-English #+language:s. This
"exceptional" treatment should be handled silently by org-mode (as it does
with ODT, HTML and plain text export...). But see below.
> > > it should be ("AUTO" "babel" t).
> >
> > OK. That's much clearer. And does what is intended, BTW.
> >
> > Shouldn't that be default ?(No, I don't (yet) know *how* to do
> > that..).
>
> Babel is no small package.
Agreed. And polyglossia is worse...
> I think it would be a bit invasive as
> a default package.
Also agreed, with the reservation that "invasive" didn't mean the same
thing in the 1980s (when the core size of computers was measured in
kilobytes) and in the 2010s (the current core measurement unit is the
/giga/byte...).
> However, it is a good candidate for user-defined
> packages, i.e., `org-latex-packages-alist'.
Again, I think that the end user should *not* have to worry with this only
when exporting to LaTeX (or beamer or PDF). If this can be handled silently
when exporting to ODT, HTML or plain text, it should be handled silently
when exporting to LaTeX.
I do not know how to handle this. My *hunch* is that the Latex Export
function generating the preamble should check for language, and if not
default, add the relevant package(s) to the preamble. I'll need to dive in
the source code to be more precise (not anytime soon, though...).
> > Thus introducing a serious problem : exporting to text or ODT works
> > as
> > described, whereas export to latex needs (undocumented)
> > supplementary
> > steps.
> >
> > At the very minimum, this need for further config should be
> > mentioned
> > in the docs ; preferably, a default should be proposed.
>
> See above about the default. However, please feel free to suggest
> documentation improvements, however.
I'll propose a documentation attempt. But this should be considered as a
workaround, the real solution being the implementation of automatic
handling...
Cordially yours,
--
Emmanuel Charpentier
> Regards,
>
>
>
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Le mercredi 28 novembre 2018 à 00:40 +0100, Nicolas Goaziou a écrit :
> emanuel.charpent...@gmail.com writes:
>
> > Le mardi 27 novembre 2018 à 21:26 +0100, Nicolas Goaziou a écrit :
> >
> > [ Snip... ]
> >
> > > What happens if you remove "org-ref.el" reference?
> >
> > Same thing.
> >
> > Even after uninstalling org-ref and its dependencies.
> >
> > Sorry...
>
> OK. I got it. This has nothing to do with LANGUAGE keyword.
>
> Babel is not a default package, per `org-latex-default-packages-
> alist.
> You need to add it to `org-latex-packages-alist'.
Close, but no cigar :
I used the `customize' interface to add it to `org-latex-default-
packages-alist' (because the package to load is compiler-dependent),
which becomes:
(("AUTO" "inputenc" t
("pdflatex"))
("T1" "fontenc" t
("pdflatex"))
(#1="" "graphicx" t nil)
(#1# "grffile" t nil)
(#1# "longtable" nil nil)
(#1# "wrapfig" nil nil)
(#1# "rotating" nil nil)
("normalem" "ulem" t nil)
(#1# "amsmath" t nil)
(#1# "textcomp" t nil)
(#1# "amssymb" t nil)
(#1# "capt-of" nil nil)
(#1# "hyperref" nil nil)
(#1# "babel" t
("pdflatex"))
(#1# "polyglossia" t
("xelatex" "lualatex")))
I then retried an example (similar to the first one, but another
machine...) (see enclosed files).
* The latex file does indeed contain "\usepackage{babel}" at the end
of preamble
* But the language is never set.
* Therefore, no "frenchizing" happens...
This is due to the fact that, in order to get what I mean, the babel
loading should be "\usepackage[frenchb]{babel}", i. e. take the value
corresponding to whatever #+language: implies ("frenchb" for "fr",
etc...). I do not know how to do that.
Is there a documented way to do that, or should I dive in ox-latex
source ?
A couple of remarks :
* If this setup is necessary to get #+langiage: honored fot LaTeX
export, this should be done by default (i. e. in org's source
code).
* One might wish to allow to fully use babel's (and polyglossia's)
abilities by specifying a set of possible #+language:s (first
call) or switch to another language (further calls down the
file...).
* concerning french: I understand that "frenchb" is obsolete and
that one should use "french" instead (better compatibility with
ispell and flyspell-babel, among others)...
* I suggest a '(#1# "fontspec" t '(xelatex lualatex)), and possibly
an '(#1# "mathspec" t '(xetex luatex)) or '(#1# "unicode-math" t
'(xetex luatex))
entry(ies) to be added to the default : xetex is more and more
used, and luatex is officially the successor to pdftex...
HTH,
--
Emmanuel Charpentier
Le mer. 28 nov. 2018 à 00:40, Nicolas Goaziou a
écrit :
> emanuel.charpent...@gmail.com writes:
>
> > Le mardi 27 novembre 2018 à 21:26 +0100, Nicolas Goaziou a écrit :
> >
> > [ Snip... ]
> >
> >> What happens if you remove "org-ref.el" reference?
> >
> > Same thing.
> >
> > Even after uninstalling org-ref and its dependencies.
> >
> > Sorry...
>
> OK. I got it. This has nothing to do with LANGUAGE keyword.
>
> Babel is not a default package, per `org-latex-default-packages-alist.
> You need to add it to `org-latex-packages-alist'.
>
>
TstFrench.org
Description: Binary data
% Created 2018-11-28 mer. 11:48
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage{babel}
\author{Emmanuel Charpentier}
\date{Novembre 2018}
\title{Test de l'option \texttt{\#+language:}}
\hypersetup{
pdfauthor={Emmanuel Charpentier},
pdftitle={Test de l'option \texttt{\#+language:}},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 27.0.50 (Org mode 9.1.14)},
pdflang={French}}
\begin{document}
\maketitle
\tableofcontents
\section{Pique.}
\label{sec:orgf5d6a52}
Baratin.
\section{Et pique\ldots{}}
\label{sec:orge68ddf8}
Autre baratin.
\section{Et colégram!}
\label{sec:orgf4c826b}
Troisième baratin.
\end{document}
TstFrench.pdf
Description: Adobe PDF document
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
My original posting included the tex file generated by C-c C-e l l. Perusing it will show you that babel is not used anywhere in this export. On the (remote) chance that my problem might be caused by my use of emacs 25.2, I just installe emacs 26 from the emacs-snapshot packages for Debian testing, ang got exactlu the same prolem. The org-relevant part of my .emacs is as follows : (require 'org) (require 'org-ref) Then, later ;; Septembre 2018 : org-mode ;; touches globales : À revoir ? (global-set-key "\C-cl" 'org-store-link) (global-set-key "\C-ca" 'org-agenda) (global-set-key "\C-cc" 'org-capture) (global-set-key "\C-cb" 'org-switchb) ;; Chemin de la bibliothèque ditaa (setq org-ditaa-jar-path "/usr/share/ditaa/ditaa.jar") ;; Autoriser les évaluations Babel (setq org-confirm-babel-evaluate nil) ;; Langages connus (org-babel-do-load-languages 'org-babel-load-languages '((ditaa . t) (emacs-lisp . t) (R . t) (python . t) (sagemath . t) (julia . t) (gnuplot . t) (maxima . t) (stan . t) (mathematica . t) (sqlite . t) ;; (sh . t) )) Like it or not, believe it or not, this setup is sufficient to create the problem I reported. HTH, -- Emmanuel Charpentier Le mar. 27 nov. 2018 à 15:20, Eric S Fraga a écrit : > On Sunday, 25 Nov 2018 at 21:36, emanuel.charpent...@gmail.com wrote: > > I forgot to add that, when exporting to plain tex or ODT, #+language* > > *seems* to be honored : the table of contents is entitled "Table des > > matières". > > > > The problem is therefore probably in ox-latex.el (but way above my > > level of competance in em... > > But it works just fine for me. Have you actually had a look at the > LaTeX that is created? I wonder whether you might have a setting for > the LaTeX export that includes other settings than just the default or > which doesn't allow the language setting to be included? > > -- > Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1034-gafcb1d >
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Yet another data point: I followed your suggestion : * desinstalled MELPA's org * cloned https://code.orgmode.org/bzg/org-mode.git * make autoloads * make * emacs -q * M-: (add-to-list 'load-path "/org-mode/lisp") C-c C-e l o still gets me the same result (i. e. a table of contents entitled "Contents" rather than "Table des matières"). I got this result * using the (default) master branch * using the "next" branch : - git branch next origin/next - git checkout next - make autoloads - make In both branches, make says "org-version: 9.1.14 (release_9.1.14-1124- gfb5e3e)" at the end of compilation. I'm stymied... I have but one *visual* clue : whereas the fontlock gives me a gray color for #+title, #+author and #+date (light gray for the tags, dark blue for the title, medium grey for author and date), "#+language: fr" remains in red, even after C-c C-c. (Approximate colors : I'm semi- color-blind). HTH, -- Emmanuel Charpentier Le dimanche 25 novembre 2018 à 23:31 +0100, Nicolas Goaziou a écrit : > Emmanuel Charpentier writes: > > > Thanks for a prompt answer ! A couple questions : > > > > 1) What do you mean by "minimal configuration" ? A stripped > > .emacs/d/init.el ? > > Indeed. > > > 2) How can I get the "development version" ? I'm following MELPA > > already... > > You have to clone the repository and load Org from there, "master" > branch, aka "Org 9.2".
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
One more data point : I can reproduce the problem with no init file :
* same org file
* emacs started by "emacs -q"
* M-x (require 'org)
* C-x C-f TstLanguage.org
* C-c C-e l p
==> Same result.
HTH,
--
Emmanuel Charpentier
Le dimanche 25 novembre 2018 à 20:03 +0100, Nicolas Goaziou a écrit :
> Hello,
>
> Emmanuel Charpentier writes:
>
> > As of today, I note that the #+langiage export variable is no
> > longer
> > honored when exporting to LaTeX/PDF. See enclosed files :
> >
> > - #+language:fr should get me a table of contents entitled "Table
> > des
> > matières" ;
> >
> > - #+ the Latex file has "pdflang={Frenchb}}" in a \hypersetup
> > call,
> > but nothing even remotely babel-related (i. e. nothing related to
> > the
> > LaTeX package babel, which isn't loaded...)
> >
> > - the PDF file has a table of contents entitled "Contents".
>
> I cannot reproduce your problem. You may try again with a minimal
> configuration, or with development version, which is very stable at
> this
> point.
>
> Regards,
>
Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
Thanks for a prompt answer ! A couple questions :
1) What do you mean by "minimal configuration" ? A stripped
.emacs/d/init.el ?
2) How can I get the "development version" ? I'm following MELPA
already...
--
Emmanuel Charpentier
Le dimanche 25 novembre 2018 à 20:03 +0100, Nicolas Goaziou a écrit :
> Hello,
>
> Emmanuel Charpentier writes:
>
> > As of today, I note that the #+langiage export variable is no
> > longer
> > honored when exporting to LaTeX/PDF. See enclosed files :
> >
> > - #+language:fr should get me a table of contents entitled "Table
> > des
> > matières" ;
> >
> > - #+ the Latex file has "pdflang={Frenchb}}" in a \hypersetup
> > call,
> > but nothing even remotely babel-related (i. e. nothing related to
> > the
> > LaTeX package babel, which isn't loaded...)
> >
> > - the PDF file has a table of contents entitled "Contents".
>
> I cannot reproduce your problem. You may try again with a minimal
> configuration, or with development version, which is very stable at
> this
> point.
>
> Regards,
>
[O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.
As of today, I note that the #+langiage export variable is no longer
honored when exporting to LaTeX/PDF. See enclosed files :
- #+language:fr should get me a table of contents entitled "Table des
matières" ;
- #+ the Latex file has "pdflang={Frenchb}}" in a \hypersetup call,
but nothing even remotely babel-related (i. e. nothing related to the
LaTeX package babel, which isn't loaded...)
- the PDF file has a table of contents entitled "Contents".
HTH,
--
Emmanuel Charpentier
# Vérification d'un loup possible sur #+language...
#+title: Option "Language" ?
#+author: Emmanuel Charpentier
#+date: novembre 2018
#+language: fr
* Pique
Baratin...
* Et pique
Autre baratin
* Et colegram...
Troisième baratin...
# Il y a bien un loup : la table des matières est intitulée
# "Contents"...
TstLanguage.pdf
Description: Adobe PDF document
% Created 2018-11-25 dim. 16:45
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\author{Emmanuel Charpentier}
\date{novembre 2018}
\title{Option "Language" ?}
\hypersetup{
pdfauthor={Emmanuel Charpentier},
pdftitle={Option "Language" ?},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 25.2.2 (Org mode 9.1.14)},
pdflang={Frenchb}}
\begin{document}
\maketitle
\tableofcontents
\section{Pique}
\label{sec:orgc6b6d38}
Baratin\ldots{}
\section{Et pique}
\label{sec:orgf382b87}
Autre baratin
\section{Et colegram\ldots{}}
\label{sec:org30745ef}
Troisième baratin\ldots{}
\end{document}
