You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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: defaultantex:
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:
The issue was initially found on figures (esp. commutative diagrams) which were short and wide.
A clarifying example reproducing the behaviour is this one:
It is renders as follows:
Note that:
One can verify there is inline CSS (inserted by
jekyll-antex
) enforcing the dimensions (calculated byantex
).The prime suspect is
antex
so we need to recover the measurementsHere they are:
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:
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:
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:
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:
This can be done either directly, with
antex
aliases or in any other way and it works well withxypic
diagrams.To wrap this up:
I think the best thing to do now is find a few reliable techniques for the most common cases and document them.
The text was updated successfully, but these errors were encountered: