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 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 . Support Org development at , or support my work at .