In order to achieve better spacing and line breaking, pdfTeX can expand fonts. The user decides how much stretching and shrinking is allowed for each desired font, and in what increments. However, another way would be to set each line knowing that the entire line can be stretched or shrunk via a pdf transform (horizontal scaling). This has two advantages: (1) the adjustment is continuous, so discreteness effects of increments are avoided; and (2) all fonts, including all math, are handled simultaneously. This also seems easier to implement. A disadvantage is that certain characters ought to be expanded in different amounts; pdfTeX used \efcode for this purpose. Note, though, that pdfTeX does not use different glyphs: according to the pdfTeX user manual (p. 22), "For practical reasons pdfTeX does not use such huge glyph collections; it uses horizontal scaling instead".

There are trade-offs. Can anyone explain why the method I suggest is not used or is not better? Is there code somewhere that uses my method?

  • 6
    perhaps the most immediate reason is same as difference between a real small caps font and a scaled caps font, you want to change the widths of the characters without noticeably changing the stroke width. so you can't simply apply a transform to the rendered line. Your method would increase the width of i by the same factor as the width of w which isn't likely to make a consistent appearance to the page. Commented Dec 20, 2015 at 20:08
  • @DavidCarlisle Yes, that is the disadvantage that I mentioned. However, I don't think that the (at most) 2% difference in width from expansion is noticeable. In fact, it is not supposed to be (that's why it doesn't get any penalties). Furthermore, you are talking about a difference in differences: is that noticeable? Even if it is noticeable, will my method not produce a more uniform appearance when math is involved, so that the math can take up a lot of the expansion?
    – Russ Lyons
    Commented Dec 20, 2015 at 21:57
  • I'd think having the stokes in some i being 2% wider than the same letter on the line above would be quite distracting but I'm not a font designer:) If you wanted to test this it would relatively easy to make a callback in luatex that takes each line in the paragraph, resets it with natural width glue and then horizontally scales back to line width. Commented Dec 20, 2015 at 22:01
  • @DavidCarlisle Actually, I did test it in pdfTeX. I set \rightskip=0pt plus .02\hsize minus .02\hsize, then disassembled the paragraph and reassembled it after resizing. It was not perfect because \badness is available only to the nearest integer, reducing the accuracy of the glue set. Other than that, it looked very good. (My code can't handle displays and other things, though.) I don't know luatex and may not have the time needed to learn it before the publisher takes over production of my book.
    – Russ Lyons
    Commented Dec 20, 2015 at 22:18
  • 3
    Microtype is certainly not a package for (pdf)latex that also does this. It is a package for pdfLaTeX (now with some support for LuaLaTeX and XeLateX) which provides, essentially, an interface to pdfTeX's abilities. It expands fonts by switching on the stuff in pdfTeX which can expand fonts. There's nothing doing font expansion at the package level and nothing which would do font expansion in LaTeX.
    – cfr
    Commented Dec 21, 2015 at 3:32

1 Answer 1


The first versions of pdftex actually implemented font expansion by way of horizontal scaling (as outlined in this TUGboat article). It was only later (with version 0.14f, I guess) that expansion was font-based. A footnote in Hàn Thê Thành's thesis explains that the scaling method

turned out to be too cumbersome and fragile, because the horizontal scaling is applied on a per line basis, thus everything on a line was expanded. In order to use this method, only text typeset by a single font is allowed. So later this approach was discarded. (p. 407)

But two subsequent developments in pdftex resulted in today's method, which is actually not so far away from the one you describe:

  • version 1.20 introduced the possibility to create the expanded font instances on the fly (before that it was necessary to create them manually in advance).
  • since version 1.40, expansion is realised by way of horizontal scaling (PDF text matrix transformation) instead of including all the expanded font instances -- leading to much smaller PDF files.

Expansion is still font-based and not line-based so that only the glyphs will be expanded, but not the inter-word spaces, or even graphical elements.

But if you load microtype like this:


all fonts, including math, will be expanded, and with step=1 (which is the default), you are quite close to avoiding discreteness effects.

The \efcode problem (the possibility to apply different expansion to different glyphs) can probably be neglected. At least microtype does not use them by default, because the experiments carried out by Hàn Thê Thành seemed to suggest that it is better to expand all glyphs by an equal amount, but less (max 2%), instead of expanding some more, some less.

(And, as @cfr says, microtype is only an interface to pdftex's microtypographic features.)

  • Thank you for this clarification of the history. I don't understand the thesis footnote: How was it "too cumbersome and fragile"? It still seems to me that pdfTeX works per line (and larger units), as does TeX, to decide line breaks, and that therefore it would be easiest to expand everything on each line. It is true that expansion of interword spaces is not ideal, but 2% is not noticeable. This is simply a trade-off. My method may not give better results than your final suggestion, but it seems faster.
    – Russ Lyons
    Commented Dec 21, 2015 at 15:28
  • Let me clarify a possible point of confusion. Line-based expansion can mean two things, both based on one expansion per line. (1) Set paragraphs and then resize them, as in my cheap experiment and as luaTeX can do. (2) Decide line breaks as pdfTeX does, but with a minor adjustment to the penalty calculation since at the end, there will be only one horizontal expansion per line, rather than one per character (or per word). I think that (2) is faster and gives smaller files than what pdfTeX does now.
    – Russ Lyons
    Commented Dec 21, 2015 at 15:45
  • First, when I wrote "penalties", I should have written "demerits and penalties". Second, "By default, all characters of a font are allowed to be stretched or shrunk by the same amount." (p. 14 of the doc) I believe this means that \efcode is not used by default, but I'm not sure.
    – Russ Lyons
    Commented Dec 21, 2015 at 21:30
  • @RussLyons regarding "too cumbersome": I would guess that this refers to filtering out things that shouldn't be stretched (first and foremost interword spaces). Re: lines, if you look at the pdf file, the matrix transformation is indeed applied to whole lines in normal cases, so I don't see much difference here. Re: \efcodes, they are indeed not used by default.
    – Robert
    Commented Dec 22, 2015 at 3:43
  • I believe that the transformation is applied to an entire line only when the font does not change in that line. And the filtering you guess is what made it "cumbersome" is still done, so I don't understand the change; maybe it's just that it is less cumbersome in the new implementation. Anyway, given these defaults, I don't see why discrete amounts of expansion are used. That seems to make it more cumbersome and less ideal. I think there ought to be an option that does what I suggest and what you say is close to an option now, but that works for dvi by leaving pdf specials.
    – Russ Lyons
    Commented Dec 22, 2015 at 17:04

You must log in to answer this question.

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