Recent notes

(Older stuff is in the notebook.)

Graphics for manuscripts and presentations

July 5, 2009

Journals require graphics in specific file formats with sufficient resolution and font sizes. For example, the Geophysics Instructions to Authors) specifies:

EPS or TIFF file format.
300-600 dpi (dots per inch) for images, 600-1200 dpi for line art.
If color, then CMYK (not RGB).
8-pt sans-serif fonts for graphic text (e.g., axes labels)

First, which format should we use, EPS or TIFF? For reasons described below, my choice is often neither. Instead I use PNG images, and convert to TIFF only when necessary for publication.

The need for graphics in both manuscripts and presentations raises a second question. Can we use a single graphic in both? For graphics with text, the answer is no. Text in graphics for manuscripts will be too small for presentations. I show below how to compute the correct font size for graphic text.

Which format?

I like image formats. Scalable vector graphic formats like EPS, PDF, and SVG permit unlimited zooming without loss of resolution. In practice, however, no one needs unlimited zooming. A factor of 4 (400% zoom) is almost always sufficient. So we need only ensure that our images have sufficient resolution, not infinite resolution.

Moreover, EPS does not support partial transparency, and none of the vector formats EPS, PDF, or SVG support 3D graphics, such as those generated by OpenGL. So an image format may sometimes be the only option available.

Note that neither of the two formats EPS and TIFF required by Geophysics is supported by the program pdflatex. Instead, pdflatex supports JPEG, PNG and PDF formats. Among these three, I choose the PNG image format for most figures.

The widely used PNG format has lossless compression, honors partial transparency, and can easily be converted to TIFF as necessary for publication. In particular, for color figures, the RGB PNG format can be easily converted to the CMYK TIFF format required by Geophysics.

Image resolution and dimensions

The Mines Java Toolkit (JTK) package edu.mines.jtk.mosaic can save graphics in PNG format with arbitrary resolution. To facilitate zooming up to 400%, I save graphics in compressed PNG images with resolution 720 dpi.

So what figure dimensions - width and height - should we use? Many figures have a natural aspect ratio, so that the height depends on the width, or vice-versa. If we know one dimension, we know the other. For other figures, we may choose width and height independently.

In manuscripts, figure width is usually the limited dimension, because the width of a text column is less than its height. Geophysics allows figures with three different widths, specified in picas. Using 1 pica = 12 pt and 1 inch = 72 pt, these widths are:

1-column = 20 picas = 240 pt ~ 3.33 inches
4/3-column = 26 picas = 312 pt ~ 4.33 inches
2-column = 42 picas = 504 pt ~ 7.00 inches

The 2-column width is not specified in the Geophysics Instructions to Authors, but Geophysics does apparently accept 2-column figures, and they appear to be about 42 picas wide when printed. Both the 1-column and 2-column widths work well with LaTeX styles.

In presentations, figure height is typically more limited than width, because the slide width:height aspect ratio is 4:3 (or higher, for wide-screen formats) and because slides often have a title, which further limits the height available for graphics. Therefore, graphics that fit well in manuscripts may be too tall for slides in presentations. And while we can scale any graphics to fit on a slide, this scaling will always make graphic text too small.

Font size

As noted above, Geophysics requires 8-pt sans serif fonts for graphic text, such as axes labels. Legibility in presentations requires that the font size be at least 1/20 of slide height. These requirements are conflicting.

To see why, suppose that we make a 1-column figure with width 240 pt. If the figure height is also 240 pt, then the 8-pt font size is too small, because 8/240 = 1/30 is less than 1/20 of the graphic height, which cannot exceed the slide height.

The disparity is worse in slides with a title, where graphic height is significantly less than slide height. It is much worse for a two-column figure (again, assuming graphic height = width), for then font size is less than 8/504 = 1/63 of slide height.

The best case occurs when the aspect ratio of our graphic is exactly the 4:3 aspect ratio of a slide. In this case, the graphic height for a 1-column figure in geophysics is 240×3/4 = 180 pt, and the 8-pt font size is approximately 1/22 (~ 8/180) of slide height. By the 1/20 rule, the 8-pt font is almost legible. In fact, a 9-pt font would be perfect for this graphic.

But remember that this is the best case. If we need a title in our slide or change the aspect ratio of the graphic, making it either wider or taller, then the 8-pt font may become much too small for the slide.

Here is an example of the best case, where the graphic has the ideal 4:3 aspect ratio. In this example, the title is part of the graphic image.

A graphic with a font suitable for a one-column figure in a printed manuscript. In this best-case scenario, for a 4:3 aspect-ratio, the text is almost large enough for slides.

The same graphic with a slightly larger font that follows the 1/20 rule for slides.

In summary, we should not use the same graphic text for both printed manuscripts and presentation slides. If we do, then graphic text in slides will be too small.

Computing the font size

The Mines JTK creates graphics in on-screen windows, and includes classes with methods to save them in PNG files with higher resolution. It also provides methods that enable the font size to be specified explicitly or computed automatically for either printed figures or slides.

Windows for on-screen graphics can be resized, so that both the width and height of a graphic can be changed interactively. But for any graphic width, it is easy to compute the font size for a figure in a printed manuscript. That is,

fontSizeGraphic = fontSizePrint*widthGraphic/widthPrint

For a 1-column figure in Geophysics, fontSizePrint = 8 pt and widthPrint = 240 pt.

For slides, the computation of font size is more complex, in part because not all of the slide width or height may be available for our graphic. Remember that some space may be required for a title or other elements, or we may want to put two graphics on the same slide. So we first introduce two parameters:

widthFraction = fraction of slide width available
heightFraction = fraction of slide height available

We then compute the font size for our graphic window as follows:

widthAvailable = 4*widthFraction
heightAvailable = 3*heightFraction
if widthGraphic*heightAvailable > heightGraphic*widthAvailable:
  heightScale = (heightGraphic*widthAvailable) /
                (widthGraphic*heightAvailable)
else:
  heightScale = 1
fontSizeGraphic = heightGraphic/heightFraction/heightScale/20

The importance of heightScale in this calculation is not obvious. The purpose of this scale factor is to account for the decreased height of a graphic placed on a slide when the width:height ratio of the graphic exceeds that of the space available on the slide.

The complexity of the font size calculation above contributes to the problem of making slides with legible text. I work with folks who all know when text on a slide is too small, but most of them would solve the problem by trial and error. Or they might be safe and always use fonts that are too large. But this simple solution wastes space that might be better used for other content. For example, axes may be necessary in a display of a seismic image, but are usually less important than the image itself.

Indeed, our desire to reserve space for the most meaningful content is the reason that Geophysics specifies a small 8-pt font for text in figures. But, as noted above, this font size is too small for slides used in presentations.

The calculation of font size for slides is tedious without a computer, and for this reason the class edu.mines.jtk.mosaic.PlotFrame in the Mines JTK will optionally compute the font size for a slide (or printed figure) automatically. With this option, as we grow or shrink the window for an on-screen graphic, the font size grows or shrinks accordingly.

Making slides and figures (for Mac users)

Given a 720-dpi PNG image with correct font sizes, we must often annotate this graphic by adding additional text, arrows, boxes, and so on. We may also need to create a composite of two or more graphics. I use Apple's Keynote presentation software for Macs to do this.

When making a slide in Keynote, I simply drag a PNG image onto the slide. For presentations I use the default 1024×768 slide size, and so must scale my high-resolution PNG images to fit the space available. I accounted for this scaling in the calculation of font size above, so that any text in the graphic will be legible when presented. I then annotate the graphic using Keynote's drawing tools and, for mathematical symbols and equations, the freely available program LaTeXiT.

Because creating slides for presentations is a visual process, I find that using KeyNote and LaTeXiT in this way is usually more efficient than using the Beamer class with LaTeX. For presentations at technical conferences, I export my KeyNote slides in PDF format.

I also use Keynote when making figures for printed manuscripts. For this purpose, I specify custom slide sizes that conform to print column widths:

1-column = 240 pt = 1200 pixels
4/3-column = 320 pt = 1560 pixels
2-column = 504 pt = 2520 pixels

The Keynote widths in pixels correspond to a resolution of 360 dpi, which is sufficient for precise editing, but half the 720-dpi in our images. That's OK, because Keynote retains the original images, and will preserve their 720-dpi resolution when exporting to a PDF file.

I do not use 720 dpi in Keynote, because the maximum size of a Keynote slide is 4000×4000 pixels. A 2-column figure at 720 dpi is 5040 pixels wide, too wide for Keynote. Also, at 720 dpi, the height of a 1-column figure could easily exceed 4000 pixels. Therefore, I use 360 dpi when annotating print figures in Keynote.

When using Keynote to add text to my figures, I select a font size of 40 pt, because 40 = 8*1200/240 = 8*1560/320 = 8*2520/504. In this way, text that I add to a figure with Keynote is the same size as that in the graphic created with the Mines JTK.

Exporting from Keynote to a PDF preserves the high resolution of any text or other annotation that I add to a figure, as well as the 720-dpi resolution of the graphic images. When I inspect the PDF file using Apple's Preview application, it will have a resolution of 72 dpi, and a large width in inches; e.g., 16.67 inches = 1200/72 for a 1-column figure.

In Apple's Preview (included with Mac OS X), we can save any PDF page as a TIFF (or PNG or JPEG) image with a resolution of 720 dpi. If necessary, with Preview we may also crop the image and, for a color image, convert (match) its RGB color profile to a CMYK color profile.

Apple's support for PDF in Preview is wonderful, but the conversion from PDF to TIFF can be tedious when repeated often as we prepare manuscripts. Therefore, I use a small Python program that exploits Mac OS X services to automate the conversion from PDF to PNG, JPEG, or TIFF.

When preparing drafts, I use low-quality JPEG images, which at 720 dpi, still look sharp, but require far less space than PNG images. Because CMYK TIFF images can be huge, even when compressed, and because pdflatex does not handle TIFF, I use this format only when submitting final figures for a journal like Geophysics.

---