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

[Timothy <orgmode@tec.tecosaur.net>]

[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]

Hi Matt,

Thanks for taking this branch for a spin and reporting back.

I’m a bit mystified by the difference you see between `$$' and `\(\)' delimiters (I
can’t detect any difference my end). Regarding the specific comments in your
last email though:

Matt Huszagh <huszaghmatt@gmail.com> writes:

> 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?

So, this minor correction factor came abound from blowing up the fontsize and
trying a number of combinations of fonts (as in the comment). The 0.02
correction isn’t a “best with computer modern” value, but a compromise between
the various values that seemed best for the common LaTeX maths fonts tested. A
value of 0.02 seemed to produce consistently good results across the range of
fonts.

This testing was done several months ago, so I forget the particular details,
but that is the methodology used. It’s entirely possible this could benefit from
some tweaking, I’d just like to see some high-res screenshots with a range of
fonts to help convince me that a chance is beneficial.

> 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 always use `\(\)' myself, but can’t see why that would affect the preview.

> I used> slightly different settings for dvisvgm in my implementation
> (including –exact-bbox). I wonder if that has any relevance…

It does. `--exact-bbox' is known to produce slightly dodgy results with recent
dvisvgm versions (and seems to behave differently on MacOS for some reason). Is
there a particular reason you changed the dvisvgm settings?

> I also used a different document class - standalone in preview mode.

Hmmm, I’m not sure if that could cause any issues.

> 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 wonder to what extend this can be resolved by just decreasing the
margins/increasing the page size.

> I can try to investigate that with a minimal issue.

That would be good :)

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>.