4

In the following MWE:

\documentclass{article}
\usepackage{mathpazo}

\begin{document} $\frac{1}{2}$ \end{document}

the fraction bar is a little bit too close to the denominator, see the screenshot:

\frac with mathpazo

Is there a reason for this behaviour, and can one adjust the position of the line? I don’t think that it should be like this, since when using lmodern instead, the bar is (as far as I can tell) exactly in the middle, see the second screenshot:

\frac with lmodern

FKranhold
  • 391
  • 3
  • 9
  • 2
    In general, these are choices of the font designer. – Steven B. Segletes Aug 31 '21 at 10:14
  • 6
    The mathpazo font package hasn't been updated in years. Are you free to switch to a different Palatino-type set of font packages? If so, you may want to look into the newpxtext and newpxmath packages, especially as they leave a tad more space between the fraction bar and the denominator. – Mico Aug 31 '21 at 10:16
  • 3
    +1 for suggestion from @Mico I proposed refinements to newpxmath almost two years ago: https://tex.stackexchange.com/a/509092 and I think you'd agree that the spacing was improved significantly :) – Ruixi Zhang Aug 31 '21 at 13:02
  • 2
    @StevenB.Segletes Judging from the \fontdimen parameters from mathpazo, I’d call them “non-choices”. Many parameters are directly inherited from Computer Modern Math, without being adjusted for the taller body of Palatino-like designs. – Ruixi Zhang Aug 31 '21 at 13:18
  • @RuixiZhang I would, in 2021, upvote your answer again, if I could. – Steven B. Segletes Aug 31 '21 at 13:27
  • @StevenB.Segletes You have, in 2021, more than enough karma to award a bounty. – Davislor Aug 31 '21 at 20:50
  • @Davislor I just had the opportunity to upvote his answer again, right below this comment. – Steven B. Segletes Aug 31 '21 at 20:55

2 Answers2

9

Let’s briefly go through how TeX creates a fraction (many details will be ignored for the sake of simplicity). First, TeX needs to know where the fraction bar should be drawn and how thick it should be. These are controlled by \fontdimen parameters, which are decided by the font designer(s) (but users can change them later). The vertical position of the bar corresponds to \fontdimen 22 of family 2, while the thickness corresponds to \fontdimen 8 of family 3. Then, TeX needs to shift the numerator and denominator up and down from the “baseline” in order to stack them into a fraction. The parameters controlling numerator are \fontdimen 8, 9, 10 of family 2, while those for denominator are \fontdimen 11, 12 of family 2. Note: It is up to the font designer(s) to set appropriate values to these parameters so the results will be visually pleasing in most cases.


Is there a reason for this behaviour

This is because mathpazo uses identical values for many parameters as Computer Modern Math does. These values work fine with Computer Modern (and also Latin Modern lmodern). But Palatino-like designs have taller “bodies”, which often need more generous spacing. So these shifting amounts (designed for Computer Modern) are probably not adequate for Palatino.


and can one adjust the position of the line?

You don’t really want to adjust the position of the fraction bar (because \fontdimen 22 of family 2 affects a lot of other different things). Instead, you can enlarge \fontdimen 11, 12 of family 2 to cause the denominator to be shifted down a bit more.

David’s answer shows how you can assign new values to \fontdimen11\textfont2. The drawback is that this assignment is very low-level (the lowest level of TeX programming). In particular, this only works for one font size (namely, the \normalsize 10pt in this case).

A slightly higher-level solution is to use \DeclareFontShape within the LaTeX NFSS (New Font Selection Scheme). The syntax is

\DeclareFontShape{<encoding>}{<family>}{<series>}{<shape>}
  {
    <size declarations>
  }
  {
    \fontdimen11\font=<some proportion of>\fontdimen6\font
    ...
  }

But IMO this sort of code should appear in packages. Well, IMO this sort of code should never be needed if the parameters in the font were adequate in the first place.


I don’t think that it should be like this, since when using lmodern instead, the bar is (as far as I can tell) exactly in the middle

Well, just as David’s answer also explained, if the bar is exactly in the middle of 1 and 2, then it certainly cannot be in the exact middle of 1 and x, nor can it be in the exact middle of 1 and (N). Remember, it’s about visual balance in an infinite number of cases, not about mathematical exactness.


My recommendation

Switch to newpxtext and newpxmath if you can. These newer packages are actively maintained. I also helped refine newpxmath in 2019, which dealt with the positions of numerator and denominator. The details are here: https://tex.stackexchange.com/a/509092 which IMO suit your current need as well. I tried to find balance between (1) equalized spacing around the fraction bar, (2) uniform baseline for numerator, and (3) uniform baseline for denominator. It can never be “perfect”, but I think the results are visually pleasing.

In conclusion, just use \usepackage[fracspacing]{newpxmath} instead of \usepackage{mathpazo} should do the trick.


If you want to stick with mathpazo, then:

If you still want to use mathpazo, then here is the LaTeX NFSS code you can use:

\documentclass{article}
\usepackage{mathpazo}

% The original declarations can be found in omszplm.fd % We are changing them to use our customized fontdimen's

\DeclareFontFamily{OMS}{zplm}{ \skewchar\font=48 % kept from the original file \fontdimen 8\font=0.789\fontdimen6\font % 0.789 of a quad \fontdimen11\font=0.798\fontdimen6\font % 0.798 of a quad } \DeclareFontShape{OMS}{zplm}{m}{n}{<-> zplmr7y}{} \DeclareFontShape{OMS}{zplm}{b}{n}{<-> zplmb7y}{} \DeclareFontShape{OMS}{zplm}{bx}{n}{<->ssub * zplm/b/n}{}

\begin{document} Inline $\frac{1}{2}$ and display [ \frac{1}{2} ] \end{document}

The two values 0.789 and 0.798 are taken from newpxmath. If memory serves me correctly, they should be adequate for Palatino’s long ascenders and descenders. You are welcome to adjust them to your need, and even adjust \fontdimen 9, 10, 12 as well.

Ruixi Zhang
  • 9,553
  • Thank you for your extensive answer! For several small reasons, I am hesitant to switch from mathpazo to newpxmath (e.g. the arrow heads, which then differ a lot from the ones in tikzcd-diagrams; or the blackboard bold letters, in particular the blackboard bold 1, which IMO doesn’t match the Palatino font). Hence I think I will stick to mathpazo and make these small adjustments, although it is not exactly what you recommend. – FKranhold Aug 31 '21 at 17:16
  • 1
    @FKranhold I can see the aesthetic reasons behind your decision. I added the NFSS code for customizing mathpazo’s font dimensions, which is located at the end (after my original recommendation). – Ruixi Zhang Aug 31 '21 at 20:00
  • I'd have used \fontdimen5 (ex-height) as a base unit instead of \fontdimen6 (em-width). Using ex-height as a unit of height makes more sense to me than using em-width. – Henri Menke Aug 31 '21 at 20:33
  • @HenriMenke In my practice, I found myself increasingly disagree with the notion/recommendation that em is better for horizontal stuff while ex is better for vertical. Reasons: 1) There's no problem if one uses em for vertical, e.g., cap-height w.r.t. em. Setting 10pt type on 12pt leading often means 1.2 line-spacing, i.e., 1.2em for line height. 2) Most font metrics are in units of em. If you look at cmsy10.pl, there're NUM1 R 0.676508, DENOM1 R 0.685951, etc., certainly proportions of 1em. 3) The notion of x-height simply does not exist in scripts/languages that don't have lowercases. – Ruixi Zhang Aug 31 '21 at 22:45
  • 1
    @RuixiZhang x-height is kind of a misnomer for non-Latin scripts, yes. But doesn’t using em for vertical go wrong if the font is especially condensed or wide? – Davislor Sep 01 '21 at 00:25
  • @Davislor For condensed or wide types, you can introduce a \condenseratio (e.g., 8/10 for condensed, 12/10 for wide), then specify the layout using \dimexpr1em*\condenseratio\relax or \glueexpr0.5em minus 0.5em*\condenseratio\relax, which is what I've explored in https://github.com/CTeX-org/ctex-kit/issues/511#issuecomment-703302835 (in Chinese; but the code is still in development, very slowly). Moreover, even for Latin normal-width type, boldface often has larger ex than regular for optical compensation. Based on the these, I'd argue em is more reliable than ex in most practice. – Ruixi Zhang Sep 01 '21 at 20:25
  • @RuixiZhang But isn’t em-width plus a condense ratio just a more complicated form of the font height parameter? With the point taken that the arbitrary size of the lowercase Latin alphabet isn’t very meaningful to many Asian fonts. But couldn’t you do what fontspec does for Scale=MatchUppercase and measure the height of an arbitrary full-size letter? – Davislor Sep 01 '21 at 21:34
  • @Davislor Yes, em+condense ratio is just another height parameter (I didn’t say em-width, because in metal type the full body on which each Latin letter sits has proportional width and uniform height of 1em). MatchXcase has the problem that different scales are used for different styles, instead of one scale for all styles within one family, see https://github.com/wspr/fontspec/issues/358 To me, em is more reliable, in the sense that derived values stay constant across a whole font family. To this post, more relevant aspect is that almost all internal font metrics is in em units. – Ruixi Zhang Sep 02 '21 at 01:10
  • For some reason, your last MWE does not work for me. It says Font family 'OSM+zplm' unknown.. – FKranhold Sep 04 '21 at 10:50
  • 1
    @FKranhold Hmm, this means omszplm.fd was not being properly loaded. I added \DeclareFontFamily in front of the three \DeclareFontShapes, which should work now. Also, since \DeclareFontFamily needs to be here anyway, I took the opportunity to collapse three identical assignments into one shared family assignment. – Ruixi Zhang Sep 04 '21 at 14:59
  • @FKranhold Oops, I dropped \skewchar\font=48 from the original family declaration. It is now added back. – Ruixi Zhang Sep 04 '21 at 15:53
  • Thank you, now it works! – FKranhold Sep 04 '21 at 17:19
4

Even in computer modern the space above is slightly larger than the space below in 1/2 and in general TeX is not trying to equalize the space see for example 1/x where the space below is a lot more than the space above, or a denominator using a tall symbol such as () where the space below is much less than the space above.

enter image description here

\documentclass{article}

\begin{document}

[\frac{1}{2} + \frac{1}{x} + \frac{1}{(N)} ]

\end{document}

So if you use a font with relatively tall digits the space above the digit below the fraction bar will be less.

However if you want to generally increase the space below the fraction bar you can set fondimen11 which is the default drop for the denominator, see

What do different \fontdimen<num> mean

enter image description here

\documentclass{article}

\begin{document} \sbox0{$x$}% initialise math

\fontdimen11\textfont2=10pt [\frac{1}{2} + \frac{1}{x} + \frac{1}{(N)} ]

\end{document}

David Carlisle
  • 757,742
  • 1
    The assignment \fontdimen11\textfont2=10pt as shown here would only work for one font size (namely, the \normalsize 10pt). Switching to \footnotesize (in \footnotes) or \Large (in \section), then the spacing is not to scale (it does not adjust according to the em). A more comprehensive (but more-advance and lower-level) solution is \DeclareFontShape{<enc>}{<name>}{<weight>}{<shape>}{<size declaration>}{\fontdimen11\font=<some proportion of>\fontdimen6\font}. Something that I tried exploring in https://tex.stackexchange.com/a/509092 – Ruixi Zhang Aug 31 '21 at 13:10
  • 1
    @RuixiZhang yes (but was all I wanted to do in the answer here) You could provide an answer here to make that link more prominent (or we could close this question as duplicate of that) – David Carlisle Aug 31 '21 at 13:24
  • @RuixiZhang -- If you think a fraction might occur in a sub- or superscript, of course you;d need to adjust the relevant \fontdimens for those fonts too, and may as well take care of the \scriptscriptsize at the same time. – barbara beeton Sep 04 '21 at 17:59
  • @barbarabeeton I think RuixiZhang knows that, was rather suggesting that I should do that in this answer:-) – David Carlisle Sep 04 '21 at 19:35