[Tex/LaTex] How are fonts “stored” on LaTeX

Question

I used a humongous letter (the font was \mathscr) on a document and I was shocked by the quality of the letter despite the size of the letter. How are all these details stored? Why does the letter not look pixelated after a certain point? This might be very basic but I have no background whatsoever on whatever area this question belongs to.

Answer 1

You may be even more shocked to learn that LaTeX knows very little about the fonts it uses for typesetting documents.

In order to typeset a document, TeX only needs to have information about the characters' bounding boxes, ligatures, italic corrections, font spacing and little else. The characters' shapes (glyphs) aren't something TeX worries about.

This was clearer before the advent of PDF. Classic TeX used to (and still can) store the typesetting information in a DVI file (the name stands for “device independent”). This file could be used for viewing or printing, maybe after transformation into a device dependent format.

In olden times, for each printing device connected to the computer, a suitable driver written for that particular device had to be used. You can still find in TeX Live programs such as dvihp and dvilj: Hewlett-Packard developed a page description language called PCL and these programs transform the DVI file into something that can be sent to a printer (HP or LJ, respectively) using that language.

However, when PostScript was released by Adobe, things started to change. More and more producers of printing devices began to use the PostScript language and the TeX world was already at ease with it because Tom Rokicki wrote dvips.

How fonts are treated by the device driver is of no concern to TeX. But, of course, TeX has needed fonts since the beginning: no font, no printing. And, indeed, Donald Knuth also wrote a sister program to TeX, namely METAFONT, aimed at producing fonts.

At the time TeX and METAFONT were being developed, the late 70s of the 20th century, bitmaps were the only technology available for storing fonts. This is the only output format for METAFONT (besides the font information needed by TeX). And, in Knuth's vision, you needed a parameter file for each printer model in order to adjust the bitmap fonts to it.

PostScript, however, has a different view on fonts: it thinks of the characters by their outlines: curves (usually splines) that delimit the region of the plane to be filled with ink; but it also allowed for different formats and one of Rokicki's jobs was to provide a transparent conversion from bitmap METAFONT's PK files to PostScript Type3 fonts.

So, typically, if one had a 300dpi laser printer able to understand PostScript, the dvips driver would have produced, if necessary, the missing bitmap fonts with the cx mode

% This applies to the LaserWriter Plus, HP LaserJet, HP LaserJet Plus,
% and also the Canon LBP-LX engine, in the LaserJet IIP, QMS 410,
% and Apple Personal LaserWriter, and also to the CanonSX engine,
% in the LaserWriter II family.  And {\tt hammond@jila02.Colorado.EDU}
% says it works well for the ``enhanced-resolution'' LaserJet III.
% {\tt swartz@cs.wisc.edu} is developing a mode for the Canon EX engine
% inside an Apple Pro 630 printer.
mode_def cx =                       %\[ Canon CX, SX, LBP-LX (300dpi)
  mode_param (pixels_per_inch, 300);
  mode_param (blacker, 0);
  mode_param (fillin, .2);
  mode_param (o_correction, .6);
  mode_common_setup_;
enddef;
CanonCX := cx;
corona := cx;
dp := cx; % some kind of DataProducts
hplaser := cx;
imagen := cx;
kyocera := cx;
laserwriter := cx;

As you see, there was actually a single supplier of laser engines, so the modes for these printers could be shared.

But PostScript prefers outline fonts to bitmaps and it has its own font format, called Type1, which is device independent and, in particular, resolution independent. This format was kept secret, so that Adobe could sell their high quality fonts. But at some point, the Type1 format was reverse-engineered, Adobe lost the lawsuit against the “perpetrators” and was in some sense forced to open the format.

Shortly thereafter, Blue Sky Research produced the first transformation of the Computer Modern fonts into Type1 format. It was needed in order to provide Textures (the TeX engine for the Macintosh they produced) with a way to use Adobe Type Manager (only able to cope with Type1 fonts) and display font outlines on the screen or print them with as little pixelation as possible.

Rokicki also provided a small utility for transforming the Adobe font metrics into TeX font metrics, so as to be able to directly use PostScript fonts in TeX.

The vast majority of the METAFONT defined fonts have since been digitized and transformed into the outlines required by Type1. This was a necessary step for the later developments.

Enter PDF.

The PDF format was derived from PostScript to allow for device independent viewing or printing. A version of TeX shipping out PDF files was developed by Hàn Thê Thành as part of his PhD thesis.

This requires font files to be (partially) embedded in the PDF file, but this does not invalidate the claim at the top of the document. We can approximately think of PDF files produced by TeX/LaTeX as a combined job of TeX and dvips. The TeX part of this production still relies on knowing nothing about the glyphs, but just about their bounding boxes and related things (italic corrections, ligatures, font spacing parameters).

When a page is shipped out to the PDF file, information is recorded about the fonts needed and at the end of the job, the needed ones are embedded in the PDF file.

No pixelation still requires Type1 fonts or its descendant OpenType format. Also TrueType fonts are allowed, though. This format was developed as a combined project by Apple and Microsoft, in an attempt to become less dependent on Adobe. Apple provided its experimental GX font technology, on which the first version of XeTeX was based. But the original model is still valid for XeTeX and also for LuaTeX. When typesetting, the engine need to know nothing about the glyphs; only PDF production eventually needs them.