Re: [PATCH v2] Fix background color of latex previews

[Roshan Shariff]

Hi Timothy,

On Mon, 8 Jan 2024 at 03:24, Timothy  wrote:
> Thanks for this info and the patch! I've had a look at both, and I'm hopeful 
> that https://git.tecosaur.net/tec/org-mode/commit/3b3d48d3bf0 might solve the 
> problem? Do let me know what your think 

Thanks for your prompt bugfix! I can confirm that it works beautifully
on both Emacs 28 and 29.

Looking at the code, I just had a small suggestion:

diff --git a/lisp/org-latex-preview.el b/lisp/org-latex-preview.el
index 19e34..973eed47b 100644
--- a/lisp/org-latex-preview.el
+++ b/lisp/org-latex-preview.el
@@ -541,7 +541,7 @@ Faces in `org-latex-preview--ignored-faces' are ignored."
 (normalising-face
  (if (>= emacs-major-version 29) 'default '(:inherit default
:extend t
 (cond
- ((consp face)
+ ((and (consp face) (not (keywordp (car face))) (listp (cdr face)))
   (nconc (cl-set-difference face
org-latex-preview--ignored-faces) (list normalising-face)))
  ((and face (not (memq face org-latex-preview--ignored-faces)))
   (list face normalising-face))

The (not (keywordp (car face))) condition ensures that the face isn't
a single anonymous face, i.e. a plist. The (listp (cdr face))
condition ensures that it's not just a cons like (foreground-color .
color). In both cases, the face spec is not a list of faces, so it
wouldn't be correct to append another face to the end. I'm not sure
how commonly this can happen in practice, but it covers all the cases
handled by merge_face_ref in xfaces.c.

Regards,
Roshan

> All the best,
> Timothy
>
> --
> Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at .

[PATCH v2] Fix background color of latex previews

[Roshan Shariff]

This change addresses two issues:

1. Latex previews in headings have the background color of the
fontified Latex code, rather than the rest of the heading.

2. If Latex code is fontified with a face that has the :extend
attribute, and the preview overlay wraps to the next line, then the
empty space after the end of the line uses the background color of the
Latex code rather than that of the surrounding text.

For example, setting org-highlight-latex-and-related to '(native)
applies the org-block face to Latex code.  Since the default heading
faces do not set :background, the org-block background is used for
preview overlays in headings.  And since org-block has :extend t, its
background color is also used for the empty space after the end of the
line preceding a wrapped latex preview.

With this change, we create a new anonymous face that inherits from
the default face and sets the :extend attribute, and use it as a
fallback for any attributes unspecified in the faces around the Latex
code.

1. Since the fallback face inherits from default, it is guaranteed to
be completely specified.  The preview overlay thus appears exactly
like the text around it; any unspecified attributes are taken from the
default face rather than the fontified Latex code.

2. When Emacs displays the empty space at the end of a line, it only
considers faces with a non-nil :extend attribute.  Since the fallback
face sets :extend, so will the merged preview overlay face.  Thus the
background color of the empty space will be taken from the surrounding
text face if it sets :extend, or the default face otherwise.
---

Please ignore the previous patch and look at this one instead :)

* I've fixed a bug in the org-latex-preview--face-with-fallback
function.

* I also noticed that the patch fixes a broader issue with background
colors for previews in headings.  I've updated the commit message to
describe both issues.

 lisp/org-latex-preview.el | 51 +--
 lisp/org.el   |  5 ++--
 2 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/lisp/org-latex-preview.el b/lisp/org-latex-preview.el
index 03c198e32..96ffe894e 100644
--- a/lisp/org-latex-preview.el
+++ b/lisp/org-latex-preview.el
@@ -505,8 +505,7 @@ overlay face is set to `org-latex-preview-processing-face'."
 (overlay-put
  ov 'hidden-face
  (or (and errors 'error)
- (org-latex-preview--face-around
-  (overlay-start ov) (overlay-end ov)
+ (org-latex-preview--overlay-face ov
(errors
 (overlay-put
  ov 'before-string
@@ -526,8 +525,7 @@ overlay face is set to `org-latex-preview-processing-face'."
 (defun org-latex-preview--face-around (start end)
   "Return the relevant face symbol around the region START to END.
 A relevant face symbol before START is prefered, with END
-examined if none could be found, and finally the default face
-used as the final fallback.
+examined if none could be found.
 Faces in `org-latex-preview--ignored-faces' are ignored."
   (or (and (> start (point-min))
(not (eq (char-before start) ?\n))
@@ -544,8 +542,47 @@ Faces in `org-latex-preview--ignored-faces' are ignored."
   ((consp face)
(cl-set-difference face org-latex-preview--ignored-faces))
   ((not (memq face org-latex-preview--ignored-faces))
-   face
-  'default))
+   face))
+
+(defun org-latex-preview--face-with-fallback (face fallback)
+  "Return a face spec combining FACE with FALLBACK.
+FACE should be valid as a value of the `face' text or overlay
+property, as specified in Info node `(elisp)Special properties'.
+The return value will also be valid as a `face' text or overlay
+property.  FALLBACK should be a either a face name (symbol or
+string) or an anonymous face (plist); see the Info
+node `(elisp)Faces'."
+  (pcase face
+('nil
+ fallback)
+(`(:filtered ,filter ,face)
+ `(:filtered ,filter ,(org-latex-preview--face-with-fallback face 
fallback)))
+(`(foreground-color . ,color)
+ `((:foreground ,color) ,fallback))
+(`(background-color . ,color)
+ `((:background ,color) ,fallback))
+(`(,(pred (not keywordp)) . ,_)
+ (append face (list fallback)))
+(_
+ (list face fallback
+
+(defun org-latex-preview--overlay-face (ov)
+  "Return `face' property to be used for preview overlay OV.
+Return the face found by `org-latex-preview--face-around', with
+unset properties falling back to an anonymous face that inherits
+from `default' and sets the `:extend' attribute.
+
+The fallback ensures that if the overlay wraps to the next line
+and the text around the overlay has a face without `:extend', the
+empty space after the end of the line uses the default background
+color.  Otherwise, the space would take on the background color
+of the latex code itself if it has a face with `:extend'.  For
+example, when 

[PATCH 1/1] Fix background color when line-wrapping latex previews

[Roshan Shariff]

If latex code is fontified with a face that has the :extend attribute,
and the preview overlay wraps to the next line, then the empty space
after the end of the line uses the background color of the latex code
rather than that of the surrounding text.  For example, setting
org-highlight-latex-and-related to '(native) applies the org-block
face to latex code.  Since org-block has :extend t, its background
color is used for the empty space after the end of the line preceding
a wrapped latex preview.

This is because when Emacs displays the empty space, it only considers
faces with a non-nil :extend attribute.  If the text surrounding the
latex code has a face without :extend, then its background color is
ignored for the end-of-line empty space; the latex code face is used
instead.

We want the empty space to use the background color of the surrounding
text if it sets :extend, or the default background color otherwise.
To accomplish this, we create a new anonymous face that inherits from
the default face and has the :extend attribute, and set it as a
fallback to the face property gleaned from the surrounding text.  This
fallback will be used only if the text surrounding the latex code
doesn't set the :extend attribute.  It has no effect on anything other
than the empty space.
---
 lisp/org-latex-preview.el | 51 +--
 lisp/org.el   |  5 ++--
 2 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/lisp/org-latex-preview.el b/lisp/org-latex-preview.el
index 03c198e32..39681aace 100644
--- a/lisp/org-latex-preview.el
+++ b/lisp/org-latex-preview.el
@@ -505,8 +505,7 @@ overlay face is set to `org-latex-preview-processing-face'."
 (overlay-put
  ov 'hidden-face
  (or (and errors 'error)
- (org-latex-preview--face-around
-  (overlay-start ov) (overlay-end ov)
+ (org-latex-preview--overlay-face ov
(errors
 (overlay-put
  ov 'before-string
@@ -526,8 +525,7 @@ overlay face is set to `org-latex-preview-processing-face'."
 (defun org-latex-preview--face-around (start end)
   "Return the relevant face symbol around the region START to END.
 A relevant face symbol before START is prefered, with END
-examined if none could be found, and finally the default face
-used as the final fallback.
+examined if none could be found.
 Faces in `org-latex-preview--ignored-faces' are ignored."
   (or (and (> start (point-min))
(not (eq (char-before start) ?\n))
@@ -544,8 +542,47 @@ Faces in `org-latex-preview--ignored-faces' are ignored."
   ((consp face)
(cl-set-difference face org-latex-preview--ignored-faces))
   ((not (memq face org-latex-preview--ignored-faces))
-   face
-  'default))
+   face))
+
+(defun org-latex-preview--face-with-fallback (face fallback)
+  "Return a face spec combining FACE with FALLBACK.
+FACE should be valid as a value of the `face' text or overlay
+property, as specified in Info node `(elisp)Special properties'.
+The return value will also be valid as a `face' text or overlay
+property.  FALLBACK should be a either a face name (symbol or
+string) or an anonymous face (plist); see the Info
+node `(elisp)Faces'."
+  (pcase face
+('nil
+ fallback)
+(`(:filtered ,filter ,face)
+ `(:filtered ,filter ,(org-latex-preview--face-with-fallback face 
fallback)))
+(`(foreground-color . ,color)
+ `((:foreground ,color) ,fallback))
+(`(background-color . ,color)
+ `((:background ,color) ,fallback))
+((pred consp)
+ (append face (list fallback)))
+(_
+ (list face fallback
+
+(defun org-latex-preview--overlay-face (ov)
+  "Return `face' property to be used for preview overlay OV.
+Return the face found by `org-latex-preview--face-around', with
+unset properties falling back to an anonymous face that inherits
+from `default' and sets the `:extend' attribute.
+
+The fallback ensures that if the overlay wraps to the next line
+and the text around the overlay has a face without `:extend', the
+empty space after the end of the line uses the default background
+color.  Otherwise, the space would take on the background color
+of the latex code itself if it has a face with `:extend'.  For
+example, when `org-highlight-latex-and-related' includes
+`native', latex code is fontified with the `org-block' face."
+  (org-latex-preview--face-with-fallback
+   (org-latex-preview--face-around
+(overlay-start ov) (overlay-end ov))
+   '(:inherit default :extend t)))
 
 ;; Code for `org-latex-preview-auto-mode':
 ;;
@@ -1479,7 +1516,7 @@ is either the substring between BEG and END or (when 
provided) VALUE."
 
 (defun org-latex-preview--colors-around (start end)
   "Find colors for LaTeX previews occuping the region START to END."
-  (let* ((face (org-latex-preview--face-around start end))
+  (let* ((face (or (org-latex-preview--face-around start end) 

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Roshan Shariff]

Hi Timothy and Karthik,

Thanks for your wonderful work on this feature!  I've been using it
for several weeks and it's been working extremely well in my
experience.

I noticed a small visual glitch when inline latex previews wrap to the
next line, that is apparent when org-highlight-latex-and-related is
set to '(native).  The post-line-ending space on the previous line
takes on the background color of the org-block face.

I've described the reason for the problem and written a potential
solution in a patch following this message.  It appears to fix the
problem completely, but I'm not sure if it's the best way to go about
it.  I'd appreciate if you could take a look, and thanks for your
time!

Regards,
Roshan

Roshan Shariff (1):
  Fix background color when line-wrapping latex previews

 lisp/org-latex-preview.el | 51 +--
 lisp/org.el   |  5 ++--
 2 files changed, 46 insertions(+), 10 deletions(-)

-- 
2.41.0

Re: [PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file

[Roshan Shariff]

Thanks again Ihor!

For the future, I wanted to clarify that I do have a copyright
assignment to the FSF "for the suite of programs known as GNU EMACS".
I have a signed copy of the assignment form dated 3 April, 2022. I
should be in the list as "Roshan Shariff", but if not I can follow up
with the FSF to see if they missed adding me.

On Sun, 6 Aug 2023 at 00:49, Ihor Radchenko  wrote:
>
> Roshan Shariff  writes:
>
> > Thanks for the feedback! I'm attaching a new version of the patch that
> > improves the commit message and avoids the use of file-name-concat.
>
> Thanks!
> Applied, onto main, with minor amendments.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4ea9a98f8
>
> I added a TINYCHANGE cookie as you do not appear to have FSF copyright
> assignment. I also duplicated your comment about "pwd" usage to
> `org-compile-file' to avoid accidental edits in future.
>
> Please note that your total contribution have now exceeded the allowed
> limit we can accept without copyright paper work.
> You may consider FSF copyright assignment in future. See
> https://orgmode.org/worg/org-contribute.html#copyright
>
> --
> 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>

Re: [PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file

[Roshan Shariff]

Hi Ihor,

On Sat, 5 Aug 2023 at 04:23, Ihor Radchenko  wrote:
> First, minor one: please put two spaces between sentences in the commit
> message. It is our convention.
> `file-name-concat' is only available since Emacs 28.
> Please use `org-file-name-concat'.

Thanks for the feedback! I'm attaching a new version of the patch that
improves the commit message and avoids the use of file-name-concat.

> The PROCESS argument can, for example, be `org-latex-pdf-process', which
> promises that "%f in the command will be replaced by the relative file
> name" (see the docstring).

The patch now converts the source to a relative path if it is
absolute. Note that, according to the documentation of
file-relative-name, the path will still be absolute on Microsoft
Windows if the source and the current directory have different drive
letters; this is probably unavoidable. I have also updated the
docstring to clarify which paths are supposed to be relative and which
are absolute.

By the way, I forgot to mention that I ran into this bug while testing
tecosaur's latex-preview patch set on macOS. When running
org-latex-export-to-pdf on an Org file in ~/Dropbox, I got a warning
message about the preamble precompilation failing because it couldn't
find a temporary .tex file in /var. With this patch applied, the PDF
export completes without warnings.

Regards,
Roshan
From 6e1f120818582695da9018f256b00c87104a Mon Sep 17 00:00:00 2001
From: Roshan Shariff 
Date: Fri, 4 Aug 2023 22:10:25 -0600
Subject: [PATCH v2] org-macs: Fix incorrect use of relative paths in
 org-compile-file

* org-macs.el (org-compile-file, org-compile-file-commands): Resolve
symlinks in default-directory before computing relative source path

Commit 5a8a1d4ff [1] changed org-compile-file to use
`file-relative-name` for the SOURCE argument.  This was intended to
fix bug [2] by expanding ~ directories, like a shell.  Unfortunately,
this breaks when DEFAULT-DIRECTORY is a symlink and SOURCE has an
absolute path.

For example, on macOS Ventura, ~/Dropbox is a symlink to
~/Library/CloudStorage/Dropbox.  Suppose DEFAULT-DIRECTORY is
/Users/username/Dropbox and SOURCE is /var/tmp/test.org, so its
relative path is ../../../var/tmp/test.org.  But the working directory
of a compilation process is actually ~/Library/CloudStorage/Dropbox,
relative to which the source path resolves to
/Users/username/var/tmp/test.org.  The process thus cannot find the
source file.

This commit changes `org-compile-file` and its helper function
`org-compile-file-commands` to resolve symlinks in DEFAULT-DIRECTORY
before computing the relative path of SOURCE.  If SOURCE is already
relative, it is used as-is.  The absolute path is processed by
`expand-file-name`, avoiding bug [1].

[1] https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5a8a1d4ff
[2] https://orgmode.org/list/25528.42190.53674.62...@gargle.gargle.howl
---
 lisp/org-macs.el | 45 +
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index e102f01c3..dc5dbeab5 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -1607,15 +1607,18 @@ When PROCESS is a list of commands, optional argument LOG-BUF can
 be set to a buffer or a buffer name.  `shell-command' then uses
 it for output."
   (let* ((commands (org-compile-file-commands source process ext spec err-msg))
- (output (expand-file-name (concat (file-name-base source) "." ext)
-   (file-name-directory source)))
+ (output (concat (file-name-sans-extension source) "." ext))
+ (relname (if (file-name-absolute-p source)
+(let ((pwd (file-truename default-directory)))
+  (file-relative-name source pwd))
+  source))
  (log-buf (and log-buf (get-buffer-create log-buf)))
  (time (file-attribute-modification-time (file-attributes output
 (save-window-excursion
   (dolist (command commands)
 (cond
  ((functionp command)
-  (funcall command (shell-quote-argument (file-relative-name source
+  (funcall command (shell-quote-argument relname)))
  ((stringp command) (shell-command command log-buf)
 ;; Check for process failure.  Output file is expected to be
 ;; located in the same directory as SOURCE.
@@ -1649,33 +1652,35 @@ the SOURCE file.
 
 If PROCESS is a list of commands, each of them is called using
 `shell-command'.  By default, in each command, %b, %f, %F, %o and
-%O are replaced with, respectively, SOURCE base name, name, full
-name, directory and absolute output file name.  It is possible,
-however, to use more place-holders by specifying them in optional
-argument SPEC, as an alist following the pattern
+%O are replaced with, respectively, SOURCE base name, relative
+file name, absolute file name, relative d

[PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file

[Roshan Shariff]

* org-macs.el (org-compile-file, org-compile-file-commands): Avoid
converting the source path to be relative to the default-directory,
which breaks for absolute source paths when the current directory is a
symlink.

Commit 5a8a1d4ff [1] changed org-compile-file to use
`file-relative-name` for the source argument. This was intended to fix
bug [2] by expanding ~ directories in the source path, like a shell.

Unfortunately, this forced use of relative paths breaks when
default-directory is a symlink, and the source to be compiled has an
absolute path.

For example, on macOS Ventura, ~/Dropbox is a symlink to
~/Library/CloudStorage/Dropbox. Suppose `default-directory` is
/Users/username/Dropbox and you try to compile /var/tmp/test.org. Its
relative path is ../../../var/tmp/test.org. But the working directory
of a compilation process is actually ~/Library/CloudStorage/Dropbox,
relative to which the source path resolves to
"/Users/username/var/tmp/test.org". The process thus cannot find the
source file.

This commit changes `org-compile-file` and its helper function
`org-compile-file-commands` to avoid the use of relative
paths. Instead, to address bug [2], `expand-file-name` is used (only
on absolute paths) for ~ expansion. Otherwise, the source path is
passed unchanged to the compilation command. The `file-truename` of
the source directory is used to construct absolute source and output
paths if needed by the command.

[1] https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5a8a1d4ff
[2] https://orgmode.org/list/25528.42190.53674.62...@gargle.gargle.howl
---
 lisp/org-macs.el | 39 +++
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index e102f01c3..5d8f65193 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -1606,16 +1606,20 @@ filename.  Otherwise, it raises an error.
 When PROCESS is a list of commands, optional argument LOG-BUF can
 be set to a buffer or a buffer name.  `shell-command' then uses
 it for output."
+  (when (file-name-absolute-p source)
+;; Expand "~" and "~user" .  Shell expansion will be disabled
+;; in the shell command call.
+(setq source (expand-file-name source)))
   (let* ((commands (org-compile-file-commands source process ext spec err-msg))
- (output (expand-file-name (concat (file-name-base source) "." ext)
-   (file-name-directory source)))
+ (output (file-name-concat (file-name-directory source)
+   (concat (file-name-base source) "." ext)))
  (log-buf (and log-buf (get-buffer-create log-buf)))
  (time (file-attribute-modification-time (file-attributes output
 (save-window-excursion
   (dolist (command commands)
 (cond
  ((functionp command)
-  (funcall command (shell-quote-argument (file-relative-name source
+  (funcall command (shell-quote-argument source)))
  ((stringp command) (shell-command command log-buf)
 ;; Check for process failure.  Output file is expected to be
 ;; located in the same directory as SOURCE.
@@ -1658,22 +1662,33 @@ argument SPEC, as an alist following the pattern
 
 Throw an error if PROCESS does not satisfy the described patterns.
 The error string will be appended with ERR-MSG, when it is a string."
+  (when (file-name-absolute-p source)
+;; Expand "~" and "~user" .  Shell expansion will be disabled
+;; in the shell command call.
+(setq source (expand-file-name source)))
   (let* ((base-name (file-name-base source))
-(full-name (file-truename source))
- (relative-name (file-relative-name source))
-(out-dir (if (file-name-directory source)
-  ;; Expand "~".  Shell expansion will be disabled
-  ;; in the shell command call.
-  (file-name-directory full-name)
-"./"))
-(output (expand-file-name (concat (file-name-base source) "." ext) 
out-dir))
+(out-dir (file-name-directory source))
+ ;; Don't use (expand-file-name SOURCE) for the absolute path,
+ ;; in case SOURCE starts with ../ and default-directory is a
+ ;; symlink.  Instead, resolve symlinks in the directory
+ ;; component of SOURCE...
+ (true-out-dir (file-truename out-dir))
+ ;; but use the original file name component of SOURCE in case
+ ;; it is a symlink; we want %f and %F to have the same file
+ ;; name component:
+(full-name (file-name-concat true-out-dir
+  (file-name-nondirectory source)))
+ ;; The absolute path OUTPUT is the same as FULL-NAME, except
+ ;; with extension EXT:
+(output (file-name-concat true-out-dir
+   (concat base-name "." ext)))
 (err-msg (if (stringp err-msg) (concat ".  " err-msg) "")))
 

Re: Bug: Can't set background color of latex fragment

[Roshan Shariff]

Hi Sébastien,

I originally made my patch because otherwise adding '(:background
"Transparent") to org-format-latex-options always resulted in a white
background (\pagecolor{white} would be forcefully added to the
generated LaTeX). Then I found that dvipng still produced a white
background even without a \pagecolor{...} directive, so I added the
-bg Transparent option. This is unlike dvisvgm, which produces an
opaque background when \pagecolor{...} is present and a transparent
background otherwise.

I didn't realize that dvipng -bg Transparent would completely ignore
the \pagecolor{...} command even if it was present. Perhaps the best
solution that allows the background color to be customized with dvipng
is to remove "-bg Transparent" from the default dvipng command line.
For people who need transparency, perhaps another "dvipng
(transparent)" option can be created, or they can use dvisvgm. This is
useful for HTML export, for example.

That said, I haven't had any issues with Emacs rendering transparent
PNGs (version 27.2 on Linux and macOS). It uses the background color
of whichever face is applied to LaTeX fragments (which seems to be
org-block, along with font-latex-verbatim-face for inline formulae). I
personally find it convenient to customize these faces as needed.

Regards,
Roshan

On Wed, May 19, 2021 at 12:30 AM Sébastien Miquel
 wrote:
>
> Hi Roshan,
>
> Roshan Shariff writes:
>
> I can confirm this bug with dvipng --- with the "-bg Transparent"
> option, dvipng ignores the background color from the input tex file,
> whereas without that option it always produces an opaque background.
> There's currently no way to dynamically change command line
> parameters, so I'm not sure how to solve this problem while supporting
> both use cases.
>
>
> I asked about this behaviour on the dvipng mailing list, and the
> maintainer doesn't consider it a bug, see
> https://lists.nongnu.org/archive/html/dvipng/2021-05/msg2.html.
>
> Can you explain the use for a `Transparent` background ? Transparent
> images are poorly supported in emacs, all it does is render it with
> the background color of the default face -- which may not be the
> expected result.
>
> Regards,
>
> --
> Sébastien Miquel
>
>
> On Wed, Apr 7, 2021 at 1:38 PM Sébastien Miquel
>  wrote:
>
> To reproduce with `emacs -Q` :
>   - Open an org buffer
>   - Call ~(setq org-format-latex-options '(:foreground default
> :background "Black" :matchers ("$")))~
>   - Call =C-c C-x C-l= (org-latex-preview) on a latex fragment such as
> $abc$
>
> This bug was introduced by the commit 2f9e1569f which adds the option
> `-bg Transparent` to the arguments of `dvipng`. According to its
> manual, this option should be ignored if a background is already set,
> but it doesn't seem to be. Perhaps org should set it differently.
>
> --
> Sébastien Miquel
>
>
>

Re: Bug: Can't set background color of latex fragment

[Roshan Shariff]

I can confirm this bug with dvipng --- with the "-bg Transparent"
option, dvipng ignores the background color from the input tex file,
whereas without that option it always produces an opaque background.
There's currently no way to dynamically change command line
parameters, so I'm not sure how to solve this problem while supporting
both use cases.

On Wed, Apr 7, 2021 at 1:38 PM Sébastien Miquel
 wrote:
>
>
> To reproduce with `emacs -Q` :
>   - Open an org buffer
>   - Call ~(setq org-format-latex-options '(:foreground default
> :background "Black" :matchers ("$")))~
>   - Call =C-c C-x C-l= (org-latex-preview) on a latex fragment such as
> $abc$
>
> This bug was introduced by the commit 2f9e1569f which adds the option
> `-bg Transparent` to the arguments of `dvipng`. According to its
> manual, this option should be ignored if a background is already set,
> but it doesn't seem to be. Perhaps org should set it differently.
>
> --
> Sébastien Miquel

[PATCH] org.el: Allow transparent background in latex images

[Roshan Shariff]

* lisp/org.el (org-create-formula-image): When `:background' is set to
"Transparent" in `org-format-latex-options', do not output a
`\pagecolor{...}' command in the generated LaTeX file.  This will
cause dvisvgm, convert, or dvipng (with the `-bg Transparent' option)
to produce png or svg images with a transparent background.

* lisp/org.el (org-preview-latex-process-alist): Add the `-bg
Transparent' command-line option to dvipng, which causes it to produce
a PNG with an alpha channel when the dvi file has no `\background'
special.

TINYCHANGE
---
 lisp/org.el | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 053635c85..108dc6b5b 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3282,7 +3282,7 @@ All available processes and theirs documents can be found 
in
  :image-output-type "png"
  :image-size-adjust (1.0 . 1.0)
  :latex-compiler ("latex -interaction nonstopmode -output-directory %o %f")
- :image-converter ("dvipng -D %D -T tight -o %O %f"))
+ :image-converter ("dvipng -D %D -T tight -bg Transparent -o %O %f"))
 (dvisvgm
  :programs ("latex" "dvisvgm")
  :description "dvi > svg"
@@ -16146,10 +16146,10 @@ a HTML file."
 (if (eq fg 'default)
(setq fg (org-latex-color :foreground))
   (setq fg (org-latex-color-format fg)))
-(if (eq bg 'default)
-   (setq bg (org-latex-color :background))
-  (setq bg (org-latex-color-format
-   (if (string= bg "Transparent") "white" bg
+(setq bg (cond
+ ((eq bg 'default) (org-latex-color :background))
+ ((string= bg "Transparent") nil)
+ (t (org-latex-color-format bg
 ;; Remove TeX \par at end of snippet to avoid trailing space.
 (if (string-suffix-p string "\n")
 (aset string (1- (length string)) ?%)
@@ -16158,8 +16158,10 @@ a HTML file."
   (insert latex-header)
   (insert "\n\\begin{document}\n"
  "\\definecolor{fg}{rgb}{" fg "}%\n"
- "\\definecolor{bg}{rgb}{" bg "}%\n"
- "\n\\pagecolor{bg}%\n"
+ (if bg
+ (concat "\\definecolor{bg}{rgb}{" bg "}%\n"
+ "\n\\pagecolor{bg}%\n")
+   "")
  "\n{\\color{fg}\n"
  string
  "\n}\n"
-- 
2.26.2