I often write a lot of mathematics where I multiply various quantities/operators/etc. by fractions. The fractions are important for bookkeeping, but usually not the most important thing in the equation by far, so I like to de-emphasize them.

My usual solution to this is to use \tfrac even in displayed environments, but this does not look as æsthetically pleasing as possible — it's a bit cramped. But I find the massive fractions produced by \dfrac to swing too far in the opposite direction in a context such as \[ \dfrac{1}{2} A + (other stuff) \].

To solve this problem in my thesis (where I was allowed to get away with things like the following), I created a custom fraction macro, roughly as follows (using the scalefnt package):


All numerical parameters were chosen arbitrarily, to make constructs such as \sfrac{1}{\sqrt 2} and \sfrac{\pi}{2} look appealing in comparison to the \tfrac and \dfrac alternatives in displayed math (e.g. when placed next to something else such as a uppercase or lowercase letter, a bracket, or a summation symbol).

If you have any, please provide arguments for the following:

  1. Fundamental æsthetic or technical problems with this macro: are there reasons why I should never want to use such a macro, if I were "right-thinking"?

  2. Technical or æsthetic improvements which are possible for this macro: how could I make it better?

  3. Are there practical problems that would be caused by this macro (aside from potentially making co-authors and journal editors hate me)?

  • This isn't even important enough to make an answer, but I'd add \mathsurround0pt inside $#x$. Alternatively, you can use \m@th which does the same thing, but you need \makeatletter beforehand.
    – TH.
    Oct 8, 2010 at 10:16
  • To be honest, I think I prefer \tfrac, but I accept it's a matter of taste. There might be a very marginal argument in favour of \tfrac in that it doesn't involve a new, potentially non-portable, piece of code. Oct 8, 2010 at 11:25
  • @Brent: are there hints as to what may make a piece of code such as the above non-portable (and ways to try to mitigate them)? Oct 8, 2010 at 15:46
  • To respond to your comment to Brent (and note that you need to put the full name after the @ to notify someone other than the author of the question/post that they have a message), different fonts can set their x height differently relative to their total height so this might need to be modified in that case.
    – TH.
    Oct 8, 2010 at 21:09
  • @TH.: Would you be able to describe a way to resolve this potential pitfall, or point me to the relevant concepts to resolve this? (E.g. is this something that can be resolved by somehow accounting for the baseline of a piece of text in an hbox?) Oct 9, 2010 at 19:47

2 Answers 2


Given the lack of answers other than the comments, here is a summary of the critiques which have come from the comments. By increasing the visibility of these comments, I'm hoping that I may get a solution to the portability problem noted so far, and provoke further critiquing of my macro generally.

  • Technical/æsthetic obstacle:
    Brent.Longborough, with further elaboration by TH., noted that this macro is not necessarily very robust to a change in font, which may have different dimensions for e.g. its ex-size relative to the size of the actual letters. It would seem that a different choice of parameters in the \raisebox-es, and possibly the \scalefont-s as well, may be necessary for each different font used.

  • Technical improvement:
    TH. suggested (if I understand correctly) that I should modify the macro using \m@th (or equivalent): a little research indicates that this is probably to improve the horizontal spacing of the result. Thus, a minor improvement would be

    \newcommand\sfrac[2]{% \dfrac{\text{\raisebox{-0.5ex}{\scalefont{0.85}{$\m@th#1$}}}}% {\text{\raisebox{0.35ex}{\scalefont{0.85}{$\m@th#2$}}}}% }

[EDIT: I am 'accepting' this answer for now, but if anyone comes along and provides useful insights, I will change the accepted answer.]


For this particular wheel, eplain defines frac this way:

   \kern.1em \raise .5ex \hbox{\the\scriptfont0 #1}%
   \kern-.1em $/$%
   \kern-.15em \lower .25ex \hbox{\the\scriptfont0 #2}%

Its usage is kinda weird: \frac 23/{64}

  • 2
    @morburg: You seem to have misunderstood the question: your macro produces a fraction in text-mode, in a style like ½. My macro does not. To see what I'm getting at, maybe try a test document defining my macro \sfrac as I do above, and then consider the output produced by \[ \tfrac2\pi \sfrac2\pi \dfrac2\pi \] in a document (don't forget to use amsmath). Oct 15, 2010 at 14:40
  • My apologies. Your definition seemed somewhat similiar at a glance.
    – morbusg
    Oct 15, 2010 at 15:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .