Some figures are rendered with the wrong size

[paolobrasolin]

The issue was initially found on figures (esp. commutative diagrams) which were short and wide.

A clarifying example reproducing the behaviour is this one:

---
antex:
  preamble:
    \usepackage{tikz}
    \usetikzlibrary{matrix}
---

The letter M thould have this size: $M$

{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}

It is renders as follows:

Note that:

• the columns seem to converge to a certain font size
• the final size is still too big compared to the inline letter

One can verify there is inline CSS (inserted by jekyll-antex) enforcing the dimensions (calculated by antex).

The prime suspect is antex so we need to recover the measurements

• of the LaTeX box (*_TEX),
• of the SVG viewport wrapping the bounding box (*_TFM), and
• of the SVG viewport fitting the ink (*_FIT).

Here they are:

EMTEX [pt]	HTTEX [pt]	DPTEX [pt]	WDTEX [pt]	OXTFM [px]	OYTFM [px]	DXTFM [px]	DYTFM [px]	OXFIT [px]	OYFIT [px]	DXFIT [px]	DYFIT [px]
10.000020	20.165220	0.000000	24.123570	83.353244	59.443040	10.751356	6.807795	83.353244	59.446352	10.400996	6.804483
10.000020	33.664490	0.000000	24.123570	83.353244	59.443123	10.751356	20.256630	83.353244	59.446435	10.400996	20.253318
10.000020	47.163760	0.000000	24.123570	83.353244	59.443205	10.751356	33.705464	83.353244	59.446517	10.400996	33.702152
10.000020	60.663020	0.000000	24.123570	83.353244	59.443288	10.751356	47.154699	83.353244	59.446600	10.400996	47.151387
10.000020	74.162300	0.000000	24.123570	83.353244	59.443371	10.751356	60.603633	83.353244	59.446683	10.400996	60.600321
10.000020	87.661560	0.000000	24.123570	83.353244	59.443454	10.751356	74.051567	83.353244	59.446766	10.400996	74.048255
10.000020	101.160830	0.000000	24.123570	83.353244	59.443637	10.751356	87.500802	83.353244	59.446949	10.400996	87.497490
10.000020	114.660100	0.000000	24.123570	83.353244	59.443619	10.751356	100.949236	83.353244	59.446931	10.400996	100.945924
10.000020	128.159360	0.000000	24.123570	83.353244	59.443802	10.751356	114.398471	83.353244	59.447114	10.400996	114.395159
10.000020	141.658630	0.000000	24.123570	83.353244	59.443905	10.751356	127.846785	83.353244	59.447217	10.400996	127.843473

A few simple sanity checks give us what we'd expect, within rounding errors due to LaTeX. That is, the difference between TFM and FIT is constant and all three series increase in height linearly:

OXFIT-OXTFM	OYFIT-OYTFM	DXFIT-DXTFM	DYFIT-DYTFM	(HTn+DPn-HTn-1-DPn-1)TEX	(DYn-DYn-1)TFM	(DYn-DYn-1)FIT
0,000000	0,003312	-0,350360	-0,003312	N/A	N/A	N/A
0,000000	0,003312	-0,350360	-0,003312	13,499270	13,448835	13,448835
0,000000	0,003312	-0,350360	-0,003312	13,499270	13,448834	13,448834
0,000000	0,003312	-0,350360	-0,003312	13,499260	13,449235	13,449235
0,000000	0,003312	-0,350360	-0,003312	13,499280	13,448934	13,448934
0,000000	0,003312	-0,350360	-0,003312	13,499260	13,447934	13,447934
0,000000	0,003312	-0,350360	-0,003312	13,499270	13,449235	13,449235
0,000000	0,003312	-0,350360	-0,003312	13,499270	13,448434	13,448434
0,000000	0,003312	-0,350360	-0,003312	13,499260	13,449235	13,449235
0,000000	0,003312	-0,350360	-0,003312	13,499270	13,448314	13,448314

The real issue is clarified with these calculations:

((HT+DP)/WD)TEX	(DY/DX)TFM	(DY/DX)FIT	((HT+DP)/EM)TEX/DYTFM [pt/px]	((HT+DP-δ)/EM)TEX/DYTFM [pt/px]
0.835914	0.633203	0.654215	0.296207	0.100373
1.395502	1.884100	1.947248	0.166190	0.100374
1.955090	3.134997	3.240281	0.139929	0.100375
2.514678	4.385930	4.533353	0.128647	0.100374
3.074267	5.636836	5.826396	0.122372	0.100374
3.633855	6.887649	7.119343	0.118379	0.100375
4.193444	8.138583	8.412415	0.115611	0.100375
4.753032	9.389442	9.705409	0.113582	0.100375
5.312620	10.640376	10.998481	0.112029	0.100375
5.872208	11.891224	12.291464	0.110803	0.100375

The first three columns are the aspect ratios. We expect them to be similar, but the TEX one is completely off.

The fourth column is the conversion factor from the points of the LaTeX figure to the pixels of the SVG ones and we use it to calculate all the final dimensions here:

https://github.com/paolobrasolin/antex/blob/2d4f0274b855c16ee9b9098177f6b5bc5f1ca855/lib/antex/set_box.rb#L45-L73

We expect it to be uniform, but it's clearly all over the place. It seems to be converging to some value for bigger total heights: a simple explanation would be that we're not compensating for an height excess δ when comparing it to TFM. Fiddling with the numbers we easily find that δ=13.332 make the fifth column uniform.

What's the meaning of this? Were implicitly assuming that the LaTeX box and the SVG bounding box are comparable when in fact they are not. While our calculations are generally well behaved (in fact they're impeccable for horizontal content), as soon as we have some vertical content with big margins this issue becomes evident.

Since LaTeX boxes have no real relation with the ink, this is not really solvable. A decent workaround is to force the LaTeX boxes to be identical to the ones the SVGs will have, and that's only doable by artificially introducing ink, e.g. a transparent background or a hairline frame around the content.

The implementation details depend on the situation. Our initial example can be fixed like so:

---
layout: default
antex:
  preamble:
    \usepackage{tikz}
    \usetikzlibrary{matrix}
    \usetikzlibrary{backgrounds}
    \tikzset{
      every picture/.append style={
        background rectangle/.style={fill=white, fill opacity=0},
        tight background,
        show background rectangle,
      }
    }
---


The letter M thould have this size: $M$

{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}
{% tex %}\begin{tikzpicture} \matrix[matrix of math nodes]{M\\M\\M\\M\\M\\M\\M\\M\\M\\M\\}; \end{tikzpicture}{% endtex %}

This now renders to

The technique above solves the problem with TikZ figures (which include CoDi and tikz-cd diagrams), and that is my main concern.

A different method (which does not work for TikZ) would be wrapping the content like so:

\setlength{\fboxrule}{1sp}
\setlength{\fboxsep}{0sp}
\fbox{...}

This can be done either directly, with antex aliases or in any other way and it works well with xypic diagrams.

---

To wrap this up:

• a general solution would imply measuring the ink within LaTeX, but it's now aware of it so it's impossible
• the second best solution is a fallback technique working with any kind of content, but I still haven't found it
• in any case, the user will need to somehow recognize and treat these situations in some special way (modifying the preamble, defining aliases, ...)

I think the best thing to do now is find a few reliable techniques for the most common cases and document them.