Matt Huszagh <huszaghm...@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
