emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Matt Huszagh <huszaghmatt@gmail.com>
To: Timothy <orgmode@tec.tecosaur.net>, emacs-orgmode@gnu.org
Subject: Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Date: Fri, 19 Jan 2024 23:13:19 -0800	[thread overview]
Message-ID: <87plxwfpf4.fsf@gmail.com> (raw)
In-Reply-To: <87cytwk0eo.fsf@gmail.com>

Matt Huszagh <huszaghmatt@gmail.com> writes:

> Another minor issue I've encountered. Using different delimiters results
> in images of slightly different sizes.
>
> For example, in a file containing:
>
> ```
> Using first delimiters: \(F=ma\).
>
> Using other delimiters: $F=ma$.
> ```
>
> The snippet with dollar sign delimiters is slightly larger than the one
> using \(\).

The following code, where you compute the ascent value, seems relevant
to this observation:

;; The baseline seems to tend to sit slightly
;; lower than it should be, and a very mild
;; bias seems to improve the visual result.
;; From testing with a collecting of LaTeX
;; maths fonts (cm, cmbright, arev, pxfonts,
;; notomath, nextxsf, eulervm) decreacing the
;; depth measurement by 0.02pt in the baseline
;; calculation seems to work well.
;; I have yet to come across any situation
;; where this results in a negative depth,
;; however we may as well ensure that never
;; occurs.
(round (* 100 (- 1 (/ (max 0.0 (- depth 0.02))
                      height))))

When using \(\) delimiters, using a depth adjustment of 0 (instead of
0.02) looks correct to me. I checked this by blowing up the fragment
with a very large scale factor (eg 10) and then baseline misalignments
become more obvious. This is how I ensured my baseline computation was
correct when I wrote that patch aligning the baseline several years
ago. I /think/ that's a valid method, and I've been using my code for
the last couple years and the baseline has always looked correct.

Anyway, can you explain more why you came to the conclusion of that
slight depth adjustment? Are you using $$ delimiters? That also appears
to produce other visual imperfections. For $F=ma$, I see the bottom of
the "m" and "a" cut off slightly. I wonder why different delimiters
produce different results. I used slightly different settings for
dvisvgm in my implementation (including --exact-bbox). I wonder if that
has any relevance... I also used a different document class - standalone
in preview mode. Now that I think about it, IIRC that was to address
another corner case I ran into, which is that for large images, article
will crop it before it gets to dvisvgm. It's been a while since I did
this and my memory is hazy, but I think that's why I used standalone. I
can try to investigate that with a minimal issue.

Matt


  reply	other threads:[~2024-01-20  7:14 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-12 12:23 [Pre-PATCH] Overhaul of the LaTeX preview system Timothy
2023-03-13 12:26 ` Ihor Radchenko
2023-03-14 16:04   ` Timothy
2023-03-15  9:34     ` Ihor Radchenko
2023-03-15 17:28       ` Rudolf Adamkovič
2023-03-13 12:30 ` Ihor Radchenko
2023-03-13 12:32   ` Ihor Radchenko
2023-03-14 14:46     ` Timothy
2023-03-13 12:36 ` Ihor Radchenko
2023-03-14 16:10   ` Timothy
2023-03-15  9:38     ` Ihor Radchenko
2023-03-13 12:37 ` Ihor Radchenko
2023-03-14 16:13   ` Timothy
2023-03-25 15:29 ` Tony Zorman
2023-05-02 12:15 ` K. Chousos
2023-05-03 10:07 ` K. Chousos
2023-05-05 17:57   ` Karthik Chikmagalur
2023-05-05 18:48     ` Konstantinos Chousos
2023-05-05 18:53     ` Konstantinos Chousos
2023-05-05 20:05       ` Karthik Chikmagalur
2023-05-05 21:06         ` Konstantinos Chousos
2023-05-05 22:58           ` Karthik Chikmagalur
2023-05-06  9:19             ` Konstantinos Chousos
2023-05-06  9:30               ` Ihor Radchenko
2023-05-06 10:08               ` Konstantinos Chousos
2023-05-08 20:04               ` Karthik Chikmagalur
2023-05-08 20:40                 ` Konstantinos Chousos
2023-05-09 11:34                 ` Ihor Radchenko
2023-05-09 12:03                   ` Timothy
2023-05-09 12:10                     ` Ruijie Yu via General discussions about Org-mode.
2023-05-09 12:12                     ` Ihor Radchenko
2023-05-09 12:10                       ` Timothy
2023-05-09 12:49                   ` Max Nikulin
2023-05-09 12:57                     ` Ihor Radchenko
2023-05-10 10:07 ` Jun Inoue
2023-05-10 10:21   ` Timothy
2023-05-10 13:09     ` Jun Inoue
2023-05-26  9:50 ` Rudolf Adamkovič
2023-05-28 17:31   ` Timothy
2023-06-03  9:00     ` Rudolf Adamkovič
2023-08-21  8:59 ` Visuwesh
2023-08-21 16:40   ` Karthik Chikmagalur
2023-08-21 17:19     ` Visuwesh
2023-08-21 21:40       ` Karthik Chikmagalur
2023-08-22  2:57         ` Visuwesh
2023-08-29  6:01 ` Roshan Shariff
2023-08-29  6:01 ` [PATCH 1/1] Fix background color when line-wrapping latex previews Roshan Shariff
2023-08-29 17:14   ` [PATCH v2] Fix background color of " Roshan Shariff
2024-01-07  7:25     ` Timothy
2024-01-07  9:50       ` Roshan Shariff
2024-01-08 10:24         ` Timothy
2024-01-09 20:12           ` Roshan Shariff
2024-01-07  7:28 ` [Pre-PATCH] Overhaul of the LaTeX preview system Timothy
2024-01-20  5:53 ` Matt Huszagh
2024-01-20  6:02 ` Matt Huszagh
2024-01-20  7:13   ` Matt Huszagh [this message]
2024-01-21 17:08     ` Timothy
2024-04-22 11:08 ` Feedback on the new "feature" system in org-export (was: [Pre-PATCH] Overhaul of the LaTeX preview system) Ihor Radchenko
  -- strict thread matches above, loose matches on Subject: below --
2023-06-04 23:29 Re: [Pre-PATCH] Overhaul of the LaTeX preview system Rudolf Adamkovič
2023-06-05  5:27 ` Pedro Andres Aranda Gutierrez
2023-08-07  8:12 WANG Yicheng
2023-08-08  8:30 ` Ihor Radchenko
2024-04-11 19:26 Yaroslav Drachov
2024-04-18 20:04 ` Karthik Chikmagalur
2024-04-18 20:13   ` Yaroslav Drachov
2024-04-17 20:11 Корякин Артём
2024-04-18  3:11 ` Karthik Chikmagalur
2024-04-18 20:47   ` Корякин Артём
2024-04-18 15:14 ` Max Nikulin
     [not found]   ` <86edb2ft89.fsf@gmail.com>
2024-04-19  2:23     ` Max Nikulin
2024-04-19  6:53       ` Корякин Артём
2024-04-18 21:49 Корякин Артём

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87plxwfpf4.fsf@gmail.com \
    --to=huszaghmatt@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=orgmode@tec.tecosaur.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).