* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
@ 2023-08-16 8:10 6% ` Ihor Radchenko
2023-08-16 14:10 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-16 8:10 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think the best thing is to rethink the :literal attribute, as I
> commented at the end of my other email:
>
> - without :literal --> verse environment with a more "canonical" syntax.
>
> - with :literal --> verse environment seen in the "old (org) style",
> preserving the blank lines. In that context \vspace does work.
+1
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-16 8:10 6% ` Ihor Radchenko
@ 2023-08-16 14:10 7% ` Juan Manuel Macías
2023-08-17 10:35 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-16 14:10 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I think the best thing is to rethink the :literal attribute, as I
>> commented at the end of my other email:
>>
>> - without :literal --> verse environment with a more "canonical" syntax.
>>
>> - with :literal --> verse environment seen in the "old (org) style",
>> preserving the blank lines. In that context \vspace does work.
>
> +1
Here is the modified patch.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-add-the-literal-attribute-to-verse-.patch --]
[-- Type: text/x-patch, Size: 5856 bytes --]
From 8c77b42404ef5d96b2944e8e43bbc6c9412ad808 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Aug 2023 21:48:58 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
block.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `:literal' attribute is
used, all blank lines are preserved and exported as
`\vspace*{\baselineskip}', including the blank lines before or after
contents. The rx code has been suggested by Ihor Radchenko, to
improve readability.
* doc/org-manual.org (Verse blocks in LaTeX export): the new feature
is documented.
---
doc/org-manual.org | 18 ++++++++++++++----
lisp/ox-latex.el | 36 +++++++++++++++++++++++++++---------
2 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..e52792183 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14425,10 +14425,10 @@ The LaTeX export backend converts horizontal rules by the specified
#+cindex: verse blocks, in @LaTeX{} export
#+cindex: @samp{ATTR_LATEX}, keyword
-The LaTeX export backend accepts four attributes for verse blocks:
-=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
-require the external LaTeX package =verse.sty=, which is an extension
-of the standard LaTeX environment.
+The LaTeX export backend accepts five attributes for verse blocks:
+=:lines=, =:center=, =:versewidth=, =:latexcode= and =:literal=. The
+three first require the external LaTeX package =verse.sty=, which is
+an extension of the standard LaTeX environment.
- =:lines= :: To add marginal verse numbering. Its value is an
integer, the sequence in which the verses should be numbered.
@@ -14440,6 +14440,16 @@ of the standard LaTeX environment.
verse.
- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
included within a LaTeX =verse= environment.
+- =:literal= :: With value t, all blank lines are preserved and
+ exported as =\vspace*{\baselineskip}=, including the blank lines
+ before or after contents. Note that without the =:literal=
+ attribute, one or more blank lines between stanzas are exported as a
+ single blank line, and any blank lines before or after the content
+ are removed, which is more consistent with the syntax of the LaTeX
+ `verse' environment, and the one provided by the `verse' package.
+ If the =verse= package is loaded, the vertical spacing between all
+ stanzas can be controlled by the global length =\stanzaskip= (see
+ https://www.ctan.org/pkg/verse).
A complete example with Shakespeare's first sonnet:
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..d11e3befa 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,10 +4116,11 @@ contextual information."
(let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
(latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
(cent (org-export-read-attribute :attr_latex verse-block :center))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
(attr (concat
- (if cent "[\\versewidth]" "")
- (if lin (format "\n\\poemlines{%s}" lin) "")
- (if latcode (format "\n%s" latcode) "")))
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) "")))
(versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
(vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
(linreset (if lin "\n\\poemlines{0}" "")))
@@ -4128,20 +4129,37 @@ contextual information."
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
- ;; into a space of 1 em. Also change each blank line with
- ;; a vertical space of 1 em.
+ ;; into a normal space, calculated with `\fontdimen2\font'. One
+ ;; or more blank lines between lines are exported as a single
+ ;; blank line. If the `:lines' attribute is used, the last
+ ;; verse of each stanza ends with the string `\\!', according to
+ ;; the syntax of the `verse' package. The separation between
+ ;; stanzas can be controlled with the length `\stanzaskip', of
+ ;; the aforementioned package. If the `:literal' attribute is
+ ;; used, all blank lines are preserved and exported as
+ ;; `\vspace*{\baselineskip}', including the blank lines before
+ ;; or after CONTENTS.
(format "%s\\begin{verse}%s\n%s\\end{verse}%s"
vwidth
attr
(replace-regexp-in-string
- "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+ "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (if (not lit)
+ (rx-to-string
+ `(seq (group ,org-latex-line-break-safe "\n")
+ (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n"))))
+ (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ (if (not lit)
+ (if lin "\\\\!\n\n" "\n\n")
+ "\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ (if (not lit)
+ (concat (org-trim contents t) "\n")
+ contents)
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 7%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-16 14:10 7% ` Juan Manuel Macías
@ 2023-08-17 10:35 6% ` Ihor Radchenko
2023-08-17 20:17 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-17 10:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here is the modified patch.
Thanks!
> * (org-latex-verse-block): now the treatment of blank lines is
> consistent with the syntax of the LaTeX `verse' environment, and the
> one provided by the `verse' package. If the `:literal' attribute is
> used, all blank lines are preserved and exported as
Please use double space between sentences and start sentences with
capital letter.
> +- =:literal= :: With value t, all blank lines are preserved and
> + exported as =\vspace*{\baselineskip}=, including the blank lines
> + before or after contents. Note that without the =:literal=
> + attribute, one or more blank lines between stanzas are exported as a
> + single blank line, and any blank lines before or after the content
> + are removed, which is more consistent with the syntax of the LaTeX
> + `verse' environment, and the one provided by the `verse' package.
> + If the =verse= package is loaded, the vertical spacing between all
> + stanzas can be controlled by the global length =\stanzaskip= (see
> + https://www.ctan.org/pkg/verse).
s/`verse'/=verse=/
And you need to update `test-ox-latex/verse' test - it is currently failing.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-17 10:35 6% ` Ihor Radchenko
@ 2023-08-17 20:17 7% ` Juan Manuel Macías
2023-08-18 8:44 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-17 20:17 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]
Ihor Radchenko writes:
> Thanks!
>
>> * (org-latex-verse-block): now the treatment of blank lines is
>> consistent with the syntax of the LaTeX `verse' environment, and the
>> one provided by the `verse' package. If the `:literal' attribute is
>> used, all blank lines are preserved and exported as
>
> Please use double space between sentences and start sentences with
> capital letter.
>
>> +- =:literal= :: With value t, all blank lines are preserved and
>> + exported as =\vspace*{\baselineskip}=, including the blank lines
>> + before or after contents. Note that without the =:literal=
>> + attribute, one or more blank lines between stanzas are exported as a
>> + single blank line, and any blank lines before or after the content
>> + are removed, which is more consistent with the syntax of the LaTeX
>> + `verse' environment, and the one provided by the `verse' package.
>> + If the =verse= package is loaded, the vertical spacing between all
>> + stanzas can be controlled by the global length =\stanzaskip= (see
>> + https://www.ctan.org/pkg/verse).
>
> s/`verse'/=verse=/
>
> And you need to update `test-ox-latex/verse' test - it is currently failing.
Sorry for the typos... Here goes the corrected patch again, with the
updated test.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-the-literal-attribute-to-verse-.patch --]
[-- Type: text/x-patch, Size: 6513 bytes --]
From bd956aa947e080ef10aa851f339414dc1cda1baf Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Aug 2023 21:48:58 +0200
Subject: [PATCH] lisp/ox-latex.el: Add the `:literal' attribute to verse
block.
* (org-latex-verse-block): Now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `:literal' attribute is
used, all blank lines are preserved and exported as
`\vspace*{\baselineskip}', including the blank lines before or after
contents. The rx code has been suggested by Ihor Radchenko, to
improve readability.
* doc/org-manual.org (Verse blocks in LaTeX export): The new feature
is documented.
* testing/lisp/test-ox-latex.el (test-ox-latex/verse): Updated.
---
doc/org-manual.org | 18 ++++++++++++++----
lisp/ox-latex.el | 36 ++++++++++++++++++++++++++---------
testing/lisp/test-ox-latex.el | 8 ++++----
3 files changed, 45 insertions(+), 17 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..ce0521dee 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14425,10 +14425,10 @@ The LaTeX export backend converts horizontal rules by the specified
#+cindex: verse blocks, in @LaTeX{} export
#+cindex: @samp{ATTR_LATEX}, keyword
-The LaTeX export backend accepts four attributes for verse blocks:
-=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
-require the external LaTeX package =verse.sty=, which is an extension
-of the standard LaTeX environment.
+The LaTeX export backend accepts five attributes for verse blocks:
+=:lines=, =:center=, =:versewidth=, =:latexcode= and =:literal=. The
+three first require the external LaTeX package =verse.sty=, which is
+an extension of the standard LaTeX environment.
- =:lines= :: To add marginal verse numbering. Its value is an
integer, the sequence in which the verses should be numbered.
@@ -14440,6 +14440,16 @@ of the standard LaTeX environment.
verse.
- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
included within a LaTeX =verse= environment.
+- =:literal= :: With value t, all blank lines are preserved and
+ exported as =\vspace*{\baselineskip}=, including the blank lines
+ before or after contents. Note that without the =:literal=
+ attribute, one or more blank lines between stanzas are exported as a
+ single blank line, and any blank lines before or after the content
+ are removed, which is more consistent with the syntax of the LaTeX
+ `verse' environment, and the one provided by the =verse= package.
+ If the =verse= package is loaded, the vertical spacing between all
+ stanzas can be controlled by the global length =\stanzaskip= (see
+ https://www.ctan.org/pkg/verse).
A complete example with Shakespeare's first sonnet:
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..d11e3befa 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,10 +4116,11 @@ contextual information."
(let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
(latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
(cent (org-export-read-attribute :attr_latex verse-block :center))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
(attr (concat
- (if cent "[\\versewidth]" "")
- (if lin (format "\n\\poemlines{%s}" lin) "")
- (if latcode (format "\n%s" latcode) "")))
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) "")))
(versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
(vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
(linreset (if lin "\n\\poemlines{0}" "")))
@@ -4128,20 +4129,37 @@ contextual information."
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
- ;; into a space of 1 em. Also change each blank line with
- ;; a vertical space of 1 em.
+ ;; into a normal space, calculated with `\fontdimen2\font'. One
+ ;; or more blank lines between lines are exported as a single
+ ;; blank line. If the `:lines' attribute is used, the last
+ ;; verse of each stanza ends with the string `\\!', according to
+ ;; the syntax of the `verse' package. The separation between
+ ;; stanzas can be controlled with the length `\stanzaskip', of
+ ;; the aforementioned package. If the `:literal' attribute is
+ ;; used, all blank lines are preserved and exported as
+ ;; `\vspace*{\baselineskip}', including the blank lines before
+ ;; or after CONTENTS.
(format "%s\\begin{verse}%s\n%s\\end{verse}%s"
vwidth
attr
(replace-regexp-in-string
- "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+ "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (if (not lit)
+ (rx-to-string
+ `(seq (group ,org-latex-line-break-safe "\n")
+ (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n"))))
+ (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ (if (not lit)
+ (if lin "\\\\!\n\n" "\n\n")
+ "\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ (if (not lit)
+ (concat (org-trim contents t) "\n")
+ contents)
+ nil t)
nil t)
nil t)
linreset)
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index adb3a60ea..79ef8793b 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -61,11 +61,11 @@ lorem ipsum dolor
(search-forward
"\\begin{verse}
lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor
+
lorem ipsum dolor\\\\[0pt]
-\\vspace*{1em}
-lorem ipsum dolor\\\\[0pt]
-lorem ipsum dolor\\\\[0pt]
-\\vspace*{1em}
+lorem ipsum dolor
+
lorem ipsum dolor\\\\[0pt]
lorem ipsum dolor\\\\[0pt]
\\end{verse}"))))
--
2.41.0
^ permalink raw reply related [relevance 7%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-17 20:17 7% ` Juan Manuel Macías
@ 2023-08-18 8:44 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-08-18 8:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Subject: [PATCH] lisp/ox-latex.el: Add the `:literal' attribute to verse
> block.
Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2eb4fd890
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* [Tip] Popup-menu with several actions for a link
@ 2023-08-18 18:27 10% Juan Manuel Macías
2023-08-19 19:53 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-18 18:27 UTC (permalink / raw)
To: orgmode
Hi,
I’ve been experimenting for a while with the popup.el library
(<https://github.com/auto-complete/popup-el>), which offers an easy way
to create popup menus (even cascading menus), with auto-completion
functions. I’m sharing here a popup menu that I’ve defined to perform
various actions on an Org link, in case anyone finds it useful.
In this list I store the functions that I am writing to manipulate links
(open the link with eww, open the file with an external application,
attach it to an email, upload it to Imgur, copy it to another directory
or move it, visit the file directory, etc.). Something like this:
┌────
│ (setq my-org-link-actions-list
│ '(("Action 1" . function1)
│ ("Action 2" . function2)
│ ("etc..." . etc)))
└────
Then, I have defined this popup-menu that is displayed on a link:
┌────
│ (defun my-org-actions-link-popup ()
│ (interactive)
│ (funcall
│ (popup-menu*
│ (mapcar
│ (lambda (x)
│ (popup-make-item (car x) :value (cdr x)))
│ my-org-link-actions-list)
│ :isearch t)))
└────
And a little addendum. Being a Hyperbole user, it occurred to me a while
ago that a ’secondary action key’ could be very useful to me in certain
contexts. So I defined this:
┌────
│ (defvar my-hyp-alt-act nil)
│
│ (defun my-hyp-action-key-alt ()
│ (interactive)
│ (let ((my-hyp-alt-act t))
│ (action-key)))
└────
If `C-c i' is for the ’primary’ action key, `C-c I' is for the
’secondary’ action:
┌────
│ (global-set-key (kbd "C-c I") #'mi-hyp-action-key-alt)
└────
And then I’ve modified hyperbole `org-link' a bit:
┌────
│ (defact org-link (&optional link)
│ "Follows an optional Org mode LINK to its target.
│ If LINK is nil, follows any link at point. Otherwise, triggers an error."
│ (if (not my-hyp-alt-act)
│ (if (stringp link)
│ (org-link-open-from-string link)
│ (org-open-at-point))
│ (hact #'my-org-actions-link-popup)))
└────
In this way, if I have the point over the link and press `C-c i', the
link opens. If I press `C-c I' the popup-menu is displayed.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [Tip] Popup-menu with several actions for a link
2023-08-18 18:27 10% [Tip] Popup-menu with several actions for a link Juan Manuel Macías
@ 2023-08-19 19:53 6% ` Ihor Radchenko
2023-08-19 20:29 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-19 19:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I’ve been experimenting for a while with the popup.el library
> (<https://github.com/auto-complete/popup-el>), which offers an easy way
> to create popup menus (even cascading menus), with auto-completion
> functions. I’m sharing here a popup menu that I’ve defined to perform
> various actions on an Org link, in case anyone finds it useful.
Since Emacs 28, Emacs has built-in context menu. (terminal is also
supported) Moreover, major modes are encouraged to add support for
context menus.
> In this list I store the functions that I am writing to manipulate links
> (open the link with eww, open the file with an external application,
> attach it to an email, upload it to Imgur, copy it to another directory
> or move it, visit the file directory, etc.). Something like this:
May you explain more about how you attach to an email/upload?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [Tip] Popup-menu with several actions for a link
2023-08-19 19:53 6% ` Ihor Radchenko
@ 2023-08-19 20:29 11% ` Juan Manuel Macías
2023-08-20 7:23 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-19 20:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> I’ve been experimenting for a while with the popup.el library
>> (<https://github.com/auto-complete/popup-el>), which offers an easy way
>> to create popup menus (even cascading menus), with auto-completion
>> functions. I’m sharing here a popup menu that I’ve defined to perform
>> various actions on an Org link, in case anyone finds it useful.
>
> Since Emacs 28, Emacs has built-in context menu. (terminal is also
> supported) Moreover, major modes are encouraged to add support for
> context menus.
Thanks for the information. Do you mean context-menu-mode? I'll keep an
eye on it. When you say terminal support, do you mean terminal emulators
or TTY? Because I often use Emacs on the linux framebuffer with fbterm,
and popup.el works fine on the tty. Also, I don't usually use the mouse
much (actually I only use it in Gimp and the like) and the combination
of popup.el with hyperbole is more comfortable and keyboard-centric for
me.
>> In this list I store the functions that I am writing to manipulate links
>> (open the link with eww, open the file with an external application,
>> attach it to an email, upload it to Imgur, copy it to another directory
>> or move it, visit the file directory, etc.). Something like this:
>
> May you explain more about how you attach to an email/upload?
Sure! But they are very simple functions, which I don't use much.
Although they work fine for what I want:
The first requires the imgur.el package; the second one needs gnus-dired-mode:
(defun my-org-link-to-ingur ()
(interactive)
(let* ((path (org-element-property :path (org-element-context))))
(imgur-upload-image (expand-file-name path) nil t)))
(defun my-org-link-to-mail-attachment ()
(interactive)
(let* ((path (org-element-property :path (org-element-context))))
(gnus-dired-attach (list (expand-file-name path)))))
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [Tip] Popup-menu with several actions for a link
2023-08-19 20:29 11% ` Juan Manuel Macías
@ 2023-08-20 7:23 6% ` Ihor Radchenko
2023-08-20 10:13 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-20 7:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Since Emacs 28, Emacs has built-in context menu. (terminal is also
>> supported) Moreover, major modes are encouraged to add support for
>> context menus.
>
> Thanks for the information. Do you mean context-menu-mode?
Yes.
> ... I'll keep an
> eye on it. When you say terminal support, do you mean terminal emulators
> or TTY?
Both.
> ... Also, I don't usually use the mouse
> much (actually I only use it in Gimp and the like) and the combination
> of popup.el with hyperbole is more comfortable and keyboard-centric for
> me.
By default, context menu is bound to S-<F10>. Who cares about mouse XD
>> May you explain more about how you attach to an email/upload?
>
> Sure! But they are very simple functions, which I don't use much.
> Although they work fine for what I want:
>
> The first requires the imgur.el package; the second one needs gnus-dired-mode:
I see. I thought that you are using built-in functionality.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [Tip] Popup-menu with several actions for a link
2023-08-20 7:23 6% ` Ihor Radchenko
@ 2023-08-20 10:13 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-20 10:13 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> ... Also, I don't usually use the mouse
>> much (actually I only use it in Gimp and the like) and the combination
>> of popup.el with hyperbole is more comfortable and keyboard-centric for
>> me.
>
> By default, context menu is bound to S-<F10>. Who cares about mouse XD
Oh I see. Very interesting. But I have seen that, at least by default,
there is no autocomplete feature. What I like about popup.el is, in
addition to autocompletion, the ability to easily create menus for
anything. Some time ago I defined a popup-menu[1] that shows me all the
header levels from where I am to the first one, defaulting to the
current level. It helps me situate myself in deep levels (other options
like imenu or org-sidebar give me too much information and I get lost).
I'm going to investigate if something similar can be done with
context-menu-mode...
Thank you for all the info!
[1] https://i.imgur.com/KoAZtIz.png
┌────
│ (defun my-org-where-i-am-popup ()
│ (interactive)
│ (setq org-heading-titles-list nil)
│ (org-with-wide-buffer
│ (save-excursion
│ (save-restriction
│ (org-back-to-heading t)
│ (if (eq (org-element-property :level (org-element-at-point)) 1)
│ (message "First level")
│ (push (cons (org-link-display-format
│ (nth 4 (org-heading-components)))
│ (point))
│ org-heading-titles-list)
│ (while
│ (ignore-errors (outline-up-heading 1 t))
│ (push (cons (org-link-display-format
│ (nth 4 (org-heading-components)))
│ (point))
│ org-heading-titles-list))))))
│ (org-with-wide-buffer
│ (save-excursion
│ (save-restriction
│ (goto-char
│ (popup-menu* (mapcar
│ (lambda (x)
│ (popup-make-item (car x) :value (cdr x)))
│ org-heading-titles-list)
│ :isearch t
│ :initial-index (length org-heading-titles-list)))
│ (org-tree-to-indirect-buffer)))))
└────
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Re-design of inlinetasks
@ 2023-08-25 17:58 9% ` Juan Manuel Macías
2023-08-26 10:58 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-25 17:58 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> 1. Inlinetasks should be exported as "boxes" - something similar to
> margin or inline notes
> - Can be used as a memo TODO in draft publication printout
> - As Samuel suggested, inlinetasks could be a basis of review
> comments - like what GDocs/Office provides in margin "chat"
I think inlinetasks may also have a use for those sections that are not
"nested". In typography they are usually called "anonymous sections" and
they are separated by some symbol (asterisks, dinkus[1], etc.). They
behave like a true section, except that they are not headed by titles or
level numbers. I think Org's support for these types of sections would
be useful and novel, since there is (as far as I know) nothing similar
in other lightweight markup languages. Anonymous sections can be useful
not only in print or PDF texts but also on web pages.
https://en.wikipedia.org/wiki/Dinkus
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-25 17:58 9% ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
@ 2023-08-26 10:58 6% ` Ihor Radchenko
2023-08-26 11:42 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-26 10:58 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think inlinetasks may also have a use for those sections that are not
> "nested". In typography they are usually called "anonymous sections" and
> they are separated by some symbol (asterisks, dinkus[1], etc.).
This is a very interesting idea. Thanks for sharing!
> ... They
> behave like a true section, except that they are not headed by titles or
> level numbers.
May they contain sub-sections?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 10:58 6% ` Ihor Radchenko
@ 2023-08-26 11:42 10% ` Juan Manuel Macías
2023-08-26 12:33 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-26 11:42 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
>> ... They
>> behave like a true section, except that they are not headed by titles or
>> level numbers.
>
> May they contain sub-sections?
I think that would not be expected, since an anonymous section is just a
break in the text that has neither a title nor a section number. There
are many possible scenarios. Let's imagine, for example, that an author
is working on a section of an article. And at the end of various
subsections he/she wants to make some text breaks that, for whatever
reason, don't deserve either a title or a subsubsection number.
Anonymous breaks using asterisks or other symbols is usually the applied
remedy. The advantage of enclosing the content of the anonymous section
in an inlinetask is that we have a 'true' section with content (over
which you have control). That would not happen if the author explicitly
added a break symbol and continue writing.
Anonymous breaks are also widely used in essay or narrative texts. An
essay text, published as a blog entry or as an article, can be perfectly
structured into anonymous sections:
contents 1
***
contents 2
***
etc
See:
https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 11:42 10% ` Juan Manuel Macías
@ 2023-08-26 12:33 5% ` Ihor Radchenko
2023-08-26 14:21 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-26 12:33 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>
>> May they contain sub-sections?
>
> I think that would not be expected, since an anonymous section is just a
> break in the text that has neither a title nor a section number.
> ... Anonymous breaks using asterisks or other symbols is usually the applied
> remedy. The advantage of enclosing the content of the anonymous section
> in an inlinetask is that we have a 'true' section with content (over
> which you have control). That would not happen if the author explicitly
> added a break symbol and continue writing.
Do you mean section in LaTeX sense or in Org sense?
> Anonymous breaks are also widely used in essay or narrative texts. An
> essay text, published as a blog entry or as an article, can be perfectly
> structured into anonymous sections:
> ...
> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>
> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
This one I know. But it can work fine with normal headings, because such
texts are nothing but a sequence of "scenes" - nothing "inline" when we
have one scene, interrupted by other, then coming back to the first one.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 12:33 5% ` Ihor Radchenko
@ 2023-08-26 14:21 9% ` Juan Manuel Macías
2023-08-26 16:33 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-26 14:21 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I think that would not be expected, since an anonymous section is just a
>> break in the text that has neither a title nor a section number.
>> ... Anonymous breaks using asterisks or other symbols is usually the applied
>> remedy. The advantage of enclosing the content of the anonymous section
>> in an inlinetask is that we have a 'true' section with content (over
>> which you have control). That would not happen if the author explicitly
>> added a break symbol and continue writing.
>
> Do you mean section in LaTeX sense or in Org sense?
In Org sense, I think. If an author adds an 'anonymous' break (through
some customary symbol) and continues writing, the content that follows
belongs (for Org) to the current section. By using an inlenitask, you
can have control over the inlinetask content, for any purpose, for
example with some export filter, etc.
On the other hand, for my own writing I usually use this:
#+begin_src emacs-lisp
(defun my-org-latex-format-inlinetask-default-function
(todo _todo-type priority title tags contents _info)
(if (string-match-p "anonsec" title)
(concat
"\n\\begin{anonsection}\n"
(org-string-nw-p contents)
"\n\\end{anonsection}\n")
(org-string-nw-p contents)))
(defun mi-org-odt-format-inlinetask-default-function
(todo todo-type priority name tags contents)
(if (string-match-p "anonsec" name)
(concat
contents
"<text:p text:style-name=\"OrgCenter\">* * *</text:p>")))
#+end_src
And for LaTeX I have defined this:
#+begin_src latex
\newcommand\dinkus{\mbox{\textasteriskcentered\space\textasteriskcentered\space\textasteriskcentered}}
\newcommand\anonsectionmark{\dinkus}
%% require the needspace package
\newcommand\anonsectionbreak{%
\nopagebreak[4]
\bigskip%
{\centering
\anonsectionmark\par}
\Needspace*{2\bigskipamount}
\bigskip}
\newenvironment{anonsection}{%
\anonsectionbreak%
}
{%
\par}
#+end_src
>> Anonymous breaks are also widely used in essay or narrative texts. An
>> essay text, published as a blog entry or as an article, can be perfectly
>> structured into anonymous sections:
>> ...
>> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>>
>> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
>
> This one I know. But it can work fine with normal headings, because such
> texts are nothing but a sequence of "scenes" - nothing "inline" when we
> have one scene, interrupted by other, then coming back to the first one.
Actually, I think any anonymous text break or sectioning can be
accomplished using Org headings and some trickery to ignore the heading on
export, but I think inlinetasks lends itself quite well to this
constructions and others I've seen discussed in this thread. In general,
for any 'piece' (section = something that is sectioned) of text that
needs to be separated in some way from the main text, without a
hierarchy of levels, inlinetasks are a great, versatile and simple tool
(IMHO).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 14:21 9% ` Juan Manuel Macías
@ 2023-08-26 16:33 6% ` Ihor Radchenko
2023-08-26 17:31 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-26 16:33 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Do you mean section in LaTeX sense or in Org sense?
>
> In Org sense, I think. If an author adds an 'anonymous' break (through
> some customary symbol) and continues writing, the content that follows
> belongs (for Org) to the current section. By using an inlenitask, you
> can have control over the inlinetask content, for any purpose, for
> example with some export filter, etc.
>
> On the other hand, for my own writing I usually use this:
>
> #+begin_src emacs-lisp
> (defun my-org-latex-format-inlinetask-default-function
> (todo _todo-type priority title tags contents _info)
> (if (string-match-p "anonsec" title)
> (concat
> "\n\\begin{anonsection}\n"
> (org-string-nw-p contents)
> "\n\\end{anonsection}\n")
> (org-string-nw-p contents)))
Why not simply
#+begin_anonsection
...
#+end_anonsection
?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 16:33 6% ` Ihor Radchenko
@ 2023-08-26 17:31 11% ` Juan Manuel Macías
2023-08-26 17:43 5% ` Ihor Radchenko
2023-08-26 18:01 6% ` Russell Adams
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-26 17:31 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> Why not simply
>
> #+begin_anonsection
> ...
> #+end_anonsection
>
> ?
Because with an inlinetask I can have something like this:
*************** TODO anonsec :tag:
Content that has neither a title nor a section number.
*************** END
and a construction that for the purposes of parceling out the text
behaves like a section. The problem is the LaTeX side. Since there is no
support for anonymous sections in LaTeX (I seem to remember that some
special class like Koma had some command to introduce anonymous breaks,
but I only use the standard classes), I had to define an environment. It
is not inconvenient, since after all what appears in LaTeX is the
typographical result. For the Org side I can use TODO keywords, tags,
deadlines, etc.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:31 11% ` Juan Manuel Macías
@ 2023-08-26 17:43 5% ` Ihor Radchenko
2023-08-26 19:19 10% ` Juan Manuel Macías
2023-08-26 18:01 6% ` Russell Adams
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-26 17:43 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Why not simply
>>
>> #+begin_anonsection
>> ...
>> #+end_anonsection
>>
>> ?
> ... The problem is the LaTeX side. Since there is no
> support for anonymous sections in LaTeX (I seem to remember that some
> special class like Koma had some command to introduce anonymous breaks,
> but I only use the standard classes), I had to define an environment. It
> is not inconvenient, since after all what appears in LaTeX is the
> typographical result. For the Org side I can use TODO keywords, tags,
> deadlines, etc.
In other words, it is not the section itself, but other
headline/inlinetask features, like todo keywords, tags, planning. Right?
Custom blocks can be exported to anything (not necessarily
\begin{foo}...), similar to how you did custom export for inlinetasks.
There was also an idea to make custom block export more customizeable,
similar to link. Like what
https://github.com/alhassy/org-special-block-extras does.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:31 11% ` Juan Manuel Macías
2023-08-26 17:43 5% ` Ihor Radchenko
@ 2023-08-26 18:01 6% ` Russell Adams
1 sibling, 0 replies; 200+ results
From: Russell Adams @ 2023-08-26 18:01 UTC (permalink / raw)
To: emacs-orgmode
On Sat, Aug 26, 2023 at 05:31:46PM +0000, Juan Manuel Macías wrote:
> Ihor Radchenko writes:
>
> *************** TODO anonsec :tag:
> Content that has neither a title nor a section number.
> *************** END
>
> and a construction that for the purposes of parceling out the text
> behaves like a section. The problem is the LaTeX side. Since there is no
> support for anonymous sections in LaTeX (I seem to remember that some
> special class like Koma had some command to introduce anonymous breaks,
> but I only use the standard classes), I had to define an environment. It
> is not inconvenient, since after all what appears in LaTeX is the
> typographical result. For the Org side I can use TODO keywords, tags,
> deadlines, etc.
Why not just put the TODO heading in a code block with type org?
Then you get all the toys, ignored by the main file.
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
https://www.adamsinfoserv.com/
^ permalink raw reply [relevance 6%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:43 5% ` Ihor Radchenko
@ 2023-08-26 19:19 10% ` Juan Manuel Macías
2023-08-27 9:21 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-26 19:19 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> In other words, it is not the section itself, but other
> headline/inlinetask features, like todo keywords, tags, planning. Right?
No, it is the section itself (or the concept of "section", with its toys
in Org, of course) that is important to me in this case. I am not
emphasizing so much how or in which way an element can be exported, but
what (semantic) role that element plays in the logical structure of an
Org document. To get a little philosophical, the Org document (where I
work and write) would be the idea, and the export to any format a
possible concrete realization. I mean, I find it comfortable and
productive to view an Org document as agnostic of any format. This use
of inlinetasks that I'm discussing here occurred to me a long time ago
because if I stop to think about an untitled, detached section of the
level hierarchy, this Org element is a perfect candidate. It is true
that you can use a special block, or another element (org is very
versatile, and supports role swapping between elements), but if I have
to think of a logical candidate, inlinetasks are the closest to that
concept. If inlinetasks didn't exist, I'd probably use special blocks
for that purpose. When I'm writing inside Org I'm not thinking about the
export (at least not simultaneously), that is, about the format; I think
more of the structure of the document, as something abstract.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 19:19 10% ` Juan Manuel Macías
@ 2023-08-27 9:21 5% ` Ihor Radchenko
2023-08-27 17:25 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-27 9:21 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> In other words, it is not the section itself, but other
>> headline/inlinetask features, like todo keywords, tags, planning. Right?
>
> No, it is the section itself (or the concept of "section", with its toys
> in Org, of course) that is important to me in this case...
So, this is a vote in favour of having a separate syntax element.
Although, the name "inlinetask" is actually awkward in such use case.
Something like inlinesection would fit better. Or inlineheading.
And what about drawers? Don't they fit the idea of "detached" element?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-27 9:21 5% ` Ihor Radchenko
@ 2023-08-27 17:25 10% ` Juan Manuel Macías
2023-08-31 9:15 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-27 17:25 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> Although, the name "inlinetask" is actually awkward in such use case.
> Something like inlinesection would fit better. Or inlineheading.
Completely agree. I like inlinesection and inlineheading equally.
> And what about drawers? Don't they fit the idea of "detached" element?
But drawers would not serve as a "detached section"... Although they are
certainly very versatile. I usually use drawers to export as small
"containers". And when I don't export them, they are very useful for
temporarily saving all kinds of "things". In Spanish we have the term
"cajón de sastre" (lit.: "a tailor drawer") to refer to something where
you can store everything :-)
As for the inlinetask (or whatever they may be called in the future),
the fact that they are a kind of hybrid between a section (unrelated to
the level hierarchy) and a drawer seems very interesting to me. Apart
from the scenario of the anonymous sections that I mentioned before, I
can think of a few more. For example, something like this:
*************** WORKING Complete this :noexport:
DEADLINE: <2023-08-27 dom>
Content
*************** END
And the combination of org-store-link with org-transclusion can also be
interesting.
Or, for example this other example, which is not possible now, but with
some modification in org-mime-org-subtree-htmlize I think it is:
*************** TODO Email this
DEADLINE: <2023-08-27 dom>
:PROPERTIES:
:mail_to: mail address
:mail_subject: mail subject
:END:
Content
*************** END
Well, it's some scattered ideas. In general I think that "inlinesection/-heading"
is an element that could be very productive in certain cases, since it
allows to "locally" suspend the (necessary) rigidity of the tree hierarchy.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Fallback fonts in LaTeX export for non latin scripts
@ 2023-08-30 8:25 10% Juan Manuel Macías
2023-08-31 8:17 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-30 8:25 UTC (permalink / raw)
To: orgmode
The Unicode TeX engines, LuaTeX and XeTeX, have certain features to
apply fonts to scripts (Greek, Cyrillic, Arabic, etc.), without the need
to switch fonts explicitly. But LaTeX does not include any functionality
for loading 'fallback fonts' out of the box. Seeing things from TeX and
LaTeX this is understandable: since LaTeX is a typographic tool, the
user has the responsibility of choosing the fonts and knowing which
fonts to use. But from the Org side things may look different, as the
average user (who may not be interested in typographical or font
complexities) is looking for immediate readability of their texts when
exporting to any format. We know that, when exporting to LaTeX, this
does not always happen, if texts include non-Latin scripts.
These days I'm working on some experimental code to try to provide Org
with some sort of fallbacks fonts on LaTeX export. The functionality
would (for now) be linked to LuaTeX + babel package, since XeTeX,
although it has the ucharclasses package, is more limited.
The idea is to start from a defcustom that is an alist where each element
has the structure (script font). There would also be a default script +
font, for example ("latin" "Linux Libertine"). At the moment it would
only work for the default roman font, but it can be extended to default
sans serif, mono, etc.
The functionality would not be activated by default. When activated, it
also enables LuaTeX as the default LaTeX engine, and on each export a
list of non-latin scripts in the buffer is extracted. Perhaps with
some code like this, which checks for any non-latin characters:
(let ((scripts))
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "\\([^\u0000-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
(let ((script (aref char-script-table
(string-to-char (match-string 1)))))
(add-to-list 'scripts script)
(setq script-list scripts))))
script-list)
?
Once the list has been extracted, an ad hoc preamble would be formatted
assigning each script the chosen font.
WDYT? Do you think this would be a viable path? I think that in a few
days I can offer something usable for discussion.
Best regards,
Juan Manuel
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-08-30 8:25 10% Fallback fonts in LaTeX export for non latin scripts Juan Manuel Macías
@ 2023-08-31 8:17 5% ` Ihor Radchenko
2023-08-31 11:42 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-31 8:17 UTC (permalink / raw)
To: Juan Manuel Macías, Timothy; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> These days I'm working on some experimental code to try to provide Org
> with some sort of fallbacks fonts on LaTeX export. The functionality
> would (for now) be linked to LuaTeX + babel package, since XeTeX,
> although it has the ucharclasses package, is more limited.
Thanks! That would be a welcome addition.
> The idea is to start from a defcustom that is an alist where each element
> has the structure (script font). There would also be a default script +
> font, for example ("latin" "Linux Libertine"). At the moment it would
> only work for the default roman font, but it can be extended to default
> sans serif, mono, etc.
Are the fonts you have in mind shipped with LuaTeX distribution?
> The functionality would not be activated by default. When activated, it
> also enables LuaTeX as the default LaTeX engine, and on each export a
> list of non-latin scripts in the buffer is extracted. Perhaps with
> some code like this, which checks for any non-latin characters:
>
> (let ((scripts))
> (save-excursion
> (goto-char (point-min))
> (while
> (re-search-forward "\\([^\u0000-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
> (let ((script (aref char-script-table
> (string-to-char (match-string 1)))))
> (add-to-list 'scripts script)
> (setq script-list scripts))))
> script-list)
>
> ?
>
> Once the list has been extracted, an ad hoc preamble would be formatted
> assigning each script the chosen font.
>
> WDYT? Do you think this would be a viable path? I think that in a few
> days I can offer something usable for discussion.
Adding Timothy to CC. His WIP conditional preamble branch looks suitable
to add the proposed functionality.
What will happen if LuaTeX is not installed on the system?
Also, just to double check, is LuaTeX fully compatible to LaTeX? That
is, if we have an existing org file using LaTeX-specific commands and
packages, will it work with LuaTeX?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-27 17:25 10% ` Juan Manuel Macías
@ 2023-08-31 9:15 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-08-31 9:15 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> And what about drawers? Don't they fit the idea of "detached" element?
>
> But drawers would not serve as a "detached section"... Although they are
> certainly very versatile. I usually use drawers to export as small
> "containers". And when I don't export them, they are very useful for
> temporarily saving all kinds of "things". In Spanish we have the term
> "cajón de sastre" (lit.: "a tailor drawer") to refer to something where
> you can store everything :-)
I am not sure here. It looks like having a new special block type
#+begin_inlinesection
...
#+end_inlinesection
would be sufficient. Given that we cannot nest inlinesections anyway.
Or special drawer
:inlinesection:
...
:end:
Although, drawers will be less powerful because, unlike special blocks,
you cannot have a different drawer type inside. For special blocks, a
different special block is perfectly fine.
I do not see any clear benefit of having a dedicated, separate markup
for inlinesection, apart from philosophical.
> As for the inlinetask (or whatever they may be called in the future),
> the fact that they are a kind of hybrid between a section (unrelated to
> the level hierarchy) and a drawer seems very interesting to me. Apart
> from the scenario of the anonymous sections that I mentioned before, I
> can think of a few more. For example, something like this:
>
> *************** WORKING Complete this :noexport:
> DEADLINE: <2023-08-27 dom>
> Content
> *************** END
>
> And the combination of org-store-link with org-transclusion can also be
> interesting.
>
> Or, for example this other example, which is not possible now, but with
> some modification in org-mime-org-subtree-htmlize I think it is:
>
> *************** TODO Email this
> DEADLINE: <2023-08-27 dom>
> :PROPERTIES:
> :mail_to: mail address
> :mail_subject: mail subject
> :END:
> Content
> *************** END
We can get the same functionality if we allow arbitrary properties and
tags assigned to non-headline elements.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-08-31 8:17 5% ` Ihor Radchenko
@ 2023-08-31 11:42 7% ` Juan Manuel Macías
2023-09-01 9:18 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-31 11:42 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Timothy, orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> The idea is to start from a defcustom that is an alist where each element
>> has the structure (script font). There would also be a default script +
>> font, for example ("latin" "Linux Libertine"). At the moment it would
>> only work for the default roman font, but it can be extended to default
>> sans serif, mono, etc.
>
> Are the fonts you have in mind shipped with LuaTeX distribution?
Yes, in fact the complete installation of TeX live includes a wide
catalog of free opentype fonts with good coverage for non-Latin scripts.
Added to that, more free (as in freedom) easily accessible fonts can be
recommended. Even many GNU/Linux distros already include them. In any
case, the fonts issue is the most delicate part. What default fonts to
add to the list? Here the user's taste or preferences would influence.
It must also be taken into account that if one has typographical
scruples, not all fonts match each other. For design purposes, I mean.
The Computer Modern, which is a modern style font (similar to the Didot
or Bodoni), does not usually pair well with (for example) a Garamond,
which is in the Renaissance style. That's why I think the best solution
would be to offer a basic defcustom, based on the purely utilitarian,
and let the user modify or extend it according to their taste,
preferences or convenience.
Another thing to keep in mind is the following. Offering basic
readability based on the unicode scripts means that we rely on scripts
and not languages. For example, the Cyrillic script covers several
languages, as you well know: Russian, Bulgarian, etc. The Latin script
is used for languages as diverse as English or Vietnamese. The choice of
font based on the script is a low-level LuaTeX functionality, that is,
it does not add features specific to each language, such as hyphenation
patterns. This means that long texts in (for example) Cyrillic or Greek
are not justified well because LaTeX does not know how hyphenate them:
https://i.imgur.com/PSja3x2.png
However, this may be sufficient for documents containing words or small
texts in non latin scripts, rather than long texts.
There is another possibility that I am working on in parallel: relying
on languages instead of scripts. This would add both readability and
support for each particular language. There could be two options for the
user: a basic one (the low level one, based on scripts: ensures
readability but the document may not look pretty) and an advanced one,
based on language support. Something like this occurred to me:
#+LaTeX_Header: % !enable-fonts-for ancientgreek russian:Old Standard
arabic
This means: enable default fonts for ancient Greek and Arabic
(associated with Greek and Arabic scripts). For Russian, enable the Old
Standard font (included in TeX live). And in the case of Arabic, enable
'bidi' (bidirectional text). If the user added that line it would be
enough to do the magic. I hope :-)
>> The functionality would not be activated by default. When activated, it
>> also enables LuaTeX as the default LaTeX engine, and on each export a
>> list of non-latin scripts in the buffer is extracted. Perhaps with
>> some code like this, which checks for any non-latin characters:
>>
>> (let ((scripts))
>> (save-excursion
>> (goto-char (point-min))
>> (while
>> (re-search-forward "\\([^\u0000-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
>> (let ((script (aref char-script-table
>> (string-to-char (match-string 1)))))
>> (add-to-list 'scripts script)
>> (setq script-list scripts))))
>> script-list)
>>
>> ?
>>
>> Once the list has been extracted, an ad hoc preamble would be formatted
>> assigning each script the chosen font.
>>
>> WDYT? Do you think this would be a viable path? I think that in a few
>> days I can offer something usable for discussion.
>
> Adding Timothy to CC. His WIP conditional preamble branch looks suitable
> to add the proposed functionality.
Great!
> What will happen if LuaTeX is not installed on the system?
Yes, there should be some kind of warning. Also it's not just LuaTeX,
but certain packages for fonts and multilingual support. The problem is
that the different versions of TeX live cooked in the distros
usually name these packages differently. This is another added problem...
Arch or Gentoo offer a more vanilla TeX live.
> Also, just to double check, is LuaTeX fully compatible to LaTeX? That
> is, if we have an existing org file using LaTeX-specific commands and
> packages, will it work with LuaTeX?
Yes, it is fully compatible, except that LuaLaTeX does not need to load
the fontenc or inputenc packages. LuaTeX is intended to be the natural
replacement for pdfTeX. The latest edition of The LaTeX Companion is
already very focused on LuaTeX. And 90% of the new LaTeX packages that
are uploaded to CTAN only work in LuaLaTeX. One of the essential
advantages of LuaTeX is that TeX now (finally!) has a simple scripting
language. With a little Lua you can achieve very low level things in TeX
that were horribly complicated in 'pure TeX'.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 7%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-08-31 11:42 7% ` Juan Manuel Macías
@ 2023-09-01 9:18 5% ` Ihor Radchenko
2023-09-02 21:39 4% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-01 9:18 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Timothy, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ...In any
> case, the fonts issue is the most delicate part. What default fonts to
> add to the list? Here the user's taste or preferences would influence.
Commonly available libre fonts look like a good candidate.
> It must also be taken into account that if one has typographical
> scruples, not all fonts match each other. For design purposes, I mean.
> The Computer Modern, which is a modern style font (similar to the Didot
> or Bodoni), does not usually pair well with (for example) a Garamond,
> which is in the Renaissance style. That's why I think the best solution
> would be to offer a basic defcustom, based on the purely utilitarian,
> and let the user modify or extend it according to their taste,
> preferences or convenience.
+1.
> Another thing to keep in mind is the following. Offering basic
> readability based on the unicode scripts means that we rely on scripts
> and not languages. For example, the Cyrillic script covers several
> languages, as you well know: Russian, Bulgarian, etc. The Latin script
> is used for languages as diverse as English or Vietnamese. The choice of
> font based on the script is a low-level LuaTeX functionality, that is,
> it does not add features specific to each language, such as hyphenation
> patterns. This means that long texts in (for example) Cyrillic or Greek
> are not justified well because LaTeX does not know how hyphenate them:
> ...
> There is another possibility that I am working on in parallel: relying
> on languages instead of scripts. This would add both readability and
> support for each particular language. There could be two options for the
> user: a basic one (the low level one, based on scripts: ensures
> readability but the document may not look pretty) and an advanced one,
> based on language support. Something like this occurred to me:
>
> #+LaTeX_Header: % !enable-fonts-for ancientgreek russian:Old Standard
> arabic
We already have #+language keyword and
`org-latex-guess-babel-language'/`org-latex-guess-polyglossia-language'.
May as well have default fonts for a given language.
As for multiple languages, do we actually support this?
>> What will happen if LuaTeX is not installed on the system?
>
> Yes, there should be some kind of warning. Also it's not just LuaTeX,
> but certain packages for fonts and multilingual support. The problem is
> that the different versions of TeX live cooked in the distros
> usually name these packages differently. This is another added problem...
> Arch or Gentoo offer a more vanilla TeX live.
We might use `org-latex-known-warnings'.
>> Also, just to double check, is LuaTeX fully compatible to LaTeX? That
>> is, if we have an existing org file using LaTeX-specific commands and
>> packages, will it work with LuaTeX?
>
> Yes, it is fully compatible, except that LuaLaTeX does not need to load
> the fontenc or inputenc packages. LuaTeX is intended to be the natural
> replacement for pdfTeX. The latest edition of The LaTeX Companion is
> already very focused on LuaTeX. And 90% of the new LaTeX packages that
> are uploaded to CTAN only work in LuaLaTeX. One of the essential
> advantages of LuaTeX is that TeX now (finally!) has a simple scripting
> language. With a little Lua you can achieve very low level things in TeX
> that were horribly complicated in 'pure TeX'.
Then, we might even consider LuaTeX as the new default for
`org-latex-compiler'.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-01 9:18 5% ` Ihor Radchenko
@ 2023-09-02 21:39 4% ` Juan Manuel Macías
2023-09-03 7:22 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-02 21:39 UTC (permalink / raw)
To: orgmode; +Cc: Ihor Radchenko, Timothy
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
Finally I can upload some usable code here, in this case to be able to
load and manage fonts for languages with non-Latin scripts, through
babel and fontspec (in LuaLaTeX). It is an attempt to simplify from Org
the multiform syntax of babel + fontspec. Of course, it is more limited,
but for regular use I think it may be enough.
Since this code is mostly a proof of concept and the names of many
things (and the things themselves) are still tentative, I thought it
would be more useful to attach it in an *.el file, rather than a regular
patch. Loading that file everything should work fine. I also attach an
org document with some examples of use. In any case, there are more
explanations inside the .el file.
One of the big problems I have encountered when trying to create a
"(LaTeX) Babel interface in Org" is the *horrible* multiplicity that
Babel has for language names. That is the reason for the :babel-alt
property in 'org-latex-language-alist', which collects the names that
babel supports for \babelprovide, which are not always the same as the
'classic' babel syntax.
Finally, I find this way more useful (that is, loading fonts with
language support), instead of a fallback font system based only on the
Unicode scripts. It is less 'automatic', but more precise, and it also
does not require much 'specialized' intervention on the part of the
user.
Best regards,
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: test-lang.org --]
[-- Type: application/vnd.lotus-organizer, Size: 2866 bytes --]
[-- Attachment #3: unicode-font-support.el --]
[-- Type: text/plain, Size: 8721 bytes --]
;; -*- lexical-binding: t; -*-
;; A proof of concept for Unicode font support in LaTeX export, using
;; babel and fontspec, with luatex as the default compiler.
;; Use example:
;; It is not necessary to load languages with non-Latin alphabet in babel options:
;; #+LaTeX_Header: \usepackage[AUTO]{babel}
;; Languages and fonts (there may be multiple lines):
;; #+LaTeX_Header: % !enable-fonts-for ancientgreek:Linux Libertine O(Scale=MatchLowercase)
;; #+LaTeX_Header: % !enable-fonts-for russian:FreeSerif(Numbers=Lowercase,Color=blue) :: arabic
;; Explanation:
;; - lang = enable default font for lang
;; - lang:font = enable font for lang in current document
;; - lanf:font(options) = enable font for lang in this document with options
;; - :: = separator
;; code
;; This is supposed to be a defcustom.
(setq org-latex-uc-fonts-support t)
;; A mini version of `org-latex-language-alist', for this proof of
;; concept. Babel uses various names for languages. The ones that
;; interest us here are those collected in `:babel-alt', which is
;; always a list. The names sometimes match the `classic' babel name
;; and other times they don't. And in the case of "el-polyton" there
;; are two possible names. For a list of these names see:
;; [[https://CTAN/macros/latex/required/babel/base/babel.pdf]],
;; p. 22.
(defconst org-latex-language-alist
'(("en" :babel "american" :babel-alt ("english-unitedstates") :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :code "latn")
("ar" :babel "arabic" :babel-alt ("arabic") :polyglossia "arabic" :lang-name "Arabic" :script "arabic" :code "arab")
("el" :babel "greek" :babel-alt ("greek") :polyglossia "greek" :lang-name "Greek" :script "greek" :code "grk")
("el-polyton" :babel "polutonikogreek" :babel-alt ("ancientgreek" "polytonicgreek") :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek" :script "greek" :code "grk")
("ru" :babel "russian" :babel-alt ("russian") :polyglossia "russian" :lang-name "Russian" :script "cyrillic" :code "cyrl"))
"TODO")
;; This is supposed to be a defcustom for the main fonts. `'default'
;; means 'use the main default fonts'. Otherwise, the value must be
;; a plist. Valid props. are:
;; - :main = roman font
;; - :sans = sans font
;; - :mono = mono font
;; - :math = math font
;; - :...-options = font options
;; For the font options and the fontspec package syntax, see
;; [[https://CTAN/macros/unicodetex/latex/fontspec/fontspec.pdf]]
(setq org-latex-uc-fonts-support-default-main-fonts
'(:main "FreeSerif" :mono "inconsolatan" :mono-options "Scale=0.95"))
;; This is supposed to be a defcustom. Each element has the structure:
;; script - font - (optional) font options
(setq org-latex-uc-fonts-support-default-scripts-fonts
'(("greek" "Linux Libertine")
("cyrillic" "Old Standard")
("arabic" "FreeSerif")))
;; Get main fonts (declared in
;; `org-latex-uc-fonts-support-default-main-fonts')
(defun org-latex-uc-fonts-support-get-main-fonts (plist prop)
(let ((format))
(if (not
(plist-member plist prop))
(ignore)
(let* ((value (plist-get plist prop))
(prop-name
(replace-regexp-in-string ":" "" (symbol-name prop)))
(options (plist-get
plist
(intern
(format
":%s-options"
prop-name)))))
(setq format
(format
"\\\\set%sfont{%s}[%s]"
prop-name value
(if options options "")
))))
format))
;; get non latin fonts explicitly added
(defun org-latex-uc-fonts-support-get-fonts-other-languages (header)
(interactive)
(let ((format-str)
(lines))
(with-temp-buffer
(insert header)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "%\s+!enable-fonts-for\s+\\(.+\\)" nil t)
(add-to-list 'lines (match-string 1)))))
(let* ((lines-list
(mapcar
(lambda (x)
(split-string x "::"))
lines))
(flat (flatten-list lines-list))
(format-list (mapcar
(lambda (x)
(org-latex-uc-fonts-support-format-font-for-language (string-trim x)))
flat)))
(setq format-str (mapconcat #'identity format-list "\n\n")))
format-str))
;; format each lang/font
(defun org-latex-uc-fonts-support-format-font-for-language (lang)
(let* ((regexp "\\([^:]+\\):*\\([^()]*\\)(*\\([^()]*\\))*")
(lang-name (when (string-match regexp lang)
(match-string 1 lang)))
(lang-explicit-font (when (string-match regexp lang)
(match-string 2 lang)))
(lang-explicit-font-opts (when (string-match regexp lang)
(match-string 3 lang)))
(lang-alias (let ((candidato))
(mapc (lambda (x)
(when (member :babel-alt x)
(let* ((plist (cdr x))
(babel-alt (plist-get plist :babel-alt)))
(when (member lang-name babel-alt)
(setq candidato (car x))))))
org-latex-language-alist)
candidato))
(plist (cdr (assoc lang-alias org-latex-language-alist)))
(script (plist-get plist :script))
(default-script-font (assoc script org-latex-uc-fonts-support-default-scripts-fonts))
(default-font (nth 1 default-script-font))
(default-font-options (nth 2 default-script-font))
(default-font-options? (if default-font-options
default-font-options
"")))
(format
"\\\\babelprovide[onchar=ids fonts]{%s}\n
\\\\babelfont[%s]{rm}[%s]{%s}\n"
lang-name
lang-name
(if (not (equal lang-explicit-font-opts "")) lang-explicit-font-opts default-font-options?)
(if (not (equal lang-explicit-font "")) lang-explicit-font default-font))))
;; make preamble definitions. This is supposed to be part of
;; `org-latex-guess-babel-language', as in the modified version below
(defun org-latex-uc-fonts-support-make-preamble (header)
(let* ((main-fonts (unless (eq 'org-latex-uc-fonts-support-default-main-fonts 'default)
(mapconcat #'identity
(cl-remove-if-not #'identity
(mapcar
(lambda (elt)
(let ((str (org-latex-uc-fonts-support-get-main-fonts
org-latex-uc-fonts-support-default-main-fonts
elt)))
(when str str)))
(list :main :sans :mono :math)))
"\n")))
(other-fonts-per-language
(org-latex-uc-fonts-support-get-fonts-other-languages header))
(preamble (with-temp-buffer
(insert "\n\n")
(when main-fonts
(insert main-fonts))
(insert "\n\n")
(when other-fonts-per-language
(insert other-fonts-per-language))
(buffer-string))))
preamble))
(defun org-latex-guess-babel-language (header info)
"Modified version for this proof of concept"
(let* ((language-code (plist-get info :language))
(plist (cdr
(assoc language-code org-latex-language-alist)))
(language (plist-get plist :babel))
(language-ini-only (plist-get plist :babel-ini-only))
;; If no language is set, or Babel package is not loaded, or
;; LANGUAGE keyword value is a language served by Babel
;; exclusively through ini files, return HEADER as-is.
(header (if (or language-ini-only
(not (stringp language-code))
(not (string-match "\\\\usepackage\\[\\(.*\\)\\]{babel}" header)))
header
(let ((options (save-match-data
(org-split-string (match-string 1 header) ",[ \t]*"))))
;; If LANGUAGE is already loaded, return header
;; without AUTO. Otherwise, replace AUTO with language or
;; append language if AUTO is not present. Languages that are
;; served in Babel exclusively through ini files are not added
;; to the babel argument, and must be loaded using
;; `\babelprovide'.
(replace-match
(mapconcat (lambda (option) (if (equal "AUTO" option) language option))
(cond ((member language options) (delete "AUTO" options))
((member "AUTO" options) options)
(t (append options (list language))))
", ")
t nil header 1)))))
;;; adition:
(when org-latex-uc-fonts-support
(setq header (let ((form (org-latex-uc-fonts-support-make-preamble header)))
(replace-regexp-in-string
"\\(\\\\usepackage\\[?.*\\]?{babel}\\)"
(format "\n\\\\usepackage{fontspec}\n\n\\1\n%s" form)
header))))
;;;
;; If `\babelprovide[args]{AUTO}' is present, AUTO is
;; replaced by LANGUAGE.
(if (not (string-match "\\\\babelprovide\\[.*\\]{\\(.+\\)}" header))
header
(let ((prov (match-string 1 header)))
(if (equal "AUTO" prov)
(replace-regexp-in-string (format
"\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
(format "\\1\\2%s}"
(or language language-ini-only))
header t)
header)))))
^ permalink raw reply [relevance 4%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-02 21:39 4% ` Juan Manuel Macías
@ 2023-09-03 7:22 5% ` Ihor Radchenko
2023-09-03 11:05 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-03 7:22 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Finally I can upload some usable code here, in this case to be able to
> load and manage fonts for languages with non-Latin scripts, through
> babel and fontspec (in LuaLaTeX). It is an attempt to simplify from Org
> the multiform syntax of babel + fontspec. Of course, it is more limited,
> but for regular use I think it may be enough.
I can see that you did not add defaults for Chinese, which is one of the
problematic scripts for LaTeX. Can you add it?
> ;; #+LaTeX_Header: % !enable-fonts-for ancientgreek:Linux Libertine O(Scale=MatchLowercase)
> ;; #+LaTeX_Header: % !enable-fonts-for russian:FreeSerif(Numbers=Lowercase,Color=blue) :: arabic
I do not like this approach.
Would be more consistent to allow multiple languages in #+language +
#+LATEX_FONT keyword to optionally specify per-language font:
#+LANGUAGE: <main language> <other languages...>
#+LATEX_FONT[lang]: font
#+language: ancientgreek russian arabic
#+latex_font[ancientgreek]: "Linux Libertine O" Scale=MatchLowercase
#+latex_font[russian]: "FreeSerif" Numbers=Lowercase,Color=blue
Also, I think that it may still make sense to have some kind of fallback
font if the specified fonts are not sufficient. For example, when using
emoji symbols, which do not correspond to any language.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-03 7:22 5% ` Ihor Radchenko
@ 2023-09-03 11:05 6% ` Juan Manuel Macías
2023-09-04 8:09 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-03 11:05 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Timothy
Thanks for your comments!
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Finally I can upload some usable code here, in this case to be able to
>> load and manage fonts for languages with non-Latin scripts, through
>> babel and fontspec (in LuaLaTeX). It is an attempt to simplify from Org
>> the multiform syntax of babel + fontspec. Of course, it is more limited,
>> but for regular use I think it may be enough.
>
> I can see that you did not add defaults for Chinese, which is one of the
> problematic scripts for LaTeX. Can you add it?
In that first proof of concept I only put a few scripts, less
problematic, simply to show the functionality. In CJK languages things
are a little more complicated, but it can be done too. The idea is to
cover all scripts. In the next code I submit, when I redo the current
one, I will try to introduce the case of CJK scripts.
>> ;; #+LaTeX_Header: % !enable-fonts-for ancientgreek:Linux Libertine O(Scale=MatchLowercase)
>> ;; #+LaTeX_Header: % !enable-fonts-for russian:FreeSerif(Numbers=Lowercase,Color=blue) :: arabic
>
> I do not like this approach.
I'm not a big fan of doing it like that either. I chose this option
because I didn't have to define a new keyword and to be less "intrusive"
with the actual code. But on the other hand it adds a new syntax. Well,
I discard it, to the detriment of an idea that you mention below.
> Would be more consistent to allow multiple languages in #+language +
> #+LATEX_FONT keyword to optionally specify per-language font:
> #+language: ancientgreek russian arabic
Of course, this syntax would be the most appropriate and consistent
within Org. The problem is LaTeX, specifically babel, and that certain
inconsistencies would be created with the rest of the backends. At first
some pitfalls come to mind:
- The keyword #+language accepts for now only language codes (es, en,
el, ar, ru, etc.). Consistency with other backends should
be maintained in this regard: ancientgreek is not a valid language
code, but a name that only babel understands. If we put something
like (a valid language code):
#+language: el-polyton
this could be translated in babel as polutonikogreek (in the classic
syntax, that is, the languages that are loaded in the options of
\usepackage[options]{babel}), or, in the new syntax, ancientgreek and
polytonicgreek, which are actually two different languages: the first
is ancient polytonic Greek and the second modern polytonic Greek. To
add more confusion to the matter, in classical babel syntax
greek.ancient and greek.polytonic are also supported. But neither of
these things can be deduced by simply putting el-polyton, unless
breaking the consistency with the other backends.
- Added to this is that Babel has two ways to load languages: the
classic syntax and the \babelprovide command, which is the one we are
interested in here for languages with non-Latin scripts, because the
onchar=ids fonts property must be added here. And what happens if the
user has already defined several languages with babel, using the
current procedure: \usepackage[french, english, AUTO]{babel}?
Therefore, the least complicated thing, in my opinion, is to leave the
syntax of the keyword #+language as it is. It is not necessary for the
user to explicitly define secondary non-latin languages. The idea is
that Org is responsible for generating the necessary babel code by
simply giving a command like enable font for X language. What we are
talking about here is ensuring readability using a series of fonts that
LaTeX does not load by default, not even LuaLaTeX. And, after all, Org
is monolingual: it does not have multilingual support at the moment;
that is, there is nothing in Org to switch languages in the middle of
the document. What happens is that here we take advantage of the
functionality that Babel has to automatically apply a font for a
non-Latin language/script, also loading its properties (hyphen rules,
captions, etc.).
A new keyword #+latex_language could be created, which would understand
the babel names, but I think it is unnecessary and would add more
complexity. As I said before, defining the necessary fonts would be
enough, since my idea in this is a basic practicality to ensure the
readability of the documents. And anyone looking for more advanced
functions would have to enter LaTeX code explicitly.
> #+latex_font[ancientgreek]: "Linux Libertine O" Scale=MatchLowercase
>
> #+latex_font[russian]: "FreeSerif" Numbers=Lowercase,Color=blue
I like this idea, but with the exception that in the two examples you
give the user is declaring two fonts for both languages. In my example
there was also Arabic, where the default font for the Arabic script is
used. Note that each script would have default fonts, which the user can
change or not change in their document. A user could simply put
something like "enable the default fonts for ancientgreek, russian,
malayalam, georgian, chinese". And nothing more. Or choose some other
font with or without options for a specific lang.
Could be:
#+latex_font: ancientgreek, russian, malayalam, sanskrit-devanagari
beside:
#+latex_font[arabic]: "FreeSerif" Numbers=Lowercase,Color=blue
This last syntax would also be valid to modify the main default fonts:
#+latex_font[main]: "FreeSerif" Numbers=Lowercase
#+latex_font[sans]: "some font"
#+latex_font[mono]: "some font"
#+latex_font[math]: "some font"
A practical use case. Suppose a user has a document in Spanish, which
includes passages in Greek and Russian. It would be enough to use the
Old Standard font (included in TeX live) for the entire document,
ensuring consistency:
#+latex_header: \usepackage[AUTO]{babel}
#+language:es
#+latex_font[main,greek,russian]: Old Standard
> Also, I think that it may still make sense to have some kind of fallback
> font if the specified fonts are not sufficient. For example, when using
> emoji symbols, which do not correspond to any language.
Yes I agree. That could also be included in the generated preamble.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 6%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-03 11:05 6% ` Juan Manuel Macías
@ 2023-09-04 8:09 4% ` Ihor Radchenko
2023-09-04 22:22 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-04 8:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> #+language: ancientgreek russian arabic
>
> Of course, this syntax would be the most appropriate and consistent
> within Org. The problem is LaTeX, specifically babel, and that certain
> inconsistencies would be created with the rest of the backends. At first
> some pitfalls come to mind:
>
> - The keyword #+language accepts for now only language codes (es, en,
> el, ar, ru, etc.). Consistency with other backends should
> be maintained in this regard: ancientgreek is not a valid language
> code, but a name that only babel understands. If we put something
> like (a valid language code):
>
> #+language: el-polyton
>
> this could be translated in babel as polutonikogreek (in the classic
> syntax, that is, the languages that are loaded in the options of
> \usepackage[options]{babel}), or, in the new syntax, ancientgreek and
> polytonicgreek, which are actually two different languages: the first
> is ancient polytonic Greek and the second modern polytonic Greek. To
> add more confusion to the matter, in classical babel syntax
> greek.ancient and greek.polytonic are also supported. But neither of
> these things can be deduced by simply putting el-polyton, unless
> breaking the consistency with the other backends.
I am now working on unifying Org translation system as discussed in
https://orgmode.org/list/87o7iw8yem.fsf@bzg.fr
As a part of the effort, I plan to introduce a new constant that will
unify language abbreviations across Org and also associate them with
more human-readable names.
(defconst org-language-abbrevs
'(("am". "Amharic")
("ar" . "Arabic")
("ast" . "Asturian")
("bg" . "Bulgarian")
("bn" . "Bengali")
...))
The idea is to allow
#+language: Austrian German, Greek
as a valid specifier, in addition to
#+language: de-at, el
Then, across Org, we will make use of the standardized language
abbreviations.
> - Added to this is that Babel has two ways to load languages: the
> classic syntax and the \babelprovide command, which is the one we are
> interested in here for languages with non-Latin scripts, because the
> onchar=ids fonts property must be added here. And what happens if the
> user has already defined several languages with babel, using the
> current procedure: \usepackage[french, english, AUTO]{babel}?
For LaTeX specifically, `org-latex-language-alist', will be re-used to
map whatever is allowed in #+language keyword to its name in
babel/polyglossia.
Does it make sense?
> Therefore, the least complicated thing, in my opinion, is to leave the
> syntax of the keyword #+language as it is. It is not necessary for the
> user to explicitly define secondary non-latin languages. The idea is
> that Org is responsible for generating the necessary babel code by
> simply giving a command like enable font for X language. What we are
> talking about here is ensuring readability using a series of fonts that
> LaTeX does not load by default, not even LuaLaTeX. And, after all, Org
> is monolingual: it does not have multilingual support at the moment;
> that is, there is nothing in Org to switch languages in the middle of
> the document. What happens is that here we take advantage of the
> functionality that Babel has to automatically apply a font for a
> non-Latin language/script, also loading its properties (hyphen rules,
> captions, etc.).
>
> A new keyword #+latex_language could be created, which would understand
> the babel names, but I think it is unnecessary and would add more
> complexity. As I said before, defining the necessary fonts would be
> enough, since my idea in this is a basic practicality to ensure the
> readability of the documents. And anyone looking for more advanced
> functions would have to enter LaTeX code explicitly.
I think that we should move towards multi-language support.
Such support would practically simplify WORG and orgmode.org translation
process, and may also be used as a basis to allow translating the
Org manual.
My rough idea is to allow specifying language as affiliated
keyword and, in future, allow selective export to certain target
language.
Multi-language documents are another potential target to support.
>> #+latex_font[ancientgreek]: "Linux Libertine O" Scale=MatchLowercase
>>
>> #+latex_font[russian]: "FreeSerif" Numbers=Lowercase,Color=blue
>
> I like this idea, but with the exception that in the two examples you
> give the user is declaring two fonts for both languages. In my example
> there was also Arabic, where the default font for the Arabic script is
> used.
My idea was that
#+language: ancientgreek russian arabic
implies "use default font for arabic", unless #+latex_font is specified.
> #+latex_font[arabic]: "FreeSerif" Numbers=Lowercase,Color=blue
>
> This last syntax would also be valid to modify the main default fonts:
>
> #+latex_font[main]: "FreeSerif" Numbers=Lowercase
> #+latex_font[sans]: "some font"
> #+latex_font[mono]: "some font"
> #+latex_font[math]: "some font"
>
> A practical use case. Suppose a user has a document in Spanish, which
> includes passages in Greek and Russian. It would be enough to use the
> Old Standard font (included in TeX live) for the entire document,
> ensuring consistency:
>
> #+latex_header: \usepackage[AUTO]{babel}
> #+language:es
> #+latex_font[main,greek,russian]: Old Standard
Looks reasonable.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 4%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-04 8:09 4% ` Ihor Radchenko
@ 2023-09-04 22:22 7% ` Juan Manuel Macías
2023-09-05 10:44 5% ` Ihor Radchenko
2023-09-05 16:42 6% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-04 22:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Timothy
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> #+language: ancientgreek russian arabic
>>
>> Of course, this syntax would be the most appropriate and consistent
>> within Org. The problem is LaTeX, specifically babel, and that certain
>> inconsistencies would be created with the rest of the backends. At first
>> some pitfalls come to mind:
>>
>> - The keyword #+language accepts for now only language codes (es, en,
>> el, ar, ru, etc.). Consistency with other backends should
>> be maintained in this regard: ancientgreek is not a valid language
>> code, but a name that only babel understands. If we put something
>> like (a valid language code):
>>
>> #+language: el-polyton
>>
>> this could be translated in babel as polutonikogreek (in the classic
>> syntax, that is, the languages that are loaded in the options of
>> \usepackage[options]{babel}), or, in the new syntax, ancientgreek and
>> polytonicgreek, which are actually two different languages: the first
>> is ancient polytonic Greek and the second modern polytonic Greek. To
>> add more confusion to the matter, in classical babel syntax
>> greek.ancient and greek.polytonic are also supported. But neither of
>> these things can be deduced by simply putting el-polyton, unless
>> breaking the consistency with the other backends.
>
> I am now working on unifying Org translation system as discussed in
> https://orgmode.org/list/87o7iw8yem.fsf@bzg.fr
> As a part of the effort, I plan to introduce a new constant that will
> unify language abbreviations across Org and also associate them with
> more human-readable names.
>
> (defconst org-language-abbrevs
> '(("am". "Amharic")
> ("ar" . "Arabic")
> ("ast" . "Asturian")
> ("bg" . "Bulgarian")
> ("bn" . "Bengali")
> ...))
>
> The idea is to allow
>
> #+language: Austrian German, Greek
> as a valid specifier, in addition to
>
> #+language: de-at, el
>
> Then, across Org, we will make use of the standardized language
> abbreviations.
Great! I think it's great news. Yes, I agree with what you say below. I
think Org should move towards a multilingual support that is 100% native
to Org. That is, Org had its own "selectlanguage" mechanism, to be able
to delimit text segments in other languages and have control over them,
both within Org and when exporting to the different backends. That
scenario seems very desirable to me, and I would like to contribute my
help to the best of my ability (and time).
In LaTeX, as I mentioned, things are complicated. There is Babel and
Polyglossia, and there is LuaTeX and XeTeX. In addition, there is also
pdfTeX, which is still the default engine and (to be honest) is the
engine used by a high percentage of LaTeX users. Although perhaps things
will change soon to the detriment of LuaTeX. Both babel and polyglossia
could be supported, but that means more work, more code, and more
complications. And we are not sure that polyglossia is no longer
maintained. After all, babel is the official LaTeX package for language
support, and polyglossia appeared at a time when babel had no support
for the new unicode engines. Now Babel supports all of that and is much
more powerful, but its interface has also grown in complexity. There is
the problem of the double syntax for loading languages: the old one,
which loads traditional ldf files, and the modern one (\babelprovide),
which loads languages using ini files. It is more powerful, with more
options, but has added more verbosity to babel. I have taken advantage
of \babelprovide, specifically its onchar=id fonts property, to
automatically apply fonts to non-Latin scripts.
>> I like this idea, but with the exception that in the two examples you
>> give the user is declaring two fonts for both languages. In my example
>> there was also Arabic, where the default font for the Arabic script is
>> used.
>
> My idea was that
>
> #+language: ancientgreek russian arabic
>
> implies "use default font for arabic", unless #+latex_font is specified.
This seems the most consistent to me for Org, but, as I mentioned in the
other email, I have some concerns. Currently, what we are talking about
is simply font support for non-Latin languages. If it is allowed, in the
current state of things, that #+language can accept a list of language
names, we can give the user a wrong perception of reality. That is:
multilingual support that does not exist as such. It is more like font
support for non-Latin languages. And only in LaTeX, and specifically in
LuaLaTeX. Furthermore, the user could mix languages that in Babel are
loaded through ldf and others through ini files. For example, something
like this:
#+language: spanish, english, french, russian
in Babel it would be:
\usepackage[english,french,spanish]{babel}
and here we need babelprovide for the font (and load Russian via ini
file):
\babelprovide[onchar=id fonts, import]{russian}
\babelfont[russian]{rm}[options]{somefont}
Org would have to discern which name refers to a non-Latin language
(which wouldn't be complicated with the functionality you're working on)
and then apply the default font by adding a line with \babelprovide.
Of course, English, French and Spanish can also be loaded via ini files:
\babelprovide[main,import]{spanish}
\babelprovide[import]{french}
\babelprovide[import]{english}
Even babel also supports:
\usepackage[english,french,spanish,provide*=*]{babel}
but in that line we cannot put Russian with onchar, etc. And then there
is pdfTeX, where only the classic babel syntax is allowed, without any
"*provide".
In short, I find everything very confusing. I am not opposed to doing it
as you propose (in fact, it is the option I like the most, especially
when org is polyglot in the future), but I also want to warn of possible
complications.
Therefore, since we are, for now, with fonts for non-Latin languages, I
think it should be made clear that the keyword is about fonts (and about
LuaLaTeX). Maybe through two keywords:
#+lualatex_fonts_for: language(s)
#+lualatex_fonts[language(s)]: "font" options
?
I think it's ugly, but I can't think of anything else.
By the way, and as a side note, is it currently possible in Org to
define a keyword within :options-alist of the style #+foo[anything] or
would something like org-collect-keywords have to be modified?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 7%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-04 22:22 7% ` Juan Manuel Macías
@ 2023-09-05 10:44 5% ` Ihor Radchenko
2023-09-20 14:03 5% ` Juan Manuel Macías
2023-09-05 16:42 6% ` Max Nikulin
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-05 10:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> The idea is to allow
>>
>> #+language: Austrian German, Greek
>> as a valid specifier, in addition to
>>
>> #+language: de-at, el
>>
>> Then, across Org, we will make use of the standardized language
>> abbreviations.
>
> In LaTeX, as I mentioned, things are complicated. There is Babel and
> Polyglossia, and there is LuaTeX and XeTeX. In addition, there is also
> pdfTeX, which is still the default engine and (to be honest) is the
> engine used by a high percentage of LaTeX users. Although perhaps things
> will change soon to the detriment of LuaTeX. Both babel and polyglossia
> could be supported, but that means more work, more code, and more
> complications. And we are not sure that polyglossia is no longer
> maintained. After all, babel is the official LaTeX package for language
> support, and polyglossia appeared at a time when babel had no support
> for the new unicode engines. Now Babel supports all of that and is much
> more powerful, but its interface has also grown in complexity. There is
> the problem of the double syntax for loading languages: the old one,
> which loads traditional ldf files, and the modern one (\babelprovide),
> which loads languages using ini files. It is more powerful, with more
> options, but has added more verbosity to babel. I have taken advantage
> of \babelprovide, specifically its onchar=id fonts property, to
> automatically apply fonts to non-Latin scripts.
> ...
> multilingual support that does not exist as such. It is more like font
> support for non-Latin languages. And only in LaTeX, and specifically in
> LuaLaTeX. Furthermore, the user could mix languages that in Babel are
> loaded through ldf and others through ini files. For example, something
> like this:
>
> #+language: spanish, english, french, russian
>
> in Babel it would be:
>
> \usepackage[english,french,spanish]{babel}
>
> and here we need babelprovide for the font (and load Russian via ini
> file):
>
> \babelprovide[onchar=id fonts, import]{russian}
> \babelfont[russian]{rm}[options]{somefont}
>
> Org would have to discern which name refers to a non-Latin language
> (which wouldn't be complicated with the functionality you're working on)
> and then apply the default font by adding a line with \babelprovide.
>
> Of course, English, French and Spanish can also be loaded via ini files:
>
> \babelprovide[main,import]{spanish}
> \babelprovide[import]{french}
> \babelprovide[import]{english}
>
> Even babel also supports:
>
> \usepackage[english,french,spanish,provide*=*]{babel}
>
> but in that line we cannot put Russian with onchar, etc. And then there
> is pdfTeX, where only the classic babel syntax is allowed, without any
> "*provide".
Aren't we already handling this problem in `org-latex-make-preamble'?
>> My idea was that
>>
>> #+language: ancientgreek russian arabic
>>
>> implies "use default font for arabic", unless #+latex_font is specified.
>
> This seems the most consistent to me for Org, but, as I mentioned in the
> other email, I have some concerns. Currently, what we are talking about
> is simply font support for non-Latin languages. If it is allowed, in the
> current state of things, that #+language can accept a list of language
> names, we can give the user a wrong perception of reality. That is:
<complications with full support not being possible in all the LaTeX flavors>
> In short, I find everything very confusing. I am not opposed to doing it
> as you propose (in fact, it is the option I like the most, especially
> when org is polyglot in the future), but I also want to warn of possible
> complications.
>
> Therefore, since we are, for now, with fonts for non-Latin languages, I
> think it should be made clear that the keyword is about fonts (and about
> LuaLaTeX). Maybe through two keywords:
>
> #+lualatex_fonts_for: language(s)
> #+lualatex_fonts[language(s)]: "font" options
>
> ?
>
> I think it's ugly, but I can't think of anything else.
Maybe just
#+lualatex_fonts[languages(s)]: default
to force the default.
> By the way, and as a side note, is it currently possible in Org to
> define a keyword within :options-alist of the style #+foo[anything] or
> would something like org-collect-keywords have to be modified?
We will need to add things to `org-element-dual-keywords' and make sure
that the code expects the keyword value to be a list, as returned by the
parser. AFAIU, it should be enough.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-04 22:22 7% ` Juan Manuel Macías
2023-09-05 10:44 5% ` Ihor Radchenko
@ 2023-09-05 16:42 6% ` Max Nikulin
2023-09-05 18:33 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-05 16:42 UTC (permalink / raw)
To: emacs-orgmode
On 05/09/2023 05:22, Juan Manuel Macías wrote:
> \usepackage[english,french,spanish,provide*=*]{babel}
>
> but in that line we cannot put Russian with onchar, etc.
Cyrillic letters may appear not only in Russian just as French and
Spanish use Latin script. So language detection based on symbol code
points works only for distinct enough languages. Explicit markup may
still be necessary to switch hyphenation rules, dash styles, etc.
I have a couple of bookmarks for language detection libraries (not for
Emacs), but I am unsure if they may work for texts containing fragments
written in different languages.
^ permalink raw reply [relevance 6%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-05 16:42 6% ` Max Nikulin
@ 2023-09-05 18:33 12% ` Juan Manuel Macías
2023-09-06 9:29 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-05 18:33 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> Cyrillic letters may appear not only in Russian just as French and
> Spanish use Latin script. So language detection based on symbol code
> points works only for distinct enough languages. Explicit markup may
> still be necessary to switch hyphenation rules, dash styles, etc.
True. Thanks for pointing it out. Indeed, \babelprovide with the
ochar=id fonts option only makes sense when 1 foreign language = 1
script. For example, different variants of Greek cannot be combined
without an explicit switch.
And something like this wouldn't work either:
\babelprovide[import,onchar=id fonts]{russian}
\babelprovide[import,onchar=id fonts]{bulgarian}
\babelfont[russian]{rm}[Color=blue]{Old Standard}
\babelfont[bulgarian]{rm}[Color=green]{FreeSerif}
because bulgarian overwrites russian.
Well, another added complication :-(.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-05 18:33 12% ` Juan Manuel Macías
@ 2023-09-06 9:29 6% ` Ihor Radchenko
2023-09-06 14:58 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-06 9:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko
Juan Manuel Macías <maciaschain@posteo.net> writes:
> True. Thanks for pointing it out. Indeed, \babelprovide with the
> ochar=id fonts option only makes sense when 1 foreign language = 1
> script. For example, different variants of Greek cannot be combined
> without an explicit switch.
>
> And something like this wouldn't work either:
>
> \babelprovide[import,onchar=id fonts]{russian}
> \babelprovide[import,onchar=id fonts]{bulgarian}
> \babelfont[russian]{rm}[Color=blue]{Old Standard}
> \babelfont[bulgarian]{rm}[Color=green]{FreeSerif}
>
> because bulgarian overwrites russian.
>
> Well, another added complication :-(.
AFAIU, there is simply no way to solve this unless the user manually
indicates the indented language.
Do I understand correctly that onchar=id will not break anything if text
is correctly marked with \selectlanguage{<lang>}?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* ox-latex language handling in Org-9.5 vs 9.6
@ 2023-09-06 14:55 5% Max Nikulin
2023-09-06 22:20 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-06 14:55 UTC (permalink / raw)
To: emacs-orgmode
Hi,
I consider the following as an issue rather close to the discussion in
the thread
Juan Manuel Macías. Fallback fonts in LaTeX export for non latin
scripts. Wed, 30 Aug 2023 08:25:53 +0000.
https://list.orgmode.org/878r9t7x7y.fsf@posteo.net
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug
report logs
I am unsure if the change was intentional.
#+language: de-de
#+latex_header: \usepackage[AUTO]{babel}
is exported to
\usepackage[ngerman]{babel}
% ...
\hypersetup{
% ...
pdflang={Ngerman}}
by Org-9.5 and as
\usepackage[]{babel}
% ...
\hypersetup{
% ...
pdflang={De-De}}
by Org-9.6. Similar user expectation should be had in mind during
planning of further changes.
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-06 9:29 6% ` Ihor Radchenko
@ 2023-09-06 14:58 8% ` Juan Manuel Macías
2023-09-07 10:22 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-06 14:58 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko
Ihor Radchenko writes:
> Do I understand correctly that onchar=id will not break anything if text
> is correctly marked with \selectlanguage{<lang>}?
To load language features (hyphen rules, captions, etc.) there is no
problem. But to load a font associated with a language, the font of the
last declared language will always be loaded. Well, it is not a problem,
because if in a document there are texts in Russian and Bulgarian, for
example, the natural thing is that they go in the same font, since both
languages share the Cyrillic script. But there may be cases when the
author needs different fonts. In such a case, the user should not use
the onchar = etc property:
https://i.imgur.com/vmsCNkP.png
In any case (to organize myself mentally) I thought that it could be
done on two levels:
- Level 0: The fonts associated with each script are loaded (from a
defcustom list) if luatex is the current engine. And low-level code is
generated in Lua with the luaotfload.add_fallback function. That code
can be in a Lua file or directly within the preamble, enclosed in the
\directlua primitive (mode=harf means that HarfBuzz is used as otf
rendering):
\directlua
{luaotfload.add_fallback("orgfallback",
{
"oldstandard:mode=harf;script=grek;",
"oldstandard:mode=harf;script=cyrl;",
"freeserif:mode=harf;script=arab;",
"freeserif:mode=harf;script=dev2;",
etc., etc.
})
}
And, to load the fallback fonts:
\setmainfont{latinmodernroman}[RawFeature={fallback=orgfallback}]
At this level per-language properties are not loaded, but at least
readability is ensured. The user cannot modify the fonts associated
with each script within the document, but can modify, of course, the
defcustom.
- Level 1: The user can load language properties and associate fonts
with each language using Babel's high-level code (via keywords in Org,
as we have commented in previous messages). Here you can also modify
the default fonts (also, as we mentioned before): main, mono, sans and
math. If the language is declared with an asterisk (for example:
russian*) the onchar=etc property will be included in the preamble,
and it would not be necessary to switch to russian explicitly. It is
assumed that in this scenario the only language with Cyrillic script
would be Russian. For language swithcing, in the rest of the cases,
some babel command would have to be used using @@latex:@@, special
blocks, etc. When Org already has its own language switching
mechanism, this would be used instead. Wdyt?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 8%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-06 14:55 5% ox-latex language handling in Org-9.5 vs 9.6 Max Nikulin
@ 2023-09-06 22:20 8% ` Juan Manuel Macías
2023-09-07 10:38 5% ` Max Nikulin
2023-09-07 11:50 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-06 22:20 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> I consider the following as an issue rather close to the discussion in
> the thread
> Juan Manuel Macías. Fallback fonts in LaTeX export for non latin
> scripts. Wed, 30 Aug 2023 08:25:53 +0000.
> https://list.orgmode.org/878r9t7x7y.fsf@posteo.net
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
> elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug
> report logs
>
> I am unsure if the change was intentional.
I seem to remember that when I made org-latex-language-alist I made some
corrections to a few language codes. I was guided by page 19 of the
Babel manual and by
https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
In both lists the language code for German is simply "de". Of course,
I'm no expert on the subject, so if I'm wrong in this case, I should
revert the change. I understand that de-de is German of Germany (="de"?); on
org-latex-language-alist exists de-at (Austrian German). The babel ini
file for german babel/locale/de/babel-de.ini has this id:
[identification]
charset = utf8
version = 1.3
date = 2020-06-30
name.local = Deutsch
name.english = German
name.babel = german
name.polyglossia = german
tag.bcp47 = de
language.tag.bcp47 = de
tag.bcp47.likely = de-Latn-DE
tag.opentype = DEU
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
level = 1
encodings = T1 OT1 LY1
derivate = no
and babel-de-AT.ini:
[identification]
charset = utf8
version = 1.3
date = 2020-06-30
name.local = Deutsch
name.english = German
name.babel = austrian german-austria german-at
name.polyglossia = german
tag.bcp47 = de-AT
language.tag.bcp47 = de
tag.opentype = DEU
region.local = Österreich
region.english = Austria
region.tag.bcp47 = AT
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
polyglossia.variant = austrian
polyglossia.spelling = new
level = 1
encodings = T1 OT1 LY1
derivate = no
ini files use german and german-at, but in classic babel nomenclature
(ldf files) we have ngerman and naustrian.
Maybe it should be corrected like this:
("de-de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
("de" :babel-ini-only "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
The case of de-at is more problematic because a single language code
serves for naustrian (ldf) and (ini:) austrian, german-at and
german-austria. Some new property, something like :babel-ini-alt, would
have to be introduced . There are other similar cases on the list, such
as el-polyton, which points to polutonikogreek (ldf). In general, except
in cases where only the ini file exists, I used the ldf nomenclature for
backward compatibility.
In any case, these dances of language names between some places and
others make the list of language names that Ihor is working on
increasingly necessary.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 8%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-06 14:58 8% ` Juan Manuel Macías
@ 2023-09-07 10:22 5% ` Ihor Radchenko
2023-09-07 12:04 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-07 10:22 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Do I understand correctly that onchar=id will not break anything if text
>> is correctly marked with \selectlanguage{<lang>}?
>
> To load language features (hyphen rules, captions, etc.) there is no
> problem. But to load a font associated with a language, the font of the
> last declared language will always be loaded.
May we explicitly set the needed font around language environments?
Something like
\setfontforrussian
\selectlanguage{russian}
....
\setfontforbulgarian
\selectlanguage{bulgarian}
....
> In any case (to organize myself mentally) I thought that it could be
> done on two levels:
>
> - Level 0: The fonts associated with each script are loaded (from a
> defcustom list) if luatex is the current engine. And low-level code is
> generated in Lua with the luaotfload.add_fallback function. That code
> can be in a Lua file or directly within the preamble, enclosed in the
> \directlua primitive (mode=harf means that HarfBuzz is used as otf
> rendering):
> ...
Sounds reasonable.
> - Level 1: The user can load language properties and associate fonts
> with each language using Babel's high-level code (via keywords in Org,
> as we have commented in previous messages). Here you can also modify
> the default fonts (also, as we mentioned before): main, mono, sans and
> math. If the language is declared with an asterisk (for example:
> russian*) the onchar=etc property will be included in the preamble,
> and it would not be necessary to switch to russian explicitly. It is
> assumed that in this scenario the only language with Cyrillic script
> would be Russian. For language swithcing, in the rest of the cases,
> some babel command would have to be used using @@latex:@@, special
> blocks, etc. When Org already has its own language switching
> mechanism, this would be used instead. Wdyt?
I am not sure if I like "russian*" idea. May you explain a bit more
about how onchar works? What if language characters are intersecting,
and not using exactly the same char sets?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-06 22:20 8% ` Juan Manuel Macías
@ 2023-09-07 10:38 5% ` Max Nikulin
2023-09-07 11:50 6% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2023-09-07 10:38 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
On 07/09/2023 05:20, Juan Manuel Macías wrote:
> Maybe it should be corrected like this:
>
> ("de-de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
> ("de" :babel-ini-only "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
Sorry, I have only used basic babel configuration, so I am unaware of
real differences of .ldf and .ini ways. My expectation is that in
absence of "de-de" definition a fallback to "de" should be used.
Perhaps .ldf vs. .ini should be an orthogonal setting independent of
locale selection.
Frankly speaking, I am a bit confused by locale definitions in general:
ls /usr/share/locale/ | grep '^de'
de
de_CH
de_DE
de@hebrew
ls /usr/share/i18n/locales/ | grep '^de'
de_AT
de_AT@euro
de_BE
de_BE@euro
de_CH
de_DE
de_DE@euro
de_IT
de_LI
de_LU
de_LU@euro
^ permalink raw reply [relevance 5%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-06 22:20 8% ` Juan Manuel Macías
2023-09-07 10:38 5% ` Max Nikulin
@ 2023-09-07 11:50 6% ` Ihor Radchenko
2023-09-07 14:19 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-07 11:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Max Nikulin writes:
>
>> I consider the following as an issue rather close to the discussion in
>> the thread
>> Juan Manuel Macías. Fallback fonts in LaTeX export for non latin
>> scripts. Wed, 30 Aug 2023 08:25:53 +0000.
>> https://list.orgmode.org/878r9t7x7y.fsf@posteo.net
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
>> elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug
>> report logs
>>
>> I am unsure if the change was intentional.
>
> I seem to remember that when I made org-latex-language-alist I made some
> corrections to a few language codes. I was guided by page 19 of the
> Babel manual and by
>
> https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
> In both lists the language code for German is simply "de". Of course,
> I'm no expert on the subject, so if I'm wrong in this case, I should
> revert the change. I understand that de-de is German of Germany (="de"?); on
> org-latex-language-alist exists de-at (Austrian German). The babel ini
> file for german babel/locale/de/babel-de.ini has this id:
I understand the motivation, but the end result is a clear regression.
May you please review 97cfb959d and recover the removed language names
to put into #+language as aliases to their correct names?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-07 10:22 5% ` Ihor Radchenko
@ 2023-09-07 12:04 9% ` Juan Manuel Macías
2023-09-08 7:42 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-07 12:04 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> May we explicitly set the needed font around language environments?
>
> Something like
>
> \setfontforrussian
> \selectlanguage{russian}
> ....
>
> \setfontforbulgarian
> \selectlanguage{bulgarian}
> ....
There's no need. With \babelfont you can associate a font with a
language (declared with both the classic syntax and \babelprovide. And
when you use \selectlanguage, \foreignlanguage or any other babel
command or environment to switch languages, the associated font is
activated for that language. For example:
\babelprovide[import]{russian}
\babelprovide[import]{bulgarian}
\babelfont[russian]{rm}[]{Old Standard}
\babelfont[bulgarian]{rm}[]{Freeserif}
and then:
\selectlanguage{russian}
...
\selectlanguage{bulgarian}
...
\babelprovide supports several properties. Adding the onchar=ids
fonts/letters property equates language and script, and everything in
that script is associated with a font. This would only make sense to use
when there is only one language in the document that has that script, as
we discussed before. In case like russian/bulgarian, the source of the
last babelprovide is overwritten for all cases where that script
appears.
>
>> In any case (to organize myself mentally) I thought that it could be
>> done on two levels:
>>
>> - Level 0: The fonts associated with each script are loaded (from a
>> defcustom list) if luatex is the current engine. And low-level code is
>> generated in Lua with the luaotfload.add_fallback function. That code
>> can be in a Lua file or directly within the preamble, enclosed in the
>> \directlua primitive (mode=harf means that HarfBuzz is used as otf
>> rendering):
>> ...
>
> Sounds reasonable.
>
>> - Level 1: The user can load language properties and associate fonts
>> with each language using Babel's high-level code (via keywords in Org,
>> as we have commented in previous messages). Here you can also modify
>> the default fonts (also, as we mentioned before): main, mono, sans and
>> math. If the language is declared with an asterisk (for example:
>> russian*) the onchar=etc property will be included in the preamble,
>> and it would not be necessary to switch to russian explicitly. It is
>> assumed that in this scenario the only language with Cyrillic script
>> would be Russian. For language swithcing, in the rest of the cases,
>> some babel command would have to be used using @@latex:@@, special
>> blocks, etc. When Org already has its own language switching
>> mechanism, this would be used instead. Wdyt?
>
> I am not sure if I like "russian*" idea. May you explain a bit more
> about how onchar works? What if language characters are intersecting,
> and not using exactly the same char sets?
Basically, it's like I said above. According to the Babel Manual:
#+begin_quote
onchar= ids | fonts | letters
This option is much like an ‘event’ called when a character belonging to
the script of this locale is found (as its name implies, it acts on
characters, not on spaces). There are currently two ‘actions’, which can
be used at the same time (separated by a space): with ids the \language
and the \localeid are set to the values of this locale; with fonts, the
fonts are changed to those of this locale (as set with \babelfont).
Characters can be added or modified with \babelcharproperty.
[...] Option letters restricts the ‘actions’ to letters, in the TEX
sense (i. e., with catcode 11). Digits and punctuation are then
considered part of current locale (as set by a selector). This option is
useful when the main script is non-Latin and there is a secondary one
whose script is Latin.
#+end_quote
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-07 11:50 6% ` Ihor Radchenko
@ 2023-09-07 14:19 12% ` Juan Manuel Macías
2023-09-07 14:49 6% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-07 14:19 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
>> In both lists the language code for German is simply "de". Of course,
>> I'm no expert on the subject, so if I'm wrong in this case, I should
>> revert the change. I understand that de-de is German of Germany (="de"?); on
>> org-latex-language-alist exists de-at (Austrian German). The babel ini
>> file for german babel/locale/de/babel-de.ini has this id:
>
> I understand the motivation, but the end result is a clear regression.
> May you please review 97cfb959d and recover the removed language names
> to put into #+language as aliases to their correct names?
I think I can introduce some fixes to org-latex-language-alist to
restore the removed language codes, without breaking the new and
maintaining compatibility with the old. As soon as I have some time I
will send a patch. Probably this weekend.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-07 14:19 12% ` Juan Manuel Macías
@ 2023-09-07 14:49 6% ` Max Nikulin
2023-09-08 10:30 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-07 14:49 UTC (permalink / raw)
To: emacs-orgmode
On 07/09/2023 21:19, Juan Manuel Macías wrote:
> I think I can introduce some fixes to org-latex-language-alist to
> restore the removed language codes
I have no idea why in
393f2f5ae 2012-06-14 12:57:35 +0200 Nicolas Goaziou: org-e-latex: Set
Babel language according to LANGUAGE keyword
new "ngerman" was used for de-de, while older "germanb" was chosen for
"de". From my point of view modern ngerman rules should be used in both
cases. Those who really need older style may specify germanb explicitly,
not through #+language mapping. Difference de-de vs. de is rather subtle
to rely on it.
^ permalink raw reply [relevance 6%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-07 12:04 9% ` Juan Manuel Macías
@ 2023-09-08 7:42 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-08 7:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I am not sure if I like "russian*" idea. May you explain a bit more
>> about how onchar works? What if language characters are intersecting,
>> and not using exactly the same char sets?
>
> Basically, it's like I said above. According to the Babel Manual:
>
> #+begin_quote
> onchar= ids | fonts | letters
>
> This option is much like an ‘event’ called when a character belonging to
> the script of this locale is found (as its name implies, it acts on
> characters, not on spaces). There are currently two ‘actions’, which can
> be used at the same time (separated by a space): with ids the \language
> and the \localeid are set to the values of this locale; with fonts, the
> fonts are changed to those of this locale (as set with \babelfont).
> Characters can be added or modified with \babelcharproperty.
>
> [...] Option letters restricts the ‘actions’ to letters, in the TEX
> sense (i. e., with catcode 11). Digits and punctuation are then
> considered part of current locale (as set by a selector). This option is
> useful when the main script is non-Latin and there is a secondary one
> whose script is Latin.
> #+end_quote
Thanks for the explanation!
Then, language* it is. I have no better idea.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-07 14:49 6% ` Max Nikulin
@ 2023-09-08 10:30 0% ` Max Nikulin
2023-09-08 14:42 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-08 10:30 UTC (permalink / raw)
To: emacs-orgmode
On 07/09/2023 21:49, Max Nikulin wrote:
> On 07/09/2023 21:19, Juan Manuel Macías wrote:
>> I think I can introduce some fixes to org-latex-language-alist to
>> restore the removed language codes
>
> I have no idea why in
>
> 393f2f5ae 2012-06-14 12:57:35 +0200 Nicolas Goaziou: org-e-latex: Set
> Babel language according to LANGUAGE keyword
https://list.orgmode.org/871umay444.fsf@med.uni-goettingen.de/
Andreas Leha <andreas.leha@med.uni-goettingen.de> Re: new (LaTeX)
exporter and date formatting. Wed, 23 May 2012 23:33:31 +0200
contains a table that is likely a source for Nicolas' commit:
> this list of LaTeX-babel supported languages from
> http://www.tug.org/texlive/Contents/live/texmf-dist/doc/generic/babel/babel.pdf:
>
> | LaTeX babel | lang symbol |
> |--------------+-------------|
> | austrian | de-at |
> | german | de |
> | germanb | de |
> | ngerman | de-de |
Contemporary babel.pdf contains another table (1.13 ini files)
de-1901 German
de-1996 German
de-AT-1901 Austrian German
de-AT-1996 Austrian German
de-AT Austrian German
de-CH-1901 Swiss High German
de-CH-1996 Swiss High German
de-CH Swiss High German
I am still unsure that de and de-de should be mapped to different babel
language configurations.
^ permalink raw reply [relevance 0%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-08 10:30 0% ` Max Nikulin
@ 2023-09-08 14:42 10% ` Juan Manuel Macías
2023-09-08 19:02 3% ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-08 14:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> I am still unsure that de and de-de should be mapped to different
> babel language configurations.
I think that for practical purposes de and de-de should be treated the
same in both babel and polyglossia. In the new fixed version of
org-babel-language-alist I thought it would be useful to support a list
of languages codes as car for each element, in addition to a simple
string. In such a way:
(("de" "de-de") :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn")
I've had to make some small modifications to
org-latex-guess-babel/polyglossia-language, to get that to work.
:babel-ini-alt refers to an alternative name that is used only if
\babelprovide is present. I'm also adding the :script and :script-tag
properties for each language.
I have done something similar with the case of Chinese Simplified (a new
language that I have added):
(("zh" "zh-cn") :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans")
Between today and tomorrow I will try to send the patch. I saw that
org-latex-language-alist had a few typos as well, some inherited from
the previous lists that were merged.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6)
2023-09-08 14:42 10% ` Juan Manuel Macías
@ 2023-09-08 19:02 3% ` Juan Manuel Macías
2023-09-09 9:11 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-08 19:02 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Max Nikulin, Ihor Radchenko
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
I think that with this patch the possible regressions are removed. I
took the opportunity to add some improvements (the :babel-ini-alt,
:script and :script-tag properties) and correct some errors and typos.
I don't know if it's a valid path to allow the car of each element to
also be a list of languages codes, but I couldn't think of a better
solution for the "de"/"de-de" cases. A similar case is in Chinese
Simplified (new language added), where the possible language codes are
zh and zh-cn, if I'm not wrong.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: 0001-ox-latex.el-Fixes-and-improvements-in-org-latex-lang.patch --]
[-- Type: text/x-patch, Size: 22948 bytes --]
From 52f17bc841241562a52e91159cb1531dbe5684e1 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 8 Sep 2023 19:33:25 +0200
Subject: [PATCH] ox-latex.el: Fixes and improvements in
`org-latex-language-alist'.
* (org-latex-language-alist): Fix a language code (`de-de') removed
when `org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' were merged. To allow language
codes that can have a similar translation in `babel' or `polyglossia'
now in each element of `org-latex-language-alist' car can also be a
list of language codes. New admitted properties: `:babel-ini-alt',
`:script' and `:script-tag'. Add language code for ancient Greek.
Fix Afrikaans (was previously removed). New languages: Chinese
Simplified and Traditional. Correction of some typos, errors and
inaccuracies.
* (org-latex-guess-babel-language): Some necessary modifications.
* (org-latex-guess-polyglossia-language): Some necessary modifications.
---
lisp/ox-latex.el | 208 +++++++++++++++++++++++++++--------------------
1 file changed, 118 insertions(+), 90 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 241ef603a..d6790ea27 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -177,94 +177,102 @@
;;; Internal Variables
(defconst org-latex-language-alist
- '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
- ("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
- ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
- ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
- ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
- ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
- ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton")
- ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
- ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
- ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech")
- ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
- ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish")
- ("de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
- ("de-at" :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
- ("dsb" :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
- ("dv" :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
- ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek")
- ("el-polyton" :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
- ("en" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
- ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
- ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
- ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
- ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
- ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
- ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
- ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
- ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
- ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque")
- ("fa" :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
- ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
- ("fr" :babel "french" :polyglossia "french" :lang-name "French")
- ("fr-ca" :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
- ("fur" :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
- ("ga" :babel "irish" :polyglossia "irish" :lang-name "Irish")
- ("gd" :babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic")
- ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician")
- ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew")
- ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi")
- ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian")
- ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian")
- ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar")
- ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian")
- ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua")
- ("id" :babel-ini-only "bahasai" :polyglossia "bahasai" :lang-name "Bahasai")
- ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic")
- ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian")
- ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada")
- ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin")
- ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin")
- ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin")
- ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin")
- ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao")
- ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian")
- ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian")
- ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam")
- ("mr" :babel-ini-only "maranthi" :polyglossia "maranthi" :lang-name "Maranthi")
- ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål")
- ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch")
- ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk")
- ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian")
- ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan")
- ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish")
- ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese")
- ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges")
- ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges")
- ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh")
- ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian")
- ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian")
- ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit")
- ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak")
- ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene")
- ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian")
- ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian")
- ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish")
- ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac")
- ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil")
- ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu")
- ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai")
- ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen")
- ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish")
- ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian")
- ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu")
- ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese"))
+ '(("af" :babel "afrikaans" :polyglossia "afrikaans" :lang-name "Afrikaans" :script "latin" :script-tag "latn")
+ ("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic" :script "ethiopic" :script-tag "ethi")
+ ("ar" :babel-ini-only "arabic" :polyglossia "arabic" :lang-name "Arabic" :script "arabic" :script-tag "arab")
+ ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian" :script "latin" :script-tag "latn")
+ ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian" :script "cyrillic" :script-tag "cyrl")
+ ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali" :script "bengali" :script-tag: "beng")
+ ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan" :script "tibetan" :script-tag "tib")
+ ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton" :script "latin" :script-tag "latn")
+ ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan" :script "latin" :script-tag "latn")
+ ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic" :script "coptic" :script-tag "copt")
+ ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech" :script "latin" :script-tag "latn")
+ ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh" :script "latin" :script-tag "latn")
+ ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish" :script "latin" :script-tag "latn")
+ (("de" "de-de") :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn")
+ ("de-at" :babel "naustrian" :babel-ini-alt "german-austria" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German" :script "latin" :script-tag "latn")
+ ("dsb" :babel "lowersorbian" :babel-ini-alt "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian" :script "latin" :script-tag "latn")
+ ("dv" :polyglossia "divehi" :lang-name "Dhivehi" :script "latin" :script-tag "latn")
+ ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek" :script "greek" :script-tag "grek")
+ ("el-polyton" :babel "polutonikogreek" :babel-ini-alt "polytonicgreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek" :script "greek" :script-tag "grek")
+ ("grc" :babel "greek.ancient" :babel-ini-alt "ancientgreek" :polyglossia "greek" :polyglossia-variant "ancient" :lang-name "Ancient Greek" :script "greek" :script-tag "grek")
+ ("en" :babel "english" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-ca" :babel "canadian" :polyglossia "english" :polyglossia-variant "canadian" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :script-tag "latn")
+ ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto" :script "latin" :script-tag "latn")
+ ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish" :script "latin" :script-tag "latn")
+ ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish" :script "latin" :script-tag "latn")
+ ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian" :script "latin" :script-tag "latn")
+ ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque" :script "latin" :script-tag "latn")
+ ("fa" :babel "persian" :polyglossia "persian" :lang-name "Persian" :script "arabic" :script-tag "arab")
+ ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish" :script "latin" :script-tag "latn")
+ ("fr" :babel "french" :polyglossia "french" :lang-name "French" :script "latin" :script-tag "latn")
+ ("fr-ca" :babel "canadien" :babel-ini-alt "canadian" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French" :script "latin" :script-tag "latn")
+ ("fur" :babel "friulian" :polyglossia "friulian" :lang-name "Friulian" :script "latin" :script-tag "latn")
+ ("ga" :babel "irish" :polyglossia "gaelic" :polyglossia-variant "irish" :lang-name "Irish Gaelic" :script "latin" :script-tag "latn")
+ ("gd" :babel "scottish" :polyglossia "gaelic" :polyglossia-variant "scottish" :lang-name "Scottish Gaelic" :script "latin" :script-tag "latn")
+ ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician" :script "latin" :script-tag "latn")
+ ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew" :script "hebrew" :script-tag "hebr")
+ ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi" :script "devanagari" :script-tag "deva")
+ ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian" :script "latin" :script-tag "latn")
+ ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian" :script "latin" :script-tag "latn")
+ ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar" :script "latin" :script-tag "latn")
+ ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian" :script "armenian" :script-tag "armn")
+ ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua" :script "latin" :script-tag "latn")
+ ("id" :babel "indonesian" :polyglossia "malay" :polyglossia-variant "indonesian" :lang-name "Indonesian" :script "latin" :script-tag "latn")
+ ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic" :script "latin" :script-tag "latn")
+ ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian" :script "latin" :script-tag "latn")
+ ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada" :script "kannada" :script-tag "knda")
+ ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin" :script "latin" :script-tag "latn")
+ ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin" :script "latin" :script-tag "latn")
+ ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin" :script "latin" :script-tag "latn")
+ ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin" :script "latin" :script-tag "latn")
+ ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao" :script "lao" :script-tag "lao")
+ ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian" :script "latin" :script-tag "latn")
+ ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian" :script "latin" :script-tag "latn")
+ ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam" :script "malayalam" :script-tag "mlym")
+ ("mr" :babel-ini-only "marathi" :polyglossia "marathi" :lang-name "Marathi" :script "devanagari" :script-tag "deva")
+ ("ms" :babel "malay" :polyglossia "malay" :polyglossia-variant "malaysian" :lang-name "Malay" :script "latin" :script-tag "latn")
+ ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål" :script "latin" :script-tag "latn")
+ ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch" :script "latin" :script-tag "latn")
+ ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk" :script "latin" :script-tag "latn")
+ ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian" :script "latin" :script-tag "latn")
+ ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan" :script "latin" :script-tag "latn")
+ ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish" :script "latin" :script-tag "latn")
+ ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese" :script "latin" :script-tag "latn")
+ ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges" :script "latin" :script-tag "latn")
+ ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges" :script "latin" :script-tag "latn")
+ ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh" :script "latin" :script-tag "latn")
+ ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian" :script "latin" :script-tag "latn")
+ ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian" :script "cyrillic" :script-tag "cyrl")
+ ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit" :script "devanagari" :script-tag "deva")
+ ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak" :script "latin" :script-tag "latn")
+ ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene" :script "latin" :script-tag "latn")
+ ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian" :script "latin" :script-tag "latn")
+ ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian" :script "latin" :script-tag "latn")
+ ("sr-cyrl" :babel-ini-only "serbian-cyrl" :polyglossia "serbian" :lang-name "Serbian" :script "cyrillic" :script-tag "cyrl")
+ ("sr-latn" :babel-ini-only "serbian-latin" :polyglossia "serbian" :lang-name "Serbian" :script "latin" :script-tag "latn")
+ ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish" :script "latin" :script-tag "latn")
+ ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac" :script "syriac" :script-tag "syrc")
+ ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil" :script "tamil" :script-tag "taml")
+ ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu" :script "telugu" :script-tag "telu")
+ ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai" :script "thai" :script-tag "thai")
+ ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen" :script "latin" :script-tag "latn")
+ ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish" :script "latin" :script-tag "latn")
+ ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian" :script "cyrillic" :script-tag "cyrl")
+ ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu" :script "arabic" :script-tag "arab")
+ ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese" :script "latin" :script-tag "latn")
+ (("zh" "zh-cn") :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans")
+ ("zh-tw" :babel-ini-only "chinese-traditional" :polyglossia "chinese" :polyglossia-variant "traditional" :lang-name "Chinese Traditional" :script "hant" :script-tag "hant"))
"Alist between language code and its properties for LaTeX export.
-In each element of the list car is always the code of the
-language and cdr is a property list. Valid keywords for this
-list can be:
+In each element of the list car is always the language code or a
+list of languages codes and cdr is a property list. Valid
+keywords for this list can be:
- `:babel' the name of the language loaded by the Babel LaTeX package
@@ -275,9 +283,17 @@ list can be:
exclusively through the new ini files method. See
`http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf'
+- `:babel-ini-alt' an alternative language name when it is loaded
+ using ini files
+
- `:polyglossia-variant' the language variant loaded by Polyglossia
-- `:lang-name' the actual name of the language.")
+- `:lang-name' the actual name of the language
+
+- `:script' the script name
+
+- `:script-tag' the script otf tag.")
+
(defconst org-latex-line-break-safe "\\\\[0pt]"
"Linebreak protecting the following [...].
@@ -1657,9 +1673,15 @@ already loaded.
Return the new header."
(let* ((language-code (plist-get info :language))
(plist (cdr
- (assoc language-code org-latex-language-alist)))
+ (cl-assoc-if (lambda (x)
+ (or (and (stringp x)
+ (string= language-code x))
+ (and (listp x)
+ (member language-code x))))
+ org-latex-language-alist)))
(language (plist-get plist :babel))
(language-ini-only (plist-get plist :babel-ini-only))
+ (language-ini-alt (plist-get plist :babel-ini-alt))
;; If no language is set, or Babel package is not loaded, or
;; LANGUAGE keyword value is a language served by Babel
;; exclusively through ini files, return HEADER as-is.
@@ -1691,7 +1713,8 @@ Return the new header."
(replace-regexp-in-string (format
"\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
(format "\\1\\2%s}"
- (or language language-ini-only))
+ (if language-ini-alt language-ini-alt
+ (or language language-ini-only)))
header t)
header)))))
@@ -1736,7 +1759,12 @@ Return the new header."
(mapconcat
(lambda (l)
(let* ((plist (cdr
- (assoc language org-latex-language-alist)))
+ (cl-assoc-if (lambda (x)
+ (or (and (stringp x)
+ (string= language x))
+ (and (listp x)
+ (member language x))))
+ org-latex-language-alist)))
(polyglossia-variant (plist-get plist :polyglossia-variant))
(polyglossia-lang (plist-get plist :polyglossia))
(l (if (equal l language)
--
2.42.0
^ permalink raw reply related [relevance 3%]
* Re: [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6)
2023-09-08 19:02 3% ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Juan Manuel Macías
@ 2023-09-09 9:11 6% ` Ihor Radchenko
2023-09-09 10:36 12% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2023-09-09 9:11 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think that with this patch the possible regressions are removed. I
> took the opportunity to add some improvements (the :babel-ini-alt,
> :script and :script-tag properties) and correct some errors and typos.
>
> I don't know if it's a valid path to allow the car of each element to
> also be a list of languages codes, but I couldn't think of a better
> solution for the "de"/"de-de" cases. A similar case is in Chinese
> Simplified (new language added), where the possible language codes are
> zh and zh-cn, if I'm not wrong.
I am not sure if making a breaking change to public constant is the best
approach.
What about simply adding an extra entry:
("de" ....)
("de-de" <copy of "de" property list>)
?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-09 9:11 6% ` Ihor Radchenko
@ 2023-09-09 10:36 12% ` Juan Manuel Macías
2023-09-09 11:33 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-09 10:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Max Nikulin
Ihor Radchenko writes:
>> I don't know if it's a valid path to allow the car of each element to
>> also be a list of languages codes, but I couldn't think of a better
>> solution for the "de"/"de-de" cases. A similar case is in Chinese
>> Simplified (new language added), where the possible language codes are
>> zh and zh-cn, if I'm not wrong.
>
> I am not sure if making a breaking change to public constant is the best
> approach.
> What about simply adding an extra entry:
> ("de" ....)
> ("de-de" <copy of "de" property list>)
> ?
At first I had done it with extra entries, but I was wondering if there
wasn't a more "economical" way... If you don't mind having extra entries
with identical plists, then I do it that way. After all, there are only
two cases (Chinese and German).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-09 10:36 12% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
@ 2023-09-09 11:33 6% ` Ihor Radchenko
2023-09-09 23:59 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-09 11:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I am not sure if making a breaking change to public constant is the best
>> approach.
>> What about simply adding an extra entry:
>> ("de" ....)
>> ("de-de" <copy of "de" property list>)
>> ?
>
> At first I had done it with extra entries, but I was wondering if there
> wasn't a more "economical" way... If you don't mind having extra entries
> with identical plists, then I do it that way. After all, there are only
> two cases (Chinese and German).
I am thinking about something like
(let ((de-plist '(...)))
`(...
("de" ,@de-plist)
("de-de" ,@de-plist)
...))
This is copy-paste-proof and does not require breaking changes in the
value structure.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-09 11:33 6% ` Ihor Radchenko
@ 2023-09-09 23:59 11% ` Juan Manuel Macías
2023-09-10 7:55 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-09 23:59 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Max Nikulin
Ihor Radchenko writes:
> I am thinking about something like
>
> (let ((de-plist '(...)))
> `(...
> ("de" ,@de-plist)
> ("de-de" ,@de-plist)
> ...))
>
> This is copy-paste-proof and does not require breaking changes in the
> value structure.
I like the idea because it avoids errors, but I don't know if
it's worth it, there being only two cases (at the moment). This other
possibility occurred to me, just to make it easier to read and not have
to navigate to the list of variables:
(let* ((basic-code)
(shared-plist (lambda (&rest plist)
(setq basic-code plist))))
`(...
("de" ,(funcall shared-plist :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn"))
("de-de" ,@basic-code)
...
("zh" ,(funcall shared-plist :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans"))
("zh-cn" ,@basic-code)))
Likewise, there being two cases (even in the case of Chinese you could
perfectly omit zh-cn, because it is a new language and there is no
danger of regression), I would say that it is not worth complicating the
code so much.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-09 23:59 11% ` Juan Manuel Macías
@ 2023-09-10 7:55 5% ` Ihor Radchenko
2023-09-10 11:06 3% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-10 7:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> (let ((de-plist '(...)))
>> `(...
>> ("de" ,@de-plist)
>> ("de-de" ,@de-plist)
>> ...))
>>
>> This is copy-paste-proof and does not require breaking changes in the
>> value structure.
>
> I like the idea because it avoids errors, but I don't know if
> it's worth it, there being only two cases (at the moment).
It is not that complex, really. I suggested the above approach because:
1. It is easy to read - clearly, ,@de-plist and ,@de-plist are the same
thing.
2. If we ever need to change de-plist, we should only do it in a single
place.
> ... This other
> possibility occurred to me, just to make it easier to read and not have
> to navigate to the list of variables:
>
> (let* ((basic-code)
> (shared-plist (lambda (&rest plist)
> (setq basic-code plist))))
> `(...
> ("de" ,(funcall shared-plist :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn"))
> ("de-de" ,@basic-code)
> ...
> ("zh" ,(funcall shared-plist :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans"))
> ("zh-cn" ,@basic-code)))
This is less readable compared to having ",@de-plist" - ",@de-plist".
One would need to put extra effort to understand the equality of
(funcall shared-plist ...) and ,@basic-code.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-10 7:55 5% ` Ihor Radchenko
@ 2023-09-10 11:06 3% ` Juan Manuel Macías
2023-09-10 13:36 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-10 11:06 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Max Nikulin
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
Ihor Radchenko writes:
> It is not that complex, really. I suggested the above approach because:
> 1. It is easy to read - clearly, ,@de-plist and ,@de-plist are the same
> thing.
> 2. If we ever need to change de-plist, we should only do it in a single
> place.
The fact of avoiding copy/paste is already an advantage. New patch
attached with your suggestions. I have simply modified the variable name
a little. de-plist may seem a bit confusing, because there is also de-at
(Austrian German). I have set de-default-plist, since for babel and
polyglossia German (de) and German from Germany (de-de) are the default
variant. The same with the case of the Chinese (Chinese = Chinese
Simplified).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: 0001-ox-latex.el-Fixes-and-improvements-in-org-latex-lang.patch --]
[-- Type: text/x-patch, Size: 22021 bytes --]
From 73057fc06990f861468c397c94b7076d025acbc8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 8 Sep 2023 19:33:25 +0200
Subject: [PATCH] ox-latex.el: Fixes and improvements in
`org-latex-language-alist'.
* (org-latex-language-alist): Fix a language code (`de-de') removed
when `org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' were merged. To allow language
codes that can have a similar translation in `babel' or `polyglossia'
now in each element of `org-latex-language-alist' car can also be a
list of language codes. New admitted properties: `:babel-ini-alt',
`:script' and `:script-tag'. Add language code for ancient Greek.
Fix Afrikaans (was previously removed). New languages: Chinese
Simplified and Traditional. Correction of some typos, errors and
inaccuracies. `let' bindings suggested by Ihor Radchenko.
* (org-latex-guess-babel-language): Some necessary modifications.
---
lisp/ox-latex.el | 197 ++++++++++++++++++++++++++---------------------
1 file changed, 109 insertions(+), 88 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 241ef603a..14105c7cc 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -177,94 +177,105 @@
;;; Internal Variables
(defconst org-latex-language-alist
- '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
- ("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
- ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
- ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
- ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
- ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
- ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton")
- ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
- ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
- ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech")
- ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
- ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish")
- ("de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
- ("de-at" :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
- ("dsb" :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
- ("dv" :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
- ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek")
- ("el-polyton" :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
- ("en" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
- ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
- ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
- ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
- ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
- ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
- ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
- ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
- ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
- ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque")
- ("fa" :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
- ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
- ("fr" :babel "french" :polyglossia "french" :lang-name "French")
- ("fr-ca" :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
- ("fur" :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
- ("ga" :babel "irish" :polyglossia "irish" :lang-name "Irish")
- ("gd" :babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic")
- ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician")
- ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew")
- ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi")
- ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian")
- ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian")
- ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar")
- ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian")
- ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua")
- ("id" :babel-ini-only "bahasai" :polyglossia "bahasai" :lang-name "Bahasai")
- ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic")
- ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian")
- ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada")
- ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin")
- ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin")
- ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin")
- ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin")
- ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao")
- ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian")
- ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian")
- ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam")
- ("mr" :babel-ini-only "maranthi" :polyglossia "maranthi" :lang-name "Maranthi")
- ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål")
- ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch")
- ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk")
- ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian")
- ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan")
- ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish")
- ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese")
- ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges")
- ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges")
- ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh")
- ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian")
- ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian")
- ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit")
- ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak")
- ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene")
- ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian")
- ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian")
- ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish")
- ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac")
- ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil")
- ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu")
- ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai")
- ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen")
- ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish")
- ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian")
- ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu")
- ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese"))
+ (let ((de-default-plist '(:babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn"))
+ (zh-default-plist '(:babel-ini-only "chinese" :polyglossia "chinese" :polyglossia-variant "simplified" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans")))
+ `(("af" :babel "afrikaans" :polyglossia "afrikaans" :lang-name "Afrikaans" :script "latin" :script-tag "latn")
+ ("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic" :script "ethiopic" :script-tag "ethi")
+ ("ar" :babel-ini-only "arabic" :polyglossia "arabic" :lang-name "Arabic" :script "arabic" :script-tag "arab")
+ ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian" :script "latin" :script-tag "latn")
+ ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian" :script "cyrillic" :script-tag "cyrl")
+ ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali" :script "bengali" :script-tag: "beng")
+ ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan" :script "tibetan" :script-tag "tib")
+ ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton" :script "latin" :script-tag "latn")
+ ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan" :script "latin" :script-tag "latn")
+ ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic" :script "coptic" :script-tag "copt")
+ ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech" :script "latin" :script-tag "latn")
+ ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh" :script "latin" :script-tag "latn")
+ ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish" :script "latin" :script-tag "latn")
+ ("de" ,@de-default-plist)
+ ("de-de" ,@de-default-plist)
+ ("de-at" :babel "naustrian" :babel-ini-alt "german-austria" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German" :script "latin" :script-tag "latn")
+ ("dsb" :babel "lowersorbian" :babel-ini-alt "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian" :script "latin" :script-tag "latn")
+ ("dv" :polyglossia "divehi" :lang-name "Dhivehi" :script "latin" :script-tag "latn")
+ ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek" :script "greek" :script-tag "grek")
+ ("el-polyton" :babel "polutonikogreek" :babel-ini-alt "polytonicgreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek" :script "greek" :script-tag "grek")
+ ("grc" :babel "greek.ancient" :babel-ini-alt "ancientgreek" :polyglossia "greek" :polyglossia-variant "ancient" :lang-name "Ancient Greek" :script "greek" :script-tag "grek")
+ ("en" :babel "english" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-ca" :babel "canadian" :polyglossia "english" :polyglossia-variant "canadian" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :script-tag "latn")
+ ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto" :script "latin" :script-tag "latn")
+ ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish" :script "latin" :script-tag "latn")
+ ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish" :script "latin" :script-tag "latn")
+ ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian" :script "latin" :script-tag "latn")
+ ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque" :script "latin" :script-tag "latn")
+ ("fa" :babel "persian" :polyglossia "persian" :lang-name "Persian" :script "arabic" :script-tag "arab")
+ ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish" :script "latin" :script-tag "latn")
+ ("fr" :babel "french" :polyglossia "french" :lang-name "French" :script "latin" :script-tag "latn")
+ ("fr-ca" :babel "canadien" :babel-ini-alt "canadian" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French" :script "latin" :script-tag "latn")
+ ("fur" :babel "friulian" :polyglossia "friulian" :lang-name "Friulian" :script "latin" :script-tag "latn")
+ ("ga" :babel "irish" :polyglossia "gaelic" :polyglossia-variant "irish" :lang-name "Irish Gaelic" :script "latin" :script-tag "latn")
+ ("gd" :babel "scottish" :polyglossia "gaelic" :polyglossia-variant "scottish" :lang-name "Scottish Gaelic" :script "latin" :script-tag "latn")
+ ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician" :script "latin" :script-tag "latn")
+ ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew" :script "hebrew" :script-tag "hebr")
+ ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi" :script "devanagari" :script-tag "deva")
+ ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian" :script "latin" :script-tag "latn")
+ ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian" :script "latin" :script-tag "latn")
+ ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar" :script "latin" :script-tag "latn")
+ ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian" :script "armenian" :script-tag "armn")
+ ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua" :script "latin" :script-tag "latn")
+ ("id" :babel "indonesian" :polyglossia "malay" :polyglossia-variant "indonesian" :lang-name "Indonesian" :script "latin" :script-tag "latn")
+ ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic" :script "latin" :script-tag "latn")
+ ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian" :script "latin" :script-tag "latn")
+ ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada" :script "kannada" :script-tag "knda")
+ ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin" :script "latin" :script-tag "latn")
+ ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin" :script "latin" :script-tag "latn")
+ ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin" :script "latin" :script-tag "latn")
+ ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin" :script "latin" :script-tag "latn")
+ ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao" :script "lao" :script-tag "lao")
+ ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian" :script "latin" :script-tag "latn")
+ ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian" :script "latin" :script-tag "latn")
+ ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam" :script "malayalam" :script-tag "mlym")
+ ("mr" :babel-ini-only "marathi" :polyglossia "marathi" :lang-name "Marathi" :script "devanagari" :script-tag "deva")
+ ("ms" :babel "malay" :polyglossia "malay" :polyglossia-variant "malaysian" :lang-name "Malay" :script "latin" :script-tag "latn")
+ ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål" :script "latin" :script-tag "latn")
+ ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch" :script "latin" :script-tag "latn")
+ ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk" :script "latin" :script-tag "latn")
+ ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian" :script "latin" :script-tag "latn")
+ ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan" :script "latin" :script-tag "latn")
+ ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish" :script "latin" :script-tag "latn")
+ ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese" :script "latin" :script-tag "latn")
+ ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges" :script "latin" :script-tag "latn")
+ ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges" :script "latin" :script-tag "latn")
+ ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh" :script "latin" :script-tag "latn")
+ ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian" :script "latin" :script-tag "latn")
+ ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian" :script "cyrillic" :script-tag "cyrl")
+ ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit" :script "devanagari" :script-tag "deva")
+ ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak" :script "latin" :script-tag "latn")
+ ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene" :script "latin" :script-tag "latn")
+ ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian" :script "latin" :script-tag "latn")
+ ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian" :script "latin" :script-tag "latn")
+ ("sr-cyrl" :babel-ini-only "serbian-cyrl" :polyglossia "serbian" :lang-name "Serbian" :script "cyrillic" :script-tag "cyrl")
+ ("sr-latn" :babel-ini-only "serbian-latin" :polyglossia "serbian" :lang-name "Serbian" :script "latin" :script-tag "latn")
+ ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish" :script "latin" :script-tag "latn")
+ ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac" :script "syriac" :script-tag "syrc")
+ ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil" :script "tamil" :script-tag "taml")
+ ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu" :script "telugu" :script-tag "telu")
+ ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai" :script "thai" :script-tag "thai")
+ ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen" :script "latin" :script-tag "latn")
+ ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish" :script "latin" :script-tag "latn")
+ ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian" :script "cyrillic" :script-tag "cyrl")
+ ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu" :script "arabic" :script-tag "arab")
+ ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese" :script "latin" :script-tag "latn")
+ ("zh" ,@zh-default-plist)
+ ("zh-cn" ,@zh-default-plist)
+ ("zh-tw" :babel-ini-only "chinese-traditional" :polyglossia "chinese" :polyglossia-variant "traditional" :lang-name "Chinese Traditional" :script "hant" :script-tag "hant")))
"Alist between language code and its properties for LaTeX export.
-In each element of the list car is always the code of the
-language and cdr is a property list. Valid keywords for this
-list can be:
+In each element of the list car is always the language code and
+cdr is a property list. Valid keywords for this list can be:
- `:babel' the name of the language loaded by the Babel LaTeX package
@@ -275,9 +286,17 @@ list can be:
exclusively through the new ini files method. See
`http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf'
+- `:babel-ini-alt' an alternative language name when it is loaded
+ using ini files
+
- `:polyglossia-variant' the language variant loaded by Polyglossia
-- `:lang-name' the actual name of the language.")
+- `:lang-name' the actual name of the language
+
+- `:script' the script name
+
+- `:script-tag' the script otf tag.")
+
(defconst org-latex-line-break-safe "\\\\[0pt]"
"Linebreak protecting the following [...].
@@ -1660,6 +1679,7 @@ Return the new header."
(assoc language-code org-latex-language-alist)))
(language (plist-get plist :babel))
(language-ini-only (plist-get plist :babel-ini-only))
+ (language-ini-alt (plist-get plist :babel-ini-alt))
;; If no language is set, or Babel package is not loaded, or
;; LANGUAGE keyword value is a language served by Babel
;; exclusively through ini files, return HEADER as-is.
@@ -1691,7 +1711,8 @@ Return the new header."
(replace-regexp-in-string (format
"\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
(format "\\1\\2%s}"
- (or language language-ini-only))
+ (if language-ini-alt language-ini-alt
+ (or language language-ini-only)))
header t)
header)))))
--
2.42.0
^ permalink raw reply related [relevance 3%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-10 11:06 3% ` Juan Manuel Macías
@ 2023-09-10 13:36 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-10 13:36 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The fact of avoiding copy/paste is already an advantage. New patch
> attached with your suggestions.
Thanks!
Applied, onto main.
I amended the commit message, removing the statement about list of
language identifiers and adding a link to this discussion.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=893c5d085
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
@ 2023-09-10 21:15 10% ` Juan Manuel Macías
2023-09-11 8:32 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-10 21:15 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> For context, I plan to provide a global language-identifier alist that
> will link human-readable language names to abbreviations like "de",
> "de-de", etc. These abbreviations are not unique to LaTeX, but also used
> elsewhere, so there is no guarantee that babel .ini files will always
> use a consistent set of language abbreviations.
Is the code you're working on in a public repository, to keep an eye on?
As I mentioned in previous messages, that seems like a great improvement
to me. I think it was not a happy decision at the time to use languages
codes to declare the language of the document in Org. Language codes can
be useful at a low level (although they can also lead to confusion), but
I think that for a user level it is more practical to use human-readable
names, as is done in babel or polyglossia, and in general, any user
interface outside of LaTeX. Although babel also allows language codes as
a value for some \babelprovide options (for example, I can define a new
"virtual" language, importing the Greek captions:
\babelprovide[captions=el]{mylanguage}).
In case it helps you, on page. 19 of the Babel manual there is an
exhaustive list of all the languages codes, and on p. 22 a list of
supported (human readable) language names for loading ini files. The
language names of the old ldf files are on p. 49:
https://CTAN/macros/latex/required/babel/base/babel.pdf
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-10 21:15 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
@ 2023-09-11 8:32 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-11 8:32 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> For context, I plan to provide a global language-identifier alist that
>> will link human-readable language names to abbreviations like "de",
>> "de-de", etc. These abbreviations are not unique to LaTeX, but also used
>> elsewhere, so there is no guarantee that babel .ini files will always
>> use a consistent set of language abbreviations.
>
> Is the code you're working on in a public repository, to keep an eye
> on?
Not really. The story starts from the previous discussion of
translations in your French quote patch:
https://list.orgmode.org/orgmode/87pm3e6qx3.fsf@localhost/
I started writing it and realized that the current situation with all
the translations scattered all over the place (at least, ox libraries,
column view, and org-clock) is not ideal. So, I plan to factor out all
the translations into a separate file (say, org-translate). That file
will also define common interfaces to work with language codes and
translating phrases.
> As I mentioned in previous messages, that seems like a great improvement
> to me. I think it was not a happy decision at the time to use languages
> codes to declare the language of the document in Org. Language codes can
> be useful at a low level (although they can also lead to confusion), but
> I think that for a user level it is more practical to use human-readable
> names, as is done in babel or polyglossia, and in general, any user
> interface outside of LaTeX. Although babel also allows language codes as
> a value for some \babelprovide options (for example, I can define a new
> "virtual" language, importing the Greek captions:
> \babelprovide[captions=el]{mylanguage}).
That's very LaTeX-specific and will be limited to LaTeX export.
I do not see any problem since we have to support languages defined by
language code anyway, for backwards compatibility.
> In case it helps you, on page. 19 of the Babel manual there is an
> exhaustive list of all the languages codes, and on p. 22 a list of
> supported (human readable) language names for loading ini files. The
> language names of the old ldf files are on p. 49:
>
> https://CTAN/macros/latex/required/babel/base/babel.pdf
Thanks!
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
@ 2023-09-12 18:12 10% ` Juan Manuel Macías
2023-09-15 9:54 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-12 18:12 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
>>> Every piece of code accessing this public constant must implement
>>> fallback from e.g. "de-ch" (or de_CH) to "de". Or to "en" for an
>>> unsupported language.
>> Not necessarily. I mostly thought about some unconventional code
>> that
>> uses the constant for some reason unexpected to us. We do not want to
>> break that.
>
> My point is that direct usage of `org-latex-language-alist' should be
> discouraged.
I understand that org-latex-language-alist is a temporary patch waiting
for something better, and is very dependent on
org-latex-guess-babel-language and
org-latex-guess-polyglossia-language[1], two functions that (IMHO)
should be made obsolete in the future. Keep in mind that the old
org-latex-babel-language-alist was more focused on the old babel ldf
files, which is a limited number of languages. Polyglossia also has a
rather limited number of supported languages. The ini files system is
more extensive and more flexible. One can even define new "virtual"
languages using \babelprovide, or write new custom ini files. With this
scenario a closed list like org-latex-language-alist doesn't make much
sense. I actually think that there would be no need for any ad hoc list
of this type for latex, and everything should be delegated to a global
language name translation system like the one Ihor is developing. I
think that would be the first stone to build native Org multilingual
support.
[1] I think also that in this function there was an unhappy decision:
using a syntax that is not from polyglossia but from babel leaves the
user with little freedom of action, since polyglossia has more 'keyval'
options, not only language variants. For example, this (real polyglossia
code):
\usepackage{polyglossia}
\setmainlanguage{spanish}
\setotherlanguage[numerals=arabic]{chinese}
cannot be translated from (fake polyglossia code):
#+language: es
#+LaTeX_Header: \usepackage[chinese,AUTO]{polyglossia}
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-12 18:12 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
@ 2023-09-15 9:54 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-15 9:54 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> [1] I think also that in this function there was an unhappy decision:
> using a syntax that is not from polyglossia but from babel leaves the
> user with little freedom of action, since polyglossia has more 'keyval'
> options, not only language variants. For example, this (real polyglossia
> code):
>
> \usepackage{polyglossia}
> \setmainlanguage{spanish}
> \setotherlanguage[numerals=arabic]{chinese}
>
> cannot be translated from (fake polyglossia code):
>
> #+language: es
> #+LaTeX_Header: \usepackage[chinese,AUTO]{polyglossia}
Since we are up to extending #+language keyword in future, may as well
allow LANG [:key val ...] values.
I expressed similar idea in https://list.orgmode.org/orgmode/87fsc05hkl.fsf@localhost/
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-09-16 18:00 10% Juan Manuel Macías
2023-09-17 10:02 6% ` Ihor Radchenko
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-16 18:00 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
Rationale for this patch: in certain cases, in a LaTeX document, it is
necessary to add code before the class declaration (\documentclass...).
For example, commands like \PassOptionsToPackage, \DocumentMetadata{ },
etc.; or certain packages that should be loaded first using
\RequirePackage{}; and other miscellaneous cases[1]. I think that by
defining a new keyword `latex_pre_header', which behaves the same as
latex_header but concatenated before the class, these situations can be
resolved from Org.
[1] A longer example to export to a pdf that has pdf-x compliance, with
the pdfx package:
\providecommand{\pdfxopts}{x-1a}
\begin{filecontents*}{\jobname.xmpdata}
\Title{Some Title}
\Author{Author}
\Language{es-ES}
\Keywords{keywords}
\Publisher{publisher}
\end{filecontents*}
\documentclass{...
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-latex-Add-LATEX_PRE_HEADER-keyword.patch --]
[-- Type: text/x-patch, Size: 1944 bytes --]
From ac6b743a4489f7bc8ab1cdae7ffd3b36e5f3c1d2 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 16 Sep 2023 19:22:39 +0200
Subject: [PATCH] lisp/ox-latex.el (latex): Add `LATEX_PRE_HEADER' keyword
* (org-latex-make-preamble): In some cases it is necessary to add code
before the `\documentclass' line. `LATEX_PRE_HEADER' behaves the same as
`LATEX_HEADER', except that it is concatenated before the class.
---
lisp/ox-latex.el | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 14105c7cc..5e97b8b3d 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -124,6 +124,7 @@
(:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t)
(:latex-header "LATEX_HEADER" nil nil newline)
(:latex-header-extra "LATEX_HEADER_EXTRA" nil nil newline)
+ (:latex-pre-header "LATEX_PRE_HEADER" nil nil newline)
(:description "DESCRIPTION" nil nil parse)
(:keywords "KEYWORDS" nil nil parse)
(:subtitle "SUBTITLE" nil nil parse)
@@ -1984,13 +1985,18 @@ specified in `org-latex-default-packages-alist' or
(replace-regexp-in-string
"^[ \t]*\\\\documentclass\\(\\(\\[[^]]*\\]\\)?\\)"
class-options header t nil 1))))
- (user-error "Unknown LaTeX class `%s'" class))))
+ (user-error "Unknown LaTeX class `%s'" class)))
+ (pre-header (mapconcat
+ #'org-element-normalize-string
+ (list (plist-get info :latex-pre-header) ""))))
(org-latex-guess-polyglossia-language
(org-latex-guess-babel-language
(org-latex-guess-inputenc
(org-element-normalize-string
(org-splice-latex-header
- class-template
+ (if pre-header
+ (format "%s\n%s" pre-header class-template)
+ class-template)
(org-latex--remove-packages org-latex-default-packages-alist info)
(org-latex--remove-packages org-latex-packages-alist info)
snippet?
--
2.42.0
^ permalink raw reply related [relevance 10%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-16 18:00 10% [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
@ 2023-09-17 10:02 6% ` Ihor Radchenko
2023-09-17 17:23 6% ` Timothy
2023-09-22 16:38 5% ` Max Nikulin
2 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-17 10:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Rationale for this patch: in certain cases, in a LaTeX document, it is
> necessary to add code before the class declaration (\documentclass...).
> For example, commands like \PassOptionsToPackage, \DocumentMetadata{ },
> etc.; or certain packages that should be loaded first using
> \RequirePackage{}; and other miscellaneous cases[1]. I think that by
> defining a new keyword `latex_pre_header', which behaves the same as
> latex_header but concatenated before the class, these situations can be
> resolved from Org.
Thanks for the patch!
It looks reasonable.
> https://gnutas.juanmanuelmacias.com
> From ac6b743a4489f7bc8ab1cdae7ffd3b36e5f3c1d2 Mon Sep 17 00:00:00 2001
> From: Juan Manuel Macias <maciaschain@posteo.net>
> Date: Sat, 16 Sep 2023 19:22:39 +0200
> Subject: [PATCH] lisp/ox-latex.el (latex): Add `LATEX_PRE_HEADER' keyword
>
> * (org-latex-make-preamble): In some cases it is necessary to add code
> before the `\documentclass' line. `LATEX_PRE_HEADER' behaves the same as
> `LATEX_HEADER', except that it is concatenated before the class.
I think that you do not need to `quote' LATEX_PRE_HEADER - it is not a
lisp symbol.
Also, the new keyword should be documented in the manual.
> - (user-error "Unknown LaTeX class `%s'" class))))
> + (user-error "Unknown LaTeX class `%s'" class)))
> + (pre-header (mapconcat
> + #'org-element-normalize-string
> + (list (plist-get info :latex-pre-header) ""))))
mapconcat is redundant here.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-16 18:00 10% [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
2023-09-17 10:02 6% ` Ihor Radchenko
@ 2023-09-17 17:23 6% ` Timothy
2023-09-22 16:38 5% ` Max Nikulin
2 siblings, 0 replies; 200+ results
From: Timothy @ 2023-09-17 17:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
Hi Juan,
I’d rather not have this merged at this stage, as I think it may be redundant
once my conditional/generated export work makes its way into Org (next few
months?).
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Rationale for this patch: in certain cases, in a LaTeX document, it is
> necessary to add code before the class declaration (\documentclass…).
> For example, commands like \PassOptionsToPackage, \DocumentMetadata{ },
> etc.; or certain packages that should be loaded first using
> \RequirePackage{}; and other miscellaneous cases[1]. I think that by
> defining a new keyword `latex_pre_header’, which behaves the same as
> latex_header but concatenated before the class, these situations can be
> resolved from Org.
>
> [1] A longer example to export to a pdf that has pdf-x compliance, with
> the pdfx package:
>
> \providecommand{\pdfxopts}{x-1a}
> \begin{filecontents*}{\jobname.xmpdata}
> \Title{Some Title}
> \Author{Author}
> \Language{es-ES}
> \Keywords{keywords}
> \Publisher{publisher}
> \end{filecontents*}
> \documentclass{…
All the best,
Timothy
--
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.
^ permalink raw reply [relevance 6%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-05 10:44 5% ` Ihor Radchenko
@ 2023-09-20 14:03 5% ` Juan Manuel Macías
2023-09-21 9:00 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-20 14:03 UTC (permalink / raw)
To: orgmode; +Cc: Ihor Radchenko, Timothy, Max Nikulin
Some new information about Babel that may be of interest to the topic of
this thread.
I have received an email from Javier Bezos (whom I know from the
Spanish-speaking TeX users' mailing list), who is the current babel
mantainer, as well as the person responsible for all the improvements
and new features of the package. Although he is not currently an
Emacs/Org user, he has been following this thread with great interest,
so I am transmitting here, with his permission, some interesting
comments from him:
#+begin_quote
[...] I am very interested in all possible improvements in babel so that
it integrates as best as possible with automatically generated files.
Among them are the possibility of using BCP47 codes or using a language
(at least basically) without the need for a prior declaration. These are
things already done, but there are others that can still be improved.
[...] any suggestion for improvement is very welcome [...]
Among the things I agree on is name issue. I am unifying the dice in the
CLDR as much as possible, and already, in fact, it is very advanced:
https://latex3.github.io/babel/guides/locale-naming.html
[...]
The ini files contain information that is not actually used by babel,
but that could be useful in other packages or even external
applications. One of them is the name of the language in English and in
the vernacular form, as they are in the Unicode CLDR. As I explain in
the link I gave you, the purpose is that the babel name is based on the
CLDR name with mechanical changes. Anyway, CLDR names are also included
in the ini files, to establish correspondences more easily.
#+end_quote
^ permalink raw reply [relevance 5%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
@ 2023-09-21 8:24 13% ` Juan Manuel Macías
2023-09-21 13:46 5% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 8:24 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Hi,
I would recommend that you use babel, as it is the official package for
language support and now has many more options than polyglossia. You can
try this preamble (compiles in LuaLaTeX):
\documentclass{article}
\usepackage[english]{babel}
\usepackage{fontspec}
\newfontscript{Devanagari}{deva}
\babelprovide[onchar=ids fonts]{sanskrit-devanagari}
\babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
With \babelprovide... there is no need to add a \selectlanguage or other
similar command. The problem with your example is that you need to put a
command to select the language before the Devanagari text, like
\selectlanguage{sanskrit}
Best regards,
Juan Manuel
Zenny <garbytrash@gmail.com> escribió:
> Hi,
>
> I tried to export to pdf with the following:
>
> #+LATEX_HEADER: \usepackage{polyglossia}
> #+LATEX_HEADER: \usepackage{fontspec}
> #+LATEX_COMPILER: xelatex (also tried with lualatex)
> #+LATEX_HEADER: \setmainlanguage{english}
> #+LATEX_HEADER: \setotherlanguage{sanskrit}
> #+LATEX_HEADER: \newfontfamily\devanagarifont{Noto Serif
> Devanagari}
>
> स्वस्ति सत्यं वचति
>
> but it exports alright to odt, and even pandoc exports alright
> directly from org file to docx file, but the Sanskrit/Devanagari fonts
> are skipped (blank) in pdf output when exported directly from org file
> with C-c C-e l o.
>
> Already tried with the solutions provided in
> https://emacs.stackexchange.com/questions/27576/exporting-devanagarai-text-from-org-mode-to-latex,
> but there are no such options (variables defined) after 'M-x
> customize-group' available.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-20 14:03 5% ` Juan Manuel Macías
@ 2023-09-21 9:00 4% ` Ihor Radchenko
2023-09-24 18:24 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-21 9:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> [...] I am very interested in all possible improvements in babel so that
> it integrates as best as possible with automatically generated files.
> Among them are the possibility of using BCP47 codes or using a language
> (at least basically) without the need for a prior declaration. These are
> things already done, but there are others that can still be improved.
Do I understand correctly that babel, in future, may be able to
auto-detect more languages without explicitly declaring them?
> [...] any suggestion for improvement is very welcome [...]
This is a bit too out of context. Improvement of what?
> Among the things I agree on is name issue. I am unifying the dice in the
> CLDR as much as possible, and already, in fact, it is very advanced:
>
> https://latex3.github.io/babel/guides/locale-naming.html
AFAIU, the relevant quote is
They are taken from the CLDR. Wherever the CLDR doesn’t provide a name
(eg, “Medieval Latin”), the pattern followed in practice for other names
is applied, namely, use the ‘natural’ form in English: medievallatin.
They should be preferably based on the description field in the IANA
registry (eg, polytonicgreek), although some simplifications can be
necessary, because some names are “too” descriptive. See also the
templates for about 500 locales already available. As a secondary
source, Glottolog is used, too. (Wikipedia articles can be taken as a
complementary but unreliable source, and its information must be
verified; on the other hand, internal data, like this one, is useful for
both names and tags.)
I am not very sure about "some simplifications" referring to IANA. I
guess it is referring to language names in
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
like "Puter idiom of Romansh".
From Org perspective, verbosity is not a primary concern as long as we
provide #+language: completion support. Probably, we should favor names
that are more likely known (or can be easily found) by the language
users. IANA and https://glottolog.org/ look like good sources we can
link to.
We can also provide multiple language name variants though I don't see a
need to bother unless we get user requests to do such thing.
> The ini files contain information that is not actually used by babel,
> but that could be useful in other packages or even external
> applications. One of them is the name of the language in English and in
> the vernacular form, as they are in the Unicode CLDR. As I explain in
> the link I gave you, the purpose is that the babel name is based on the
> CLDR name with mechanical changes. Anyway, CLDR names are also included
> in the ini files, to establish correspondences more easily.
Are the "verbose" language names (name.english) changed to "simplify"
them? Or is it only done for name.babel?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 8:24 13% ` Juan Manuel Macías
@ 2023-09-21 13:46 5% ` Zenny
2023-09-21 15:33 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 13:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 4344 bytes --]
Thanks Juan for prompt response, my replies inline below:
On Thu, Sep 21, 2023 at 10:24 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi,
>
> I would recommend that you use babel, as it is the official package for
> language support and now has many more options than polyglossia.
Thanks for the pointer and explanation.
> You can
> try this preamble (compiles in LuaLaTeX):
>
> \documentclass{article}
> \usepackage[english]{babel}
> \usepackage{fontspec}
> \newfontscript{Devanagari}{deva}
> \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>
Where does this preamble goes to? Any example?
>
> With \babelprovide... there is no need to add a \selectlanguage or other
> similar command. The problem with your example is that you need to put a
> command to select the language before the Devanagari text, like
> \selectlanguage{sanskrit}
>
Yet I am a bit confused because the Sanskrit/Devanagari words are used not
in a whole block, but in between English sentences, eg.:
Old expression goes like स्वस्ति सत्यं वचति (meaning 'Always tell the truth
> with positive vibes') where स्वस्ति means positive, सत्यं means truth and
> वचति means tell or speak out.
>
Any example would be appreciated for pdf export. Thanks again.
> Best regards,
>
> Juan Manuel
>
> Zenny <garbytrash@gmail.com> escribió:
>
> > Hi,
> >
> > I tried to export to pdf with the following:
> >
> > #+LATEX_HEADER: \usepackage{polyglossia}
> > #+LATEX_HEADER: \usepackage{fontspec}
> > #+LATEX_COMPILER: xelatex (also tried with lualatex)
> > #+LATEX_HEADER: \setmainlanguage{english}
> > #+LATEX_HEADER: \setotherlanguage{sanskrit}
> > #+LATEX_HEADER: \newfontfamily\devanagarifont{Noto Serif
> > Devanagari}
> >
> > स्वस्ति सत्यं वचति
> >
> > but it exports alright to odt, and even pandoc exports alright
> > directly from org file to docx file, but the Sanskrit/Devanagari fonts
> > are skipped (blank) in pdf output when exported directly from org file
> > with C-c C-e l o.
> >
> > Already tried with the solutions provided in
> >
> https://emacs.stackexchange.com/questions/27576/exporting-devanagarai-text-from-org-mode-to-latex
> ,
> > but there are no such options (variables defined) after 'M-x
> > customize-group' available.
>
> --
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
>
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 6318 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 13:46 5% ` Zenny
@ 2023-09-21 15:33 5% ` Juan Manuel Macías
2023-09-21 17:53 5% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 15:33 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Hi, Zenny,
Zenny writes:
> Where does this preamble goes to? Any example?
As in your example, using latex_header keywords (replacing the
polyglossia code with the babel code):
#+LaTeX_Header: \usepackage[english]{babel}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \newfontscript{Devanagari}{deva}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
#+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
> Yet I am a bit confused because the Sanskrit/Devanagari words are used
> not in a whole block, but in between English sentences, eg.:
With Polyglossia and babel it is necessary to enter a command that
changes the language. In the case of polyglossia, if you don't
explicitly switch to Sanskrit the font you declared for Sanskrit is not
used, and LaTeX still thinks the text is English. Polyglossia uses some
commands similar to those of babel (\selectlanguage, for long texts) and
other native ones, such as \text<lang>{text}, where <lang> is the
secondary language. In babel you have the command
\foreignlanguage{<lang>}{text}. For example (using polyglossia):
Old expression goes like \textsanskrit{स्वस्ति सत्यं वचति}
Of course, in org you would have to use some trick, like defining some
macro (since org does not have, at the moment[1], a native language
switching method):
#+macro: sanskrit @@latex:\textsanskrit{@@$1@@latex:}@@
Old expression goes like {{{sanskrit(स्वस्ति सत्यं वचति)}}}
With LuaLaTeX, babel can associate a non latin language to a font
without requiring an explicit language switch:
#+LaTeX_Header: \usepackage[english]{babel}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \newfontscript{Devanagari}{deva}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
#+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
Old expression goes like स्वस्ति सत्यं वचति
[1] You might be interested in this thread: https://list.orgmode.org/878r9t7x7y.fsf@posteo.net/
^ permalink raw reply [relevance 5%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 15:33 5% ` Juan Manuel Macías
@ 2023-09-21 17:53 5% ` Zenny
2023-09-21 18:28 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 17:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 4828 bytes --]
Hi Juan,
On Thu, Sep 21, 2023 at 5:33 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi, Zenny,
>
> Zenny writes:
>
> > Where does this preamble goes to? Any example?
>
> As in your example, using latex_header keywords (replacing the
> polyglossia code with the babel code):
>
> #+LaTeX_Header: \usepackage[english]{babel}
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>
> > Yet I am a bit confused because the Sanskrit/Devanagari words are used
> > not in a whole block, but in between English sentences, eg.:
>
> With Polyglossia and babel it is necessary to enter a command that
> changes the language. In the case of polyglossia, if you don't
> explicitly switch to Sanskrit the font you declared for Sanskrit is not
> used, and LaTeX still thinks the text is English. Polyglossia uses some
> commands similar to those of babel (\selectlanguage, for long texts) and
> other native ones, such as \text<lang>{text}, where <lang> is the
> secondary language. In babel you have the command
> \foreignlanguage{<lang>}{text}. For example (using polyglossia):
>
> Old expression goes like \textsanskrit{स्वस्ति सत्यं वचति}
>
> Of course, in org you would have to use some trick, like defining some
> macro (since org does not have, at the moment[1], a native language
> switching method):
>
> #+macro: sanskrit @@latex:\textsanskrit{@@$1@@latex:}@@
>
> Old expression goes like {{{sanskrit(स्वस्ति सत्यं वचति)}}}
>
> With LuaLaTeX, babel can associate a non latin language to a font
> without requiring an explicit language switch:
>
> #+LaTeX_Header: \usepackage[english]{babel}
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>
With above code for LuaLaTeX, I have also appended:
#+LATEX_COMPILER: lualatex
even after specifying the LaTeX compiler to lualatex a report that says,
the compiler seems to use pdflatex:
! Fatal Package fontspec Error: The fontspec package requires either XeTeX
> or
> (fontspec) LuaTeX.
> (fontspec)
> (fontspec) You must change your typesetting engine to,
> (fontspec) e.g., "xelatex" or "lualatex" instead of
> (fontspec) "latex" or "pdflatex".
>
> Type <return> to continue.
> ...
>
> l.45 \msg_fatal:nn {fontspec} {cannot-use-pdftex}
>
Entire texlive packages are installed and lualatex binary is at:
$ which lualatex
> /opt/texlive/2023/bin/x86_64-linux/lualatex
>
Thanks for your attention!
/z
> Old expression goes like स्वस्ति सत्यं वचति
>
> [1] You might be interested in this thread:
> https://list.orgmode.org/878r9t7x7y.fsf@posteo.net/
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 6485 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 17:53 5% ` Zenny
@ 2023-09-21 18:28 13% ` Juan Manuel Macías
2023-09-21 18:44 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 18:28 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> With above code for LuaLaTeX, I have also appended:
>
> #+LATEX_COMPILER: lualatex
>
> even after specifying the LaTeX compiler to lualatex a report that
> says, the compiler seems to use pdflatex:
>
> ! Fatal Package fontspec Error: The fontspec package requires
> either XeTeX or
> (fontspec) LuaTeX.
> (fontspec)
> (fontspec) You must change your typesetting
> engine to,
> (fontspec) e.g., "xelatex" or "lualatex"
> instead of
> (fontspec) "latex" or "pdflatex".
>
> Type <return> to continue.
> ...
>
> l.45 \msg_fatal:nn {fontspec} {cannot-use-pdftex}
>
>
> Entire texlive packages are installed and lualatex binary is at:
>
> $ which lualatex
> /opt/texlive/2023/bin/x86_64-linux/lualatex
Can you please show here the value of 'org-latex-pdf-process'?
(M-x describe-variable RET org-latex-pdf-process RET)
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 18:28 13% ` Juan Manuel Macías
@ 2023-09-21 18:44 4% ` Zenny
2023-09-21 19:32 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 18:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 4891 bytes --]
On Thu, Sep 21, 2023 at 8:28 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > With above code for LuaLaTeX, I have also appended:
> >
> > #+LATEX_COMPILER: lualatex
> >
> > even after specifying the LaTeX compiler to lualatex a report that
> > says, the compiler seems to use pdflatex:
> >
> > ! Fatal Package fontspec Error: The fontspec package requires
> > either XeTeX or
> > (fontspec) LuaTeX.
> > (fontspec)
> > (fontspec) You must change your typesetting
> > engine to,
> > (fontspec) e.g., "xelatex" or "lualatex"
> > instead of
> > (fontspec) "latex" or "pdflatex".
> >
> > Type <return> to continue.
> > ...
> >
> > l.45 \msg_fatal:nn {fontspec} {cannot-use-pdftex}
> >
> >
> > Entire texlive packages are installed and lualatex binary is at:
> >
> > $ which lualatex
> > /opt/texlive/2023/bin/x86_64-linux/lualatex
>
> Can you please show here the value of 'org-latex-pdf-process'?
>
> (M-x describe-variable RET org-latex-pdf-process RET)
>
Here it comes:
org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
>
> Its value is
> ("pdflatex -interaction nonstopmode -output-directory %o %f" "bibtex %b"
> "pdflatex -shell-escape -interaction nonstopmode -output-directory %o %f"
> "pdflatex -shell-escape -interaction nonstopmode -output-directory %o %f")
> Original value was
> ("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o
> %f")
>
> Commands to process a LaTeX file to a PDF file.
>
> The command output will be parsed to extract compilation errors and
> warnings according to ‘org-latex-known-warnings’.
>
> This is a list of strings, each of them will be given to the
> shell as a command. %f in the command will be replaced by the
> relative file name, %F by the absolute file name, %b by the file
> base name (i.e. without directory and extension parts), %o by the
> base directory of the file, %O by the absolute file name of the
> output file, %latex is the LaTeX compiler (see
> ‘org-latex-compiler’), and %bib is the BibTeX-like compiler (see
> ‘org-latex-bib-compiler’).
>
> The reason why this is a list is that it usually takes several
> runs of ‘pdflatex’, maybe mixed with a call to ‘bibtex’. Org
> does not have a clever mechanism to detect which of these
> commands have to be run to get to a stable result, and it also
> does not do any error checking.
>
> Consider a smart LaTeX compiler such as ‘texi2dvi’ or ‘latexmk’,
> which calls the "correct" combinations of auxiliary programs.
>
> Alternatively, this may be a Lisp function that does the
> processing, so you could use this to apply the machinery of
> AUCTeX or the Emacs LaTeX mode. This function should accept the
> file name as its single argument.
>
> You can customize this variable.
>
Thanks!
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
>
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 6618 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 18:44 4% ` Zenny
@ 2023-09-21 19:32 6% ` Juan Manuel Macías
2023-09-21 20:26 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 19:32 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Here it comes:
>
> org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
>
> Its value is
> ("pdflatex -interaction nonstopmode -output-directory %o %f"
> "bibtex %b" "pdflatex -shell-escape -interaction nonstopmode -
> output-directory %o %f" "pdflatex -shell-escape -interaction
> nonstopmode -output-directory %o %f")
> Original value was
> ("latexmk -f -pdf -%latex -interaction=nonstopmode -
> output-directory=%o %f")
It seems that you have modified the original value. Besides, the
docstring says:
[...] %latex is the LaTeX compiler (see ‘org-latex-compiler’) [...]
If you put 'pdflatex ...', it will always compile with pdflatex.
I would recommend that you restore the original value of
org-latex-pdf-process, which uses latexmk (if it is installed, which
seems to be your case), which executes '%latex' (=
`org-latex-compiler'). latexmk is a perl script included in texlive that
is responsible for executing all the necessary compilations (including
the call to the bibliographic engine[1]).
[1] In some cases some configuration is required for latexmk via a
~/latexmkrc file, but by default everything should work fine.
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 19:32 6% ` Juan Manuel Macías
@ 2023-09-21 20:26 4% ` Zenny
2023-09-21 20:39 0% ` Zenny
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 20:26 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 3731 bytes --]
On Thu, Sep 21, 2023 at 9:32 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Here it comes:
> >
> > org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
> >
> > Its value is
> > ("pdflatex -interaction nonstopmode -output-directory %o %f"
> > "bibtex %b" "pdflatex -shell-escape -interaction nonstopmode -
> > output-directory %o %f" "pdflatex -shell-escape -interaction
> > nonstopmode -output-directory %o %f")
> > Original value was
> > ("latexmk -f -pdf -%latex -interaction=nonstopmode -
> > output-directory=%o %f")
>
> It seems that you have modified the original value. Besides, the
> docstring says:
>
> [...] %latex is the LaTeX compiler (see ‘org-latex-compiler’) [...]
>
> If you put 'pdflatex ...', it will always compile with pdflatex.
>
> I would recommend that you restore the original value of
> org-latex-pdf-process, which uses latexmk (if it is installed, which
> seems to be your case), which executes '%latex' (=
> `org-latex-compiler'). latexmk is a perl script included in texlive that
> is responsible for executing all the necessary compilations (including
> the call to the bibliographic engine[1]).
>
When I checked the `ox-latex.el` it appears using latexmk
(defcustom org-latex-pdf-process
> (if (executable-find "latexmk")
> '("latexmk -f -pdf -%latex -interaction=nonstopmode
> -output-directory=%o %f")
> '("%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"))
> "Commands to process a LaTeX file to a PDF file.
>
And latexmk is already installed by texlive:
$ which latexmk
> /opt/texlive/2023/bin/x86_64-linux/latexmk
>
Or do you mean to change latexmk in init.el?
Thanks!
>
> [1] In some cases some configuration is required for latexmk via a
> ~/latexmkrc file, but by default everything should work fine.
>
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 5111 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 20:26 4% ` Zenny
@ 2023-09-21 20:39 0% ` Zenny
2023-09-21 20:41 0% ` Zenny
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 20:39 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 6054 bytes --]
On Thu, Sep 21, 2023 at 10:26 PM Zenny <garbytrash@gmail.com> wrote:
>
> On Thu, Sep 21, 2023 at 9:32 PM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Zenny writes:
>>
>> > Here it comes:
>> >
>> > org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
>> >
>> > Its value is
>> > ("pdflatex -interaction nonstopmode -output-directory %o %f"
>> > "bibtex %b" "pdflatex -shell-escape -interaction nonstopmode -
>> > output-directory %o %f" "pdflatex -shell-escape -interaction
>> > nonstopmode -output-directory %o %f")
>> > Original value was
>> > ("latexmk -f -pdf -%latex -interaction=nonstopmode -
>> > output-directory=%o %f")
>>
>> It seems that you have modified the original value. Besides, the
>> docstring says:
>>
>> [...] %latex is the LaTeX compiler (see ‘org-latex-compiler’) [...]
>>
>> If you put 'pdflatex ...', it will always compile with pdflatex.
>>
>
Does `#+LATEX_COMPILER: lualatex` makes no difference?
>
>> I would recommend that you restore the original value of
>> org-latex-pdf-process, which uses latexmk (if it is installed, which
>> seems to be your case), which executes '%latex' (=
>> `org-latex-compiler'). latexmk is a perl script included in texlive that
>> is responsible for executing all the necessary compilations (including
>> the call to the bibliographic engine[1]).
>>
>
> When I checked the `ox-latex.el` it appears using latexmk
>
> (defcustom org-latex-pdf-process
>> (if (executable-find "latexmk")
>> '("latexmk -f -pdf -%latex -interaction=nonstopmode
>> -output-directory=%o %f")
>> '("%latex -interaction nonstopmode -output-directory %o %f"
>> "%latex -interaction nonstopmode -output-directory %o %f"
>> "%latex -interaction nonstopmode -output-directory %o %f"))
>> "Commands to process a LaTeX file to a PDF file.
>>
>
> And latexmk is already installed by texlive:
>
> $ which latexmk
>> /opt/texlive/2023/bin/x86_64-linux/latexmk
>>
>
>
> Or do you mean to change latexmk in init.el?
>
I do see in init.el that it has been changed to something like:
(setq org-latex-pdf-process
> '("pdflatex -interaction nonstopmode -output-directory %o %f"
> "bibtex %b"
> "pdflatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"
> "pdflatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"))
>
> Thanks!
>
>>
>> [1] In some cases some configuration is required for latexmk via a
>> ~/latexmkrc file, but by default everything should work fine.
>>
>>
>>
>
> --
> Cheers,
> /z
>
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
> contents by anyone other than the intended recipient is unauthorized as it
> contains privileged and confidential information, and is subject to legal
> privilege. Please do not re/distribute it. If you are not the intended
> recipient (or responsible for delivery of the message to such person), you
> may not use, copy, distribute or deliver the email and part of its contents
> to anyone this message (or any part of its contents or take any action in
> connection to it. In such case, you should destroy this message, and notify
> the sender immediately. If you have received this email in error, please
> notify the sender or your sysadmin immediately by e-mail or telephone, and
> delete the e-mail from any computer. If you or your employer does not
> consent to internet e-mail messages of this kind, please notify the sender
> immediately. All reasonable precautions have been taken to ensure no
> viruses are present in this e-mail and attachments included. As the sender
> cannot accept responsibility for any loss or damage arising from the use of
> this e-mail or attachments it is recommended that you are responsible to
> follow your virus checking procedures prior to use. The views, opinions,
> conclusions and other informations expressed in this electronic mail are
> not given or endorsed by any company including the network providers unless
> otherwise indicated by an authorized representative independent of this
> message.
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 8681 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 20:39 0% ` Zenny
@ 2023-09-21 20:41 0% ` Zenny
2023-09-21 21:19 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 20:41 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 8430 bytes --]
On Thu, Sep 21, 2023 at 10:39 PM Zenny <garbytrash@gmail.com> wrote:
>
> On Thu, Sep 21, 2023 at 10:26 PM Zenny <garbytrash@gmail.com> wrote:
>
>>
>> On Thu, Sep 21, 2023 at 9:32 PM Juan Manuel Macías <
>> maciaschain@posteo.net> wrote:
>>
>>> Zenny writes:
>>>
>>> > Here it comes:
>>> >
>>> > org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
>>> >
>>> > Its value is
>>> > ("pdflatex -interaction nonstopmode -output-directory %o %f"
>>> > "bibtex %b" "pdflatex -shell-escape -interaction nonstopmode -
>>> > output-directory %o %f" "pdflatex -shell-escape -interaction
>>> > nonstopmode -output-directory %o %f")
>>> > Original value was
>>> > ("latexmk -f -pdf -%latex -interaction=nonstopmode -
>>> > output-directory=%o %f")
>>>
>>> It seems that you have modified the original value. Besides, the
>>> docstring says:
>>>
>>> [...] %latex is the LaTeX compiler (see ‘org-latex-compiler’) [...]
>>>
>>> If you put 'pdflatex ...', it will always compile with pdflatex.
>>>
>>
> Does `#+LATEX_COMPILER: lualatex` makes no difference?
>
I also tried with:
(setq org-latex-pdf-process
> (if (executable-find "latexmk")
> '("latexmk -interaction nonstopmode -output-directory %o %f")
> "bibtex %b"
> '("%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"))
>
but it did not produce any pdf at all.
>
>
>>
>>> I would recommend that you restore the original value of
>>> org-latex-pdf-process, which uses latexmk (if it is installed, which
>>> seems to be your case), which executes '%latex' (=
>>> `org-latex-compiler'). latexmk is a perl script included in texlive that
>>> is responsible for executing all the necessary compilations (including
>>> the call to the bibliographic engine[1]).
>>>
>>
>> When I checked the `ox-latex.el` it appears using latexmk
>>
>> (defcustom org-latex-pdf-process
>>> (if (executable-find "latexmk")
>>> '("latexmk -f -pdf -%latex -interaction=nonstopmode
>>> -output-directory=%o %f")
>>> '("%latex -interaction nonstopmode -output-directory %o %f"
>>> "%latex -interaction nonstopmode -output-directory %o %f"
>>> "%latex -interaction nonstopmode -output-directory %o %f"))
>>> "Commands to process a LaTeX file to a PDF file.
>>>
>>
>> And latexmk is already installed by texlive:
>>
>> $ which latexmk
>>> /opt/texlive/2023/bin/x86_64-linux/latexmk
>>>
>>
>>
>> Or do you mean to change latexmk in init.el?
>>
>
> I do see in init.el that it has been changed to something like:
>
> (setq org-latex-pdf-process
>> '("pdflatex -interaction nonstopmode -output-directory %o %f"
>> "bibtex %b"
>> "pdflatex -shell-escape -interaction nonstopmode
>> -output-directory %o %f"
>> "pdflatex -shell-escape -interaction nonstopmode
>> -output-directory %o %f"))
>>
>
>
>> Thanks!
>>
>>>
>>> [1] In some cases some configuration is required for latexmk via a
>>> ~/latexmkrc file, but by default everything should work fine.
>>>
>>>
>>>
>>
>> --
>> Cheers,
>> /z
>>
>> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
>> contents by anyone other than the intended recipient is unauthorized as it
>> contains privileged and confidential information, and is subject to legal
>> privilege. Please do not re/distribute it. If you are not the intended
>> recipient (or responsible for delivery of the message to such person), you
>> may not use, copy, distribute or deliver the email and part of its contents
>> to anyone this message (or any part of its contents or take any action in
>> connection to it. In such case, you should destroy this message, and notify
>> the sender immediately. If you have received this email in error, please
>> notify the sender or your sysadmin immediately by e-mail or telephone, and
>> delete the e-mail from any computer. If you or your employer does not
>> consent to internet e-mail messages of this kind, please notify the sender
>> immediately. All reasonable precautions have been taken to ensure no
>> viruses are present in this e-mail and attachments included. As the sender
>> cannot accept responsibility for any loss or damage arising from the use of
>> this e-mail or attachments it is recommended that you are responsible to
>> follow your virus checking procedures prior to use. The views, opinions,
>> conclusions and other informations expressed in this electronic mail are
>> not given or endorsed by any company including the network providers unless
>> otherwise indicated by an authorized representative independent of this
>> message.
>> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>>
>>
>
> --
> Cheers,
> /z
>
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
> contents by anyone other than the intended recipient is unauthorized as it
> contains privileged and confidential information, and is subject to legal
> privilege. Please do not re/distribute it. If you are not the intended
> recipient (or responsible for delivery of the message to such person), you
> may not use, copy, distribute or deliver the email and part of its contents
> to anyone this message (or any part of its contents or take any action in
> connection to it. In such case, you should destroy this message, and notify
> the sender immediately. If you have received this email in error, please
> notify the sender or your sysadmin immediately by e-mail or telephone, and
> delete the e-mail from any computer. If you or your employer does not
> consent to internet e-mail messages of this kind, please notify the sender
> immediately. All reasonable precautions have been taken to ensure no
> viruses are present in this e-mail and attachments included. As the sender
> cannot accept responsibility for any loss or damage arising from the use of
> this e-mail or attachments it is recommended that you are responsible to
> follow your virus checking procedures prior to use. The views, opinions,
> conclusions and other informations expressed in this electronic mail are
> not given or endorsed by any company including the network providers unless
> otherwise indicated by an authorized representative independent of this
> message.
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 12464 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 20:41 0% ` Zenny
@ 2023-09-21 21:19 12% ` Juan Manuel Macías
2023-09-22 7:04 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 21:19 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> I also tried with:
>
> (setq org-latex-pdf-process
> (if (executable-find "latexmk")
> '("latexmk -interaction nonstopmode -output-directory %o
> %f")
> "bibtex %b"
> '("%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"))
I think the expression is bad formed; In addition, latexmk is already
responsible for executing bibtex or biber and other processes that
require more than one compilation. The right thing would be:
(setq org-latex-pdf-process (if (executable-find "latexmk")
'("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
'("%latex -interaction nonstopmode -output-directory %o %f"
"%latex -interaction nonstopmode -output-directory %o %f"
"%latex -interaction nonstopmode
-output-directory %o %f")))
(or just remove the customization of that variable from your init).
And then put in your document:
#+LATEX_COMPILER: lualatex (or pdflatex or xelatex)
This keyword modifies the value of org-latex-compiler in the document.
If you are going to use lualatex more often, you can put in your init:
(setq org-latex-compiler "lualatex")
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 21:19 12% ` Juan Manuel Macías
@ 2023-09-22 7:04 4% ` Zenny
2023-09-22 8:00 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-22 7:04 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 3665 bytes --]
On Thu, Sep 21, 2023 at 11:19 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > I also tried with:
> >
> > (setq org-latex-pdf-process
> > (if (executable-find "latexmk")
> > '("latexmk -interaction nonstopmode -output-directory %o
> > %f")
> > "bibtex %b"
> > '("%latex -interaction nonstopmode -output-directory %o %f"
> > "%latex -interaction nonstopmode -output-directory %o %f"
> > "%latex -interaction nonstopmode -output-directory %o %f"))
>
> I think the expression is bad formed; In addition, latexmk is already
> responsible for executing bibtex or biber and other processes that
> require more than one compilation. The right thing would be:
>
> (setq org-latex-pdf-process (if (executable-find "latexmk")
> '("latexmk -f -pdf -%latex
> -interaction=nonstopmode -output-directory=%o %f")
> '("%latex -interaction nonstopmode
> -output-directory %o %f"
> "%latex -interaction nonstopmode
> -output-directory %o %f"
> "%latex -interaction nonstopmode
> -output-directory %o %f")))
>
> (or just remove the customization of that variable from your init).
>
> And then put in your document:
>
> #+LATEX_COMPILER: lualatex (or pdflatex or xelatex)
>
Exactly done as you advised, but no pdf is produced even after waiting for
~10minutes (attached screenshot)
>
> This keyword modifies the value of org-latex-compiler in the document.
> If you are going to use lualatex more often, you can put in your init:
>
> (setq org-latex-compiler "lualatex")
>
Thanks for your input.
>
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 5173 bytes --]
[-- Attachment #2: pic-selected-230922-0903-25.png --]
[-- Type: image/png, Size: 10237 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 7:04 4% ` Zenny
@ 2023-09-22 8:00 10% ` Juan Manuel Macías
2023-09-22 8:07 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:00 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Exactly done as you advised, but no pdf is produced even after waiting
> for ~10minutes (attached screenshot)
Let's try the following:
1. Export your document to a 'your-document.tex' file: C-c C-e l l
2. Open a terminal in your directory and run:
latexmk -f -pdf -lualatex -interaction=nonstopmode your-document.tex
(a pdf would have to be created after compilation. If there are any
errors, please copy your-document.log here).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:00 10% ` Juan Manuel Macías
@ 2023-09-22 8:07 4% ` Zenny
2023-09-22 8:09 0% ` Zenny
2023-09-22 8:18 6% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Zenny @ 2023-09-22 8:07 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 5090 bytes --]
On Fri, Sep 22, 2023 at 10:00 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Exactly done as you advised, but no pdf is produced even after waiting
> > for ~10minutes (attached screenshot)
>
> Let's try the following:
>
> 1. Export your document to a 'your-document.tex' file: C-c C-e l l
>
> 2. Open a terminal in your directory and run:
>
> latexmk -f -pdf -lualatex -interaction=nonstopmode your-document.tex
>
Thanks, this was extremely helpful. The pdf is produced, but the Devanagari
glyphs were not respected. See screenshot.
>
> (a pdf would have to be created after compilation. If there are any
> errors, please copy your-document.log here).
>
Also the Bengali letters were omitted with:
Latexmk: Summary of warnings from last run of *latex:
> =====Latex reported missing or unavailable character(s).
> =====See log file for details.
> Latexmk: ====List of undefined refs and citations:
> Missing character: There is no ঘ (U+0998) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no ো (U+09CB) in
> font [lmroman10-regular]:+tlig;!Missing character: There is no ষ (U+09B7)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no া
> (U+09BE) in font [lmroman10-regular]:+tlig;!Missing character: There is no
> ল (U+09B2) in font [lmroman10-regular]:+tlig;!Missing character: There is
> no া (U+09BE) in font [lmroman10-regular]:+tlig;!Missing character: There
> is no ম (U+09AE) in font [lmroman10-regular]:+tlig;!Missing character:
> There is no ঙ (U+0999) in font [lmroman10-regular]:+tlig;!Missing
> character: There is no (U+09CD) in font [lmroman10-regular]:+tlig;!Missing
> character: There is no গ (U+0997) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no (U+09CD) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no য (U+09AF) in
> font [lmroman10-regular]:+tlig;!Missing character: There is no া (U+09BE)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no য
> (U+09AF) in font [lmroman10-regular]:+tlig;!Missing character: There is no
> (U+09BC) in font [lmroman10-regular]:+tlig;!] [2] [3
> Missing character: There is no ঘ (U+0998) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no ো (U+09CB) in
> font [lmroman10-regular]:+tlig;!Missing character: There is no ষ (U+09B7)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no প
> (U+09AA) in font [lmroman10-regular]:+tlig;!Missing character: There is no
> ত (U+09A4) in font [lmroman10-regular]:+tlig;!Missing character: There is
> no (U+09C1) in font [lmroman10-regular]:+tlig;!Missing character: There is
> no আ (U+0986) in font [lmroman10-regular]:+tlig;!Missing character: There
> is no ঘ (U+0998) in font [lmroman10-regular]:+tlig;!Missing character:
> There is no ো (U+09CB) in font [lmroman10-regular]:+tlig;!Missing
> character: There is no ষ (U+09B7) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no প (U+09AA) in
> font [lmroman10-regular]:+tlig;!Missing character: There is no ত (U+09A4)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no (U+09C1)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no আ
> (U+0986) in font [lmroman10-regular]:+tlig;!] [4] [5]
>
> Best regards,
>
> Juan Manuel
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 6123 bytes --]
[-- Attachment #2: pic-selected-230922-1000-58.png --]
[-- Type: image/png, Size: 66542 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:07 4% ` Zenny
@ 2023-09-22 8:09 0% ` Zenny
2023-09-22 8:41 6% ` Juan Manuel Macías
2023-09-22 8:18 6% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Zenny @ 2023-09-22 8:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 7223 bytes --]
On Fri, Sep 22, 2023 at 10:07 AM Zenny <garbytrash@gmail.com> wrote:
>
> On Fri, Sep 22, 2023 at 10:00 AM Juan Manuel Macías <
> maciaschain@posteo.net> wrote:
>
>> Zenny writes:
>>
>> > Exactly done as you advised, but no pdf is produced even after waiting
>> > for ~10minutes (attached screenshot)
>>
>> Let's try the following:
>>
>> 1. Export your document to a 'your-document.tex' file: C-c C-e l l
>>
>> 2. Open a terminal in your directory and run:
>>
>> latexmk -f -pdf -lualatex -interaction=nonstopmode your-document.tex
>>
>
> Thanks, this was extremely helpful. The pdf is produced, but the
> Devanagari glyphs were not respected. See screenshot.
>
>>
>> (a pdf would have to be created after compilation. If there are any
>> errors, please copy your-document.log here).
>>
>
> Also the Bengali letters were omitted with:
>
> Latexmk: Summary of warnings from last run of *latex:
>> =====Latex reported missing or unavailable character(s).
>> =====See log file for details.
>> Latexmk: ====List of undefined refs and citations:
>> Missing character: There is no ঘ (U+0998) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no ো (U+09CB) in
>> font [lmroman10-regular]:+tlig;!Missing character: There is no ষ (U+09B7)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no া
>> (U+09BE) in font [lmroman10-regular]:+tlig;!Missing character: There is no
>> ল (U+09B2) in font [lmroman10-regular]:+tlig;!Missing character: There is
>> no া (U+09BE) in font [lmroman10-regular]:+tlig;!Missing character: There
>> is no ম (U+09AE) in font [lmroman10-regular]:+tlig;!Missing character:
>> There is no ঙ (U+0999) in font [lmroman10-regular]:+tlig;!Missing
>> character: There is no (U+09CD) in font [lmroman10-regular]:+tlig;!Missing
>> character: There is no গ (U+0997) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no (U+09CD) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no য (U+09AF) in
>> font [lmroman10-regular]:+tlig;!Missing character: There is no া (U+09BE)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no য
>> (U+09AF) in font [lmroman10-regular]:+tlig;!Missing character: There is no
>> (U+09BC) in font [lmroman10-regular]:+tlig;!] [2] [3
>> Missing character: There is no ঘ (U+0998) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no ো (U+09CB) in
>> font [lmroman10-regular]:+tlig;!Missing character: There is no ষ (U+09B7)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no প
>> (U+09AA) in font [lmroman10-regular]:+tlig;!Missing character: There is no
>> ত (U+09A4) in font [lmroman10-regular]:+tlig;!Missing character: There is
>> no (U+09C1) in font [lmroman10-regular]:+tlig;!Missing character: There is
>> no আ (U+0986) in font [lmroman10-regular]:+tlig;!Missing character: There
>> is no ঘ (U+0998) in font [lmroman10-regular]:+tlig;!Missing character:
>> There is no ো (U+09CB) in font [lmroman10-regular]:+tlig;!Missing
>> character: There is no ষ (U+09B7) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no প (U+09AA) in
>> font [lmroman10-regular]:+tlig;!Missing character: There is no ত (U+09A4)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no (U+09C1)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no আ
>> (U+0986) in font [lmroman10-regular]:+tlig;!] [4] [5]
>>
>
The bengali is already installed by tlmgr:
# tlmgr install bengali
> tlmgr: package repository
> https://ftpmirror1.infania.net/mirror/CTAN/systems/texlive/tlnet
> (verified)
> tlmgr install: package already present: bengali
>
>
>
>
>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>
> --
> Cheers,
> /z
>
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
> contents by anyone other than the intended recipient is unauthorized as it
> contains privileged and confidential information, and is subject to legal
> privilege. Please do not re/distribute it. If you are not the intended
> recipient (or responsible for delivery of the message to such person), you
> may not use, copy, distribute or deliver the email and part of its contents
> to anyone this message (or any part of its contents or take any action in
> connection to it. In such case, you should destroy this message, and notify
> the sender immediately. If you have received this email in error, please
> notify the sender or your sysadmin immediately by e-mail or telephone, and
> delete the e-mail from any computer. If you or your employer does not
> consent to internet e-mail messages of this kind, please notify the sender
> immediately. All reasonable precautions have been taken to ensure no
> viruses are present in this e-mail and attachments included. As the sender
> cannot accept responsibility for any loss or damage arising from the use of
> this e-mail or attachments it is recommended that you are responsible to
> follow your virus checking procedures prior to use. The views, opinions,
> conclusions and other informations expressed in this electronic mail are
> not given or endorsed by any company including the network providers unless
> otherwise indicated by an authorized representative independent of this
> message.
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 9121 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:07 4% ` Zenny
2023-09-22 8:09 0% ` Zenny
@ 2023-09-22 8:18 6% ` Juan Manuel Macías
2023-09-22 8:30 4% ` Zenny
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:18 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Thanks, this was extremely helpful. The pdf is produced, but the
> Devanagari glyphs were not respected. See screenshot.
Could you please create this MWE, and execute the same process?
#+LaTeX_Header: \usepackage[english]{babel}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \newfontscript{Devanagari}{deva}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
#+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
<some text in English>
<some text in Devanagari>
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:18 6% ` Juan Manuel Macías
@ 2023-09-22 8:30 4% ` Zenny
0 siblings, 0 replies; 200+ results
From: Zenny @ 2023-09-22 8:30 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]
On Fri, Sep 22, 2023 at 10:18 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Thanks, this was extremely helpful. The pdf is produced, but the
> > Devanagari glyphs were not respected. See screenshot.
>
> Could you please create this MWE, and execute the same process?
>
> #+LaTeX_Header: \usepackage[english]{babel}
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>
> <some text in English>
>
> <some text in Devanagari>
>
Thanks!
With above MWE, the org can directly be exported to pdf, but
1. Glyphs in Devanagari are not respected as earlier
2. Bengali is completely skipped.
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 3206 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:09 0% ` Zenny
@ 2023-09-22 8:41 6% ` Juan Manuel Macías
2023-09-22 8:49 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:41 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Also the Bengali letters were omitted with:
Sorry, this is the correct MWE:
#+LaTeX_Header: \usepackage[english]{babel}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \newfontscript{Devanagari}{deva}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-bengali}
#+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
#+LaTeX_Header: \babelfont[sanskrit-bengali]{rm}{Noto Sans Bengali}
<some text in english>
<some text in devanagari>
<some text in bengali>
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:41 6% ` Juan Manuel Macías
@ 2023-09-22 8:49 4% ` Zenny
2023-09-22 8:54 0% ` Zenny
2023-09-22 8:54 6% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Zenny @ 2023-09-22 8:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2515 bytes --]
On Fri, Sep 22, 2023 at 10:41 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Also the Bengali letters were omitted with:
>
> Sorry, this is the correct MWE:
>
> #+LaTeX_Header: \usepackage[english]{babel}
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-bengali}
> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
> #+LaTeX_Header: \babelfont[sanskrit-bengali]{rm}{Noto Sans Bengali}
>
> <some text in english>
> <some text in devanagari>
> <some text in bengali>
>
With this both languages (scripts) were rendered) but both renderings has
no correct glyphs (see screenshots)
Thanks!
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 3212 bytes --]
[-- Attachment #2: pic-selected-230922-1049-01.png --]
[-- Type: image/png, Size: 16577 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:49 4% ` Zenny
2023-09-22 8:54 0% ` Zenny
@ 2023-09-22 8:54 6% ` Juan Manuel Macías
2023-09-22 8:58 4% ` Zenny
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:54 UTC (permalink / raw)
To: Zenny; +Cc: orgmode
Zenny writes:
> <some text in english>
> <some text in devanagari>
> <some text in bengali>
>
> With this both languages (scripts) were rendered) but both renderings
> has no correct glyphs (see screenshots)
Could you please copy the text of your example here, so I can compile
it?
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:49 4% ` Zenny
@ 2023-09-22 8:54 0% ` Zenny
2023-09-22 8:54 6% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Zenny @ 2023-09-22 8:54 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 4429 bytes --]
On Fri, Sep 22, 2023 at 10:49 AM Zenny <garbytrash@gmail.com> wrote:
> On Fri, Sep 22, 2023 at 10:41 AM Juan Manuel Macías <
> maciaschain@posteo.net> wrote:
>
>> Zenny writes:
>>
>> > Also the Bengali letters were omitted with:
>>
>> Sorry, this is the correct MWE:
>>
>> #+LaTeX_Header: \usepackage[english]{babel}
>> #+LaTeX_Header: \usepackage{fontspec}
>> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
>> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
>> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-bengali}
>> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>> #+LaTeX_Header: \babelfont[sanskrit-bengali]{rm}{Noto Sans Bengali}
>>
>> <some text in english>
>> <some text in devanagari>
>> <some text in bengali>
>>
>
> With this both languages (scripts) were rendered) but both renderings has
> no correct glyphs (see screenshots)
> Thanks!
>
Actually, the former should look like the latter, for a comparison.
> --
> Cheers,
> /z
>
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
> contents by anyone other than the intended recipient is unauthorized as it
> contains privileged and confidential information, and is subject to legal
> privilege. Please do not re/distribute it. If you are not the intended
> recipient (or responsible for delivery of the message to such person), you
> may not use, copy, distribute or deliver the email and part of its contents
> to anyone this message (or any part of its contents or take any action in
> connection to it. In such case, you should destroy this message, and notify
> the sender immediately. If you have received this email in error, please
> notify the sender or your sysadmin immediately by e-mail or telephone, and
> delete the e-mail from any computer. If you or your employer does not
> consent to internet e-mail messages of this kind, please notify the sender
> immediately. All reasonable precautions have been taken to ensure no
> viruses are present in this e-mail and attachments included. As the sender
> cannot accept responsibility for any loss or damage arising from the use of
> this e-mail or attachments it is recommended that you are responsible to
> follow your virus checking procedures prior to use. The views, opinions,
> conclusions and other informations expressed in this electronic mail are
> not given or endorsed by any company including the network providers unless
> otherwise indicated by an authorized representative independent of this
> message.
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 5845 bytes --]
[-- Attachment #2: pic-selected-230922-1052-44.png --]
[-- Type: image/png, Size: 16340 bytes --]
[-- Attachment #3: pic-selected-230922-1053-10.png --]
[-- Type: image/png, Size: 72162 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:54 6% ` Juan Manuel Macías
@ 2023-09-22 8:58 4% ` Zenny
2023-09-22 9:06 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-22 8:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
On Fri, Sep 22, 2023 at 10:54 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > <some text in english>
> > <some text in devanagari>
> > <some text in bengali>
> >
> > With this both languages (scripts) were rendered) but both renderings
> > has no correct glyphs (see screenshots)
>
> Could you please copy the text of your example here, so I can compile
> it?
>
Here it comes:
| Original | Anglicized | Switch |
|----------+------------+------------|
| सत्य | Satya | Sathya |
| सरस्वती | Saraswati | Saraswathy |
| गणपति | Ganapati | Ganapathy |
| गोषाल | goShal | Ghoshal |
| गोष्ठ | GoShTha | Ghosht |
| मुम्बा | Mumba | Bombay |
| घोष | GhoSha | Ghosh |
| बिष्ट | BiSht | Bista |
| अंग | Anga | Banga |
Gosala Mankhya (घोषाला मंख्य in Sanskrit and ঘোষালা মঙ্গ্যায় in Bengali)
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 3545 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:58 4% ` Zenny
@ 2023-09-22 9:06 6% ` Juan Manuel Macías
2023-09-22 9:37 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 9:06 UTC (permalink / raw)
To: Zenny; +Cc: orgmode
Zenny writes:
> Here it comes:
>
> | Original | Anglicized | Switch |
> |----------+------------+------------|
> | सत्य | Satya | Sathya |
> | सरस्वती | Saraswati | Saraswathy |
> | गणपति | Ganapati | Ganapathy |
> | गोषाल | goShal | Ghoshal |
> | गोष्ठ | GoShTha | Ghosht |
> | मुम्बा | Mumba | Bombay |
> | घोष | GhoSha | Ghosh |
> | बिष्ट | BiSht | Bista |
> | अंग | Anga | Banga |
>
> Gosala Mankhya (घोषाला मंख्य in Sanskrit and ঘোষালা মঙ্গ্যায় in Bengali)
See screenshot. It's right?
https://i.imgur.com/OD5nl1Q.png
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 9:06 6% ` Juan Manuel Macías
@ 2023-09-22 9:37 4% ` Zenny
2023-09-22 10:02 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-22 9:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2779 bytes --]
On Fri, Sep 22, 2023 at 11:06 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Here it comes:
> >
> > | Original | Anglicized | Switch |
> > |----------+------------+------------|
> > | सत्य | Satya | Sathya |
> > | सरस्वती | Saraswati | Saraswathy |
> > | गणपति | Ganapati | Ganapathy |
> > | गोषाल | goShal | Ghoshal |
> > | गोष्ठ | GoShTha | Ghosht |
> > | मुम्बा | Mumba | Bombay |
> > | घोष | GhoSha | Ghosh |
> > | बिष्ट | BiSht | Bista |
> > | अंग | Anga | Banga |
> >
> > Gosala Mankhya (घोषाला मंख्य in Sanskrit and ঘোষালা মঙ্গ্যায় in
> Bengali)
>
> See screenshot. It's right?
>
> https://i.imgur.com/OD5nl1Q.png
>
It still shows the problem with glyphs:
Should look like in the attached screenshots, in emacs orgmode and rendered
to pdf (from org to docx using pandoc)
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 3673 bytes --]
[-- Attachment #2: pic-selected-230922-1136-17.png --]
[-- Type: image/png, Size: 37836 bytes --]
[-- Attachment #3: pic-selected-230922-1053-10.png --]
[-- Type: image/png, Size: 72162 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 9:37 4% ` Zenny
@ 2023-09-22 10:02 6% ` Juan Manuel Macías
2023-09-22 12:59 6% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 10:02 UTC (permalink / raw)
To: Zenny; +Cc: orgmode
Zenny <garbytrash@gmail.com> writes:
> It still shows the problem with
> glyphs:
>
> Should look like in the attached
> screenshots, in emacs orgmode
> and rendered to pdf (from org to
> docx using pandoc)
Add this line to the bottom:
#+LaTeX_Header:\defaultfontfeatures{Renderer=HarfBuzz}
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 10:02 6% ` Juan Manuel Macías
@ 2023-09-22 12:59 6% ` Zenny
2023-09-22 15:12 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-22 12:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1.1: Type: text/plain, Size: 553 bytes --]
On Fri, Sep 22, 2023 at 12:02 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny <garbytrash@gmail.com> writes:
>
> > It still shows the problem with
> > glyphs:
> >
> > Should look like in the attached
> > screenshots, in emacs orgmode
> > and rendered to pdf (from org to
> > docx using pandoc)
>
> Add this line to the bottom:
>
> #+LaTeX_Header:\defaultfontfeatures{Renderer=HarfBuzz}
>
Appended the above line, but the rendering became much worse, see Ganapati
and BiSht lines:
Thanks.
--
Cheers,
/z
[-- Attachment #1.2: Type: text/html, Size: 1194 bytes --]
[-- Attachment #2: pic-selected-230922-1458-27.png --]
[-- Type: image/png, Size: 16213 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 12:59 6% ` Zenny
@ 2023-09-22 15:12 6% ` Juan Manuel Macías
2023-09-22 17:51 5% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 15:12 UTC (permalink / raw)
To: Zenny; +Cc: orgmode
Zenny writes:
> Appended the above line, but the rendering became much worse, see
> Ganapati and BiSht lines:
Well, try this:
1. remove \newfontscript{Devanagari}{deva}
2. modify the \babelprovide for Bengali like this:
\babelprovide[onchar=ids fonts,import,script=Bengali]{sanskrit-bengali}
(it seems like something strange is happening between the Noto Sans
Bengali font and LuaTeX. I don't know if it's a bug, but if I explicitly
add the script name, it seems to render the words well. With Noto Serif
Bengali it doesn't happen).
Sorry, I'm afraid I don't know the language, so I'm going a bit blind
here...
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-16 18:00 10% [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
2023-09-17 10:02 6% ` Ihor Radchenko
2023-09-17 17:23 6% ` Timothy
@ 2023-09-22 16:38 5% ` Max Nikulin
2023-09-24 18:42 12% ` Juan Manuel Macías
2 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-22 16:38 UTC (permalink / raw)
To: emacs-orgmode
On 17/09/2023 01:00, Juan Manuel Macías wrote:
>
> [1] A longer example to export to a pdf that has pdf-x compliance, with
> the pdfx package:
>
> \providecommand{\pdfxopts}{x-1a}
> \begin{filecontents*}{\jobname.xmpdata}
> \Title{Some Title}
> \Author{Author}
> \Language{es-ES}
> \Keywords{keywords}
> \Publisher{publisher}
> \end{filecontents*}
> \documentclass{...
Perhaps you have in mind other cases, but I am unsure concerning this
one. However I have tried only setting metadata for hyperref only, so I
may miss some important aspects.
First of all, I was unaware of .xmpdata and, trying to get more info, I
have found hyperxmp that declares to reuse data from \hypersetup without
extra files and without the requirement to add settings before
\documentclass.
Do you need to add commands before \documentclass because you are using
custom classes that loads a lot of packages, so there is no chance to
specify various options after \documentclass, but before specific
packages are loaded?
I do not think the lines above should be used directly in
LATEX_PRE_HEADER. They should be generated from #+AUTHOR:, #+TITLE:,
#+LANGUAGE: keywords. Have you considered the option to generate
.xmpdata files directly from Org instead of delegating the task to LaTeX?
Another idea is to try export filter to insert content of a source block
to the beginning of the export buffer. Unsure if it is convenient.
^ permalink raw reply [relevance 5%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 15:12 6% ` Juan Manuel Macías
@ 2023-09-22 17:51 5% ` Zenny
0 siblings, 0 replies; 200+ results
From: Zenny @ 2023-09-22 17:51 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2690 bytes --]
On Fri, Sep 22, 2023 at 5:13 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Appended the above line, but the rendering became much worse, see
> > Ganapati and BiSht lines:
>
> Well, try this:
>
> 1. remove \newfontscript{Devanagari}{deva}
>
> 2. modify the \babelprovide for Bengali like this:
>
> \babelprovide[onchar=ids fonts,import,script=Bengali]{sanskrit-bengali}
>
> (it seems like something strange is happening between the Noto Sans
> Bengali font and LuaTeX. I don't know if it's a bug, but if I explicitly
> add the script name, it seems to render the words well. With Noto Serif
> Bengali it doesn't happen).
>
Thank you, I made the changes as you advised and changed the font to Noto
Serif variant, and it worked like wonder.
The problem is solved. Thanks a zillion.
Now it renders alright as seen in the screenshot. Have a nice weekend, Juan.
>
> Sorry, I'm afraid I don't know the language, so I'm going a bit blind
> here...
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 3522 bytes --]
[-- Attachment #2: pic-selected-230922-1950-54.png --]
[-- Type: image/png, Size: 16160 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-21 9:00 4% ` Ihor Radchenko
@ 2023-09-24 18:24 12% ` Juan Manuel Macías
2023-09-26 10:37 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-24 18:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Timothy, Max Nikulin
Sorry for the late reply.
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> [...] I am very interested in all possible improvements in babel so that
>> it integrates as best as possible with automatically generated files.
>> Among them are the possibility of using BCP47 codes or using a language
>> (at least basically) without the need for a prior declaration. These are
>> things already done, but there are others that can still be improved.
>
> Do I understand correctly that babel, in future, may be able to
> auto-detect more languages without explicitly declaring them?
Correct. Indeed, it is possible to use the command \foreignlanguage or
its environment version (otherlanguage*) without having to
declare the language previously. I would say that \foreignlanguage is a
command that covers a high percentage of use cases in multilingual
documents, since it is intended for short fragments of text and only
loads the hyphen rules of the host language.
>> [...] any suggestion for improvement is very welcome [...]
>
> This is a bit too out of context. Improvement of what?
I think it is related to the previous paragraph: "I am very interested
in all possible improvements in babel so that it integrates as best as
possible with automatically generated files[...]"
>> Among the things I agree on is name issue. I am unifying the dice in the
>> CLDR as much as possible, and already, in fact, it is very advanced:
>>
>> https://latex3.github.io/babel/guides/locale-naming.html
>
> AFAIU, the relevant quote is
>
> They are taken from the CLDR. Wherever the CLDR doesn’t provide a name
> (eg, “Medieval Latin”), the pattern followed in practice for other names
> is applied, namely, use the ‘natural’ form in English: medievallatin.
> They should be preferably based on the description field in the IANA
> registry (eg, polytonicgreek), although some simplifications can be
> necessary, because some names are “too” descriptive. See also the
> templates for about 500 locales already available. As a secondary
> source, Glottolog is used, too. (Wikipedia articles can be taken as a
> complementary but unreliable source, and its information must be
> verified; on the other hand, internal data, like this one, is useful for
> both names and tags.)
>
> I am not very sure about "some simplifications" referring to IANA. I
> guess it is referring to language names in
> https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
> like "Puter idiom of Romansh".
>
> From Org perspective, verbosity is not a primary concern as long as we
> provide #+language: completion support. Probably, we should favor names
> that are more likely known (or can be easily found) by the language
> users. IANA and https://glottolog.org/ look like good sources we can
> link to.
>
> We can also provide multiple language name variants though I don't see a
> need to bother unless we get user requests to do such thing.
I agree. I even think it would be a good point to also include the
vernacular name of each language.
By the way, Javier has also told me that he is going to consider the
'onchar=ids fonts' issue related to the case of several languages that
use the same script (already discussed here in past messages).
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-22 16:38 5% ` Max Nikulin
@ 2023-09-24 18:42 12% ` Juan Manuel Macías
2023-09-25 13:58 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-24 18:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 17/09/2023 01:00, Juan Manuel Macías wrote:
>>
>> [1] A longer example to export to a pdf that has pdf-x compliance, with
>> the pdfx package:
>>
>> \providecommand{\pdfxopts}{x-1a}
>> \begin{filecontents*}{\jobname.xmpdata}
>> \Title{Some Title}
>> \Author{Author}
>> \Language{es-ES}
>> \Keywords{keywords}
>> \Publisher{publisher}
>> \end{filecontents*}
>> \documentclass{...
>
> Perhaps you have in mind other cases, but I am unsure concerning this
> one. However I have tried only setting metadata for hyperref only, so I
> may miss some important aspects.
>
> First of all, I was unaware of .xmpdata and, trying to get more info, I
> have found hyperxmp that declares to reuse data from \hypersetup without
> extra files and without the requirement to add settings before
> \documentclass.
According to the pdfx package documentation
(https://www.ctan.org/pkg/pdfx), p. 6 (at the bottom of the page)/7:
---
Warning: The \jobname.xmpdata file may be included in the main document
source, within a {filecontents*} environment, provided this comes before
the \documentclass command, as follows[...]
---
> Do you need to add commands before \documentclass because you are using
> custom classes that loads a lot of packages, so there is no chance to
> specify various options after \documentclass, but before specific
> packages are loaded?
Apart from the previous case, there are other varied cases (as I
mentioned) in which it is necessary to put code before documentclass.
For example, the newpax package, to preserve the internal links of a pdf
included in the document, requires putting commands like
\DocumentMetadata{ } before documentclass.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-24 18:42 12% ` Juan Manuel Macías
@ 2023-09-25 13:58 5% ` Max Nikulin
2023-09-25 18:49 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-25 13:58 UTC (permalink / raw)
To: emacs-orgmode
On 25/09/2023 01:42, Juan Manuel Macías wrote:
> According to the pdfx package documentation
> (https://www.ctan.org/pkg/pdfx), p. 6 (at the bottom of the page)/7:
> ---
> Warning: The \jobname.xmpdata file may be included in the main document
> source, within a {filecontents*} environment, provided this comes before
> the \documentclass command, as follows[...]
> ---
Does it mean that with hyperxmp you can not generate documents
satisfying some requirements and you need namely pdfx? Is there a reason
that .xmpdata files must be generated namely by a LaTeX engine and
writing them by elisp code is unacceptable?
> For example, the newpax package, to preserve the internal links of a pdf
> included in the document, requires putting commands like
> \DocumentMetadata{ } before documentclass.
If I understand it correctly, \DocumentMetadata is a switch to enable
"new" LaTeX like it was for \documentclass vs. \documentstyle during
transition to LaTeX2e from LaTeX 2.09. If so, Org should have native
support of \DocumentMetadata, not LATEX_PRE_HEADER or something similar.
I have not looked into Timothy's branch, so I am unaware if it is addressed.
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-25 13:58 5% ` Max Nikulin
@ 2023-09-25 18:49 9% ` Juan Manuel Macías
2023-09-25 21:57 7% ` Thomas S. Dye
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-25 18:49 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 25/09/2023 01:42, Juan Manuel Macías wrote:
>> According to the pdfx package documentation
>> (https://www.ctan.org/pkg/pdfx), p. 6 (at the bottom of the page)/7:
>> ---
>> Warning: The \jobname.xmpdata file may be included in the main document
>> source, within a {filecontents*} environment, provided this comes before
>> the \documentclass command, as follows[...]
>> ---
>
> Does it mean that with hyperxmp you can not generate documents
> satisfying some requirements and you need namely pdfx? Is there a
> reason that .xmpdata files must be generated namely by a LaTeX engine
> and writing them by elisp code is unacceptable?
In the hyperxmp manual a comparison is made with the pdfx package and
other similar packages. Anyway, this topic deviates drastically from the
original topic of the thread. There will be users who prefer to use
hyperxmp package and users who prefer pdfx. Hyperxmp is probably more
recommended, but I don't know either one deeply, so I couldn't say. In
any case: I think the central issue is to provide support for inserting
arbitrary code before \documentclass. The pdfx example is just one valid
example (ideally Org should not put obstacles to the use of any
package). As I said, there are more cases. For example, a few packages
(I don't remember their names) are recommended to be loaded first using
\RequirePackage. And there is also the case of the \PassOptionsToPackage
command. A good practice in LaTeX documents is usually to put this
command at the very beginning of the document, to avoid messages such as
"option class for xx package error". It is placed at the very beginning
because there may be classes that already require the package involved
in the error. And one more example: a new package for LuaLaTeX was
recently uploaded to CTAN, which allows the use of shebangs in LaTeX
documents. In short, there are many heterogeneous cases, and it is the
very heterogeneity of these cases that leads to a solution similar to
LaTeX_header, IMHO. Actually, any code (except \usepackage) would be
possible before \cocumentclass.
>> For example, the newpax package, to preserve the internal links of a pdf
>> included in the document, requires putting commands like
>> \DocumentMetadata{ } before documentclass.
>
> If I understand it correctly, \DocumentMetadata is a switch to enable
> "new" LaTeX like it was for \documentclass vs. \documentstyle during
> transition to LaTeX2e from LaTeX 2.09.
https://tex.stackexchange.com/questions/686898/what-is-documentmetadata-what-key-value-pairs-does-it-take-and-when-should-i-u
(As for the transition from LaTeX2e to LaTeX 3, it seems that it is not
going to be as defined as the transition we witnessed in the leap from
LaTeX 2.09. In reality it seems that there is not going to be such a
leap but rather a "coexistence" of both worlds:
https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf)
> If so, Org should have native support of \DocumentMetadata, not
> LATEX_PRE_HEADER or something similar.
If it were the only case of code before \documentclass, I would agree.
But, as I have already said above, the diversity of use cases makes the
implementation of /ad hoc/ solutions unviable, in my opinion.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-25 18:49 9% ` Juan Manuel Macías
@ 2023-09-25 21:57 7% ` Thomas S. Dye
2023-09-26 15:39 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Thomas S. Dye @ 2023-09-25 21:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Aloha all,
Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> If so, Org should have native support of \DocumentMetadata, not
>> LATEX_PRE_HEADER or something similar.
>
> If it were the only case of code before \documentclass, I would
> agree.
> But, as I have already said above, the diversity of use cases
> makes the
> implementation of /ad hoc/ solutions unviable, in my opinion.
FWIW, I agree with Juan Manuel here and would welcome a
straightforward way to insert material before the header.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 7%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-24 18:24 12% ` Juan Manuel Macías
@ 2023-09-26 10:37 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-26 10:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>> [...] any suggestion for improvement is very welcome [...]
>>
>> This is a bit too out of context. Improvement of what?
>
> I think it is related to the previous paragraph: "I am very interested
> in all possible improvements in babel so that it integrates as best as
> possible with automatically generated files[...]"
That's good to hear. In practical terms, if Javier gives us some contact
email, we may CC him when we think that what we discuss is related to
Babel.
>> We can also provide multiple language name variants though I don't see a
>> need to bother unless we get user requests to do such thing.
>
> I agree. I even think it would be a good point to also include the
> vernacular name of each language.
Sounds reasonable. Although, let's come back to this when we have actual
code to discuss.
> By the way, Javier has also told me that he is going to consider the
> 'onchar=ids fonts' issue related to the case of several languages that
> use the same script (already discussed here in past messages).
That would be nice, although determining language may not be trivial.
AFAIK, automatic language detection often relies upon word frequencies
(for example, see https://pypi.org/project/langdetect/) and cannot be
reliable for very short text fragments. In the case of texts combining
multiple languages arbitrarily, the problem becomes even more difficult.
In some cases (dialects), multiple languages can be valid for the same
text fragment.
That said, frequency-based approach can mostly work well, except certain
edge cases. But it requires word corpus. I am not sure how feasible it
would be to include into TeX distribution. (Maybe not very hard - it is
already quite large and a few dictionary files will not change much).
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-25 21:57 7% ` Thomas S. Dye
@ 2023-09-26 15:39 0% ` Max Nikulin
2023-09-26 19:12 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-26 15:39 UTC (permalink / raw)
To: emacs-orgmode
On 26/09/2023 04:57, Thomas S. Dye wrote:
> Aloha all,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>>
>>> If so, Org should have native support of \DocumentMetadata, not
>>> LATEX_PRE_HEADER or something similar.
>>
>> If it were the only case of code before \documentclass, I would agree.
>> But, as I have already said above, the diversity of use cases makes the
>> implementation of /ad hoc/ solutions unviable, in my opinion.
>
> FWIW, I agree with Juan Manuel here and would welcome a straightforward
> way to insert material before the header.
I just have checked that a dirty hack with a few lines of code for
`org-export-filter-final-output-functions' allows to insert arbitrary
text to the beginning of export result. Perhaps a more elegant solution
exists, but I admit it is not a straightforward way. At least it is
possible.
I do not mind that generation of preamble should be more flexible, but I
consider LATEX_PRE_HEADER as an ad hoc solution, so I am trying to find
a better variant. That is why I asked for details concerning particular
use cases.
I remember recipes like "put \usepackage{cmap} immediately after
\documentclass" (nowadays this particular one should not be necessary).
So I would prefer to avoid keywords per each chunk of preamble code.
\begin{filecontents*} from the original post is not convincing.
\DocumentMetadata perhaps should be supported out of the box.
I would consider some kind of templates that use predefined fragments
#+LATEX_REPLACE_TEMPLATE: :preamble mypreamble
#+name: mypreamble
#+begin_src latex :exports none :noweb yes
\providecommand{\pdfxopts}{x-1a}
<<ox-latex-template-preamble>>
#+end_src
with ability to use fine grain snippets instead
#+LATEX_REPLACE_TEMPLATE: :preamble detailedpreamble
#+name: detailedpreamble
#+begin_src latex :exports none :noweb yes
<<ox-latex-template-DocumentMetadata>>
\PassOptionsToPackage...
<<ox-latex-template-documentclass>>
\usepackage{cmap}
\usepackage[english,<<ox-template-language>>]{babel}
<<ox-latex-template-usepackage>>
#+end_src
I hope, something similar may be made more readable than series of
LATEX_HEADER & Co lines.
^ permalink raw reply [relevance 0%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-26 15:39 0% ` Max Nikulin
@ 2023-09-26 19:12 9% ` Juan Manuel Macías
2023-09-28 10:07 4% ` Max Nikulin
2023-10-02 10:42 5% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-26 19:12 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Thomas S. Dye
Max Nikulin writes:
> I just have checked that a dirty hack with a few lines of code for
> `org-export-filter-final-output-functions' allows to insert arbitrary
> text to the beginning of export result. Perhaps a more elegant solution
> exists, but I admit it is not a straightforward way. At least it is
> possible.
And it is also possible by simply defining a new class (in Org
terminology, not LaTeX). My usual class is an almost empty one, without
documentclass and without packages, because I don't want org to write
the preamble for me. But I think this is not the point.
> I do not mind that generation of preamble should be more flexible, but I
> consider LATEX_PRE_HEADER as an ad hoc solution, so I am trying to find
> a better variant. That is why I asked for details concerning particular
> use cases.
IMHO, LaTeX_pre_header is obvious and transparent to the user: a version
of LaTeX_header that behaves exactly the same, except that it exports
the lines before \documentclass. It is simple and requires little code
to implement, and it is used for all cases of code before the
declaration of the class, since its syntax is consistent with
LaTeX_header. And its use does not require further explanation. You can
even play with constructions like:
#+NAME: pre
#+begin_src latex :exports none
(some stuff)
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_pre_header: <<pre>>
#+end_src
> I remember recipes like "put \usepackage{cmap} immediately after
> \documentclass" (nowadays this particular one should not be necessary).
> So I would prefer to avoid keywords per each chunk of preamble code.
I think that this would not be the case. This is not just any part of
the preamble, but a fairly definite part. Broadly speaking, LaTeX_header
would take care of what is after \documenclass (the axis of a LaTeX
document); LaTeX_pre_header would do it of anything that may have come
before. And both provide a less constricted preamble for advanced use of
LaTeX. Frankly, I can't think of a simpler solution.
> \begin{filecontents*} from the original post is not convincing.
Are you not convinced by some instructions that are included in the
official documentation of a LaTeX package (pdfx)?
https://i.imgur.com/NdLWmwc.png
The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-26 19:12 9% ` Juan Manuel Macías
@ 2023-09-28 10:07 4% ` Max Nikulin
2023-09-28 12:31 9% ` Juan Manuel Macías
2023-10-02 10:42 5% ` Max Nikulin
1 sibling, 2 replies; 200+ results
From: Max Nikulin @ 2023-09-28 10:07 UTC (permalink / raw)
To: emacs-orgmode
On 27/09/2023 02:12, Juan Manuel Macías wrote:
> Max Nikulin writes:
>> I remember recipes like "put \usepackage{cmap} immediately after
>> \documentclass" (nowadays this particular one should not be necessary).
>> So I would prefer to avoid keywords per each chunk of preamble code.
>
> I think that this would not be the case. This is not just any part of
> the preamble, but a fairly definite part. Broadly speaking, LaTeX_header
> would take care of what is after \documenclass (the axis of a LaTeX
> document); LaTeX_pre_header would do it of anything that may have come
> before. And both provide a less constricted preamble for advanced use of
> LaTeX. Frankly, I can't think of a simpler solution.
LaTeX code may be inserted
- before \DocumentMetadata
- between \DocumentMetadata and \documentclass
- between \documentclass and preamble added by Org
- between Org preamble and \begin{document}
Since ordering is important, I would prefer to assemble preamble from
predefined fragments (or replace particular ones) to putting code into
these (and probably more) slots.
>> \begin{filecontents*} from the original post is not convincing.
>
> Are you not convinced by some instructions that are included in the
> official documentation of a LaTeX package (pdfx)?
More I read about .xmpdata, more it looks similar to an ugly kludge from
my point of view. The following phrases are hardly consistent:
- "Including the metadata with the LATEX source is very convenient."
- "remember to remove the existing copy of \jobname.xmpdata file before
the next processing run".
(A side note: "overwrite" option of filecontents looks promising.)
So the goal is an XML document embedded into PDF. I admit, Org can not
provide it directly since e.g. PDF compliance level is responsibility of
a PDF engine.
However the intermediate .xmpdata file may be provided independently of
its .tex counterpart accordingly to docs. This file contains metadata
and in Org metadata are managed through keywords. Significant fraction
of metadata may be shared with HTML or MarkDown, so keywords should be
considered as primary data. Writing this file from Org (e.g. by a babel
source code block) should avoid issues with LaTeX input encodings
described in the docs. Thus generation of .xmpdata during exporting of
an .org file allows to keep metadata consistent.
Currently I do not see a way to get values of INFO argument of
org-export functions from source code blocks making access to metadata
tricky. This should be addressed somehow. I would consider specifying
metadata in a way similar to org-babel header arguments to allow more
fields than currently supported by Org. It should facilitate generation
of \DocumentMedata, .xmpdada, etc.
Ability to overwrite fragments of preamble should be supported, but only
as last resort. Specifying \DocumentMetadata or .xmpdata contents
literally should be avoided to prevent discrepancy with metadata keywords.
I consider \begin{filecontents*}{\jobname.xmpdata} as an acceptable (but
perhaps fragile) hack for LaTeX-first document. During export of Org
file, this file should be written directly with values from Org metadata.
^ permalink raw reply [relevance 4%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-28 10:07 4% ` Max Nikulin
@ 2023-09-28 12:31 9% ` Juan Manuel Macías
2023-09-29 2:38 5% ` Max Nikulin
2023-10-01 16:32 5% ` Max Nikulin
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-28 12:31 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> LaTeX code may be inserted
> - before \DocumentMetadata
> - between \DocumentMetadata and \documentclass
> - between \documentclass and preamble added by Org
> - between Org preamble and \begin{document}
The first two cases can be solved perfectly with LaTeX_pre_header,
without having to complicate your life further.
> Since ordering is important [...]
Starting with \documentclass, the order is important in certain cases
and not so important in others. And, anyway, you can always use a hook
like \AtBegin... \AtEnd..., etc.
And if users want to have complete control over the preamble (that is,
everything before \begin{document}), they can always define a new class
(in Org terminology) or write a preamble or a sty file in a separate Org
document using org-babel and literary programming. In a job I'm doing
now my preamble has 1736 lines. Writing it with org-babel is quite
comfortable. In short, I think (IMHO) Org already has enough resources
for those situations.
> I consider \begin{filecontents*}{\jobname.xmpdata} as an acceptable
> (but perhaps fragile) hack for LaTeX-first document. During export of
> Org file, this file should be written directly with values from Org
> metadata.
I think I should insist on what I said in my previous message, with a
copy/paste:
The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.
Apart from that, since any code (except \usepackage) is allowed before
\documentclass, I think that the user should have the possibility (and
the freedom) to enter in their *tex documents whatever they want in that
place, including comments, luacode, shebangs, etc.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-28 12:31 9% ` Juan Manuel Macías
@ 2023-09-29 2:38 5% ` Max Nikulin
2023-10-01 16:32 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2023-09-29 2:38 UTC (permalink / raw)
To: emacs-orgmode
On 28/09/2023 19:31, Juan Manuel Macías wrote:
> I think I should insist on what I said in my previous message, with a
> copy/paste:
>
> The thing is that here it is not a question of whether something can be
> done in this way or in another better way. This is how a given package
> recommends doing it. If the user wants to use that specific package, she/he
> will have to follow these instructions.
My reading of these instructions: users have 2 options, they either
provide .xmpdata files directly or they ask LaTeX to generate it using
filecontents* and take responsibility to remove the file when they
change metadata.
I do not see any words discouraging the former way, while there are
warnings concerning pitfalls with the latter approach that still may be
convenient in some cases.
> It's more. I am thinking, for
> example, of the case in which the user has to obtain a * tex file, not a
> PDF, because she/he is collaborating with more people who do not use
> Org, but do use that code in the * tex document.
Perhaps I am wrong in my assumption that in particular case of PDF-X
compliant documents, it is unlikely that it is just a single .tex
document. If there are more files: graphics, custom packages, included
.tex file then an additional separate .xmpdata file is not an issue.
^ permalink raw reply [relevance 5%]
* Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
@ 2023-10-01 15:08 7% Juan Manuel Macías
2023-10-01 18:07 12% ` Juan Manuel Macías
2023-10-02 13:10 5% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-01 15:08 UTC (permalink / raw)
To: orgmode
I don't know if this nomenclature issue that I'm going to raise is
excessively formalist, but here it goes.
Since the header arg :float now supports any string in inline images
exported to latex (that is, ':float foo' is exported as the environment
\begin{foo}…\end{foo}), the header arg :placement can be used for more
than just "placement". For example, this:
┌────
│ #+ATTR_LaTeX: :float minipage :placement {\textwidth}
│ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
└────
produces in LaTeX this:
┌────
│ \begin{minipage}{\textwidth}
│ \centering
│ \includegraphics[width=.9\linewidth]{/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg}
│ \end{minipage}
└────
(in this case :placement is exported as the required minipage argument,
which is its width).
An example of more "unexpected" (but very practical) uses is this one
with three subfigures and the subcaption package:
┌────
│ #+caption: Main caption
│ #+begin_figure
│ #+CAPTION: subcaption 1
│ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width \textwidth
│ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
│ @@latex:\vspace{2ex}@@
│ #+CAPTION: subcaption 2
│ #+ATTR_LaTeX: :float subfigure :placement {.4\textwidth} :center nil :width \textwidth
│ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
│ @@latex:\hfill@@
│ #+CAPTION: subcaption3
│ #+ATTR_LaTeX: :float subfigure :placement {.4\textwidth} :center nil :width \textwidth
│ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
│ #+end_figure
└────
(In all three subfigures, :placement is exported as the subfigure
environment argument, which designates the width of each subfigure).
I think this is a case where certain elements of Org have evolved
(consciously or unconsciously) ahead of the names, and these names have
become somewhat outdated. There is not only the case of :placement. Even
:float seems imprecise, since can be used to create a minipage, and the
minipage environment is not a float environment. Would it be worth
making those names obsolete (with backward compatibility, of course) and
replacing them with slightly more precise ones? I think that new names
would give the user an idea of more variety of uses, like the examples I
have put here.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-28 12:31 9% ` Juan Manuel Macías
2023-09-29 2:38 5% ` Max Nikulin
@ 2023-10-01 16:32 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2023-10-01 16:32 UTC (permalink / raw)
To: emacs-orgmode
On 28/09/2023 19:31, Juan Manuel Macías wrote:
> Starting with \documentclass, the order is important in certain cases
> and not so important in others. And, anyway, you can always use a hook
> like \AtBegin... \AtEnd..., etc.
I am judging from my past experience. Besides \usepackage{cmap} that was
necessary to be put immediately after \documentclass, there were issues
with order of \usepackage for hyperref and some other packages.
Custom commands may require some attention as well. There is an example
of reusing year in .xmpdata and document title in the pdfx docs. Such
cases may be more subtle. In the case of .xmpdata command must be
defined at the moment when the file is loaded, so it is not important
either command definition or \begin{filecontents*} placed first
(.xmpdata may be provided directly as well). In the case of
\DocumentMetadata it is not obvious if commands may defined later.
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-10-01 17:48 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-01 17:48 UTC (permalink / raw)
To: AW; +Cc: emacs-orgmode
Max Nikulin writes:
> On 28/09/2023 22:36, AW wrote:
>>
>> The idea to have a LATEX_PRE_HEADER to insert `\DocumentMetadata{}` is exactly
>> what you need right now, if you export from orgmode to current LaTeX. With
>> `\DocumentMetadata{}` you can add most of the necessary xmp data -- and I
>> write most, because I'm using it on a daily basis, but haven't checked if
>> really everything is included yet.
>
> The question is if Juan Manuel can use \DocumentMetadata instead of the
> pdfx package in his workflow.
I'm afraid that with the pdfx example that I put in the first post I
have caused a little confusion. pdfx is not part of my workflow. I only
used it once a long time ago. I've cited the code from that package here
as another example of arbitrary code that can be placed before
\documentclass. As I said, there are many more examples and possible
cases: \DocumentMetadata and \PassOptionsToPackage are two typical
cases. But, as I have already mentioned, /almost/ any LaTeX code can be
accommodated before class declaration. Even simple comments. Why not
think about a hypothetical case in which a user needs to create from Org
a *.tex file that contains comments before \documentclass? With a
LaTeX_pre_header keyword that would be possible.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-01 15:08 7% Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? Juan Manuel Macías
@ 2023-10-01 18:07 12% ` Juan Manuel Macías
2023-10-02 13:10 5% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-01 18:07 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> Since the header arg :float now supports any string in inline images[...]
Sorry, I meant "the LaTeX attribute :float ..."
^ permalink raw reply [relevance 12%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-26 19:12 9% ` Juan Manuel Macías
2023-09-28 10:07 4% ` Max Nikulin
@ 2023-10-02 10:42 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2023-10-02 10:42 UTC (permalink / raw)
To: emacs-orgmode
On 27/09/2023 02:12, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> I just have checked that a dirty hack with a few lines of code for
>> `org-export-filter-final-output-functions' allows to insert arbitrary
>> text to the beginning of export result. Perhaps a more elegant solution
>> exists, but I admit it is not a straightforward way. At least it is
>> possible.
>
> And it is also possible by simply defining a new class (in Org
> terminology, not LaTeX). My usual class is an almost empty one, without
> documentclass and without packages, because I don't want org to write
> the preamble for me. But I think this is not the point.
LATEX_PRE_HEADER you proposed is a document-local setting while
`org-latex-classes' is shared by all Org documents. In that hack I used
a buffer-local variable to achieve document-specific fragment.
In the specific cases of \DocumentMetadata and .xmpdata,
LATEX_PRE_HEADER needs to be passed through `format-spec' with result of
`org-latex--format-spec' call to get notion of Org metadata. Whether it
is necessary for \PassOptionsToPackage depends on particular cases. If
such options do not vary across documents then certainly
`org-latex-classes' becomes viable.
I do not like "[NO-PACKAGES]" and similar keywords to suppress adding of
some code snippets. That is why I believe it is better to seek for
another approach to generate LaTeX preamble. I have not had a look into
Timothy's code yet, so I can say nothing concerning its flexibility in
respect to substituting metadata into code before \documentclass.
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-01 15:08 7% Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? Juan Manuel Macías
2023-10-01 18:07 12% ` Juan Manuel Macías
@ 2023-10-02 13:10 5% ` Ihor Radchenko
2023-10-02 14:55 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-02 13:10 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> An example of more "unexpected" (but very practical) uses is this one
> with three subfigures and the subcaption package:
>
> ┌────
> │ #+caption: Main caption
> │ #+begin_figure
> │ #+CAPTION: subcaption 1
> │ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width \textwidth
> │ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
> ...
> I think this is a case where certain elements of Org have evolved
> (consciously or unconsciously) ahead of the names, and these names have
> become somewhat outdated. There is not only the case of :placement. Even
> :float seems imprecise, since can be used to create a minipage, and the
> minipage environment is not a float environment. Would it be worth
> making those names obsolete (with backward compatibility, of course) and
> replacing them with slightly more precise ones? I think that new names
> would give the user an idea of more variety of uses, like the examples I
> have put here.
I am not sure about obsolete - I see not reason to obsolete the intended
use case. Your example is rather an abuse.
What we might do it to introduce something like a new :wrap attribute:
#+attr_latex: :wrap subfigure,{\textwidht}
I think we have discussed something similar in the past, but more
generic - allow wrapping arbitrary Org elements (headings, drawers,
paragraphs, etc) on export.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-02 13:10 5% ` Ihor Radchenko
@ 2023-10-02 14:55 9% ` Juan Manuel Macías
2023-10-04 9:12 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-02 14:55 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> ┌────
>> │ #+caption: Main caption
>> │ #+begin_figure
>> │ #+CAPTION: subcaption 1
>> │ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width \textwidth
>> │ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
>> ...
>> I think this is a case where certain elements of Org have evolved
>> (consciously or unconsciously) ahead of the names, and these names have
>> become somewhat outdated. There is not only the case of :placement. Even
>> :float seems imprecise, since can be used to create a minipage, and the
>> minipage environment is not a float environment. Would it be worth
>> making those names obsolete (with backward compatibility, of course) and
>> replacing them with slightly more precise ones? I think that new names
>> would give the user an idea of more variety of uses, like the examples I
>> have put here.
>
> I am not sure about obsolete - I see not reason to obsolete the intended
> use case. Your example is rather an abuse.
Why abuse? First, it works like a charm. Second, if :float can support
any string as an environment name, why not minipage or subfigure? As for
:placement, the term would seem more precise to me if it were really
"placement" (as :align in tables is actually "align"), not LaTeX code
passed directly after the \begin{...}. That a user can put things like
this (I do it often, and I think I'm not the only one):
:placement [htbp]\SomeExtraLaTeXCode...
it is a consequence of the above. It is not an "orthodox" use (I mean,
it's not described in the manual), but it works without problems. Again,
I don't want to seem too picky about the names, but a user who doesn't
understand the source code might think that :placement only supports
things like [htbp]. My idea here is: instead of implementing new
features, recycle and take advantage of those that arise unexpectedly
:-). Although :placement was created thinking about putting code related
to placement figures, as it is implemented I would have called it
:latex-code or something similar.
> What we might do it to introduce something like a new :wrap attribute:
>
> #+attr_latex: :wrap subfigure,{\textwidht}
That would be nice if with a single latex_attr line you could export a
single figure environment for several images, since every subfigure
environment must be inside a figure environment. And putting a single
subfigure inside a figure environment doesn't make much sense. Other
than that, the idea of :wrap is good. I find it very useful, especially
on tables.
> I think we have discussed something similar in the past, but more
> generic - allow wrapping arbitrary Org elements (headings, drawers,
> paragraphs, etc) on export.
I remember that thread. In fact, I think I created a TODO to study that,
but due to lack of time I haven't been able to take a look at it.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-02 14:55 9% ` Juan Manuel Macías
@ 2023-10-04 9:12 5% ` Ihor Radchenko
2023-10-04 14:34 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-04 9:12 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I am not sure about obsolete - I see not reason to obsolete the intended
>> use case. Your example is rather an abuse.
>
> Why abuse? First, it works like a charm. Second, if :float can support
> any string as an environment name, why not minipage or subfigure? As for
> :placement, the term would seem more precise to me if it were really
> "placement" (as :align in tables is actually "align"), not LaTeX code
> passed directly after the \begin{...}. That a user can put things like
> this (I do it often, and I think I'm not the only one):
>
> :placement [htbp]\SomeExtraLaTeXCode...
>
> it is a consequence of the above. It is not an "orthodox" use (I mean,
> it's not described in the manual), but it works without problems. Again,
> I don't want to seem too picky about the names, but a user who doesn't
> understand the source code might think that :placement only supports
> things like [htbp]. My idea here is: instead of implementing new
> features, recycle and take advantage of those that arise unexpectedly
> :-). Although :placement was created thinking about putting code related
> to placement figures, as it is implemented I would have called it
> :latex-code or something similar.
:float is only used for (1) tables; (2) src-blocks; (3) inline images
that are a sole element in their paragraph. But not for other Org syntax
elements - you cannot, for example, wrap a paragraph or heading into
custom environment with :float.
Further, we also provide :environment and :options attributes that do
the same thing, but without special treatment of standard
t/multicolumn/wrap/sideways/nil values in :float.
>> What we might do it to introduce something like a new :wrap attribute:
>>
>> #+attr_latex: :wrap subfigure,{\textwidht}
So, it might be even better idea to extend :environment/:options
attributes to more elements - their names make more sense and the values
do not have a pre-defined special meanings.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-04 9:12 5% ` Ihor Radchenko
@ 2023-10-04 14:34 11% ` Juan Manuel Macías
2023-10-06 16:29 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-04 14:34 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Further, we also provide :environment and :options attributes that do
> the same thing, but without special treatment of standard
> t/multicolumn/wrap/sideways/nil values in :float.
t/multicolumn/wrap/sideways/nil... and any arbitrary value (see lines 14125
and 14262 in org-manual.org).
>>> What we might do it to introduce something like a new :wrap attribute:
>>>
>>> #+attr_latex: :wrap subfigure,{\textwidht}
>
> So, it might be even better idea to extend :environment/:options
> attributes to more elements - their names make more sense and the values
> do not have a pre-defined special meanings.
Currently it is not possible in inline images (if I don't miss anything) this:
#+ATTR_LaTeX: :environment minipage :options {\textwidth}
[[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
Implementing :environment/:options here would result in redundancy with:
#+ATTR_LaTeX: :float minipage :placement {\textwidth}
[[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
which produces the same.
In tables there is more consistency because :float is a float
environment (table or any arbitrary value) and :environment is a table
environment (tabular or any arbitrary value). Here :placement :options
and :align act as what is expected of them:
#+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
|a|a|a|a|
===>
\begin{var}[!h]
\centering
\begin{foo}[blah]{cccc}
a & a & a & a\\[0pt]
\end{foo}
\end{var}
\end{document}
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* [proof of concept, tip] 'Templates with arguments' using org src blocks
@ 2023-10-06 8:07 11% Juan Manuel Macías
2023-10-13 16:00 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-06 8:07 UTC (permalink / raw)
To: orgmode
Hi, this is a proof of concept of how a sort of 'templates with
arguments' can be used within Org, just with Org’s own resources at the
user level. It occurred to me that org src blocks might be handy for
this. For this test I just made a disguised format string using this
function:
┌────
│ (defun my-format-template (template vars)
│ (format
│"#+begin_src emacs-lisp :results raw :exports results :var template = %s
│ (format
│ (format \"%%s\" template)
│ %s)
│ #+end_src" template vars))
└────
and a macro:
┌────
│ #+MACRO: template (eval (my-format-template $1 $2))
└────
A simple example. We start from this template:
┌────
│ #+NAME: template1
│ #+begin_src org :exports none
│ ,*%s*
│ %s
│ #+end_src
│
│ #+header: :var hello = "Hello World"
│ #+header: :var str = "Lorem ipsum dolor"
│ {{{template(template1,hello str)}}}
└────
An example with a src block inside the template:
┌────
│ #+NAME: template2
│ #+begin_src org :exports none
│ ,#+begin_src emacs-lisp :exports results :results raw
│ (let ((name "%s"))
│ (format "/Hello, %%s/" name))
│ ,#+end_src
│ #+end_src
│
│ #+header: :var name = "World"
│ {{{template(template2,name)}}}
└────
And this example is somewhat more elaborate. We want a table in LaTeX
with the threeparttable package. Template:
┌────
│ #+NAME: tptable
│ #+begin_src org :exports none
│ ,#+begin_table
│ ,#+ATTR_LaTeX: :options [b]
│ ,#+begin_threeparttable
│ %s
│ ,#+begin_tablenotes
│ %s
│ ,#+end_tablenotes
│ ,#+end_threeparttable
│ ,#+end_table
│ #+end_src
└────
the table:
┌────
│ #+NAME: table1
│ #+begin_src org :exports none
│ ,#+ATTR_LaTeX: :center nil :booktabs t :float nil
│ ,#+caption: Lorem ipsum dolor
│ ,#+name: table1
│ |-------+--------------------------+-------|
│ | lorem | ipsum@@latex:\tnote{1}@@ | dolor |
│ | lorem | ipsum@@latex:\tnote{2}@@ | dolor |
│ |-------+--------------------------+-------|
│ #+end_src
└────
And, finally:
┌────
│ #+header: :var table = table1
│ #+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
│ {{{template(tptable,table notes)}}}
└────
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-04 14:34 11% ` Juan Manuel Macías
@ 2023-10-06 16:29 5% ` Ihor Radchenko
2023-10-06 18:35 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-06 16:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> Further, we also provide :environment and :options attributes that do
>> the same thing, but without special treatment of standard
>> t/multicolumn/wrap/sideways/nil values in :float.
>
> t/multicolumn/wrap/sideways/nil... and any arbitrary value (see lines 14125
> and 14262 in org-manual.org).
My point is that actual "t", "multicolumn", "wrap", "sideways", and
"nil" LaTeX environments are not allowed.
>> So, it might be even better idea to extend :environment/:options
>> attributes to more elements - their names make more sense and the values
>> do not have a pre-defined special meanings.
>
> Currently it is not possible in inline images (if I don't miss anything) this:
>
> #+ATTR_LaTeX: :environment minipage :options {\textwidth}
> [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
Sure. But we might as well implement :environment support in addition to :float.
> Implementing :environment/:options here would result in redundancy with:
>
> #+ATTR_LaTeX: :float minipage :placement {\textwidth}
> [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
>
> which produces the same.
Sure. But didn't you motivate the change with the confusing _name_
:float? IMHO, :environment is more clear.
> In tables there is more consistency because :float is a float
> environment (table or any arbitrary value) and :environment is a table
> environment (tabular or any arbitrary value). Here :placement :options
> and :align act as what is expected of them:
>
> #+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
> |a|a|a|a|
>
> ===>
>
> \begin{var}[!h]
> \centering
> \begin{foo}[blah]{cccc}
> a & a & a & a\\[0pt]
> \end{foo}
> \end{var}
> \end{document}
This is not documented and is possibly a bug.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-06 16:29 5% ` Ihor Radchenko
@ 2023-10-06 18:35 5% ` Juan Manuel Macías
2023-10-06 19:49 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-06 18:35 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> In tables there is more consistency because :float is a float
>> environment (table or any arbitrary value) and :environment is a table
>> environment (tabular or any arbitrary value). Here :placement :options
>> and :align act as what is expected of them:
>>
>> #+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
>> |a|a|a|a|
>>
>> ===>
>>
>> \begin{var}[!h]
>> \centering
>> \begin{foo}[blah]{cccc}
>> a & a & a & a\\[0pt]
>> \end{foo}
>> \end{var}
>> \end{document}
>
> This is not documented and is possibly a bug.
I would say that it is the expected behavior: :float is for a float
environment and :environment is for the environment that builds the
table (by default tabular). According to the manual:
#+begin_quote
The table environments by default are not floats in LaTeX. To make
them floating objects use =:float= with one of the following
options: =t= (for a default =table= environment), =sideways= (for a
=sidewaystable= environment), =multicolumn= [...] and
=nil=. In addition to these three values, =:float= can pass through
any arbitrary value, for example a user-defined float type with the
=float= LaTeX package
#+end_quote
and (for :environment):
#+begin_quote
Set the default LaTeX table environment for the LaTeX export
backend to use when exporting Org tables. Common LaTeX table
environments are provided by these packages: tabularx, longtable,
array, tabu, and bmatrix. For packages, such as tabularx and tabu,
or any newer replacements
#+end_quote
The difference is that with images, except in cases of somewhat more
complex constructions where there are subfigures, there is only one
environment, "figure" by default or any other arbitrary one. There was a
commit a while ago, I don't remember when, that allowed :float to
support any arbitrary string as the float environment name, in images
and tables. In images ':float t' is figure (by default) and in tables it
is table (also by default).
Update: ah, I already have the commit located, because I also remember
that I myself sent a patch to update the documentation and correct a
regression that that commit introduced (:float t produced an environment
"t" (\begin{t}...\end{t}):
https://list.orgmode.org/878ruhrvfq.fsf@posteo.net/
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-06 18:35 5% ` Juan Manuel Macías
@ 2023-10-06 19:49 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-10-06 19:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>>> In tables there is more consistency because :float is a float
>>> environment (table or any arbitrary value) and :environment is a table
>>> environment (tabular or any arbitrary value). Here :placement :options
>>> and :align act as what is expected of them:
>>>
>>> #+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
>>> |a|a|a|a|
>> ...
>> This is not documented and is possibly a bug.
>
> I would say that it is the expected behavior: :float is for a float
> environment and :environment is for the environment that builds the
> table (by default tabular). According to the manual:
Oops. You are indeed right. I missed that both :float and :environment
are documented for tables.
> The difference is that with images, except in cases of somewhat more
> complex constructions where there are subfigures, there is only one
> environment, "figure" by default or any other arbitrary one. There was a
> commit a while ago, I don't remember when, that allowed :float to
> support any arbitrary string as the float environment name, in images
> and tables. In images ':float t' is figure (by default) and in tables it
> is table (also by default).
So, the difference between :environment and :float is that :float also
encapsulates \caption in addition to the actual environment (like
tabularx or includegraphics) used for transcoded exported element.
I can see how :float+:placement can be imprecise and that the existing
:environment indeed serves a different purpose. (It might be worth
clarifying this distinction in the manual - it seems arbitrary from the
first glance).
But what would be the better name then?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Pandoc and nested emhases
@ 2023-10-11 16:11 6% ` Max Nikulin
2023-10-22 19:15 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-10-11 16:11 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
It was long time ago...
On 18/02/2022 07:47, Juan Manuel Macías wrote:
> Otherwise, if you export to LaTeX with pandoc (v. 2.14.2), the result is
> (to my surprise) correct:
>
> #+begin_src sh :results latex
> str="/lorem /ipsum/ dolor/"
> pandoc -f org -t latex <<< $str
> #+end_src
>
> #+RESULTS:
> #+begin_export latex
> \emph{lorem \emph{ipsum} dolor}
> #+end_export
Nesting of the same emphasis style may be achieved with Org parser as well:
(org-export-string-as
"/lorem /ipsum// /dolor/"
'latex t)
"\\emph{lorem \\emph{ipsum}} \\emph{dolor}
"
Namely closing markers should be combined. See the recent thread
Tom Alexander to emacs-orgmode. Inconsistent text markup handling when
double-nesting markers. Mon, 09 Oct 2023 19:02:18 -0400.
https://list.orgmode.org/dad964f5-c764-4dd5-9829-ca38e3fbeb0d@app.fastmail.com
^ permalink raw reply [relevance 6%]
* Re: [proof of concept, tip] 'Templates with arguments' using org src blocks
2023-10-06 8:07 11% [proof of concept, tip] 'Templates with arguments' using org src blocks Juan Manuel Macías
@ 2023-10-13 16:00 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-10-13 16:00 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
On 06/10/2023 15:07, Juan Manuel Macías wrote:
> And, finally:
>
> ┌────
> │ #+header: :var table = table1
> │ #+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
> │ {{{template(tptable,table notes)}}}
> └────
Usage is quite close to "#+call:", but it does not support specifying
arguments using "#+header:"
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-org.html
I would still consider noweb (table1 is omitted):
--- 8< ---
#+property: header-args:org :exports results :results replace :noweb yes
#+NAME: tptable
#+begin_src org :exports none
,#+begin_table
,#+ATTR_LaTeX: :options [b]
,#+begin_threeparttable
$table
,#+begin_tablenotes
$notes
,#+end_tablenotes
,#+end_threeparttable
,#+end_table
#+end_src
#+header: :var table = table1
#+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
#+begin_src org
<<tptable>>
#+end_src
--- >8 ---
or "%(param)s" substitutions in python (another variant f"""{param}"""
is inconvenient for LaTeX):
--- 8< ---
#+property: header-args:python :python python3 :results org :noweb yes
:exports results
#+property: header-args:org :exports results :results replace
#+NAME: tptable
#+begin_src python :exports none
return """\
,#+begin_table
,#+ATTR_LaTeX: :options [b]
,#+begin_threeparttable
%(table)s
,#+begin_tablenotes
%(notes)s
,#+end_tablenotes
,#+end_threeparttable
,#+end_table
""" % locals()
#+end_src
#+header: :var table = table1
#+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
#+begin_src python
<<tptable>>
#+end_src
--- >8 ---
^ permalink raw reply [relevance 5%]
* Re: Pandoc and nested emhases
2023-10-11 16:11 6% ` Max Nikulin
@ 2023-10-22 19:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-22 19:15 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Sorry for the late reply. I haven't had much time these days to
keep up with the list...
Max Nikulin writes:
> It was long time ago...
>
> On 18/02/2022 07:47, Juan Manuel Macías wrote:
>> Otherwise, if you export to LaTeX with pandoc (v. 2.14.2), the result is
>> (to my surprise) correct:
>> #+begin_src sh :results latex
>> str="/lorem /ipsum/ dolor/"
>> pandoc -f org -t latex <<< $str
>> #+end_src
>> #+RESULTS:
>> #+begin_export latex
>> \emph{lorem \emph{ipsum} dolor}
>> #+end_export
>
> Nesting of the same emphasis style may be achieved with Org parser as well:
>
> (org-export-string-as
> "/lorem /ipsum// /dolor/"
> 'latex t)
> "\\emph{lorem \\emph{ipsum}} \\emph{dolor}
> "
>
> Namely closing markers should be combined. See the recent thread
> Tom Alexander to emacs-orgmode. Inconsistent text markup handling when
> double-nesting markers. Mon, 09 Oct 2023 19:02:18 -0400.
> https://list.orgmode.org/dad964f5-c764-4dd5-9829-ca38e3fbeb0d@app.fastmail.com
Interesting. So it should be understood that in Org syntax this dummy
title would be possible:
/Essays on Homer's /Odyssey//
==>
\emph{Essays on Homer's \emph{Odyssey}}
but not this other one:
/Essays on Homer's /Odyssey/. Part One/
\emph{Essays on Homer's /Odyssey}. Part One/
In any case, as Ihor commented in the thread you link, and as you also
commented in the other old thread of my discovery about Pandoc, this
behavior of Pandoc should be understood as a bug since it does not
respect the Org syntax. Although the previous example leaves me a little
perplexed.
Actually, I think nested emphases of equal category are not that
necessary. In general, putting something like \textbf{lorem
\textbf{ipsum} dolor} in LaTeX doesn't make much sense, because \textbf
is not a switch. It would only make sense with the LaTeX \emph command,
which, contrary to what some may think, is not used to put text in
italics (that's what \textit is for), but to emphasize a text according
to the context: if the context is in normal font, italics; and vice
versa. If I don't miss anything, I think there is nothing similar in
either html or odt/docx.
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
@ 2023-10-22 21:12 9% Juan Manuel Macías
2023-10-23 9:27 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-22 21:12 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor, sorry for the late reply.
Ihor Radchenko writes:
> So, the difference between :environment and :float is that :float also
> encapsulates \caption in addition to the actual environment (like
> tabularx or includegraphics) used for transcoded exported element.
> I can see how :float+:placement can be imprecise and that the existing
> :environment indeed serves a different purpose. (It might be worth
> clarifying this distinction in the manual - it seems arbitrary from
> the first glance).
> But what would be the better name then?
I think the problem is limited to images, where there is no "double"
environment as in the case of tables (float environment that encloses an
environment to generate the table, and :placement points to the correct
environment). In the case of images, I am afraid that the new features
have advanced the meaning of the old ones. Previously, :float only
supported t/nil ("figure" by default, in case of t) along with a few
explicit "float" environments, such as sidewaysfigure or wrapfigure.
Since :float now can accept any string as an environment name, Pandora's
box has been opened and the meaning of the old :float has been left
behind: for example, we can put :float minipage, and minipage is not a
float environment. Something similar has happened to :placement.
My suggestion is to add a :environment attribute next to another
:environment-options attr (or something like that, to introduce any
arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
types, float or non-float. However, :float can still be useful for
certain combinations. For example, a minipage environment cannot include
a caption (it produces an error of the type "LaTeX Error: \caption
outside float"). Then you would have to put something like
#+ATTR_LaTeX: :float nil :environment minipage :environment-options {\linewidth}
#+CAPTION: caption
[[file:foo.png]]
==>
\begin{minipage}{\linewidth}
\includegraphics[width=.9\linewidth]{foo.png}
\captionof{figure}{caption}
\end{minipage}
Anyway, I find pros and cons of all this:
- pros: a intended feature is added, although with :float and :placement
the same thing can be achieved (sometimes), but here the effect is not
intended (in origin).
- cons: redundancy, more complexity in the code (and probably more confusion for the user?).
--
Juan Manuel Macías
^ permalink raw reply [relevance 9%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
2023-10-22 21:12 9% Are 'placement' and 'float' "obsolete terms" in inline images export Juan Manuel Macías
@ 2023-10-23 9:27 5% ` Ihor Radchenko
2023-10-23 19:00 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-23 9:27 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> So, the difference between :environment and :float is that :float also
>> encapsulates \caption in addition to the actual environment (like
>> tabularx or includegraphics) used for transcoded exported element.
>
>> I can see how :float+:placement can be imprecise and that the existing
>> :environment indeed serves a different purpose. (It might be worth
>> clarifying this distinction in the manual - it seems arbitrary from
>> the first glance).
>
>> But what would be the better name then?
>
> I think the problem is limited to images, where there is no "double"
> environment as in the case of tables (float environment that encloses an
> environment to generate the table, and :placement points to the correct
> environment).
IMHO, an equivalent of :environment for images is
\includegraphics or \includesvg.
> ... In the case of images, I am afraid that the new features
> have advanced the meaning of the old ones. Previously, :float only
> supported t/nil ("figure" by default, in case of t) along with a few
> explicit "float" environments, such as sidewaysfigure or wrapfigure.
> Since :float now can accept any string as an environment name, Pandora's
> box has been opened and the meaning of the old :float has been left
> behind: for example, we can put :float minipage, and minipage is not a
> float environment. Something similar has happened to :placement.
>
> My suggestion is to add a :environment attribute next to another
> :environment-options attr (or something like that, to introduce any
> arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
> types, float or non-float.
As I said above, I feel that :environment term will be overloaded then.
What about :wrap?
> ... However, :float can still be useful for
> certain combinations. For example, a minipage environment cannot include
> a caption (it produces an error of the type "LaTeX Error: \caption
> outside float").
Do we know in advance which environments support \caption and which not?
I feel that we may handle this programmatically without creating an array
of almost-identical attributes.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
2023-10-23 9:27 5% ` Ihor Radchenko
@ 2023-10-23 19:00 10% ` Juan Manuel Macías
2023-10-26 9:14 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-23 19:00 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> My suggestion is to add a :environment attribute next to another
>> :environment-options attr (or something like that, to introduce any
>> arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
>> types, float or non-float.
>
> As I said above, I feel that :environment term will be overloaded then.
> What about :wrap?
I like :wrap. What's more, remembering that old thread where
some questions about code before/after the image were discussed,
what if the expected value of :wrap were a kind of template? This would
allow code to be placed before and/or after (not just an environment)
the image, always within the float environment, if it exists. Something
like this:
#+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage}
#+CAPTION: caption
[[file:foo.png]]
Thus :caption with value nil does not add any higher float environment
and would enclose (always within the template) the value of #+CAPTION as
\captionof{figure}{caption}. Of course, with a float environment
declared, :wrap can still be used. An internal environment is unlikely
(I can't think of any use case right now), but you can add arbitrary
code like \captionsetup{} or \ContinuedFloat, which should always go
inside the float environment.
The result of the previous example could also be obtained with:
#+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{figure}{caption}
[[file:foo.png]]
I don't know if it would be appropriate to explain in the Manual that
doing so would not be... "correct"? I don't know if there is any term in
programming to designate these situations which, without being bugs, are
functionalities not consciously sought...
>> ... However, :float can still be useful for
>> certain combinations. For example, a minipage environment cannot include
>> a caption (it produces an error of the type "LaTeX Error: \caption
>> outside float").
>
> Do we know in advance which environments support \caption and which not?
> I feel that we may handle this programmatically without creating an array
> of almost-identical attributes.
I like the idea, but unfortunately, apart from the known float
environments, there are those that a user can define using the \newfloat
command from the float package.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
2023-10-23 19:00 10% ` Juan Manuel Macías
@ 2023-10-26 9:14 5% ` Ihor Radchenko
2024-01-02 21:43 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-26 9:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> What about :wrap?
>
> I like :wrap. What's more, remembering that old thread where
> some questions about code before/after the image were discussed,
> what if the expected value of :wrap were a kind of template? This would
> allow code to be placed before and/or after (not just an environment)
> the image, always within the float environment, if it exists. Something
> like this:
>
> #+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage}
> #+CAPTION: caption
> [[file:foo.png]]
> ...
> #+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{figure}{caption}
> [[file:foo.png]]
>
> I don't know if it would be appropriate to explain in the Manual that
> doing so would not be... "correct"? I don't know if there is any term in
> programming to designate these situations which, without being bugs, are
> functionalities not consciously sought...
What about making :wrap override :float completely + obsoleting :float.
We can allow wrap to have special values like in float:
:wrap t/:wrap multicolumn/:wrap sideways
With these special values, :placement will be taken into account.
Further, we can make templates a bit more detailed.
Starting from similar to what you proposed in the above
:wrap \begin{minipage}[b]{10pc}\small\n%{body}\n\end{minipage}
to more granular control over caption, centering, comment-include,
and image-code:
%{caption} %{caption-text} %{centering} %{comment} %{comment-text}
%{image} %{image-path}.
If the :wrap text does not contain %{...} placeholder, it will be
treated as what :float artbirary-environment does.
We may even consider something like
#+name: latex-template
#+begin_src latex :export none
\begin{minipage}[b]{10pc}\small
%{body}
\end{minipage}
#+end_src
#+attr_latex: :wrap latex-template[]
As a bonus, :wrap may allow prepending/appending arbitrary code to
headings:
* Heading starting at a new page
:PROPERTIES:
:ATTR_LATEX: :wrap \clarpage%{default}
:END:
>>> ... However, :float can still be useful for
>>> certain combinations. For example, a minipage environment cannot include
>>> a caption (it produces an error of the type "LaTeX Error: \caption
>>> outside float").
>>
>> Do we know in advance which environments support \caption and which not?
>> I feel that we may handle this programmatically without creating an array
>> of almost-identical attributes.
>
> I like the idea, but unfortunately, apart from the known float
> environments, there are those that a user can define using the \newfloat
> command from the float package.
We might also consider :caption-template \captionof{figure}{%{caption-text}}
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Regression in latex export of tables?
@ 2023-11-03 2:30 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-11-03 2:30 UTC (permalink / raw)
To: emacs-orgmode
On 03/11/2023 07:58, Vikas Rawal wrote:
> Earlier version gives me this:
> \begin{center}
> \begin{tabular}{ll}
> (a,b) & open interval\\\empty
> [0,1] & closed interval\\\empty
It was changed to avoid your inconvenience:
https://list.orgmode.org/874jw2conh.fsf@posteo.net/T/#u
Juan Manuel Macías. Re: Line breaks and brackets in LaTeX export. Mon,
17 Oct 2022 18:04:34 +0000
That moment there was no hope that tabularray would support \empty out
of the box. Perhaps some stable Linux distribution still have its
version unaware of \empty.
> (defun org-export-midrule-filter-latex (row backend info)
> (replace-regexp-in-string
> "\\(<mid>\\([[:blank:]]+\\&\\)+\\)[[:blank:]]\\\\\\\\" "\\\\midrule" row))
>
> Now my \midrule becomes \midrule[0pt].
Sorry, but your have to adjust the pattern and the replacement string to
allow either optional \empty or [0pt].
I still do not see a better solution that does not require substantional
changes of the org-export framework.
^ permalink raw reply [relevance 5%]
* Re: Links & images with different attributes in the same paragraph
@ 2023-12-16 8:06 5% ` Max Nikulin
2023-12-16 14:44 0% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-12-16 8:06 UTC (permalink / raw)
To: emacs-orgmode
On 14/12/2023 22:23, Ihor Radchenko wrote:
>
> Not necessarily. The current parser also allows balanced brackets inside
> an object.
Thanks, I forgot about it. Balancing of brackets alleviates the issue
with nested objects. I am unsure if it is still pure top-down parser,
but it does not matter.
> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
Are you assuming invisible zero-width space as a way to escape literal
{{ or }}? I would prefer some visible characters.
> As you see, my solution is conceptually similar to #+begin_quote1 idea.
It is better since balanced delimiters make adding unique suffix to
#+begin_... and #+end... unnecessary.
> What about @wrap[#+attr_html: :alt "Text"]{[[/path/to/image]]}?
Leaving aside precise syntax (that perhaps should be discussed in
another thread), it solves the issue.
Do you have any idea how to address the following complain?
https://list.orgmode.org/orgmode/875ykwvmz7.fsf@posteo.net
Juan Manuel Macías. Re: About 'inline special blocks' Sun, 19 Jun 2022
12:47:40 +0000
> Bringing that into the paragraph is
> unnecessarily overloading the paragraph and breaking the social contract
> of lightweight markup, where paragraphs should still look like
> paragraphs.
I consider it as a valid point, so I tried to take advantage of noweb
features. I am in doubts concerning *evaluation* of expressions in
addition to just substitutions. It allows to implement another kind of
#+link: macro, but it gives too much power to my taste.
^ permalink raw reply [relevance 5%]
* Re: Links & images with different attributes in the same paragraph
2023-12-16 8:06 5% ` Max Nikulin
@ 2023-12-16 14:44 0% ` Ihor Radchenko
2023-12-19 14:39 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-12-16 14:44 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
>> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
>
> Are you assuming invisible zero-width space as a way to escape literal
> {{ or }}? I would prefer some visible characters.
No, not zero-width space. Literally, {{...}}. The idea is to define
delimiters as "[{]+" the matching number of "}". This way, we do not
need to worry about escaping "}" inside and can get nested markup for
free. It is more or less how Org parser works for special block:
the opening delimiter is #+begin_whatever is matched against
#+end_<same as opening delimiter>.
Also, see https://list.orgmode.org/orgmode/87mtaez8do.fsf@localhost/
with my original proposal and some discussion that followed up.
>> What about @wrap[#+attr_html: :alt "Text"]{[[/path/to/image]]}?
>
> Leaving aside precise syntax (that perhaps should be discussed in
> another thread), it solves the issue.
>
> Do you have any idea how to address the following complain?
>
> https://list.orgmode.org/orgmode/875ykwvmz7.fsf@posteo.net
> Juan Manuel Macías. Re: About 'inline special blocks' Sun, 19 Jun 2022
> 12:47:40 +0000
>> Bringing that into the paragraph is
>> unnecessarily overloading the paragraph and breaking the social contract
>> of lightweight markup, where paragraphs should still look like
>> paragraphs.
>
> I consider it as a valid point, so I tried to take advantage of noweb
> features. I am in doubts concerning *evaluation* of expressions in
> addition to just substitutions. It allows to implement another kind of
> #+link: macro, but it gives too much power to my taste.
I am pretty sure that I replied to that concern raised in a parallel
thread. My idea was to allow macro replacement inside attributes:
#+macro: alt #+attr_html :alt $1
What about @wrap[<<<alt(Text)>>>]{[[/path/to/image]]}
Or even inline definition like
#+@macro: alt @wrap[@+attr_html :alt $1]
What about @alt[Text]{[[/path/to/image]]}
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 0%]
* Re: Links & images with different attributes in the same paragraph
2023-12-16 14:44 0% ` Ihor Radchenko
@ 2023-12-19 14:39 0% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-12-19 14:39 UTC (permalink / raw)
To: emacs-orgmode
On 16/12/2023 21:44, Ihor Radchenko wrote:
> Max Nikulin writes:
>
>>> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
>>
>> Are you assuming invisible zero-width space as a way to escape literal
>> {{ or }}? I would prefer some visible characters.
>
> No, not zero-width space. Literally, {{...}}. The idea is to define
> delimiters as "[{]+" the matching number of "}". This way, we do not
> need to worry about escaping "}" inside and can get nested markup for
> free. It is more or less how Org parser works for special block:
> the opening delimiter is #+begin_whatever is matched against
> #+end_<same as opening delimiter>.
I am afraid, there is an issue if wrapped content is surrounded by
braces. An ambiguity arises for
@wrap{{{content}}}
it may be @wrap{{{ content }}}, @wrap{{ {content} }},
or @wrap{ {{content}} }. It seems, some escape character is unavoidable.
> Also, see https://list.orgmode.org/orgmode/87mtaez8do.fsf@localhost/
> with my original proposal and some discussion that followed up.
I completely forgot that you wrote about balanced parenthesis earlier.
>> Juan Manuel Macías. Re: About 'inline special blocks'
>>> Bringing that into the paragraph is
>>> unnecessarily overloading the paragraph and breaking the social contract
>>> of lightweight markup, where paragraphs should still look like
>>> paragraphs.
> I am pretty sure that I replied to that concern raised in a parallel
> thread. My idea was to allow macro replacement inside attributes:
>
> #+macro: alt #+attr_html :alt $1
> What about @wrap[<<<alt(Text)>>>]{[[/path/to/image]]}
Certainly it allows to shorten in-text arguments. Just as noweb
references, it has some disadvantages. I consider comma as macro
argument separator as a kind of a pitfall. Macro definitions, unlike
code blocks definitions for noweb references, can not be multiline
(unless defined in elisp code).
Unless something better will be proposed, I consider macro expansion
inside arguments as a viable approach. (I can not recall if it was
discussed earlier.)
^ permalink raw reply [relevance 0%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
2023-10-26 9:14 5% ` Ihor Radchenko
@ 2024-01-02 21:43 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-02 21:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Apologies for my delay in answering all the interesting questions
you raised in this last message. November and December have been
horrible work days for me (all publishers are always in a hurry) and I
haven't been able to attend to the mailing list as I would like...
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> What about :wrap?
>>
>> I like :wrap. What's more, remembering that old thread where
>> some questions about code before/after the image were discussed,
>> what if the expected value of :wrap were a kind of template? This would
>> allow code to be placed before and/or after (not just an environment)
>> the image, always within the float environment, if it exists. Something
>> like this:
>>
>> #+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage}
>> #+CAPTION: caption
>> [[file:foo.png]]
>> ...
>> #+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{figure}{caption}
>> [[file:foo.png]]
>>
>> I don't know if it would be appropriate to explain in the Manual that
>> doing so would not be... "correct"? I don't know if there is any term in
>> programming to designate these situations which, without being bugs, are
>> functionalities not consciously sought...
>
> What about making :wrap override :float completely + obsoleting :float.
> We can allow wrap to have special values like in float:
>
> :wrap t/:wrap multicolumn/:wrap sideways
>
> With these special values, :placement will be taken into account.
+1. Great idea.
> Further, we can make templates a bit more detailed.
> Starting from similar to what you proposed in the above
>
> :wrap \begin{minipage}[b]{10pc}\small\n%{body}\n\end{minipage}
>
> to more granular control over caption, centering, comment-include,
> and image-code:
>
> %{caption} %{caption-text} %{centering} %{comment} %{comment-text}
> %{image} %{image-path}.
>
> If the :wrap text does not contain %{...} placeholder, it will be
> treated as what :float artbirary-environment does.
>
> We may even consider something like
>
> #+name: latex-template
> #+begin_src latex :export none
>
> \begin{minipage}[b]{10pc}\small
> %{body}
> \end{minipage}
> #+end_src
>
> #+attr_latex: :wrap latex-template[]
>
> As a bonus, :wrap may allow prepending/appending arbitrary code to
> headings:
>
> * Heading starting at a new page
> :PROPERTIES:
> :ATTR_LATEX: :wrap \clarpage%{default}
> :END:
I really like what you propose, both the idea and the syntax. I think
that such a versatile template system (with such a level of granularity
but with a clear syntax at the same time) would be a killer feature. It
wouldn't be bad to also extend it to the case of tables and other
backends, such as html. I also think it would solve a "classic" Org
syntax issue (in my opinion) which is the difficulty in 'nesting things'.
Well, it can be done currently (for example, the special blocks do their job
pretty well), but at the cost of increasing the verbosity of the code (I am
thinking, for example, of using the LaTeX threeparttable package through
nested special blocks...)
Best regards, and happy New Year
--
Juan Manuel Macías
^ permalink raw reply [relevance 11%]
* [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-02 23:46 11% Juan Manuel Macías
2024-01-13 15:08 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-02 23:46 UTC (permalink / raw)
To: orgmode
Hi,
I recently discovered that if the last line of a LaTeX 'verse'
environment ends in '\\[0pt]', the space after the environment is
drastically altered. The space after a 'verse' environment (which is a
modified list environment) must be equivalent to
\partopsep+\topsep+\baselineskip. I have done the test with a document,
defining a rectangle of that height with tikz, where you can see the
difference in vertical space with and without '\\[0pt]':
https://i.imgur.com/khbboDZ.png
Naturally, this implies an issue when exporting the verse block to
LaTeX, since the presence of the '\\[0pt]' string alters the expected
result in the compiled PDF. My suggestion is that the last line of the
verse block is not exported with either the string '[0pt]' or the line
break mark '\\', since it makes no sense for that mark to be there: it
is the end of a paragraph and the very end of the environment.
Can anyone think of a possible scenario where removing the '\\[0pt]' in
the last line would cause a problem? If not, I might send a patch in the
next few days. (I'm afraid that going back to abusing
replace-regexp-in-string. I can't think of any other more elegant
solution...).
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: org-attach-git don't automatically commit changes
@ 2024-01-10 16:05 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-01-10 16:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> In any case, if you provide a patch, it will encourage the org
>> maintainers to join this discussion and proceed with changes.
>
> OK, this week I will try to propose a patch here, and bring it up for
> (possible) discussion. Thanks for the suggestions.
For the record, this appears to be fixed in df9b509a6.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-02 23:46 11% [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
@ 2024-01-13 15:08 6% ` Ihor Radchenko
2024-01-13 16:05 10% ` Juan Manuel Macías
2024-01-20 10:27 3% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-01-13 15:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Can anyone think of a possible scenario where removing the '\\[0pt]' in
> the last line would cause a problem? If not, I might send a patch in the
> next few days. (I'm afraid that going back to abusing
> replace-regexp-in-string. I can't think of any other more elegant
> solution...).
In such scenario, we may technically violate what users ask us to do:
#+begin_verse
I really want newline here\\
#+end_verse
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 15:08 6% ` Ihor Radchenko
@ 2024-01-13 16:05 10% ` Juan Manuel Macías
2024-01-13 18:28 5% ` Ihor Radchenko
2024-01-20 10:27 3% ` Max Nikulin
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-13 16:05 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> Can anyone think of a possible scenario where removing the '\\[0pt]' in
>> the last line would cause a problem? If not, I might send a patch in the
>> next few days. (I'm afraid that going back to abusing
>> replace-regexp-in-string. I can't think of any other more elegant
>> solution...).
>
> In such scenario, we may technically violate what users ask us to do:
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
I'm not sure if users asked for that specifically.
You want a new line when there is a new line.
This makes sense:
#+begin_verse
I really want newline here\\
blah...
#+end_verse
This does not:
#+begin_verse
I really want newline here\\
#+end_verse
For LaTeX it is the same as this:
#+begin_verse
I really want newline here
#+end_verse
But this specifically alters the expected result in LaTeX, modifying the
space after the environment:
#+begin_verse
I really want newline here\\[0pt]
#+end_verse
What is the cause? I don't know. But it happens.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 16:05 10% ` Juan Manuel Macías
@ 2024-01-13 18:28 5% ` Ihor Radchenko
2024-01-13 20:22 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-13 18:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> In such scenario, we may technically violate what users ask us to do:
>>
>> #+begin_verse
>> I really want newline here\\
>> #+end_verse
>
> I'm not sure if users asked for that specifically.
> ...
> This does not:
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
I am not sure.
What about
#+begin_verse
I really want newline here\\
#+end_verse
This must not be indented.
(Just trying to come up with valid uses of newline at the end of
LaTeX environment)
Although, the above causes Org export to fail...
\begin{verse}
This is test\\[0pt]\\[0pt]
\end{verse}
Paragraph.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 18:28 5% ` Ihor Radchenko
@ 2024-01-13 20:22 8% ` Juan Manuel Macías
2024-01-14 12:33 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-13 20:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> In such scenario, we may technically violate what users ask us to do:
>>>
>>> #+begin_verse
>>> I really want newline here\\
>>> #+end_verse
>>
>> I'm not sure if users asked for that specifically.
>> ...
>> This does not:
>>
>> #+begin_verse
>> I really want newline here\\
>> #+end_verse
>
> I am not sure.
> What about
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
>
> This must not be indented.
If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
that is, within a paragraph. At the end of an environment like verse
(\end{verse}) you are forced to enter vertical mode, and a new paragraph
starts. Doing something like this, for example, adds a new paragraph
after the environment:
\documentclass{article}
\usepackage{lipsum}
\begin{document}
\begin{verse}
Lorem ipsum dolor\\
\end{verse}
\lipsum[1]
\end{document}
Even this one produces the same result:
\documentclass{article}
\usepackage{lipsum}
\begin{document}
\begin{verse}
Lorem ipsum dolor\\
\end{verse}\lipsum[1]
\end{document}
If one wants, for example, that after a verse environment there is no
vertical space or indentation, the only way to do it is by modifying, globally or
locally (with another environment) the space after the environment and
adding a \noindent to the following paragraph:
\documentclass{article}
\usepackage{lipsum}
\setlength\partopsep{-\topsep}\addtolength\partopsep{0pt}
\begin{document}
\begin{verse}
Lorem ipsum dolor\\
\end{verse}
\noindent\lipsum[1]
\end{document}
(taking into account that within the verse environment there is also a
left indentation that would also have to be modified).
Therefore, I think that whether or not a verse environment ends with \\ is
irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
some reason that escapes me, the space after the environment is altered.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 20:22 8% ` Juan Manuel Macías
@ 2024-01-14 12:33 6% ` Ihor Radchenko
2024-01-14 21:58 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-14 12:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
> that is, within a paragraph. At the end of an environment like verse
> (\end{verse}) you are forced to enter vertical mode, and a new paragraph
> starts.
Is it true for any environment? Or just some?
> Therefore, I think that whether or not a verse environment ends with \\ is
> irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
> some reason that escapes me, the space after the environment is altered.
I see. Although, I am not 100% if it is something we have to deal with
in Org mode. May it be better to report this as a bug to LaTeX devs?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-14 12:33 6% ` Ihor Radchenko
@ 2024-01-14 21:58 7% ` Juan Manuel Macías
2024-01-16 14:09 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-14 21:58 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
>> that is, within a paragraph. At the end of an environment like verse
>> (\end{verse}) you are forced to enter vertical mode, and a new paragraph
>> starts.
>
> Is it true for any environment? Or just some?
In principle, nothing prevents one from defining an environment for use
in horizontal mode (within the paragraph). E.g.:
\newenvironment{foo}{\itshape}{}
Lorem \begin{foo}ipsum\end{foo} dolor.
But the usual thing is that the beginning/end of an environment changes to
vertical mode, with \par or something more elaborate.
>> Therefore, I think that whether or not a verse environment ends with \\ is
>> irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
>> some reason that escapes me, the space after the environment is altered.
>
> I see. Although, I am not 100% if it is something we have to deal with
> in Org mode. May it be better to report this as a bug to LaTeX devs?
hmm... I don't know if this should be considered a bug. We may think
that \\[0pt] should never do anything, but we must keep in mind that the
end of the verse environment is the end of a paragraph, and it changes
to vertical mode. And the end of a paragraph is an illogical place to
put that command. But it seems that it also alters things when it is at
that point. Check out this reply from David Carlisle
(https://tex.stackexchange.com/a/82666):
#+begin_quote
\\ at the end of a paragraph causes bad output with an empty, maximally under-full, box,
and so you get a warning about badness 10000, the visual effect looks a bit like extra
vertical space but it is not: it is an extra spurious line at the end of the paragraph,
and for example it is not dropped at a page break and will break widow/club line
calculations.
#+end_quote
If there are environments that redefine \\, such as verse or tabular,
probably putting the optional argument of \\ with a value of 0pt at the
end of verse alters the calculation of the normal space after the
environment, making it shorter. I think that here we would not have a
LaTeX bug, because the syntax of the verse environment itself says that
the last line should not carry any \\ mark.
At the end of the tables I have not noticed any side effects. But in the
export of the verse block, I would be in favor of somehow eliminating
that last \\[0pt].
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-14 21:58 7% ` Juan Manuel Macías
@ 2024-01-16 14:09 4% ` Ihor Radchenko
2024-01-16 19:33 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-16 14:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
>>> that is, within a paragraph. At the end of an environment like verse
>>> (\end{verse}) you are forced to enter vertical mode, and a new paragraph
>>> starts.
>>
>> Is it true for any environment? Or just some?
>
> In principle, nothing prevents one from defining an environment for use
> in horizontal mode (within the paragraph). E.g.:
> ...
> But the usual thing is that the beginning/end of an environment changes to
> vertical mode, with \par or something more elaborate.
This is annoying.
ox-latex has some transcoders that unconditionally add \\ at the
end: clocks and planning lines. If they happen to be at the end of an
environment, it can be problematic.
> hmm... I don't know if this should be considered a bug. We may think
> that \\[0pt] should never do anything, but we must keep in mind that the
> end of the verse environment is the end of a paragraph, and it changes
> to vertical mode. And the end of a paragraph is an illogical place to
> put that command. But it seems that it also alters things when it is at
> that point. Check out this reply from David Carlisle
> (https://tex.stackexchange.com/a/82666):
The very reason we use \\[0pt] is because it supposed to prevent
interpreting [...] at the new line/transcoded element as argument.
You demonstrated that it is yet not always safe enough.
May it be better to use something like
\newcommand\nothing{}
\newcommand{\safenewline}{\\\nothing}
And then use \safenewline instead of \\[0pt]
In my tests,
\begin{center}
\begin{tabular}{ll}
[t] & s\safenewline
[I] & A\safenewline
[m] & kg\safenewline
\end{tabular}
\end{center}
Does not suffer from misinterpreting new line as argument.
> If there are environments that redefine \\, such as verse or tabular,
> probably putting the optional argument of \\ with a value of 0pt at the
> end of verse alters the calculation of the normal space after the
> environment, making it shorter. I think that here we would not have a
> LaTeX bug, because the syntax of the verse environment itself says that
> the last line should not carry any \\ mark.
AFAIU, \safenewline should still use re-defined version of \\ according
to the context.
> At the end of the tables I have not noticed any side effects. But in the
> export of the verse block, I would be in favor of somehow eliminating
> that last \\[0pt].
`org-latex-verse-block' already has a giant regexp replacement:
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
;; into a normal space, calculated with `\fontdimen2\font'. One
;; or more blank lines between lines are exported as a single
;; blank line. If the `:lines' attribute is used, the last
;; verse of each stanza ends with the string `\\!', according to
;; the syntax of the `verse' package. The separation between
;; stanzas can be controlled with the length `\stanzaskip', of
;; the aforementioned package. If the `:literal' attribute is
;; used, all blank lines are preserved and exported as
;; `\vspace*{\baselineskip}', including the blank lines before
;; or after CONTENTS.
We may as well strip the trailing \\[0pt] there.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 4%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-16 14:09 4% ` Ihor Radchenko
@ 2024-01-16 19:33 8% ` Juan Manuel Macías
2024-01-17 13:00 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-16 19:33 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> The very reason we use \\[0pt] is because it supposed to prevent
> interpreting [...] at the new line/transcoded element as argument.
>
> You demonstrated that it is yet not always safe enough.
>
> May it be better to use something like
>
> \newcommand\nothing{}
> \newcommand{\safenewline}{\\\nothing}
>
> And then use \safenewline instead of \\[0pt]
>
> In my tests,
>
> \begin{center}
> \begin{tabular}{ll}
> [t] & s\safenewline
> [I] & A\safenewline
> [m] & kg\safenewline
> \end{tabular}
> \end{center}
>
> Does not suffer from misinterpreting new line as argument.
I remember the thread where these issues were discussed and the long
discussion where many alternatives were proposed. After all, the \\[0pt]
solution still seems the safest to me. It seems that the problem is
located only in the verse environment, probably due to some particular
redefinition of the \\ macro that makes that environment.
In any case, square brackets are a problematic character in LaTeX
(think, e.g., of some environment that takes an optional argument). I
think pandoc chooses to always export them as {[}{]}:
#+begin_src sh :results latex
str="[hello world] [foo] [bar]"
pandoc -f org -t latex <<< $str
#+end_src
#+RESULTS:
#+begin_export latex
{[}hello world{]} {[}foo{]} {[}bar{]}
#+end_export
We could do the same, but I'm afraid it's too late if
org-latex-line-break-safe already exists... I don't remember if
something similar was proposed in that discussion, and it was rejected
for some reason.
> `org-latex-verse-block' already has a giant regexp replacement:
>
> ;; In a verse environment, add a line break to each newline
> ;; character and change each white space at beginning of a line
> ;; into a normal space, calculated with `\fontdimen2\font'. One
> ;; or more blank lines between lines are exported as a single
> ;; blank line. If the `:lines' attribute is used, the last
> ;; verse of each stanza ends with the string `\\!', according to
> ;; the syntax of the `verse' package. The separation between
> ;; stanzas can be controlled with the length `\stanzaskip', of
> ;; the aforementioned package. If the `:literal' attribute is
> ;; used, all blank lines are preserved and exported as
> ;; `\vspace*{\baselineskip}', including the blank lines before
> ;; or after CONTENTS.
>
> We may as well strip the trailing \\[0pt] there.
I think it would be best to remove the last \\[0pt] in the verse block.
I can prepare a patch, but I'm afraid that org-latex-verse-block is
becoming an homage to replace-regexp-in-string...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: #+LATEX_HEADER: \usepackage[greek,german]{babel} ??
@ 2024-01-16 19:46 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-16 19:46 UTC (permalink / raw)
To: Horst Leps; +Cc: emacs-orgmode@gnu.org
Horst Leps writes:
> % Created 2024-01-16 Tue 20:00
> % Intended LaTeX compiler: pdflatex
> \documentclass{scrartcl}
> \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[germanb]{babel}
> \usepackage[utf8]{inputenc}
> \usepackage[LGR,T1]{fontenc}
> \usepackage[greek,german]{babel}
> \author{HL}
The document loads babel twice:
\usepackage[germanb]{babel} <==
\usepackage[utf8]{inputenc}
\usepackage[LGR,T1]{fontenc}
\usepackage[greek,german]{babel} <==
Hence the 'option class for package babel' error. You have loaded babel
in your org document with the [greek,german] option and (probably, in
the class you are loading) babel is already loaded as well.
Try:
#+LaTeX_Header: \PassOptionsToPackage{greek,german}{babel}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-16 19:33 8% ` Juan Manuel Macías
@ 2024-01-17 13:00 4% ` Ihor Radchenko
2024-01-17 17:50 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-17 13:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> May it be better to use something like
>>
>> \newcommand\nothing{}
>> \newcommand{\safenewline}{\\\nothing}
>>
>> And then use \safenewline instead of \\[0pt]
>>
>> In my tests,
>>
>> \begin{center}
>> \begin{tabular}{ll}
>> [t] & s\safenewline
>> [I] & A\safenewline
>> [m] & kg\safenewline
>> \end{tabular}
>> \end{center}
>>
>> Does not suffer from misinterpreting new line as argument.
>
> I remember the thread where these issues were discussed and the long
> discussion where many alternatives were proposed. After all, the \\[0pt]
> solution still seems the safest to me. It seems that the problem is
> located only in the verse environment, probably due to some particular
> redefinition of the \\ macro that makes that environment.
We chose \\[0pt] simply because we did not find anything better.
In fact, Max expressed some concerns about \\[0pt] - in
https://list.orgmode.org/orgmode/tik0uf$td1$1@ciao.gmane.io/ and
https://list.orgmode.org/orgmode/tio0th$vn8$1@ciao.gmane.io/
If the idea with custom command does not have obvious downsides, it
might be a better option. In the previous thread, we only considered
redefining \\ itself - obviously a non-starter for environments that
re-define \\ by their own, like here.
> In any case, square brackets are a problematic character in LaTeX
> (think, e.g., of some environment that takes an optional argument). I
> think pandoc chooses to always export them as {[}{]}:
>
> #+begin_src sh :results latex
> str="[hello world] [foo] [bar]"
> pandoc -f org -t latex <<< $str
> #+end_src
>
> #+RESULTS:
> #+begin_export latex
> {[}hello world{]} {[}foo{]} {[}bar{]}
> #+end_export
>
> We could do the same, but I'm afraid it's too late if
> org-latex-line-break-safe already exists... I don't remember if
> something similar was proposed in that discussion, and it was rejected
> for some reason.
It is not too late.
AFAIR, we just decided not to dig deeper about pandoc's approach.
As for {[}{]}, it is a bit difficult to implement. Especially when we
also consider user filters and derived backends. If we have several
transcoders of consequent elements, there is always a risk that even
when a given filter/transcoder is generating a valid LaTeX code,
concatenating them may still cause issues like we have with \\.
I am wondering if there are other examples of commands with optional
arguments that may cause a similar problem with
\command
[unrelated text]
If there are, we may actually want to consider pandoc's approach
seriously.
>> We may as well strip the trailing \\[0pt] there.
>
> I think it would be best to remove the last \\[0pt] in the verse block.
> I can prepare a patch, but I'm afraid that org-latex-verse-block is
> becoming an homage to replace-regexp-in-string...
Not a big deal. Or, if you want, you can make changes via temporary
buffer; if that is cleaner.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 4%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-17 13:00 4% ` Ihor Radchenko
@ 2024-01-17 17:50 7% ` Juan Manuel Macías
2024-01-18 13:05 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-17 17:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> If the idea with custom command does not have obvious downsides, it
> might be a better option. In the previous thread, we only considered
> redefining \\ itself - obviously a non-starter for environments that
> re-define \\ by their own, like here.
I find several drawbacks to adding a new latex command like \nothing.
First, the standardization of the exported LaTeX code is lost. \\[0pt],
at least, always compiles. A new command obviously needs to be defined
first. Let's imagine that someone wants to simply share the LaTeX code
of a table... Then there is the problem of how to name the new command
so that it doesn't 'clash' with some user-defined command. In LaTeX it
is usually good practice to use the at sign character (@) in the name of
a command or macro that is not in user space, since this character can
only be used in a *.sty file. In a *.tex file, if you want to use the at
sign to define or redefine something, you have to enclose the code
between \makeatletter...\makeatother. And, in any case, I think that the
LaTeX code produced by org should be as 'universal' as possible (standard
LaTeX code + packages included in TeX live), and leave the definition of
new commands or environments to the user's discretion.
On the other hand, we are not sure that a command like \nothing does not
have some undesirable effect. I seem to remember that in the
aforementioned thread, adding \relax (the typical command that is used
to tell LaTeX do nothing) was also proposed as a solution, and it was
discarded for some reason.
>> In any case, square brackets are a problematic character in LaTeX
>> (think, e.g., of some environment that takes an optional argument). I
>> think pandoc chooses to always export them as {[}{]}:
>>
>> #+begin_src sh :results latex
>> str="[hello world] [foo] [bar]"
>> pandoc -f org -t latex <<< $str
>> #+end_src
>>
>> #+RESULTS:
>> #+begin_export latex
>> {[}hello world{]} {[}foo{]} {[}bar{]}
>> #+end_export
>>
>> We could do the same, but I'm afraid it's too late if
>> org-latex-line-break-safe already exists... I don't remember if
>> something similar was proposed in that discussion, and it was rejected
>> for some reason.
>
> It is not too late.
>
> AFAIR, we just decided not to dig deeper about pandoc's approach.
>
> As for {[}{]}, it is a bit difficult to implement. Especially when we
> also consider user filters and derived backends. If we have several
> transcoders of consequent elements, there is always a risk that even
> when a given filter/transcoder is generating a valid LaTeX code,
> concatenating them may still cause issues like we have with \\.
I see. I think pandoc's solution is what Leslie Lamport recommends
(naturally, Lamport doesn't say to enclose /all/ brackets in curly
braces).
> I am wondering if there are other examples of commands with optional
> arguments that may cause a similar problem with
>
> \command
> [unrelated text]
>
> If there are, we may actually want to consider pandoc's approach
> seriously.
In principle, any environment that takes an optional argument in a
"dangerous" position. Just do a simple test. Something like this:
#+begin_figure
[lorem] ipsum
#+end_figure
will throw an error like ''LaTeX Error: Unknown float option...''
Of course, putting an empty line after #+begin... usually solves it. But
the user may not know it.
There are also a number of commands with an optional argument. For
example \pagebreak. Something like this will give an error:
lorem @@latex:\pagebreak@@ [ipsum]
\item is another typical example, but in this case org adds \relax.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-17 17:50 7% ` Juan Manuel Macías
@ 2024-01-18 13:05 4% ` Ihor Radchenko
2024-01-19 17:28 10% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-01-18 13:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> As for {[}{]}, it is a bit difficult to implement. Especially when we
>> also consider user filters and derived backends. If we have several
>> transcoders of consequent elements, there is always a risk that even
>> when a given filter/transcoder is generating a valid LaTeX code,
>> concatenating them may still cause issues like we have with \\.
>
> I see. I think pandoc's solution is what Leslie Lamport recommends
> (naturally, Lamport doesn't say to enclose /all/ brackets in curly
> braces).
This turned out to be a lot easier than I thought.
See the attached patch.
>> \command
>> [unrelated text]
>>
>> If there are, we may actually want to consider pandoc's approach
>> seriously.
>
> In principle, any environment that takes an optional argument in a
> "dangerous" position. Just do a simple test. Something like this:
>
> #+begin_figure
> [lorem] ipsum
> #+end_figure
>
> will throw an error like ''LaTeX Error: Unknown float option...''
>
> Of course, putting an empty line after #+begin... usually solves it. But
> the user may not know it.
>
> There are also a number of commands with an optional argument. For
> example \pagebreak. Something like this will give an error:
>
> lorem @@latex:\pagebreak@@ [ipsum]
>
> \item is another typical example, but in this case org adds \relax.
With the patch, I am getting the following:
* This is test
lorem @@latex:\pagebreak@@ [ipsum]
#+begin_figure
[lorem] figure
#+end_figure
| [foo] | 2 |
| [bar] | 3 |
- [bax]
- [aur]
exports to
lorem \pagebreak {[}ipsum]
\begin{figure}
{[}lorem] figure
\end{figure}
\begin{center}
\begin{tabular}{lr}
{[}foo] & 2\\[0pt]
{[}bar] & 3\\[0pt]
\end{tabular}
\end{center}
\begin{itemize}
\item {[}bax]
\item {[}aur]
\end{itemize}
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex-Make-sure-that-text-is-not-misinterpreted-a.patch --]
[-- Type: text/x-patch, Size: 2511 bytes --]
From db3fa01d6f15b3d3f499f77e342a608a822029c8 Mon Sep 17 00:00:00 2001
Message-ID: <db3fa01d6f15b3d3f499f77e342a608a822029c8.1705583005.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Thu, 18 Jan 2024 14:01:32 +0100
Subject: [PATCH] ox-latex: Make sure that [text] is not misinterpreted as
LaTeX argument
* lisp/ox-latex.el (org-latex-plain-text): Protect plain text starting
from [. It might be misinterpreted as optional command argument if
previous exported fragment ends with a command accepting such.
*
testing/lisp/test-ox-latex.el (text-ox-latex/protect-square-brackets):
Add new test.
Link: https://orgmode.org/list/87o7dju9vn.fsf@posteo.net
---
lisp/ox-latex.el | 9 +++++++++
testing/lisp/test-ox-latex.el | 23 +++++++++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 432f09f4e..a3505c25f 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3094,6 +3094,15 @@ (defun org-latex-plain-text (text info)
"\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
output nil t)))
+ ;; Protect [foo] at the beginning of lines / beginning of the
+ ;; plain-text object. This prevents LaTeX from unexpectedly
+ ;; interpreting @@latex:\pagebreak@@ [foo] as a command with
+ ;; optional argument.
+ (setq output (replace-regexp-in-string
+ (rx bol (0+ space) (group "["))
+ "{[}"
+ output
+ nil nil 1))
;; Return value.
output))
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 41df1b823..237ad97ec 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -29,6 +29,29 @@ (unless (featurep 'ox-latex)
\f
+(ert-deftest text-ox-latex/protect-square-brackets ()
+ "Test [foo] being interpreted as plain text even after LaTeX commands."
+ (org-test-with-exported-text
+ 'latex
+ "* This is test
+lorem @@latex:\\pagebreak@@ [ipsum]
+
+#+begin_figure
+[lorem] figure
+#+end_figure
+
+| [foo] | 2 |
+| [bar] | 3 |
+
+- [bax]
+- [aur]
+"
+ (goto-char (point-min))
+ (should (search-forward "lorem \\pagebreak {[}ipsum]"))
+ (should (search-forward "{[}lorem] figure"))
+ (should (search-forward "{[}foo]"))
+ (should (search-forward "\\item {[}bax]"))))
+
(ert-deftest test-ox-latex/verse ()
"Test verse blocks."
(org-test-with-exported-text
--
2.43.0
[-- Attachment #3: Type: text/plain, Size: 224 bytes --]
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply related [relevance 4%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-18 13:05 4% ` Ihor Radchenko
@ 2024-01-19 17:28 10% ` Juan Manuel Macías
2024-01-20 12:34 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-19 17:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> This turned out to be a lot easier than I thought.
> See the attached patch.
>
>>> \command
>>> [unrelated text]
>>>
>>> If there are, we may actually want to consider pandoc's approach
>>> seriously.
>>
>> In principle, any environment that takes an optional argument in a
>> "dangerous" position. Just do a simple test. Something like this:
>>
>> #+begin_figure
>> [lorem] ipsum
>> #+end_figure
>>
>> will throw an error like ''LaTeX Error: Unknown float option...''
>>
>> Of course, putting an empty line after #+begin... usually solves it. But
>> the user may not know it.
>>
>> There are also a number of commands with an optional argument. For
>> example \pagebreak. Something like this will give an error:
>>
>> lorem @@latex:\pagebreak@@ [ipsum]
>>
>> \item is another typical example, but in this case org adds \relax.
>
> With the patch, I am getting the following:
>
> * This is test
> lorem @@latex:\pagebreak@@ [ipsum]
>
> #+begin_figure
> [lorem] figure
> #+end_figure
>
> | [foo] | 2 |
> | [bar] | 3 |
>
> - [bax]
> - [aur]
>
> exports to
>
> lorem \pagebreak {[}ipsum]
>
> \begin{figure}
> {[}lorem] figure
> \end{figure}
>
> \begin{center}
> \begin{tabular}{lr}
> {[}foo] & 2\\[0pt]
> {[}bar] & 3\\[0pt]
> \end{tabular}
> \end{center}
>
> \begin{itemize}
> \item {[}bax]
> \item {[}aur]
> \end{itemize}
Great! Simple and effective. And more surgical than pandoc's global
solution. But now a question arises... Your code clearly solves the
problem that led to the declaration of org-latex-line-break-safe,
without foreseeing any unwanted effects, since it is the solution that
is usually recommended from LaTeX. So, if this code is included in Org,
what is the future of org-latex-line-break-safe?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-20 10:57 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-20 10:57 UTC (permalink / raw)
To: Max Nikulin; +Cc: Ihor Radchenko, orgmode
Max Nikulin writes:
> On 18/01/2024 20:05, Ihor Radchenko wrote:
>> With the patch, I am getting the following:[...]
>> \begin{center}
>> \begin{tabular}{lr}
>> {[}foo] & 2\\[0pt]
>> {[}bar] & 3\\[0pt]
>> \end{tabular}
>> \end{center}
>
> It means that [0pt] is not necessary any more. However users will have
> adjust their filters once more. I have no idea if many of them will
> complain concerning {[} where it is not really required.
> (/[omitted]/).
>
> To have an additional excuse, it is better to add a note that it is
> inspired by pandoc strategy.
I agree with the note. Perhaps both strategies could coexist: by
default, Ihor's code; and org-latex-line-break-safe with value "\\\\".
And, after some time, the latter could become obsolete, unless a new
''raison d'etre'' is found for it...
In any case, I would no longer see it necessary to modify
org-latex-verse-block anymore.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 15:08 6% ` Ihor Radchenko
2024-01-13 16:05 10% ` Juan Manuel Macías
@ 2024-01-20 10:27 3% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2024-01-20 10:27 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 13/01/2024 22:08, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
>
>> Can anyone think of a possible scenario where removing the '\\[0pt]' in
>> the last line would cause a problem?
I would suggest to strip leading and trailing newlines before processing
of the block content.
> In such scenario, we may technically violate what users ask us to do:
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
I really want newline here@@latex:\\%@@
P.S. Juan Manuel, I have sent another message to this thread without
your address in Cc.
^ permalink raw reply [relevance 3%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-19 17:28 10% ` Juan Manuel Macías
@ 2024-01-20 12:34 5% ` Ihor Radchenko
2024-01-20 13:22 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-20 12:34 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> \begin{itemize}
>> \item {[}bax]
>> \item {[}aur]
>> \end{itemize}
>
> Great! Simple and effective. And more surgical than pandoc's global
> solution. But now a question arises... Your code clearly solves the
> problem that led to the declaration of org-latex-line-break-safe,
> without foreseeing any unwanted effects, since it is the solution that
> is usually recommended from LaTeX. So, if this code is included in Org,
> what is the future of org-latex-line-break-safe?
It is still useful in situations like
Paragraph\\
#+begin_export latex
[foo]
#+end_export
or
Paragraph\\
@@latex:[foo]@@
My patch does not do anything about verbatim environments.
We may remove the use of `org-latex-line-break-safe' from some places,
but not all.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-20 12:34 5% ` Ihor Radchenko
@ 2024-01-20 13:22 9% ` Juan Manuel Macías
2024-01-20 13:46 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-20 13:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> \begin{itemize}
>>> \item {[}bax]
>>> \item {[}aur]
>>> \end{itemize}
>>
>> Great! Simple and effective. And more surgical than pandoc's global
>> solution. But now a question arises... Your code clearly solves the
>> problem that led to the declaration of org-latex-line-break-safe,
>> without foreseeing any unwanted effects, since it is the solution that
>> is usually recommended from LaTeX. So, if this code is included in Org,
>> what is the future of org-latex-line-break-safe?
>
> It is still useful in situations like
>
> Paragraph\\
>
> #+begin_export latex
> [foo]
> #+end_export
>
> or
>
> Paragraph\\
> @@latex:[foo]@@
But since in both cases it is literal LaTeX code, the correct thing
would be for the user to be in charge of adding the curly braces to the
square brackets. I mean in such scenario it is LaTeX code, not Org.
Anyway, in both examples it does not make sense for LaTeX to end a
paragraph with the \\ macro, which is why we commented in previous
messages in the thread. The \\ macro is only used in horizontal mode;
this macro does not add a new paragraph but rather a forced line break
within the paragraph.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-20 13:22 9% ` Juan Manuel Macías
@ 2024-01-20 13:46 5% ` Ihor Radchenko
2024-01-20 15:41 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-20 13:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Paragraph\\
>> @@latex:[foo]@@
>
> But since in both cases it is literal LaTeX code, the correct thing
> would be for the user to be in charge of adding the curly braces to the
> square brackets. I mean in such scenario it is LaTeX code, not Org.
Not really. Because we do not give guarantees about the details of LaTeX
export, we should try hard to not break things that users may put into
literal export snippets.
> Anyway, in both examples it does not make sense for LaTeX to end a
> paragraph with the \\ macro, which is why we commented in previous
> messages in the thread. The \\ macro is only used in horizontal mode;
> this macro does not add a new paragraph but rather a forced line break
> within the paragraph.
In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph
- it is inside paragraph.
Another alternative could be modifying how inline latex snippet is
exported, but that's worse IMHO - we should try hard not to touch what
users tell Org to do explicitly.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-20 13:46 5% ` Ihor Radchenko
@ 2024-01-20 15:41 9% ` Juan Manuel Macías
2024-01-20 18:47 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-20 15:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Paragraph\\
>>> @@latex:[foo]@@
>>
>> But since in both cases it is literal LaTeX code, the correct thing
>> would be for the user to be in charge of adding the curly braces to the
>> square brackets. I mean in such scenario it is LaTeX code, not Org.
>
> Not really. Because we do not give guarantees about the details of LaTeX
> export, we should try hard to not break things that users may put into
> literal export snippets.
>
>> Anyway, in both examples it does not make sense for LaTeX to end a
>> paragraph with the \\ macro, which is why we commented in previous
>> messages in the thread. The \\ macro is only used in horizontal mode;
>> this macro does not add a new paragraph but rather a forced line break
>> within the paragraph.
>
> In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph
> - it is inside paragraph.
What I mean is that literal LaTeX code is LaTeX code, despite the
redundancy. IMHO, Org's only duty in that case is to export such literal
code as valid LaTeX code, but Org "does not know" what that literal code
consists of. The user who enters the literal LaTeX code is the one who
has the duty to add the necessary elements to that code so that it is
compiled correctly by LaTeX. Let's look at this as a territorial
question:
Scenario A:
@@LaTeX:\libebreak@@ [ipsum] ==> the problem is in Org territory
Scenario B:
lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated
@ 2024-01-20 16:04 0% ` Ihor Radchenko
2024-01-24 13:21 0% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-01-20 16:04 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
> On 18/02/2023 17:18, Ihor Radchenko wrote:
>> In https://orgmode.org/worg/org-faq.html#org60202b9, the answer uses
>> obsolete function `org-add-link-type'. We should change it to
>> `org-link-set-parameters'.
>
> Confirmed.
Fixed.
https://git.sr.ht/~bzg/worg/commit/3194e6d5
> A newer recipe:
>
> Juan Manuel Macías to emacs-orgmode… Re: how to export red colored TeX
> to latex. Tue, 30 Nov 2021 16:56:00 +0000.
> https://list.orgmode.org/87bl21vazj.fsf@posteo.net
>
> Likely should be modified a bit to support derived backends.
I think we do not do this in any of the examples for :export link
property in WORG. I am actually not sure how to update things to work
for derived backends as well.
> The following package might be mentioned:
>
> Colours section in org-special-block-extras
> https://alhassy.com/org-special-block-extras/#Colours
Agree.
https://git.sr.ht/~bzg/worg/commit/5edf3ab0
> Other files:
> - org-tutorials/org-R/org-variables-counts.org
> - org-tutorials/org-R/variable-popcon.org
> - org-configs/org-customization-survey.org
> - org-configs/org-customization-survey-2013.org
These are not relevant - they contain tables for old Org mode
customization polls.
> Need review:
> - org-hacks.org
> mid: links for org-gnus (not ol-gnus) and org-occur example
Done.
https://git.sr.ht/~bzg/worg/commit/83e85f8e
> - exporters/anno-bib-template-worg.org
> citations using ebib
Thomas kindly updated the whole thing.
https://git.sr.ht/~bzg/worg/commit/c864fe68
> Outdated:
> - org-tutorials/org-latex-export.org
> Org < 8.0
This is also authored by Thomas. I will ask him in another thread.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 0%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-20 15:41 9% ` Juan Manuel Macías
@ 2024-01-20 18:47 5% ` Ihor Radchenko
2024-01-20 20:27 9% ` Juan Manuel Macías
2024-01-21 6:06 3% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-01-20 18:47 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Scenario B:
>
> lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory
I see your point.
Although I am still a bit hesitant to remove
`org-latex-line-break-safe'.
What would be the benefit of removing it? For now, I mostly just see
that it will make the life harder for users in Scenario B.
For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong)
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-20 18:47 5% ` Ihor Radchenko
@ 2024-01-20 20:27 9% ` Juan Manuel Macías
2024-01-21 13:42 1% ` Ihor Radchenko
2024-01-21 6:06 3% ` Max Nikulin
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-20 20:27 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> I see your point.
> Although I am still a bit hesitant to remove
> `org-latex-line-break-safe'.
> What would be the benefit of removing it? For now, I mostly just see
> that it will make the life harder for users in Scenario B.
It's a complicated situation, because we now have two solutions to the
same problem... It certainly sounds a bit abrupt to remove
org-latex-line-break-safe (at least for now). I see no problem in both
solutions coexisting. After all, the user can always give an "\\\\"
value to org-latex-line-break-safe. The other possibility is that
org-latex-line-break-safe is selectively deleted, as you mentioned in a
previous email. In tables and verse blocks, unless I'm missing
something, I think adding [0pt] would be unnecessary, with the new
solution.
> For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong)
From the tests I have done, the problem of the vertical space being
altered after the verse environment only appears when the last line ends
in \\[0pt]. If it ends in \\ the problem does not appear. It is not
recommended that a verse environment ends in \\, but it does not seem to
influence the output. In fact, that was how it was in Org in the days
pre org-latex-line-break-safe and there were never any problems.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-20 18:47 5% ` Ihor Radchenko
2024-01-20 20:27 9% ` Juan Manuel Macías
@ 2024-01-21 6:06 3% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2024-01-21 6:06 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 21/01/2024 01:47, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
>>
>> lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory
I agree with Juan Manuel.
> I see your point.
> Although I am still a bit hesitant to remove
> `org-latex-line-break-safe'.
> What would be the benefit of removing it? For now, I mostly just see
> that it will make the life harder for users in Scenario B.
An option might be disabling it by default without removing the code
completely. Depending on user feedback it may be removed later.
Users, who need to submit LaTeX code, consider [0pt] as undesired noise.
I see their point of view.
^ permalink raw reply [relevance 3%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-20 20:27 9% ` Juan Manuel Macías
@ 2024-01-21 13:42 1% ` Ihor Radchenko
2024-01-21 19:25 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-21 13:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Although I am still a bit hesitant to remove
>> `org-latex-line-break-safe'.
>> What would be the benefit of removing it? For now, I mostly just see
>> that it will make the life harder for users in Scenario B.
>
> It's a complicated situation, because we now have two solutions to the
> same problem... It certainly sounds a bit abrupt to remove
> org-latex-line-break-safe (at least for now). I see no problem in both
> solutions coexisting. After all, the user can always give an "\\\\"
> value to org-latex-line-break-safe. The other possibility is that
> org-latex-line-break-safe is selectively deleted, as you mentioned in a
> previous email. In tables and verse blocks, unless I'm missing
> something, I think adding [0pt] would be unnecessary, with the new
> solution.
Upon looking closer into selective removal, it turned out to be more
tricky than I thought. I'm afraid that using \\[0pt] only in some places
may become a bit of headache to maintain - we may accidentally break
certain regexp replacements in `org-latex-verse-block'. In particular,
when verse contents is not straightforward and uses \\[0pt].
Given that `org-latex-line-break-safe' also introduced the problem with
verse blocks, I decided that it is better to remove it at the end.
See the attached tentative patchset.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v2-0001-ox-latex-Make-sure-that-text-is-not-misinterprete.patch --]
[-- Type: text/x-patch, Size: 2518 bytes --]
From d2e74cc2734eaf8d782f5acf66b11956d6ffa47e Mon Sep 17 00:00:00 2001
Message-ID: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Thu, 18 Jan 2024 14:01:32 +0100
Subject: [PATCH v2 1/2] ox-latex: Make sure that [text] is not misinterpreted
as LaTeX argument
* lisp/ox-latex.el (org-latex-plain-text): Protect plain text starting
from [. It might be misinterpreted as optional command argument if
previous exported fragment ends with a command accepting such.
*
testing/lisp/test-ox-latex.el (text-ox-latex/protect-square-brackets):
Add new test.
Link: https://orgmode.org/list/87o7dju9vn.fsf@posteo.net
---
lisp/ox-latex.el | 9 +++++++++
testing/lisp/test-ox-latex.el | 23 +++++++++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index df20345f8..a64dd5a87 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3095,6 +3095,15 @@ (defun org-latex-plain-text (text info)
"\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
output nil t)))
+ ;; Protect [foo] at the beginning of lines / beginning of the
+ ;; plain-text object. This prevents LaTeX from unexpectedly
+ ;; interpreting @@latex:\pagebreak@@ [foo] as a command with
+ ;; optional argument.
+ (setq output (replace-regexp-in-string
+ (rx bol (0+ space) (group "["))
+ "{[}"
+ output
+ nil nil 1))
;; Return value.
output))
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 41df1b823..237ad97ec 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -29,6 +29,29 @@ (unless (featurep 'ox-latex)
\f
+(ert-deftest text-ox-latex/protect-square-brackets ()
+ "Test [foo] being interpreted as plain text even after LaTeX commands."
+ (org-test-with-exported-text
+ 'latex
+ "* This is test
+lorem @@latex:\\pagebreak@@ [ipsum]
+
+#+begin_figure
+[lorem] figure
+#+end_figure
+
+| [foo] | 2 |
+| [bar] | 3 |
+
+- [bax]
+- [aur]
+"
+ (goto-char (point-min))
+ (should (search-forward "lorem \\pagebreak {[}ipsum]"))
+ (should (search-forward "{[}lorem] figure"))
+ (should (search-forward "{[}foo]"))
+ (should (search-forward "\\item {[}bax]"))))
+
(ert-deftest test-ox-latex/verse ()
"Test verse blocks."
(org-test-with-exported-text
--
2.43.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: v2-0002-ox-latex-Remove-org-latex-line-break-safe.patch --]
[-- Type: text/x-patch, Size: 11526 bytes --]
From dd4618b31dc5070d6802e484fd58cf50f5d3606d Mon Sep 17 00:00:00 2001
Message-ID: <dd4618b31dc5070d6802e484fd58cf50f5d3606d.1705844367.git.yantar92@posteo.net>
In-Reply-To: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net>
References: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Sun, 21 Jan 2024 14:21:33 +0100
Subject: [PATCH v2 2/2] ox-latex: Remove org-latex-line-break-safe
This reverts commit 3f60acff7717e472d06833e9cf9fff6ca3d59337 and
subsequent relevant comments.
* lisp/ox-latex.el (org-latex-line-break-safe): Remove constant. The
\\[0pt] is actually not safe to use in some scenarios. We use a
different approach to avoid plain text [...] being interpreted as
LaTeX optional argument - we escape [ like {[}; that's what pandoc
does.
(org-latex-clock):
(org-latex-line-break):
(org-latex-plain-text):
(org-latex-planning):
(org-latex--org-table):
(org-latex--math-table):
(org-latex-table-row):
(org-latex-verse-block):
* testing/lisp/test-org-table.el (test-org-table/to-latex):
* testing/lisp/test-ox-latex.el (test-ox-latex/verse):
(test-ox-latex/longtable): Remove references to
`org-latex-line-break-safe'.
* etc/ORG-NEWS (=ox-latex=: ~org-latex-line-break-safe~ is removed):
Announce removal.
* lisp/org-compat.el (org-latex-line-break-safe): Make obsolete.
Link: https://orgmode.org/list/878r4jg37s.fsf@posteo.net
---
etc/ORG-NEWS | 10 +++++++
lisp/org-compat.el | 18 +++++++++++++
lisp/ox-latex.el | 49 ++++++++++++----------------------
testing/lisp/test-org-table.el | 6 ++---
testing/lisp/test-ox-latex.el | 16 +++++------
5 files changed, 56 insertions(+), 43 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 847ddf614..46f1e66a7 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,16 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
* Version 9.7 (not released yet)
** Important announcements and breaking changes
+*** =ox-latex=: ~org-latex-line-break-safe~ is removed
+
+~org-latex-line-break-safe~ constant was previously introduced to deal
+with edge cases when LaTeX interprets [...] as LaTeX command
+argument. However, it caused a number of other issues and proved
+itself not to be as "safe" as it supposed to be.
+
+We now use a Pandoc's approach to deal with the same problem,
+utilizing ={[}= to escape =[...]= instances where needed.
+
*** ~org-agenda-search-headline-for-time~ now ignores all the timestamp in headings
Previously, ~org-agenda-search-headline-for-time~ made Org agenda
diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 17f07db9d..27d094b07 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -629,6 +629,24 @@ (define-obsolete-variable-alias 'org-reveal-start-hook
(define-obsolete-function-alias 'org-file-url-p 'org-url-p "9.6")
(define-obsolete-variable-alias 'org-plantuml-executable-args 'org-plantuml-args
"Org 9.6")
+
+(defconst org-latex-line-break-safe "\\\\[0pt]"
+ "Linebreak protecting the following [...].
+
+Without \"[0pt]\" it would be interpreted as an optional argument to
+the \\\\.
+
+This constant, for example, makes the below code not err:
+
+\\begin{tabular}{c|c}
+ [t] & s\\\\[0pt]
+ [I] & A\\\\[0pt]
+ [m] & kg
+\\end{tabular}")
+(make-obsolete 'org-latex-line-break-safe
+ "should not be used - it is not safe in all the scenarios."
+ "9.7")
+
(defun org-in-fixed-width-region-p ()
"Non-nil if point in a fixed-width region."
(save-match-data
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a64dd5a87..d6e74cb45 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -298,23 +298,10 @@ (defconst org-latex-language-alist
- `:script-tag' the script otf tag.")
-(defconst org-latex-line-break-safe "\\\\[0pt]"
- "Linebreak protecting the following [...].
-Without \"[0pt]\" it would be interpreted as an optional argument to
-the \\\\.
-
-This constant, for example, makes the below code not err:
-
-\\begin{tabular}{c|c}
- [t] & s\\\\[0pt]
- [I] & A\\\\[0pt]
- [m] & kg
-\\end{tabular}")
-
-(defconst org-latex-table-matrix-macros `(("bordermatrix" . "\\cr")
+(defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
("qbordermatrix" . "\\cr")
- ("kbordermatrix" . ,org-latex-line-break-safe))
+ ("kbordermatrix" . "\\\\"))
"Alist between matrix macros and their row ending.")
(defconst org-latex-math-environments-re
@@ -2124,7 +2111,7 @@ (defun org-latex-clock (clock _contents info)
(concat (org-timestamp-translate (org-element-property :value clock))
(let ((time (org-element-property :duration clock)))
(and time (format " (%s)" time)))))
- org-latex-line-break-safe))
+ "\\\\"))
;;;; Code
@@ -2722,7 +2709,7 @@ ;;;; Line Break
(defun org-latex-line-break (_line-break _contents _info)
"Transcode a LINE-BREAK object from Org to LaTeX.
CONTENTS is nil. INFO is a plist holding contextual information."
- (concat org-latex-line-break-safe "\n"))
+ "\\\\\n")
;;;; Link
@@ -3092,9 +3079,7 @@ (defun org-latex-plain-text (text info)
;; Handle break preservation if required.
(when (plist-get info :preserve-breaks)
(setq output (replace-regexp-in-string
- "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n"
- (concat org-latex-line-break-safe "\n")
- output nil t)))
+ "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n" output nil t)))
;; Protect [foo] at the beginning of lines / beginning of the
;; plain-text object. This prevents LaTeX from unexpectedly
;; interpreting @@latex:\pagebreak@@ [foo] as a command with
@@ -3139,7 +3124,7 @@ (defun org-latex-planning (planning _contents info)
(format (plist-get info :latex-active-timestamp-format)
(org-timestamp-translate scheduled)))))))
" ")
- org-latex-line-break-safe))
+ "\\\\"))
;;;; Property Drawer
@@ -3919,11 +3904,11 @@ (defun org-latex--org-table (table contents info)
(format "\\begin{%s}%s{%s}\n" table-env width alignment)
(and above?
(org-string-nw-p caption)
- (concat caption org-latex-line-break-safe "\n"))
+ (concat caption "\\\\\n"))
contents
(and (not above?)
(org-string-nw-p caption)
- (concat caption org-latex-line-break-safe "\n"))
+ (concat caption "\\\\\n"))
(format "\\end{%s}" table-env)
(and fontsize "}"))))
(t
@@ -4008,7 +3993,7 @@ (defun org-latex--math-table (table info)
(lambda (cell)
(substring (org-element-interpret-data cell) 0 -1))
(org-element-map row 'table-cell #'identity info) "&")
- (or (cdr (assoc env org-latex-table-matrix-macros)) org-latex-line-break-safe)
+ (or (cdr (assoc env org-latex-table-matrix-macros)) "\\\\")
"\n")))
(org-element-map table 'table-row #'identity info) "")))
(concat
@@ -4083,7 +4068,7 @@ (defun org-latex-table-row (table-row contents info)
(setq table-head-cache (make-hash-table :test #'eq))
(plist-put info :org-latex-table-head-cache table-head-cache))
(if-let ((head-contents (gethash (org-element-parent table-row) table-head-cache)))
- (puthash (org-element-parent table-row) (concat head-contents org-latex-line-break-safe "\n" contents)
+ (puthash (org-element-parent table-row) (concat head-contents "\\\\\n" contents)
table-head-cache)
(puthash (org-element-parent table-row) contents table-head-cache))))
;; Return LaTeX string as the transcoder.
@@ -4092,7 +4077,7 @@ (defun org-latex-table-row (table-row contents info)
;; hline was specifically marked.
(and booktabsp (not (org-export-get-previous-element table-row info))
"\\toprule\n")
- contents org-latex-line-break-safe "\n"
+ contents "\\\\\n"
(cond
;; Special case for long tables. Define header and footers.
((and longtablep (org-export-table-row-ends-header-p table-row info))
@@ -4100,9 +4085,9 @@ (defun org-latex-table-row (table-row contents info)
(org-element-lineage table-row 'table) info))))
(format "%s
\\endfirsthead
-\\multicolumn{%d}{l}{%s} \\\\[0pt]
+\\multicolumn{%d}{l}{%s} \\\\
%s
-%s \\\\[0pt]\n
+%s \\\\\n
%s
\\endhead
%s\\multicolumn{%d}{r}{%s} \\\\
@@ -4211,15 +4196,15 @@ (defun org-latex-verse-block (verse-block contents info)
(replace-regexp-in-string
(if (not lit)
(rx-to-string
- `(seq (group ,org-latex-line-break-safe "\n")
- (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n"))))
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ `(seq (group "\\\\\n")
+ (1+ (group line-start (0+ space) "\\\\\n"))))
+ "^[ \t]*\\\\$")
(if (not lit)
(if lin "\\\\!\n\n" "\n\n")
"\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
- (concat org-latex-line-break-safe "\n")
+ "\\\\\n"
(if (not lit)
(concat (org-trim contents t) "\n")
contents)
diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el
index 92ccd2a05..6ee790894 100644
--- a/testing/lisp/test-org-table.el
+++ b/testing/lisp/test-org-table.el
@@ -1633,11 +1633,11 @@ (ert-deftest test-org-table/to-generic ()
(ert-deftest test-org-table/to-latex ()
"Test `orgtbl-to-latex' specifications."
(should
- (equal "\\begin{tabular}{l}\na\\\\[0pt]\n\\end{tabular}"
+ (equal "\\begin{tabular}{l}\na\\\\\n\\end{tabular}"
(orgtbl-to-latex (org-table-to-lisp "| a |") nil)))
;; Test :environment parameter.
(should
- (equal "\\begin{tabularx}{l}\na\\\\[0pt]\n\\end{tabularx}"
+ (equal "\\begin{tabularx}{l}\na\\\\\n\\end{tabularx}"
(orgtbl-to-latex (org-table-to-lisp "| a |")
'(:environment "tabularx"))))
;; Test :booktabs parameter.
@@ -1646,7 +1646,7 @@ (ert-deftest test-org-table/to-latex ()
"\\toprule" (orgtbl-to-latex (org-table-to-lisp "| a |") '(:booktabs t))))
;; Handle LaTeX snippets.
(should
- (equal "\\begin{tabular}{l}\n\\(x\\)\\\\[0pt]\n\\end{tabular}"
+ (equal "\\begin{tabular}{l}\n\\(x\\)\\\\\n\\end{tabular}"
(orgtbl-to-latex (org-table-to-lisp "| $x$ |") nil)))
;; Test pseudo objects and :raw parameter.
(should
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 237ad97ec..d0be4e5a4 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -71,14 +71,14 @@ (ert-deftest test-ox-latex/verse ()
(should
(search-forward
"\\begin{verse}
-lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\
lorem ipsum dolor
-lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\
lorem ipsum dolor
-lorem ipsum dolor\\\\[0pt]
-lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\
+lorem ipsum dolor\\\\
\\end{verse}"))))
(ert-deftest test-ox-latex/longtable ()
@@ -98,15 +98,15 @@ (ert-deftest test-ox-latex/longtable ()
(should
(search-forward
"\\begin{longtable}{lr}
-First & Second\\\\[0pt]
-Column & Column\\\\[0pt]
+First & Second\\\\
+Column & Column\\\\
\\hline
\\endfirsthead"))
(goto-char (point-min))
(should
(search-forward
- "First & Second\\\\[0pt]
-Column & Column \\\\[0pt]
+ "First & Second\\\\
+Column & Column \\\\
\\hline
\\endhead"))
--
2.43.0
[-- Attachment #4: Type: text/plain, Size: 224 bytes --]
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply related [relevance 1%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
@ 2024-01-21 17:47 9% ` Juan Manuel Macías
2024-01-22 6:30 6% ` Pedro Andres Aranda Gutierrez
2024-01-22 12:10 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-21 17:47 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Pedro Andres Aranda Gutierrez writes:
> +#+begin_example
> +,#+latex_class_options: [greek,spanish,oneside]
> +,#+language: es
> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> +#+end_example
I think this example doesn't take advantage of the AUTO facility, which
is what the section is about. Btw, maybe it would be nice to extend ''AUTO'' to
latex_class_options and \PassOptionsToPackage? Something like:
#+latex_class_options: [greek,AUTO,oneside]
#+language: es
...
However, I would only find the \PassOptionsToPackage command useful in
classes that already load babel with a main language. From Org, using
just pdfTeX, I think it would be simpler:
#+language: es
#+latex_header: \usepackage[greek,AUTO]{babel}
#+latex_header: \usepackage{alphabeta} % to support greek script
or this variant, using babelprovide and an INI file:
#+language: es
#+latex_header: \usepackage[greek]{babel}
#+latex_header: \babelprovide[import,main]{AUTO}
#+latex_header: \usepackage{alphabeta}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-21 13:42 1% ` Ihor Radchenko
@ 2024-01-21 19:25 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-21 19:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Max Nikulin
Ihor Radchenko writes:
> Upon looking closer into selective removal, it turned out to be more
> tricky than I thought. I'm afraid that using \\[0pt] only in some places
> may become a bit of headache to maintain - we may accidentally break
> certain regexp replacements in `org-latex-verse-block'. In particular,
> when verse contents is not straightforward and uses \\[0pt].
>
> Given that `org-latex-line-break-safe' also introduced the problem with
> verse blocks, I decided that it is better to remove it at the end.
LaTeX code generated without org-latex-line-break-safe is much cleaner.
The decision to make this variable obsolete seems correct to me, if
there is already a better and more discreet solution. I don't know if it
will cause many problems with custom settings and filters written in
relation to this variable, as Maxim commented in a previous email... I
hope not. I have a couple of filters written already, but I don't think
it will take much work for me to readjust them.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
2024-01-21 17:47 9% ` Juan Manuel Macías
@ 2024-01-22 6:30 6% ` Pedro Andres Aranda Gutierrez
2024-01-22 6:47 0% ` Pedro Andres Aranda Gutierrez
2024-01-22 12:10 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-01-22 6:30 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List
[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]
HI Juan Manuel,
you are absolutely right. There are many things that should improve in the
LaTeX exporter and simplifying language treatment is one of them. What I
show in my example is how to circumvent all the limitations in the exporter
and give a working example for people who need it.
Adding AUTO to latex_class_options would be extremely helpful, since then
you can load babel indicating the main language only and even avoid the
PassOptions and can live with \usepackage{alphabeta} only.
This is a MWE for mixing German and Greek which I use to compare with what
org-mode generates:
---cut---
\documentclass[greek,ngerman]{scrartcl}
%% \documentclass[greek,ngerman]{scrreprt}
%% \documentclass[greek,ngerman]{scrbook}
%% \documentclass[greek,ngerman]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
%% \PassOptionsToPackage{main=ngerman}{babel}
\usepackage{alphabeta}
\begin{document}
Ach, unsere Freunde die Griechen: \textgreek{νους} (mit
\verb|\textgreek{}|).\par
Ach, unsere Freunde die Griechen: νους (direkt im Text).
\end{document}
---cut---
The commented document classes are all I had the time to test.
Best, /PA
On Sun, 21 Jan 2024 at 18:47, Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Pedro Andres Aranda Gutierrez writes:
>
> > +#+begin_example
> > +,#+latex_class_options: [greek,spanish,oneside]
> > +,#+language: es
> > +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> > +,#+latex_header: \usepackage{alphabeta} % to support greek script
> > +#+end_example
>
> I think this example doesn't take advantage of the AUTO facility, which
> is what the section is about. Btw, maybe it would be nice to extend
> ''AUTO'' to
> latex_class_options and \PassOptionsToPackage? Something like:
>
> #+latex_class_options: [greek,AUTO,oneside]
> #+language: es
> ...
>
> However, I would only find the \PassOptionsToPackage command useful in
> classes that already load babel with a main language. From Org, using
> just pdfTeX, I think it would be simpler:
>
> #+language: es
> #+latex_header: \usepackage[greek,AUTO]{babel}
> #+latex_header: \usepackage{alphabeta} % to support greek script
>
> or this variant, using babelprovide and an INI file:
>
> #+language: es
> #+latex_header: \usepackage[greek]{babel}
> #+latex_header: \babelprovide[import,main]{AUTO}
> #+latex_header: \usepackage{alphabeta}
>
> Best regards,
>
> Juan Manuel
>
>
>
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
[-- Attachment #2: Type: text/html, Size: 3574 bytes --]
^ permalink raw reply [relevance 6%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
2024-01-22 6:30 6% ` Pedro Andres Aranda Gutierrez
@ 2024-01-22 6:47 0% ` Pedro Andres Aranda Gutierrez
2024-01-22 13:11 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-01-22 6:47 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List
[-- Attachment #1: Type: text/plain, Size: 3524 bytes --]
PS: This is a very limited example. It would be nice to have more control
on fontenc. AFAIK there is not alphabeta for cyrillic encodings and
typesetting 'War and Peace' with its passages in French embedded in the
Russian text is sort of a headache ;-)
/PA
On Mon, 22 Jan 2024 at 07:30, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:
> HI Juan Manuel,
>
> you are absolutely right. There are many things that should improve in the
> LaTeX exporter and simplifying language treatment is one of them. What I
> show in my example is how to circumvent all the limitations in the exporter
> and give a working example for people who need it.
>
> Adding AUTO to latex_class_options would be extremely helpful, since then
> you can load babel indicating the main language only and even avoid the
> PassOptions and can live with \usepackage{alphabeta} only.
> This is a MWE for mixing German and Greek which I use to compare with what
> org-mode generates:
>
> ---cut---
> \documentclass[greek,ngerman]{scrartcl}
> %% \documentclass[greek,ngerman]{scrreprt}
> %% \documentclass[greek,ngerman]{scrbook}
> %% \documentclass[greek,ngerman]{article}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage[ngerman]{babel}
> %% \PassOptionsToPackage{main=ngerman}{babel}
> \usepackage{alphabeta}
>
> \begin{document}
> Ach, unsere Freunde die Griechen: \textgreek{νους} (mit
> \verb|\textgreek{}|).\par
> Ach, unsere Freunde die Griechen: νους (direkt im Text).
> \end{document}
> ---cut---
> The commented document classes are all I had the time to test.
>
> Best, /PA
>
>
> On Sun, 21 Jan 2024 at 18:47, Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>> > +#+begin_example
>> > +,#+latex_class_options: [greek,spanish,oneside]
>> > +,#+language: es
>> > +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>> > +,#+latex_header: \usepackage{alphabeta} % to support greek script
>> > +#+end_example
>>
>> I think this example doesn't take advantage of the AUTO facility, which
>> is what the section is about. Btw, maybe it would be nice to extend
>> ''AUTO'' to
>> latex_class_options and \PassOptionsToPackage? Something like:
>>
>> #+latex_class_options: [greek,AUTO,oneside]
>> #+language: es
>> ...
>>
>> However, I would only find the \PassOptionsToPackage command useful in
>> classes that already load babel with a main language. From Org, using
>> just pdfTeX, I think it would be simpler:
>>
>> #+language: es
>> #+latex_header: \usepackage[greek,AUTO]{babel}
>> #+latex_header: \usepackage{alphabeta} % to support greek script
>>
>> or this variant, using babelprovide and an INI file:
>>
>> #+language: es
>> #+latex_header: \usepackage[greek]{babel}
>> #+latex_header: \babelprovide[import,main]{AUTO}
>> #+latex_header: \usepackage{alphabeta}
>>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
[-- Attachment #2: Type: text/html, Size: 4747 bytes --]
^ permalink raw reply [relevance 0%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
2024-01-21 17:47 9% ` Juan Manuel Macías
2024-01-22 6:30 6% ` Pedro Andres Aranda Gutierrez
@ 2024-01-22 12:10 6% ` Ihor Radchenko
2024-01-22 13:40 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-22 12:10 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Pedro Andres Aranda Gutierrez writes:
>
>> +#+begin_example
>> +,#+latex_class_options: [greek,spanish,oneside]
>> +,#+language: es
>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
>> +#+end_example
>
> I think this example doesn't take advantage of the AUTO facility, which
> is what the section is about.
Do you have any suggestions how to improve the patch?
> ... Btw, maybe it would be nice to extend ''AUTO'' to
> latex_class_options and \PassOptionsToPackage? Something like:
It would really be nice to have an ox-latex maintainer who is deeply
familiar with LaTeX :)
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
2024-01-22 6:47 0% ` Pedro Andres Aranda Gutierrez
@ 2024-01-22 13:11 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-22 13:11 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Hi, Pedro Andrés,
Pedro Andres Aranda Gutierrez writes:
> PS: This is a very limited example. It would be nice to have more
> control on fontenc. AFAIK there is not alphabeta for cyrillic
> encodings and typesetting 'War and Peace' with its passages in French
> embedded in the Russian text is sort of a headache ;-)
For scripts other than Latin it is highly recommended to use the 'new'
Unicode versions of TeX, XeTeX or LuaTeX, especially the latter, since
it is the natural replacement for pdfTeX. The input is Unicode and you
can easily use true type or opentype fonts via the fontspec package.
Babel already has full support for these engines and it is not necessary
to use polyglossia. Even with Babel you can associate fonts with certain
scripts such as Greek, Cyrillic, Devanagari, etc. Look at this example I
made with several scripts and several fonts:
https://i.imgur.com/56P6U0R.png
I'm currently working on Org having multilingual font and script support
in LaTeX export with LuaTeX and babel. Although now I have put it on
hold due to lack of time :-). And Ihor is working on a much more
flexible language naming system. These are issues that were discussed,
among others, in this thread:
https://list.orgmode.org/878r9t7x7y.fsf@posteo.net/
Regarding your patch example, is there any special reason for you to
load the languages in the class options? It's perfectly valid, although,
as I said, it's not supported by org's AUTO facility (at the moment). I
understand that it is useful when the document is monolingual, but for
more than one language I find it unnecessary and, in addition to loading the
options with \PassOptionsToPackage.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
2024-01-22 12:10 6% ` Ihor Radchenko
@ 2024-01-22 13:40 8% ` Juan Manuel Macías
2024-01-23 7:41 3% ` Pedro Andres Aranda Gutierrez
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-22 13:40 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> +#+begin_example
>>> +,#+latex_class_options: [greek,spanish,oneside]
>>> +,#+language: es
>>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
>>> +#+end_example
>>
>> I think this example doesn't take advantage of the AUTO facility, which
>> is what the section is about.
> Do you have any suggestions how to improve the patch?
I would give an example that did include the AUTO 'facility', to unify
with the rest of the examples in the section:
#+language: es
#+latex_header: \usepackage[greek,ngerman,AUTO]{babel}
#+latex_header: \usepackage{alphabeta} % to support greek script
It is also said in the patch that this example is for pdfTeX, but it
works equally well for LuaTeX and XeTeX, since Babel and alphabeta
packages support both engines. However, the alphabeta package is not a
specific package for writing texts in Greek. Rather, according to the
package documentation: "The alphabeta package makes the standard macros
for Greek letters in mathematical mode also available in text mode." In
pdfTeX it is useful because you can enter the Greek input directly in
Unicode. But in LuaTeX or XeTeX it would be unnecessary, since Greek can
be written directly, without the help of additional packages.
>> ... Btw, maybe it would be nice to extend ''AUTO'' to
>> latex_class_options and \PassOptionsToPackage? Something like:
>
> It would really be nice to have an ox-latex maintainer who is deeply
> familiar with LaTeX :)
My knowledge of LaTeX (and Elisp) has huge gaps :-). Of course, I am
willing to learn everything I can. And, naturally, I would like to help
in any way I can. But my main problem (currently) is the lack of time to
dedicate myself to it. My presence on this list is intermittent, and
that for a maintainer is horrible. Maybe in a few months (spring
perhaps), when my personal situation stabilizes a little, I could
consider it...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
2024-01-22 13:40 8% ` Juan Manuel Macías
@ 2024-01-23 7:41 3% ` Pedro Andres Aranda Gutierrez
0 siblings, 0 replies; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-01-23 7:41 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List
[-- Attachment #1.1: Type: text/plain, Size: 2920 bytes --]
Hi,
Attached is a _proof of concept_ for supporting AUTO in
\usepackage{fontenc}. Just an idea of how things could evolve.
This only uses a variable you can define as directory or file local to
control what is generated in the LaTeX file.
Could be expanded in the future to check #+language:
Best, /PA
On Mon, 22 Jan 2024 at 14:40, Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Ihor Radchenko writes:
>
> > Juan Manuel Macías <maciaschain@posteo.net> writes:
> >
> >> Pedro Andres Aranda Gutierrez writes:
> >>
> >>> +#+begin_example
> >>> +,#+latex_class_options: [greek,spanish,oneside]
> >>> +,#+language: es
> >>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> >>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> >>> +#+end_example
> >>
> >> I think this example doesn't take advantage of the AUTO facility, which
> >> is what the section is about.
>
> > Do you have any suggestions how to improve the patch?
>
> I would give an example that did include the AUTO 'facility', to unify
> with the rest of the examples in the section:
>
> #+language: es
> #+latex_header: \usepackage[greek,ngerman,AUTO]{babel}
> #+latex_header: \usepackage{alphabeta} % to support greek script
>
> It is also said in the patch that this example is for pdfTeX, but it
> works equally well for LuaTeX and XeTeX, since Babel and alphabeta
> packages support both engines. However, the alphabeta package is not a
> specific package for writing texts in Greek. Rather, according to the
> package documentation: "The alphabeta package makes the standard macros
> for Greek letters in mathematical mode also available in text mode." In
> pdfTeX it is useful because you can enter the Greek input directly in
> Unicode. But in LuaTeX or XeTeX it would be unnecessary, since Greek can
> be written directly, without the help of additional packages.
>
> >> ... Btw, maybe it would be nice to extend ''AUTO'' to
> >> latex_class_options and \PassOptionsToPackage? Something like:
> >
> > It would really be nice to have an ox-latex maintainer who is deeply
> > familiar with LaTeX :)
>
> My knowledge of LaTeX (and Elisp) has huge gaps :-). Of course, I am
> willing to learn everything I can. And, naturally, I would like to help
> in any way I can. But my main problem (currently) is the lack of time to
> dedicate myself to it. My presence on this list is intermittent, and
> that for a maintainer is horrible. Maybe in a few months (spring
> perhaps), when my personal situation stabilizes a little, I could
> consider it...
>
> Best regards,
>
> Juan Manuel
>
>
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
[-- Attachment #1.2: Type: text/html, Size: 3828 bytes --]
[-- Attachment #2: 0001-PoC-support-AUTO-for-the-fontenc-package-in-LaTeX-ex.patch --]
[-- Type: text/x-patch, Size: 4180 bytes --]
From 66634498275a4dbea4cb8dc225db28bdea1bdf1a Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" <paaguti@gmail.com>
Date: Tue, 23 Jan 2024 08:31:46 +0100
Subject: [PATCH] PoC: support AUTO for the fontenc package in LaTeX exports
* lisp/org.el: Add `org-latex-fontenc' to support translation for
\usepackage[AUTO]{fontenc}
* lisp/ox-latex.el: Implement rudimentary translation for the above
---
lisp/org.el | 17 ++++++++++++-----
lisp/ox-latex.el | 36 ++++++++++++++++++++++++------------
2 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index cf9abafac..d4356e15d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3401,9 +3401,16 @@ header, or they will be appended."
x))
(default-value var)))
+(defcustom org-latex-fontenc "T1"
+ "The fontenc for the file. Customise to LGR,T1 when including
+Greek, etc."
+ :group 'org-export-latex
+ :type 'string
+ :safe #'stringp)
+
(defcustom org-latex-default-packages-alist
'(("AUTO" "inputenc" t ("pdflatex"))
- ("T1" "fontenc" t ("pdflatex"))
+ ("AUTO" "fontenc" t ("pdflatex"))
("" "graphicx" t)
("" "longtable" nil)
("" "wrapfig" nil)
@@ -15159,20 +15166,20 @@ INCREMENT-STEP divisor."
(setq hour (mod hour 24))
(setq pos-match-group 1
new (format "-%02d:%02d" hour minute)))
-
+
((org-pos-in-match-range pos 6) ;; POS on "dmwy" repeater char.
(setq pos-match-group 6
new (car (rassoc (+ nincrements (cdr (assoc (match-string 6 ts-string) idx))) idx))))
-
+
((org-pos-in-match-range pos 5) ;; POS on X in "Xd" repeater.
(setq pos-match-group 5
;; Never drop below X=1.
new (format "%d" (max 1 (+ nincrements (string-to-number (match-string 5 ts-string)))))))
-
+
((org-pos-in-match-range pos 9) ;; POS on "dmwy" repeater in warning interval.
(setq pos-match-group 9
new (car (rassoc (+ nincrements (cdr (assoc (match-string 9 ts-string) idx))) idx))))
-
+
((org-pos-in-match-range pos 8) ;; POS on X in "Xd" in warning interval.
(setq pos-match-group 8
;; Never drop below X=0.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 57ea66ef1..6da8b8e53 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1639,6 +1639,17 @@ For non-floats, see `org-latex--wrap-label'."
(org-trim label)
(org-export-data main info))))))
+(defun org-latex-guess-fontenc (header)
+ "Set the fontenc.
+
+This is currently a copy of `org-latex-guess-inputenc'.
+Currently only goes for `org-latex-fontenc', but can be extended.
+Replaces AUTO for the font encoding string."
+ (let ((fenc org-latex-fontenc))
+ (if (not fenc) header
+ (replace-regexp-in-string "\\\\usepackage\\[\\(AUTO\\)\\]{fontenc}"
+ fenc header t nil 1))))
+
(defun org-latex-guess-inputenc (header)
"Set the coding system in inputenc to what the buffer is.
@@ -1989,18 +2000,19 @@ specified in `org-latex-default-packages-alist' or
(user-error "Unknown LaTeX class `%s'" class))))
(org-latex-guess-polyglossia-language
(org-latex-guess-babel-language
- (org-latex-guess-inputenc
- (org-element-normalize-string
- (org-splice-latex-header
- class-template
- (org-latex--remove-packages org-latex-default-packages-alist info)
- (org-latex--remove-packages org-latex-packages-alist info)
- snippet?
- (mapconcat #'org-element-normalize-string
- (list (plist-get info :latex-header)
- (and (not snippet?)
- (plist-get info :latex-header-extra)))
- ""))))
+ (org-latex-guess-fontenc
+ (org-latex-guess-inputenc
+ (org-element-normalize-string
+ (org-splice-latex-header
+ class-template
+ (org-latex--remove-packages org-latex-default-packages-alist info)
+ (org-latex--remove-packages org-latex-packages-alist info)
+ snippet?
+ (mapconcat #'org-element-normalize-string
+ (list (plist-get info :latex-header)
+ (and (not snippet?)
+ (plist-get info :latex-header-extra)))
+ "")))))
info)
info)))
--
2.34.1
^ permalink raw reply related [relevance 3%]
* Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated
2024-01-20 16:04 0% ` Ihor Radchenko
@ 2024-01-24 13:21 0% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-01-24 13:21 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
> Juan Manuel Macías to emacs-orgmode… Re: how to export red colored TeX
> to latex. Tue, 30 Nov 2021 16:56:00 +0000.
> https://list.orgmode.org/87bl21vazj.fsf@posteo.net
>
> Likely should be modified a bit to support derived backends.
Done.
https://git.sr.ht/~bzg/worg/commit/405547ac
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 0%]
* Re: [BUG] Footnotes in section titles
@ 2024-01-24 15:23 12% ` Juan Manuel Macías
2024-01-24 15:31 0% ` Colin Baxter
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-24 15:23 UTC (permalink / raw)
To: Max Nikulin; +Cc: Eric Anderson, ihor Timothy, Ihor Radchenko, orgmode
Max Nikulin writes:
> I recall some tricks with \footnotemark and \footnotetext, but I do
> not remember details and whether it may work for section titles.
> Complications may arise if a heading title has several footnotes.
ox-latex has 'org-latex--delayed-footnotes-definitions': "[...] This
function is used within constructs that don't support \footnote{}
command (e.g., an item tag). In that case, \footnotemark is used within
the construct and the function just outside of it."
The \footnotetext/\footnotemark option works well for specific cases,
but in general I don't like to abuse this method.
> Perhaps it is better to avoid footnotes in titles and to add some
> phrase to the body instead.
That is the ideal scenario. I also believe that footnotes should be
avoided in section headings, if possible. Or at least, have another type
of numbering (symbols, letters...). The manyfoot and bigfoot packages
allow constructions of this type, with various footnote apparatus.
Best regards,
Juan Manuel
--
Juan Manuel Macías --
^ permalink raw reply [relevance 12%]
* Re: [BUG] Footnotes in section titles
2024-01-24 15:23 12% ` Juan Manuel Macías
@ 2024-01-24 15:31 0% ` Colin Baxter
2024-01-24 15:41 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Colin Baxter @ 2024-01-24 15:31 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Max Nikulin, Eric Anderson, ihor Timothy, Ihor Radchenko, orgmode
>>>>> Juan Manuel Macías <maciaschain@posteo.net> writes:
> Max Nikulin writes:
>> I recall some tricks with \footnotemark and \footnotetext, but I
>> do not remember details and whether it may work for section
>> titles. Complications may arise if a heading title has several
>> footnotes.
> ox-latex has 'org-latex--delayed-footnotes-definitions': "[...]
> This function is used within constructs that don't support
> \footnote{} command (e.g., an item tag). In that case,
> \footnotemark is used within the construct and the function just
> outside of it."
> The \footnotetext/\footnotemark option works well for specific
> cases, but in general I don't like to abuse this method.
>> Perhaps it is better to avoid footnotes in titles and to add some
>> phrase to the body instead.
> That is the ideal scenario. I also believe that footnotes should
> be avoided in section headings, if possible. Or at least, have
> another type of numbering (symbols, letters...). The manyfoot and
> bigfoot packages allow constructions of this type, with various
> footnote apparatus.
Indeed, but many journals *require* footnotes in titles, especially for
affiliation, email, etc.
^ permalink raw reply [relevance 0%]
* Re: [BUG] Footnotes in section titles
2024-01-24 15:31 0% ` Colin Baxter
@ 2024-01-24 15:41 9% ` Juan Manuel Macías
2024-01-26 12:53 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-24 15:41 UTC (permalink / raw)
To: Colin Baxter
Cc: Max Nikulin, Eric Anderson, ihor Timothy, Ihor Radchenko, orgmode
Colin Baxter writes:
> >> Perhaps it is better to avoid footnotes in titles and to add some
> >> phrase to the body instead.
>
> > That is the ideal scenario. I also believe that footnotes should
> > be avoided in section headings, if possible. Or at least, have
> > another type of numbering (symbols, letters...). The manyfoot and
> > bigfoot packages allow constructions of this type, with various
> > footnote apparatus.
>
> Indeed, but many journals *require* footnotes in titles, especially for
> affiliation, email, etc.
Notes on article titles (and even on the author name) are a slightly
different case from notes on section titles. In LaTeX there is the
"\thanks" command, which inserts footnotes for title and author,
numbered with fnsymbol. For example:
...
\title{Lorem ipsum dolor\thanks{blah blah}}
...
Org does not have support for this type of notes in the #+title or
#+author keywords. For LaTeX you can use a macro. For backends like odt
it is trickier. Look at this thread:
https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html
I think it would be nice if Org had some kind of support for notes in
#+title and #+author...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [BUG] Footnotes in section titles
2024-01-24 15:41 9% ` Juan Manuel Macías
@ 2024-01-26 12:53 5% ` Ihor Radchenko
2024-01-26 13:17 11% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-01-26 12:53 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Colin Baxter, Max Nikulin, Eric Anderson, ihor Timothy, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ...
> \title{Lorem ipsum dolor\thanks{blah blah}}
> ...
>
> Org does not have support for this type of notes in the #+title or
> #+author keywords. For LaTeX you can use a macro.
Hmm.
The reason footnotes are not allowed in #+title and other keywords is
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7ebe87e2d5fb6c
Inserting footnote references in parsed keywords (e.g., TITLE or
CAPTION) can lead to subtle bugs. Indeed, it is impossible to know in
time if that particular footnote is going to be used in the output,
and, therefore, if it should count, e.g., in
`org-export-get-footnote-number'.
However, I am not sure about that line of reasoning - we generally don't
know if *any* given footnote reference is going to be used in the output
or not because export backend may skip references or whole parts of the
original Org file. Same for user filters.
So, I am leaning towards reverting that commit - that will allow things
like
#+TITLE: This is a test title[fn::This is test]
If we need special handling for footnotes in title (like using \thanks
instead of \footnote), it is easy.
> ... For backends like odt
> it is trickier. Look at this thread:
>
> https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html
>
> I think it would be nice if Org had some kind of support for notes in
> #+title and #+author...
No idea about how to do it in ODT. If someone familiar with OpenDocument
spec can help, it would be welcome.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [BUG] Footnotes in section titles
2024-01-26 12:53 5% ` Ihor Radchenko
@ 2024-01-26 13:17 11% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-26 13:17 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Colin Baxter, Max Nikulin, Eric Anderson, ihor Timothy, orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> ...
>> \title{Lorem ipsum dolor\thanks{blah blah}}
>> ...
>>
>> Org does not have support for this type of notes in the #+title or
>> #+author keywords. For LaTeX you can use a macro.
>
> Hmm.
> The reason footnotes are not allowed in #+title and other keywords is
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7ebe87e2d5fb6c
>
> Inserting footnote references in parsed keywords (e.g., TITLE or
> CAPTION) can lead to subtle bugs. Indeed, it is impossible to know in
> time if that particular footnote is going to be used in the output,
> and, therefore, if it should count, e.g., in
> `org-export-get-footnote-number'.
>
> However, I am not sure about that line of reasoning - we generally don't
> know if *any* given footnote reference is going to be used in the output
> or not because export backend may skip references or whole parts of the
> original Org file. Same for user filters.
>
> So, I am leaning towards reverting that commit - that will allow things
> like
>
> #+TITLE: This is a test title[fn::This is test]
>
> If we need special handling for footnotes in title (like using \thanks
> instead of \footnote), it is easy.
I completely agree. I think it would be a great improvement, since, as
Colin Baxter says, in academic articles it is a very common practice to
add foot notes to the title of the article or the name of the author.
As for the \thanks{} command, org exports the keyword #+email within a
\thanks{} command as '\author{Name\thanks{email}}0. I don't think two
\thanks macros collide within author (assuming the user adds the email
and puts a footnote in #+author. Anyway, I think the most common thing
is to put the email below the author's name, not as a footnote, but that
is another topic and also depends on the style of each publication,
journal, etc.
>> ... For backends like odt
>> it is trickier. Look at this thread:
>>
>> https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html
>>
>> I think it would be nice if Org had some kind of support for notes in
>> #+title and #+author...
>
> No idea about how to do it in ODT. If someone familiar with OpenDocument
> spec can help, it would be welcome.
I don't have much idea about odt, but I think the problem comes from a
type of nesting that is not allowed in the odt xml. I think org exports
#+author inside the initial-creator tag:
(format "<meta:initial-creator>%s</meta:initial-creator>\n" author)
And within that tag the code for a footnote produces an error when
opening the document. If the footnote is placed right after
</meta:initial-creator>, there would be no problem.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* An academic journal entirely made in Org-Mode
@ 2024-01-29 20:03 10% Juan Manuel Macías
2024-01-29 20:16 6% ` Daniel Ortmann
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-29 20:03 UTC (permalink / raw)
To: orgmode
Hi,
In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
of Latin Studies) was published, sponsored by the Spanish Society of
Latin Studies. It is designed and produced by me using Org-Mode,
Org-Publish and LuaTeX. If anyone is interested in the code I used for
specific aspects of the publication, I can share it here :-).
Link to the journal in PDF version:
https://recyt.fecyt.es/index.php/rel/issue/view/4327/948
And a screenshot of the making-off:
https://i.imgur.com/lkwIOGA.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* An academic journal made entirely in Org-Mode
@ 2024-01-29 20:05 10% Juan Manuel Macías
2024-01-30 0:00 6% ` William Denton
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-29 20:05 UTC (permalink / raw)
To: orgmode
Hi,
In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
of Latin Studies) was published, sponsored by the Spanish Society of
Latin Studies. It is designed and produced by me using Org-Mode,
Org-Publish and LuaTeX. If anyone is interested in the code I used for
specific aspects of the publication, I can share it here :-).
Link to the journal in PDF version:
https://recyt.fecyt.es/index.php/rel/issue/view/4327/948
And a screenshot of the making-off:
https://i.imgur.com/lkwIOGA.png
Best regards,
Juan Manuel
--
^ permalink raw reply [relevance 10%]
* Re: An academic journal entirely made in Org-Mode
2024-01-29 20:03 10% An academic journal entirely made in Org-Mode Juan Manuel Macías
@ 2024-01-29 20:16 6% ` Daniel Ortmann
2024-01-29 23:16 6% ` Dr. Arne Babenhauserheide
2024-01-30 5:34 6% ` tomas
2 siblings, 0 replies; 200+ results
From: Daniel Ortmann @ 2024-01-29 20:16 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
Yes, please!
--
Daniel Ortmann<dortmann31415@pobox.com>
https://www.linkedin.com/in/danieldeanortmann/
https://ieee-collabratec.ieee.org/app/p/DanielDeanOrtmann/
612-518-3147 m
On 1/29/24 14:03, Juan Manuel Macías wrote:
> Hi,
>
> In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
> of Latin Studies) was published, sponsored by the Spanish Society of
> Latin Studies. It is designed and produced by me using Org-Mode,
> Org-Publish and LuaTeX. If anyone is interested in the code I used for
> specific aspects of the publication, I can share it here :-).
>
> Link to the journal in PDF version:
>
> https://recyt.fecyt.es/index.php/rel/issue/view/4327/948
>
> And a screenshot of the making-off:
>
> https://i.imgur.com/lkwIOGA.png
>
> Best regards,
>
> Juan Manuel
>
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 1702 bytes --]
^ permalink raw reply [relevance 6%]
* Re: An academic journal entirely made in Org-Mode
2024-01-29 20:03 10% An academic journal entirely made in Org-Mode Juan Manuel Macías
2024-01-29 20:16 6% ` Daniel Ortmann
@ 2024-01-29 23:16 6% ` Dr. Arne Babenhauserheide
2024-01-31 14:30 6% ` Juan Manuel Macías
2024-01-30 5:34 6% ` tomas
2 siblings, 1 reply; 200+ results
From: Dr. Arne Babenhauserheide @ 2024-01-29 23:16 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
Hi,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Org-Publish and LuaTeX. If anyone is interested in the code I used for
> specific aspects of the publication, I can share it here :-).
That sounds very interesting! I’m writing roleplaying books and my
website with org-mode and since there are many small pieces I found over
the years, I expect that the solved problems for a journal will be very
educational!
> https://recyt.fecyt.es/index.php/rel/issue/view/4327/948
One small thing: the boxes for the abstract look pretty nice! How to
create the complex tables on page 109ff would also be great to know.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [relevance 6%]
* Re: An academic journal made entirely in Org-Mode
2024-01-29 20:05 10% An academic journal made entirely " Juan Manuel Macías
@ 2024-01-30 0:00 6% ` William Denton
0 siblings, 0 replies; 200+ results
From: William Denton @ 2024-01-30 0:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Monday, January 29th, 2024 at 15:05, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
> of Latin Studies) was published, sponsored by the Spanish Society of
> Latin Studies. It is designed and produced by me using Org-Mode,
> Org-Publish and LuaTeX. If anyone is interested in the code I used for
> specific aspects of the publication, I can share it here :-).
Fantastic work! Congratulations. Open scholarship in every sense of the word. I'd love to see how you handled the publishing of such a complex project. (And what citation style is used by that journal?)
Bill
--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
^ permalink raw reply [relevance 6%]
* Re: An academic journal entirely made in Org-Mode
2024-01-29 20:03 10% An academic journal entirely made in Org-Mode Juan Manuel Macías
2024-01-29 20:16 6% ` Daniel Ortmann
2024-01-29 23:16 6% ` Dr. Arne Babenhauserheide
@ 2024-01-30 5:34 6% ` tomas
2 siblings, 0 replies; 200+ results
From: tomas @ 2024-01-30 5:34 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
On Mon, Jan 29, 2024 at 08:03:36PM +0000, Juan Manuel Macías wrote:
> Hi,
>
> In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
> of Latin Studies) was published, sponsored by the Spanish Society of
> Latin Studies. It is designed and produced by me using Org-Mode,
> Org-Publish and LuaTeX. If anyone is interested in the code I used for
> specific aspects of the publication, I can share it here :-).
Very nice, thanks :)
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [relevance 6%]
* Re: An academic journal entirely made in Org-Mode
2024-01-29 23:16 6% ` Dr. Arne Babenhauserheide
@ 2024-01-31 14:30 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-31 14:30 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: emacs-orgmode
Hi, Arne, thank you for your comments.
Dr. Arne Babenhauserheide writes:
> Hi,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Org-Publish and LuaTeX. If anyone is interested in the code I used for
>> specific aspects of the publication, I can share it here :-).
>
> That sounds very interesting! I’m writing roleplaying books and my
> website with org-mode and since there are many small pieces I found over
> the years, I expect that the solved problems for a journal will be very
> educational!
I am currently responsible for the production of five academic journals,
and I have ended up developing a fairly productive workflow using
org/luatex. A little background on the matter: in my editorial design
work I used to work only in (La)TeX, but I discovered that org can
function as a fairly competent high-level interface to LaTeX. One of the
main advantages is the clarity that a light markup language brings to
the content, since pure LaTeX code is cumbersome. I know LaTeX code
reasonably well (in fact, I'm working on a couple of packages for
LuaLaTeX), but it's not comfortable for me to work on content.
Naturally, for heavy and complex jobs, post-processing is always
necessary. Org is still very useful as it is not only a lightweight
markup language but also a set of tools. And, loosely speaking, a work
environment on Emacs (which in itself is a work environment).
The main challenge of this workflow is obtaining the content, the data,
from the Word documents that the authors deliver, since, unfortunately,
everyone uses Word. Pandoc does a good job, as long as the Word
documents arrive reasonably well structured. Unfortunately, this is not
the case, at least in Humanities. Word documents usually have the
following defects:
- abuse of direct format;
- absence of applied styles, therefore it is impossible to obtain a
hierarchical outline of the document;
- absence of an automated system of bibliographies and citations.
Humanities authors don't even use "friendly" things like Zotero. That
is, Humanities authors make citations and bibliographies by hand (!!),
which means multiplying inconsistencies and typos.
Therefore, it is necessary to subject the original Word documents to a
cleaning process. Then I run pandoc using some templates and some custom
lua filters.
The journal is basically an org-publish project, where only the articles
and other parts are exported to *.tex files. There is a master document
that I export and compile using a function that runs latexmk in
interactive mode. This way I have more control over the parts, I can
deactivate nodes, etc. Each node, therefore, is an article, with a
series of properties: author, email, orcid-id, doi, title in English,
etc. In a sty document created ad hoc I have defined a series of LaTeX
variables, and then incorporated them into each heading. E.g.:
#+begin_src latex
\def\@author{}
\newcommand\author[1]{\def\@author{#1}}
\def\@mail{}
\newcommand\mail[1]{\def\@mail{#1}}
\def\@doi{}
\newcommand\doi[1]{\def\@doi{DOI: #1}}
etc...
#+end_src
I use org-capture to populate the nodes in the master document with all
that information.
>> https://recyt.fecyt.es/index.php/rel/issue/view/4327/948
>
> One small thing: the boxes for the abstract look pretty nice! How to
> create the complex tables on page 109ff would also be great to know.
The boxes are made with the mdframed package, which is very versatile for this type of
objets. The code used:
#+begin_src latex
\usepackage[framemethod=tikz,everyline=true]{mdframed}
#+end_src
A box style:
#+begin_src latex
\colorlet{background}{gray!7}
\mdfdefinestyle{mdabstracts}{%
linewidth=.3pt,
topline = true,
leftline =true,
rightline = true,
bottomline = true,
skipabove=0pt,
skipbelow=2\bigskipamount,
leftmargin=0em,
backgroundcolor=background,
roundcorner = 5pt,
innerleftmargin=1.5em,
rightmargin=0em,
innerrightmargin=1.5em,
innertopmargin=1em,
splittopskip=\topskip,
innerbottommargin=1em,
}
#+end_src
And an environment:
#+begin_src latex
\newmdenv[style=mdabstracts]{abstracts}
#+end_src
As for tables, I always try to apply the ideas of Edward Tufte. I use the booktabs package
with some modifications. An example of a table:
https://i.imgur.com/70NtdGb.png
Here I use these two macros:
#+macro: cmd @@latex:\cmidrule(rl){$1}@@
#+macro: mc @@latex:\multicolumn{$1}{$2}{$3}@@
And this filter for multicolumn rows (simply, the cells that contain "!!" are removed:
#+BIND: org-export-filter-table-functions (my-multicolumn-filter)
#+begin_src emacs-lisp :exports results :results none
(defun my-multicolumn-flilter (texto backend info)
(when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "&\s+!!" "" texto)))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
@ 2024-02-01 17:44 10% ` Juan Manuel Macías
2024-02-01 17:57 5% ` Marvin Gülker
2024-02-02 17:00 5% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-01 17:44 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 26/01/2024 19:53, Ihor Radchenko wrote:
>>> So, I am leaning towards reverting that commit - that will allow things
>>> like
>>>
>>> #+TITLE: This is a test title[fn::This is test]
>>
>> I hope, document metadata will be generated with stripped footnotes.
>
> This is a good point.
>
> For now, [fn::This is test], when passed to exporters, is simply treated
> as plain text.
>
> If we change the parser nesting rules, Org will pass footnote-reference
> objects instead.
>
> Then, in a number of parsers, if something like
> (org-export-data (plist-get info :title) info) or
> (org-export-data author info)
> is used, footnotes may break export because metadata fields often have
> special rules about markup that is allowed inside.
>
> In particular, ox-odt will be broken; ox-latex will be broken.
>
> Of course, we can adjust built-in backends to take into account the new
> parsing rules, but we have no control over the third-party backends.
>
> On the other hand, when user exports something like
>
> #+AUTHOR: John Doe[fn::935 Pennsylvania Avenue, NW Washington, D.C. 20535-0001]
> it is probably not exported as expected anyway.
How about using dedicated keywords? Something like:
#+FN_AUTHOR: footnote text
#+FN_TITLE: footnote text
I give these two examples because they are the two places where a
footnote of this type is expected. I know: it's ugly and corseted (what
to do if a title has more than one footnote or an "inner" footnote?).
But I suppose it would be safe for a basic case, since it would only be
necessary to modify org-latex-template, org-odt-template, etc., without
risk of unexpected results.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
2024-02-01 17:44 10% ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) Juan Manuel Macías
@ 2024-02-01 17:57 5% ` Marvin Gülker
2024-02-02 17:00 5% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Marvin Gülker @ 2024-02-01 17:57 UTC (permalink / raw)
To: emacs-orgmode
Am Donnerstag, dem 01. Februar 2024 schrieb Juan Manuel Macías:
> How about using dedicated keywords? Something like:
>
> #+FN_AUTHOR: footnote text
> #+FN_TITLE: footnote text
For reference -- I do not know if this prompted the discussion here --
just a few days ago I asked about footnotes in author information
because such footnotes are just so common in the field I write in. They
are used to give a short description of the author's position usually
("XY is a researcher at the chair of Foo Bar..."). Since in my field I
have to submit DOCX to journals, such footnotes should be properly
exported by ox-odt in particular.
Here is the thread over at emacs-humanities:
https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html
It includes an ugly workaround I applied in form of an advice. A proper
solution directly in org would of course be much preferable.
I like the dedicated keyword solution. This way third party backends
will probably ignore the new keywords, because for them they will look
like a comment.
Marvin
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland | kontakt@guelker.eu | O<
^ permalink raw reply [relevance 5%]
* Re: [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages
@ 2024-02-02 16:18 12% ` Juan Manuel Macías
2024-02-02 16:41 0% ` Pedro Andres Aranda Gutierrez
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-02 16:18 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Ihor Radchenko writes:
> #+LANGUAGE: fa
> #+LaTeX_Header: \usepackage[AUTO]{polyglossia}
>
> #+latex_header: \usepackage[AUTO]{fontspec}
I think Pedro is referring to fontenc not fontspec. fontenc cannot be
used in either lualatex or XelaTeX. fontspec is for advanced selection
of truetype and opentype fonts in XeLatex and LuaLaTeX and setting
opentype properties. fontenc is for 'pre-Unicode' LaTeX font encoding. I
would say that what Pedro proposes is limited only to the output in
pdfTeX.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages
2024-02-02 16:18 12% ` Juan Manuel Macías
@ 2024-02-02 16:41 0% ` Pedro Andres Aranda Gutierrez
0 siblings, 0 replies; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-02-02 16:41 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List
Hi,
I’m just trying to cover the “legacy” latex.
I’ve finally migrated to lualatex for my stuff, and it has really been worthwhile. But who knows what a conference might want me to use ;-P
Differentiating between pdflatex and lualatex was what my last patch was for.
I also sent a PoC for the fontenc stuff a couple of weeks ago. And I was trying to continue this work and collect info needed for handling fontenc when you need pdflatex as your latex compiler.
Best, /PA
> El 2 feb 2024, a las 17:18, Juan Manuel Macías <maciaschain@posteo.net> escribió:
>
> Ihor Radchenko writes:
>
>> #+LANGUAGE: fa
>> #+LaTeX_Header: \usepackage[AUTO]{polyglossia}
>>
>> #+latex_header: \usepackage[AUTO]{fontspec}
>
> I think Pedro is referring to fontenc not fontspec. fontenc cannot be
> used in either lualatex or XelaTeX. fontspec is for advanced selection
> of truetype and opentype fonts in XeLatex and LuaLaTeX and setting
> opentype properties. fontenc is for 'pre-Unicode' LaTeX font encoding. I
> would say that what Pedro proposes is limited only to the output in
> pdfTeX.
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
>
^ permalink raw reply [relevance 0%]
* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
2024-02-01 17:44 10% ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) Juan Manuel Macías
2024-02-01 17:57 5% ` Marvin Gülker
@ 2024-02-02 17:00 5% ` Ihor Radchenko
2024-02-02 18:10 13% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-02 17:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> #+AUTHOR: John Doe[fn::935 Pennsylvania Avenue, NW Washington, D.C. 20535-0001]
>> it is probably not exported as expected anyway.
>
> How about using dedicated keywords? Something like:
>
> #+FN_AUTHOR: footnote text
> #+FN_TITLE: footnote text
What if you have multiple authors?
If you mean
#+AUTHOR: author1
#+FN_AUTHOR: footnote for author 1
#+AUTHOR: author2
#+FN_AUTHOR: footnote for author 2
, it is actually problematic because the code concatenates the values of
#+AUTHOR keywords before processing, and it is hard to know which author
corresponds to which footnote.
If we really need something safe, pre-processing values in ox.el and
producing backward-compatible :author value and addition
:author-w-footnotes value in the export INFO plist would be more
reasonable and less ugly. Still ugly though.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
2024-02-02 17:00 5% ` Ihor Radchenko
@ 2024-02-02 18:10 13% ` Juan Manuel Macías
2024-02-02 20:21 5% ` Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)) Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-02 18:10 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> #+AUTHOR: author1
> #+FN_AUTHOR: footnote for author 1
>
> #+AUTHOR: author2
> #+FN_AUTHOR: footnote for author 2
Sorry if this is off topic, but something like this:
#+AUTHOR: Fred Astaire
#+AUTHOR: Ginger Rogers
is exported to LaTeX as:
\author{Fred Astaire Ginger Rogers}
Shouldn't there be some separation? In LaTeX the usual thing is:
\author{Fred Astaire \and Ginger Rogers}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc))
2024-02-02 18:10 13% ` Juan Manuel Macías
@ 2024-02-02 20:21 5% ` Ihor Radchenko
2024-02-02 22:26 11% ` Exporting multiple #+AUTHOR keywords Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-02 20:21 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Sorry if this is off topic, but something like this:
>
> #+AUTHOR: Fred Astaire
> #+AUTHOR: Ginger Rogers
>
> is exported to LaTeX as:
>
> \author{Fred Astaire Ginger Rogers}
>
> Shouldn't there be some separation? In LaTeX the usual thing is:
>
> \author{Fred Astaire \and Ginger Rogers}
You can do
#+AUTHOR: Fred
#+AUTHOR: Astaire
#+AUTHOR: and Ginger
#+AUTHOR: Rogers
The values are simply concatenated before passing to the exporter.
Can we concatenate with "\and"? Sure. But not by default or it would be
a breaking change.
In fact, you can already concatenate with "\and" when exporting
subtrees:
(push '("EXPORT_AUTHOR" . "\\and ") org-property-separators)
then
* This is test
:PROPERTIES:
:EXPORT_AUTHOR: John Doe
:EXPORT_AUTHOR+: David Stefanson
:END:
Text.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Exporting multiple #+AUTHOR keywords
2024-02-02 20:21 5% ` Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)) Ihor Radchenko
@ 2024-02-02 22:26 11% ` Juan Manuel Macías
2024-02-04 15:21 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-02 22:26 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Sorry if this is off topic, but something like this:
>>
>> #+AUTHOR: Fred Astaire
>> #+AUTHOR: Ginger Rogers
>>
>> is exported to LaTeX as:
>>
>> \author{Fred Astaire Ginger Rogers}
>>
>> Shouldn't there be some separation? In LaTeX the usual thing is:
>>
>> \author{Fred Astaire \and Ginger Rogers}
>
> You can do
>
> #+AUTHOR: Fred
> #+AUTHOR: Astaire
>
> #+AUTHOR: and Ginger
> #+AUTHOR: Rogers
>
> The values are simply concatenated before passing to the exporter.
>
> Can we concatenate with "\and"? Sure. But not by default or it would be
> a breaking change.
Thanks for the explanation. I've never made documents with more than one
author, so I've never thought about this scenario. For a moment I
thought org supported more than one author (explicitly, I mean).
Anyway, \and is just a formatting command: add a space between two
authors. Some people may prefer to put a line break \\ or anything else.
Of course, \and (and any other format command) will have a negative
effect on the pdfauthor metadata, which only collects text strings. It
is a similar problem to the one with footnotes, which Maxim commented
on. I think the basic problem is that org uses #+author, #+title, etc.
as a single source for both the metadata strings and the exported
format, i.e. the title, the author, the date that is printed somewhere.
Perhaps the ideal would be to distinguish in some way between
author-metadata and author-exported-format. For example something like:
#+AUTHOR[John Doe and Luke Skywalker]: John Doe @@latex:\and@@ Luke
Skywalker
The optional string in square brackets would be the metadata; the rest
would be the direct exported format. If there is no optional string, the
value is used for both metadata and format. Could this be also a
possible solution to the footnote problem?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: Exporting multiple #+AUTHOR keywords
2024-02-02 22:26 11% ` Exporting multiple #+AUTHOR keywords Juan Manuel Macías
@ 2024-02-04 15:21 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-04 15:21 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ... I think the basic problem is that org uses #+author, #+title, etc.
> as a single source for both the metadata strings and the exported
> format, i.e. the title, the author, the date that is printed somewhere.
>
> Perhaps the ideal would be to distinguish in some way between
> author-metadata and author-exported-format. For example something like:
>
> #+AUTHOR[John Doe and Luke Skywalker]: John Doe @@latex:\and@@ Luke
> Skywalker
>
> The optional string in square brackets would be the metadata; the rest
> would be the direct exported format. If there is no optional string, the
> value is used for both metadata and format. Could this be also a
> possible solution to the footnote problem?
Another option is to have a new set of keywords:
#+LATEX_AUTHOR: <author with formatting goes here>
#+HTML_AUTHOR: ...
For multiple authors, we may introduce something like
#+AUTHOR: John Doe
#+AUTHOR+: Luke Skywalker
That should be fully backwards-compatible.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [DISCUSSION] Add "Recent News" to orgmode.org
@ 2024-02-04 20:24 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-04 20:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Sacha Chua, Bastien, Timothy
Ihor Radchenko writes:
> Hi,
>
> What do you think about an idea to modify Org mode front page
> (https://orgmode.org/), adding the most recent blog posts and
> discussions about Org mode?
>
> We might use Org-related records from Sacha's news and/or
> https://planet.emacslife.com/ as a source, scrape it regularly (once per
> day/week or on every export), and embed the relevant links into the
> orgweb/index.html
>
> This way, visitors can easily see how active Org mode community is and
> discover Org-related blogs/forums.
+1
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Exporting multiple #+AUTHOR keywords
@ 2024-02-04 22:13 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-04 22:13 UTC (permalink / raw)
To: Max Nikulin; +Cc: Ihor Radchenko, orgmode
Max Nikulin writes:
> On 04/02/2024 22:21, Ihor Radchenko wrote:
>>
>> Another option is to have a new set of keywords:
>> #+LATEX_AUTHOR: <author with formatting goes here>
>> #+HTML_AUTHOR: ...
>>
>> For multiple authors, we may introduce something like
>>
>> #+AUTHOR: John Doe
>> #+AUTHOR+: Luke Skywalker
>
> Another idea:
>
> #+metadata:
> - author ::
> - John Doe
> - Luke Skywalker
> - title :: Some text
>
> With overrides for specific backends
>
> #+metadata: :backend latex
> - author :: ....
>
> Perhaps backends may declare if they support footnotes, etc. by defining
> some backend property.
I like both ideas. If I had to choose, perhaps I would prefer Ihor's
approach since it separates the formatting value and the metadata value
using simple keywords. I understand that in the former you could add any
direct format (LaTeX, odt, html...), macros and even footnotes. And if
the former is not explicitly included in the document, then the latter
is used to populate both the formatting value and the metadata value.
Anyway, I think your approach would work very well for more complex pdf
metadata like xmp. Maybe using the hyperxmp package, which you mentioned
in a thread months ago?
Maybe something like this:
#+latex_xmp
...
#+end
?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Link type for pdf-tools annotations
@ 2024-02-08 22:13 11% Juan Manuel Macías
2024-02-08 23:25 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-08 22:13 UTC (permalink / raw)
To: orgmode
Hi,
Many times I need to "save" an annotation point in the pdf-tools
annotations buffer. So I defined a new link type and the function to
store it. The link is stored with the structure:
[[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]
The link opens the PDF and jumps to the specific annotation. A screenshot:
https://i.imgur.com/hw96NfD.png
I share the code here in case it is useful to someone:
#+begin_src emacs-lisp
(defun my-org-pdf-annot-store-link ()
(when (equal (format "%s" major-mode) "pdf-annot-list-mode")
(let* ((pdf-buf pdf-annot-list-document-buffer)
(pdf-file (buffer-file-name pdf-buf))
(annot (pdf-annot-getannot (tabulated-list-get-id) pdf-buf))
(date (pdf-annot-print-property annot 'modified))
(page (save-excursion
(beginning-of-line)
(re-search-forward "\\(^\s+\\)\\([[:digit:]]+\\)" nil t)
(match-string 2)))
(link (concat "pdf-annot:" pdf-file "::" date))
(desc (format "%s (annot. on p. %s)" (file-name-nondirectory pdf-file) page)))
(org-link-store-props
:type "pdf-annot"
:link link
:description desc))))
(org-link-set-parameters
"pdf-annot"
:follow (lambda (path)
(let ((a (if (string-match "::\\(.+\\)" path)
(match-string 1 path)
(error "no annotation date")))
(file-path (replace-regexp-in-string "::.+" "" path)))
(find-file file-path)
(pdf-annot-list-annotations)
(let ((anot-buf (format "*%s's annots*"
(file-name-sans-extension
(buffer-name)))))
(with-current-buffer anot-buf
(save-excursion
(goto-char (point-min))
(re-search-forward a nil t)
(call-interactively #'pdf-annot-list-display-annotation-from-id))))))
:store #'my-org-pdf-annot-store-link)
#+end_src
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: Link type for pdf-tools annotations
2024-02-08 22:13 11% Link type for pdf-tools annotations Juan Manuel Macías
@ 2024-02-08 23:25 6% ` Ihor Radchenko
2024-02-09 0:40 11% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-08 23:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Many times I need to "save" an annotation point in the pdf-tools
> annotations buffer. So I defined a new link type and the function to
> store it. The link is stored with the structure:
>
> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]
>
> The link opens the PDF and jumps to the specific annotation.
You may also utilize `org-create-file-search-functions' and
`org-execute-file-search-functions' to make an ordinary file: links
works for the same purpose.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Link type for pdf-tools annotations
2024-02-08 23:25 6% ` Ihor Radchenko
@ 2024-02-09 0:40 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-09 0:40 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Many times I need to "save" an annotation point in the pdf-tools
>> annotations buffer. So I defined a new link type and the function to
>> store it. The link is stored with the structure:
>>
>> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]
>>
>> The link opens the PDF and jumps to the specific annotation.
>
> You may also utilize `org-create-file-search-functions' and
> `org-execute-file-search-functions' to make an ordinary file: links
> works for the same purpose.
Thanks for the pointers. Note that in this use case I don't need to
search in the PDF file itself but in the pdf-annot-list-mode buffer that
is created via pdf-annot-list-annotations. This buffer is synchronized
with the PDF to which it is linked. What this link type does is visit
the pdf file (with pdf-tools), create the list of annotations and jump
to the specific annotation, by date.
pdf-annot-list-display-annotation-from-id highlights the specific list
annotation in the linked PDF (if necessary, moves to the corresponding
page), and opens the content of the annotation in another window
(interactively the function is executed by pressing SPC on the
annotation list at point). Storing the annotation date seemed like the
safest option to me, since the annotation id can change when adding new
annotations, each time the list is created. The typical scenario: when I
am consulting a PDF annotated by someone and I want to store the
location of some specific annotations. As there can be many annotations
per page, adding a simple bookmark to the page would not be enough
either.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: Link type for pdf-tools annotations
@ 2024-02-09 12:48 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-09 12:48 UTC (permalink / raw)
To: Irfan S; +Cc: orgmode
Irfan S writes:
> FYI, there is also
> [[https://github.com/fuxialexander/org-pdftools][org-pdftools]] which
> provides similar (and additional) functionality, and is on MELPA.
> Thanks for sharing your code.
Thank you very much, I didn't know that.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* [patch] Add two new header args to LaTeX block
@ 2024-02-10 1:58 9% Juan Manuel Macías
2024-02-10 14:37 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 1:58 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
The attached patch adds two new header args to the LaTeX block:
- `:pdf-process' allows modifying the value of `org-latex-pdf-process'
locally to the block. This can be useful for evaluating a given block
with another LaTeX compiler, or even using some custom script.
Example:
#+begin_src latex :pdf-process '("lualatex -shell-escape -interaction nonstopmode -output-directory %o %f")
\textbf{hello world}
#+end_src
- `:full-to-pdf' makes the block like a standalone LaTeX document, which
should contain everything needed to be compiled, from \documentclass{}
to \end{document}. Example:
#+begin_src latex :full-to-pdf yes
\documentclass{article}
\begin{document}
\textbf{hello world}
\end{document}
#+end_src
I think both arguments can have many practical uses. For example, to
compile separately and load multiple subdocuments, with different
preambles:
#+NAME: doc1
#+begin_src org :exports none :results latex
,#+include: some-document.org
#+end_src
#+begin_src latex :noweb yes :results silent file :file file.pdf :full-to-pdf yes
\documentclass{article}
\usepackage[spanish]{babel}
\usepackage{fontspec}
\setmainfont{Vollkorn}
\begin{document}
<<doc1()>>
\end{document}
#+end_src
#+latex: \includepdf{file.pdf}
Or even to evaluate ConTeXt code within a LaTeX block:
#+begin_src latex :full-to-pdf yes :results raw file :file file.pdf :pdf-process '("cd %o && context %f")
\starttext
\startsection[title={Testing ConTeXt}]
Lorem ipsum dolor.
\stopsection
\stoptext
#+end_src
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-latex.el-Add-two-new-header-args-to-LaTeX-bl.patch --]
[-- Type: text/x-patch, Size: 2148 bytes --]
From fe1b40e2b22e2c668440bea13feda0ab7923bdd8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.
* (org-babel-execute:latex): `:pdf-process' allows modifying the value
of `org-latex-pdf-process' in a specific block. The `:full-to-pdf'
argument requires that the LaTeX block contains all the code necessary
to be compiled, as if it were an autonomous LaTeX document: the
expected result will always be a PDF file.
---
lisp/ob-latex.el | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..118d81338 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,9 @@ This function is called by `org-babel-execute-src-block'."
(height (and fit (cdr (assq :pdfheight params))))
(width (and fit (cdr (assq :pdfwidth params))))
(headers (cdr (assq :headers params)))
+ (pdf-process (cdr (assq :pdf-process params)))
+ (org-latex-pdf-process (if pdf-process pdf-process org-latex-pdf-process))
+ (full-to-pdf (cdr (assq :full-to-pdf params)))
(in-buffer (not (string= "no" (cdr (assq :buffer params)))))
(org-latex-packages-alist
(append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +190,14 @@ This function is called by `org-babel-execute-src-block'."
(list org-babel-latex-pdf-svg-process)
extension err-msg log-buf)))
(rename-file img-out out-file t))))
+ ((and (string= "pdf" extension) full-to-pdf)
+ (with-temp-file tex-file
+ (insert body))
+ (when (file-exists-p out-file) (delete-file out-file))
+ (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+ (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+ (err-msg "org babel latex failed"))
+ (rename-file tmp-pdf out-file t))))
((string-suffix-p ".tikz" out-file)
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
--
2.43.0
^ permalink raw reply related [relevance 9%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 1:58 9% [patch] Add two new header args to LaTeX block Juan Manuel Macías
@ 2024-02-10 14:37 6% ` Ihor Radchenko
2024-02-10 15:20 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-10 14:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The attached patch adds two new header args to the LaTeX block:
>
> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
> locally to the block. This can be useful for evaluating a given block
> with another LaTeX compiler, or even using some custom script.
> Example:
> ...
> - `:full-to-pdf' makes the block like a standalone LaTeX document, which
> should contain everything needed to be compiled, from \documentclass{}
> to \end{document}. Example:
Thanks!
May you please explain in more detail how these new header arguments fit
into other available LaTeX code block parameters? In particular, when
exporting to .png/.svg/.html or when :imagemagick header argument is provided.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 14:37 6% ` Ihor Radchenko
@ 2024-02-10 15:20 12% ` Juan Manuel Macías
2024-02-10 16:35 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 15:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> The attached patch adds two new header args to the LaTeX block:
>>
>> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
>> locally to the block. This can be useful for evaluating a given block
>> with another LaTeX compiler, or even using some custom script.
>> Example:
>> ...
>> - `:full-to-pdf' makes the block like a standalone LaTeX document, which
>> should contain everything needed to be compiled, from \documentclass{}
>> to \end{document}. Example:
>
> Thanks!
> May you please explain in more detail how these new header arguments fit
> into other available LaTeX code block parameters? In particular, when
> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
Sure! `:pdf-process' simply applies a local value to
org-latex-pdf-process. It does not affect the export to png in its
version without imagemagick process, since this option depends on
org-create-formula-image, which in turn depends on
org-preview-latex-default-process. It also does not affect the export to
html, which depends on org-babel-latex-htlatex. It should work in all
other cases, including imagemagick, which ultimately depend on
org-latex-pdf-process.
As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
better name), the expected result is a pdf file. Therefore it is
incompatible with exporting to png, svg or conversion with imagemagick.
For it to work, it is enough to provide these 2 args: ":file foo.pdf
:full-to-pdf yes."
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 15:20 12% ` Juan Manuel Macías
@ 2024-02-10 16:35 6% ` Ihor Radchenko
2024-02-10 17:48 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-10 16:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> May you please explain in more detail how these new header arguments fit
>> into other available LaTeX code block parameters? In particular, when
>> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
>
> Sure! `:pdf-process' simply applies a local value to
> org-latex-pdf-process. It does not affect the export to png in its
> version without imagemagick process, since this option depends on
> org-create-formula-image, which in turn depends on
> org-preview-latex-default-process. It also does not affect the export to
> html, which depends on org-babel-latex-htlatex. It should work in all
> other cases, including imagemagick, which ultimately depend on
> org-latex-pdf-process.
Would it make sense to make :pdf-process work for png previews as well?
> As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
> better name), the expected result is a pdf file. Therefore it is
> incompatible with exporting to png, svg or conversion with imagemagick.
> For it to work, it is enough to provide these 2 args: ":file foo.pdf
> :full-to-pdf yes."
Maybe just :standalone?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 16:35 6% ` Ihor Radchenko
@ 2024-02-10 17:48 12% ` Juan Manuel Macías
2024-02-10 19:35 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 17:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> May you please explain in more detail how these new header arguments fit
>>> into other available LaTeX code block parameters? In particular, when
>>> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
>>
>> Sure! `:pdf-process' simply applies a local value to
>> org-latex-pdf-process. It does not affect the export to png in its
>> version without imagemagick process, since this option depends on
>> org-create-formula-image, which in turn depends on
>> org-preview-latex-default-process. It also does not affect the export to
>> html, which depends on org-babel-latex-htlatex. It should work in all
>> other cases, including imagemagick, which ultimately depend on
>> org-latex-pdf-process.
>
> Would it make sense to make :pdf-process work for png previews as well?
It would be ideal. The expected value for org-latex-pdf-process is a
command or a list of commands, but org-preview-latex-default-process
expects a plist of various processes and parameters. Maybe with some
conditional? If only the png extension is provided (without the
:imagemagick argument), then the expected value is for
org-preview-latex-default-process. In all other cases, the value is for
org-latex-pdf-process. The argument could then be called simply
:process. E.g.:
Assuming the user has somewhere (add-to-list
org-preview-latex-process-alist my-process):
:results file :file foo.png :process 'my-process [or :process '(a plist)]
In other cases, like this:
:imagemagick yes :results file :file foo.png :process '("lualatex -interaction nonstopmode -output-directory %o %f")
wdyt?
>> As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
>> better name), the expected result is a pdf file. Therefore it is
>> incompatible with exporting to png, svg or conversion with imagemagick.
>> For it to work, it is enough to provide these 2 args: ":file foo.pdf
>> :full-to-pdf yes."
>
> Maybe just :standalone?
Yes, I totally agree.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 17:48 12% ` Juan Manuel Macías
@ 2024-02-10 19:35 10% ` Juan Manuel Macías
2024-02-10 21:07 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 19:35 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
Juan Manuel Macías writes:
>> Ihor Radchenko writes:
>> Would it make sense to make :pdf-process work for png previews as well?
>
> It would be ideal. The expected value for org-latex-pdf-process is a
> command or a list of commands, but org-preview-latex-default-process
> expects a plist of various processes and parameters. Maybe with some
> conditional? If only the png extension is provided (without the
> :imagemagick argument), then the expected value is for
> org-preview-latex-default-process. In all other cases, the value is for
> org-latex-pdf-process. The argument could then be called simply
> :process. E.g.:
>
> Assuming the user has somewhere (add-to-list
> org-preview-latex-process-alist my-process):
>
> :results file :file foo.png :process 'my-process [or :process '(a plist)]
>
> In other cases, like this:
>
> :imagemagick yes :results file :file foo.png :process '("lualatex -interaction nonstopmode -output-directory %o %f")
>
> wdyt?
I am attaching a new patch with this idea incorporated. I have also
changed the name from full-to-pdf to standalone.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-latex.el-Add-two-new-header-args-to-LaTeX-bl.patch --]
[-- Type: text/x-patch, Size: 2634 bytes --]
From a7f72015007722e665338c39b9a02d675c31cd93 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.
* (org-babel-execute:latex): `:process' allows modifying the value of
`org-latex-pdf-process' or `org-preview-latex-default-process' in a
specific block. If only the `png' extension is provided (without the
`:imagemagick' argument), then the expected value is for
`org-preview-latex-default-process'. In all other cases, the value is
for `org-latex-pdf-process'. This argument has no effect if the
conversion is to `HTML'. The `:standalone' argument requires that
the LaTeX block contains all the code necessary to be compiled, as if
it were an autonomous LaTeX document: the expected result will always
be a PDF file.
---
lisp/ob-latex.el | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..8bec0c661 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,14 @@ This function is called by `org-babel-execute-src-block'."
(height (and fit (cdr (assq :pdfheight params))))
(width (and fit (cdr (assq :pdfwidth params))))
(headers (cdr (assq :headers params)))
+ (process (cdr (assq :process params)))
+ (org-preview-latex-default-process (if (and process
+ (string-suffix-p ".png" out-file)
+ (not imagemagick))
+ process
+ org-preview-latex-default-process))
+ (org-latex-pdf-process (if process process org-latex-pdf-process))
+ (standalone (cdr (assq :standalone params)))
(in-buffer (not (string= "no" (cdr (assq :buffer params)))))
(org-latex-packages-alist
(append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +195,14 @@ This function is called by `org-babel-execute-src-block'."
(list org-babel-latex-pdf-svg-process)
extension err-msg log-buf)))
(rename-file img-out out-file t))))
+ ((and (string= "pdf" extension) standalone)
+ (with-temp-file tex-file
+ (insert body))
+ (when (file-exists-p out-file) (delete-file out-file))
+ (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+ (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+ (err-msg "org babel latex failed"))
+ (rename-file tmp-pdf out-file t))))
((string-suffix-p ".tikz" out-file)
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
--
2.43.0
^ permalink raw reply related [relevance 10%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 19:35 10% ` Juan Manuel Macías
@ 2024-02-10 21:07 6% ` Ihor Radchenko
2024-02-10 23:34 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-10 21:07 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am attaching a new patch with this idea incorporated. I have also
> changed the name from full-to-pdf to standalone.
>
> + (process (cdr (assq :process params)))
> + (org-preview-latex-default-process (if (and process
> + (string-suffix-p ".png" out-file)
> + (not imagemagick))
Considering that 'imagemagick is one of the variants in
`org-preview-latex-process-alist', it might be reasonable to allow
:process imagemagick == :imagemagick yes
Also, it feels incomplete to be able to define latex command for :file
foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 21:07 6% ` Ihor Radchenko
@ 2024-02-10 23:34 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-10 23:34 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I am attaching a new patch with this idea incorporated. I have also
>> changed the name from full-to-pdf to standalone.
>>
>> + (process (cdr (assq :process params)))
>> + (org-preview-latex-default-process (if (and process
>> + (string-suffix-p ".png" out-file)
>> + (not imagemagick))
>
> Considering that 'imagemagick is one of the variants in
> `org-preview-latex-process-alist', it might be reasonable to allow
> :process imagemagick == :imagemagick yes
I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
Instead, «:process 'imagemagick» depends on:
(imagemagick :programs
("latex" "convert")
:description "pdf > png"
:message "you need to install the programs: latex and imagemagick."
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("pdflatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O"))
Also, one may want to put «:imagemagick yes» and compile the PDF
with another compiler or with a custom script:
:imagemagick yes :process '(...)
> Also, it feels incomplete to be able to define latex command for :file
> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
The ".png" method without ":imagemagick" does not depend on
'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
depends on the value of 'org-preview-latex-default-process':
...
((and (string-suffix-p ".png" out-file) (not imagemagick))
(let ((org-format-latex-header
(concat org-format-latex-header "\n"
(mapconcat #'identity headers "\n"))))
(org-create-formula-image
body out-file org-format-latex-options in-buffer)))
...
If you put :file foo.png without :imagemagick, and want to control the
process or change the compiler, you can do it with:
:process '(foo :latex-compiler ("some LaTeX command"))
since this syntax is what org-preview-latex-default-process expects.
In all other cases, including :imagemagick, the compilation process
depends on the value of org-latex-pdf-process.
Anyway, I don't understand why that feature option (convert to an image
without :imagemagick method) is limited to .png, when other graphic files are
possible. I can define something like this:
(setq org-preview-latex-default-process
'(my-process
:programs ("lualatex" "convert")
:description "pdf > jpg"
:image-input-type "pdf"
:image-output-type "jpg"
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
But if I put :file foo.jpg nothing happens. Maybe that part should be
corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
Results 1201-1400 of ~1600 next (newer) | prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-01-29 16:03 org-attach-git don't automatically commit changes Juan Manuel Macías
2021-01-30 5:10 ` Ihor Radchenko
2021-01-30 13:38 ` Juan Manuel Macías
2021-01-31 3:33 ` Ihor Radchenko
2021-01-31 10:29 ` Juan Manuel Macías
2021-01-31 10:52 ` Ihor Radchenko
2021-01-31 13:16 ` Juan Manuel Macías
2021-01-31 13:40 ` Ihor Radchenko
2021-01-31 14:36 ` Juan Manuel Macías
2024-01-10 16:05 6% ` Ihor Radchenko
2022-02-18 0:47 Pandoc and nested emhases Juan Manuel Macías
2023-10-11 16:11 6% ` Max Nikulin
2023-10-22 19:15 10% ` Juan Manuel Macías
2023-02-18 10:18 [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated Ihor Radchenko
2023-03-05 11:12 ` Max Nikulin
2024-01-20 16:04 0% ` Ihor Radchenko
2024-01-24 13:21 0% ` Ihor Radchenko
2023-03-21 3:36 org-ctags land grab Nick Dokos
2023-08-08 8:48 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Ihor Radchenko
2023-08-08 13:29 ` Bastien Guerry
2023-08-11 9:44 ` Ihor Radchenko
2023-08-12 12:46 ` Bastien Guerry
2023-08-12 22:18 ` Samuel Wales
2023-08-14 13:19 ` Fraga, Eric
2023-08-22 15:15 ` Bastien Guerry
2023-08-23 9:33 ` Ihor Radchenko
2023-08-24 11:39 ` Bastien Guerry
2023-08-24 11:44 ` Ihor Radchenko
2023-08-24 12:08 ` Bastien Guerry
2023-08-24 12:15 ` Ihor Radchenko
2023-08-24 12:36 ` Bastien Guerry
2023-08-24 12:40 ` Ihor Radchenko
2023-08-24 12:48 ` Bastien Guerry
2023-08-24 12:56 ` Ihor Radchenko
2023-08-24 13:02 ` Bastien Guerry
2023-08-24 13:36 ` Ihor Radchenko
2023-08-24 14:08 ` Bastien Guerry
2023-08-25 9:44 ` [DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?) Ihor Radchenko
2023-08-25 17:58 9% ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
2023-08-26 10:58 6% ` Ihor Radchenko
2023-08-26 11:42 10% ` Juan Manuel Macías
2023-08-26 12:33 5% ` Ihor Radchenko
2023-08-26 14:21 9% ` Juan Manuel Macías
2023-08-26 16:33 6% ` Ihor Radchenko
2023-08-26 17:31 11% ` Juan Manuel Macías
2023-08-26 17:43 5% ` Ihor Radchenko
2023-08-26 19:19 10% ` Juan Manuel Macías
2023-08-27 9:21 5% ` Ihor Radchenko
2023-08-27 17:25 10% ` Juan Manuel Macías
2023-08-31 9:15 5% ` Ihor Radchenko
2023-08-26 18:01 6% ` Russell Adams
2023-08-06 12:03 [patch] ox-latex.el: fix blank lines behavior in verse block Juan Manuel Macías
2023-08-07 11:40 ` Ihor Radchenko
2023-08-07 17:23 ` Juan Manuel Macías
2023-08-09 7:57 ` Ihor Radchenko
2023-08-09 8:41 ` Juan Manuel Macías
2023-08-10 9:27 ` Ihor Radchenko
2023-08-10 10:39 ` Juan Manuel Macías
2023-08-11 10:00 ` Ihor Radchenko
2023-08-11 18:52 ` Juan Manuel Macías
2023-08-12 7:56 ` Ihor Radchenko
2023-08-14 20:10 ` Juan Manuel Macías
2023-08-15 10:08 ` Ihor Radchenko
2023-08-15 11:50 ` Juan Manuel Macías
2023-08-15 11:53 ` Ihor Radchenko
2023-08-15 14:25 ` Juan Manuel Macías
2023-08-16 8:10 6% ` Ihor Radchenko
2023-08-16 14:10 7% ` Juan Manuel Macías
2023-08-17 10:35 6% ` Ihor Radchenko
2023-08-17 20:17 7% ` Juan Manuel Macías
2023-08-18 8:44 6% ` Ihor Radchenko
2023-08-18 18:27 10% [Tip] Popup-menu with several actions for a link Juan Manuel Macías
2023-08-19 19:53 6% ` Ihor Radchenko
2023-08-19 20:29 11% ` Juan Manuel Macías
2023-08-20 7:23 6% ` Ihor Radchenko
2023-08-20 10:13 10% ` Juan Manuel Macías
2023-08-30 8:25 10% Fallback fonts in LaTeX export for non latin scripts Juan Manuel Macías
2023-08-31 8:17 5% ` Ihor Radchenko
2023-08-31 11:42 7% ` Juan Manuel Macías
2023-09-01 9:18 5% ` Ihor Radchenko
2023-09-02 21:39 4% ` Juan Manuel Macías
2023-09-03 7:22 5% ` Ihor Radchenko
2023-09-03 11:05 6% ` Juan Manuel Macías
2023-09-04 8:09 4% ` Ihor Radchenko
2023-09-04 22:22 7% ` Juan Manuel Macías
2023-09-05 10:44 5% ` Ihor Radchenko
2023-09-20 14:03 5% ` Juan Manuel Macías
2023-09-21 9:00 4% ` Ihor Radchenko
2023-09-24 18:24 12% ` Juan Manuel Macías
2023-09-26 10:37 5% ` Ihor Radchenko
2023-09-05 16:42 6% ` Max Nikulin
2023-09-05 18:33 12% ` Juan Manuel Macías
2023-09-06 9:29 6% ` Ihor Radchenko
2023-09-06 14:58 8% ` Juan Manuel Macías
2023-09-07 10:22 5% ` Ihor Radchenko
2023-09-07 12:04 9% ` Juan Manuel Macías
2023-09-08 7:42 6% ` Ihor Radchenko
2023-09-06 14:55 5% ox-latex language handling in Org-9.5 vs 9.6 Max Nikulin
2023-09-06 22:20 8% ` Juan Manuel Macías
2023-09-07 10:38 5% ` Max Nikulin
2023-09-07 11:50 6% ` Ihor Radchenko
2023-09-07 14:19 12% ` Juan Manuel Macías
2023-09-07 14:49 6% ` Max Nikulin
2023-09-08 10:30 0% ` Max Nikulin
2023-09-08 14:42 10% ` Juan Manuel Macías
2023-09-08 19:02 3% ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Juan Manuel Macías
2023-09-09 9:11 6% ` Ihor Radchenko
2023-09-09 10:36 12% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
2023-09-09 11:33 6% ` Ihor Radchenko
2023-09-09 23:59 11% ` Juan Manuel Macías
2023-09-10 7:55 5% ` Ihor Radchenko
2023-09-10 11:06 3% ` Juan Manuel Macías
2023-09-10 13:36 6% ` Ihor Radchenko
2023-09-10 16:15 ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Max Nikulin
2023-09-10 16:52 ` Ihor Radchenko
2023-09-10 21:15 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
2023-09-11 8:32 5% ` Ihor Radchenko
2023-09-11 17:06 ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Max Nikulin
2023-09-12 9:05 ` Ihor Radchenko
2023-09-12 15:22 ` Max Nikulin
2023-09-12 18:12 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
2023-09-15 9:54 6% ` Ihor Radchenko
2023-09-16 18:00 10% [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
2023-09-17 10:02 6% ` Ihor Radchenko
2023-09-17 17:23 6% ` Timothy
2023-09-22 16:38 5% ` Max Nikulin
2023-09-24 18:42 12% ` Juan Manuel Macías
2023-09-25 13:58 5% ` Max Nikulin
2023-09-25 18:49 9% ` Juan Manuel Macías
2023-09-25 21:57 7% ` Thomas S. Dye
2023-09-26 15:39 0% ` Max Nikulin
2023-09-26 19:12 9% ` Juan Manuel Macías
2023-09-28 10:07 4% ` Max Nikulin
2023-09-28 12:31 9% ` Juan Manuel Macías
2023-09-29 2:38 5% ` Max Nikulin
2023-10-01 16:32 5% ` Max Nikulin
2023-09-28 15:36 ` AW
2023-10-01 16:02 ` Max Nikulin
2023-10-01 17:48 11% ` Juan Manuel Macías
2023-10-02 10:42 5% ` Max Nikulin
2023-09-21 7:46 Sanskrit/Devanagari fonts not exported to org-pdf output Zenny
2023-09-21 8:24 13% ` Juan Manuel Macías
2023-09-21 13:46 5% ` Zenny
2023-09-21 15:33 5% ` Juan Manuel Macías
2023-09-21 17:53 5% ` Zenny
2023-09-21 18:28 13% ` Juan Manuel Macías
2023-09-21 18:44 4% ` Zenny
2023-09-21 19:32 6% ` Juan Manuel Macías
2023-09-21 20:26 4% ` Zenny
2023-09-21 20:39 0% ` Zenny
2023-09-21 20:41 0% ` Zenny
2023-09-21 21:19 12% ` Juan Manuel Macías
2023-09-22 7:04 4% ` Zenny
2023-09-22 8:00 10% ` Juan Manuel Macías
2023-09-22 8:07 4% ` Zenny
2023-09-22 8:09 0% ` Zenny
2023-09-22 8:41 6% ` Juan Manuel Macías
2023-09-22 8:49 4% ` Zenny
2023-09-22 8:54 0% ` Zenny
2023-09-22 8:54 6% ` Juan Manuel Macías
2023-09-22 8:58 4% ` Zenny
2023-09-22 9:06 6% ` Juan Manuel Macías
2023-09-22 9:37 4% ` Zenny
2023-09-22 10:02 6% ` Juan Manuel Macías
2023-09-22 12:59 6% ` Zenny
2023-09-22 15:12 6% ` Juan Manuel Macías
2023-09-22 17:51 5% ` Zenny
2023-09-22 8:18 6% ` Juan Manuel Macías
2023-09-22 8:30 4% ` Zenny
2023-10-01 15:08 7% Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? Juan Manuel Macías
2023-10-01 18:07 12% ` Juan Manuel Macías
2023-10-02 13:10 5% ` Ihor Radchenko
2023-10-02 14:55 9% ` Juan Manuel Macías
2023-10-04 9:12 5% ` Ihor Radchenko
2023-10-04 14:34 11% ` Juan Manuel Macías
2023-10-06 16:29 5% ` Ihor Radchenko
2023-10-06 18:35 5% ` Juan Manuel Macías
2023-10-06 19:49 5% ` Ihor Radchenko
2023-10-06 8:07 11% [proof of concept, tip] 'Templates with arguments' using org src blocks Juan Manuel Macías
2023-10-13 16:00 5% ` Max Nikulin
2023-10-22 21:12 9% Are 'placement' and 'float' "obsolete terms" in inline images export Juan Manuel Macías
2023-10-23 9:27 5% ` Ihor Radchenko
2023-10-23 19:00 10% ` Juan Manuel Macías
2023-10-26 9:14 5% ` Ihor Radchenko
2024-01-02 21:43 11% ` Juan Manuel Macías
2023-11-02 9:29 Regression in latex export of tables? Fraga, Eric
2023-11-03 0:58 ` Vikas Rawal
2023-11-03 2:30 5% ` Max Nikulin
2023-11-11 15:54 Links & images with different attributes in the same paragraph Max Nikulin
2023-12-05 13:46 ` Ihor Radchenko
2023-12-12 11:08 ` Max Nikulin
2023-12-12 13:18 ` Ihor Radchenko
2023-12-13 11:50 ` Max Nikulin
2023-12-14 15:23 ` Ihor Radchenko
2023-12-16 8:06 5% ` Max Nikulin
2023-12-16 14:44 0% ` Ihor Radchenko
2023-12-19 14:39 0% ` Max Nikulin
2024-01-02 23:46 11% [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
2024-01-13 15:08 6% ` Ihor Radchenko
2024-01-13 16:05 10% ` Juan Manuel Macías
2024-01-13 18:28 5% ` Ihor Radchenko
2024-01-13 20:22 8% ` Juan Manuel Macías
2024-01-14 12:33 6% ` Ihor Radchenko
2024-01-14 21:58 7% ` Juan Manuel Macías
2024-01-16 14:09 4% ` Ihor Radchenko
2024-01-16 19:33 8% ` Juan Manuel Macías
2024-01-17 13:00 4% ` Ihor Radchenko
2024-01-17 17:50 7% ` Juan Manuel Macías
2024-01-18 13:05 4% ` Ihor Radchenko
2024-01-19 17:28 10% ` Juan Manuel Macías
2024-01-20 12:34 5% ` Ihor Radchenko
2024-01-20 13:22 9% ` Juan Manuel Macías
2024-01-20 13:46 5% ` Ihor Radchenko
2024-01-20 15:41 9% ` Juan Manuel Macías
2024-01-20 18:47 5% ` Ihor Radchenko
2024-01-20 20:27 9% ` Juan Manuel Macías
2024-01-21 13:42 1% ` Ihor Radchenko
2024-01-21 19:25 10% ` Juan Manuel Macías
2024-01-21 6:06 3% ` Max Nikulin
2024-01-20 10:09 ` Max Nikulin
2024-01-20 10:57 10% ` Juan Manuel Macías
2024-01-20 10:27 3% ` Max Nikulin
2024-01-12 10:24 Tableofcontents Horst Leps
2024-01-12 16:53 ` Tableofcontents Tory S. Anderson
2024-01-13 12:27 ` Tableofcontents Ihor Radchenko
2024-01-16 19:12 ` #+LATEX_HEADER: \usepackage[greek,german]{babel} ?? Horst Leps
2024-01-16 19:46 10% ` Juan Manuel Macías
2024-01-21 8:44 New try at multi-lingual export to latex/pdf using pdflatex and babel Pedro Andres Aranda Gutierrez
2024-01-21 13:02 ` Ihor Radchenko
2024-01-21 17:11 ` Pedro Andres Aranda Gutierrez
2024-01-21 17:47 9% ` Juan Manuel Macías
2024-01-22 6:30 6% ` Pedro Andres Aranda Gutierrez
2024-01-22 6:47 0% ` Pedro Andres Aranda Gutierrez
2024-01-22 13:11 8% ` Juan Manuel Macías
2024-01-22 12:10 6% ` Ihor Radchenko
2024-01-22 13:40 8% ` Juan Manuel Macías
2024-01-23 7:41 3% ` Pedro Andres Aranda Gutierrez
2024-01-22 20:42 Possible LaTeX export bug: Footnotes in items Eric Anderson
2024-01-24 12:11 ` [BUG] Footnotes in section titles Ihor Radchenko
2024-01-24 14:14 ` Max Nikulin
2024-01-24 15:23 12% ` Juan Manuel Macías
2024-01-24 15:31 0% ` Colin Baxter
2024-01-24 15:41 9% ` Juan Manuel Macías
2024-01-26 12:53 5% ` Ihor Radchenko
2024-01-26 13:17 11% ` Juan Manuel Macías
2024-01-26 16:43 ` Max Nikulin
2024-02-01 14:44 ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) (was: [BUG] Footnotes in section titles) Ihor Radchenko
2024-02-01 17:44 10% ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) Juan Manuel Macías
2024-02-01 17:57 5% ` Marvin Gülker
2024-02-02 17:00 5% ` Ihor Radchenko
2024-02-02 18:10 13% ` Juan Manuel Macías
2024-02-02 20:21 5% ` Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)) Ihor Radchenko
2024-02-02 22:26 11% ` Exporting multiple #+AUTHOR keywords Juan Manuel Macías
2024-02-04 15:21 6% ` Ihor Radchenko
2024-02-04 16:16 ` Max Nikulin
2024-02-04 22:13 9% ` Juan Manuel Macías
2024-01-29 20:03 10% An academic journal entirely made in Org-Mode Juan Manuel Macías
2024-01-29 20:16 6% ` Daniel Ortmann
2024-01-29 23:16 6% ` Dr. Arne Babenhauserheide
2024-01-31 14:30 6% ` Juan Manuel Macías
2024-01-30 5:34 6% ` tomas
2024-01-29 20:05 10% An academic journal made entirely " Juan Manuel Macías
2024-01-30 0:00 6% ` William Denton
2024-02-01 7:07 RFI: LaTeX - AUTO for \usepackage{inputenc} Pedro Andres Aranda Gutierrez
2024-02-02 16:00 ` [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages Ihor Radchenko
2024-02-02 16:18 12% ` Juan Manuel Macías
2024-02-02 16:41 0% ` Pedro Andres Aranda Gutierrez
2024-02-04 19:41 [DISCUSSION] Add "Recent News" to orgmode.org Ihor Radchenko
2024-02-04 20:24 10% ` Juan Manuel Macías
2024-02-08 22:13 11% Link type for pdf-tools annotations Juan Manuel Macías
2024-02-08 23:25 6% ` Ihor Radchenko
2024-02-09 0:40 11% ` Juan Manuel Macías
2024-02-09 12:13 ` Irfan S
2024-02-09 12:48 13% ` Juan Manuel Macías
2024-02-10 1:58 9% [patch] Add two new header args to LaTeX block Juan Manuel Macías
2024-02-10 14:37 6% ` Ihor Radchenko
2024-02-10 15:20 12% ` Juan Manuel Macías
2024-02-10 16:35 6% ` Ihor Radchenko
2024-02-10 17:48 12% ` Juan Manuel Macías
2024-02-10 19:35 10% ` Juan Manuel Macías
2024-02-10 21:07 6% ` Ihor Radchenko
2024-02-10 23:34 10% ` Juan Manuel Macías
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).