All 4 books by Edward Tufte now in
paperback editions, $100 for all 4
Visual Display of Quantitative Information
Paper/printing = original clothbound books.
Only available through ET's Graphics Press:
catalog + shopping cart
Edward Tufte e-books
Immediate download to any computer:
Die visuelle Darstellung quantitativer
Informationen, 200 Seiten, $12
A exibição visual das informações
quantitativas 200 pãginas $12
Visualizzare l'informazione quantitativa
200 pagine $12
《量化資訊的視覺顯示》200 頁 $12
La représentation de l'information
quantitative 200 pages $12
La Representación Visual de Información
Cuantitativa 200 páginas $12
Visual and Statistical Thinking $2
The Cognitive Style of Powerpoint $2
Seeing Around + Feynman Diagrams $2
Data Analysis for Politics and Policy $2
catalog + shopping cart
Edward Tufte one-day course,
Presenting Data and Information
Atlanta, March 28
Charlotte, March 30
Raleigh, April 1
Boston, April 25, 26, 27
Software for typesetting a book
What software do you use to prepare your beautiful books? What's your view of LaTeX, based on Dr. Knuth's TeX?
-- Charlie Guo (email)
Framemaker is excellent for long documents such as books or thesis.
-- JeffT (email)
From the phrasing of your letter I know you're looking for a response by Dr Tufte, however I couldn't resist putting in my two cents-worth.
In my opinion, TeX/LateX is a superb system for typesetting books. Examples of what can be accomplished with this system can be found at The TeX users group showcase page. While I don't believe Dr Tufte uses TeX/LateX (he has mentioned using a visual approach to design man times and TeX/LaTeX is markup based) I do believe that TeX/LaTeX/ConTeXt is/are capable of producing books of the same or better quality.
-- John Walker (email)
Another recommendation, with regards to LaTeX, is to look at the "memoir" package -- it is designed to be a highly customizable package for doing book layouts, whereas the base LaTeX packages, being just the base packages, pretty much only do one default layout. The manual (pdf file here) is also well worth reading for its introduction to the concepts of doing book layouts, even if you never intend to use the software -- it's about two thirds "why you might want to do things this way and what to consider in making layout decisions", and one third "how to do this with LaTeX/memoir".
There is a significant potential disadvantage of LaTeX for doing books with lots of graphics -- it's designed to do most of the page layout decisions automatically, so that the author is free to worry about the content. In general, for text-heavy books with sparse small figures, this is a good thing; it does what I consider to be an excellent job of this, better than most people would do if they were doing the layout manually. However, that doesn't work very well for graphics-heavy books such as E.T.'s -- on those, the layout of which figure is on which page starts to matter very strongly to the presentation, as do the spatial relationships between the figures and captions on the page, and there is a strong possiblity of graphical interconnections between figures even beyond the matters of layout. For that sort of whole-page multifigure composition, LaTeX is the wrong tool for the job, and while there are ways to make it work, it becomes a process of fighting the tool rather than being helped by it.
However, if my understanding is correct, most of this comes from LaTeX, not TeX itself. That is, the mostly automatic layout features (which work so well in text-heavy documents) are largely part of LaTeX's macros, not part of the TeX foundation on which they are built. And thus it would be quite reasonably possible to build a system on top of TeX -- whether general-purpose or a very limited macro-set that one uses just for a single book -- that would be tailored for doing visual layout of figure-heavy books. Even then, I suspect that it would need to be closely tied to a graphical front-end to be efficient to use.
-- Brooks Moses (email)
'Typesetting diagrams?' - Response to Software for typesetting a book
Is there an equivalent to TeX for creating block diagrams and flowcharts? I presently have to do these in Powerpoint or Visio, neither of which allow any intelligence to be embedded in the drawings. Make a change, redo the entire layout through a numbing series of clicks and drags. I'd like to create a text file that describes what connects to what, perhaps add some overall style information, and then have the computer create the diagram. I thought about GraphViz from Bell Labs but, according to its website, it is not intended for this kind of use.
-- Ravi Narasimhan (email)
Response to Typesetting diagrams
There are several ways of creating block diagrams and flow charts within the TeX framework.
My favourite tool is PGF and TikZ, a powerful, well documented macro package.
You can find a few examples here:
For an overview of other alternatives, I have an entry about it on my web page. Most of the tools are general drawing tools capable of many kinds of graphics. For MetaPost there exists a nice macro package called Blockdraw for creating block diagrams.
-- Kjell Magne Fauske (email)
Response to 'Typesetting diagrams?' - Software for typesetting a book
On the surface, GraphViz seems tantalyzingly close to what you're looking for, Ravi,
but its true strength lies in the algorithms it uses for calculating the positions of nodes
and edges when drawing arbitrarily complex graphs in an automated way. It may not be
very helpful for the style of diagram I think you envision.
Although it's also not exactly what you're asking for, there is a distant
cousin to Visio available on the Mac called OmniGraffle which might be what you're
looking for. (I am not affiliated with the company other than as a happy
customer.) Unlike PowerPoint or Visio, OmniGraffle does a very nice job of keeping your
blocks and arrows connected in an intelligent way and it provides very helpful interactive
layout hints that are difficult to describe in words but make complete sense when you see
them in action. If you have access to a Mac, this would be a good option to try.
Both GraphViz and OmniGraffle are good tools for creating the kinds of diagrams
described in Links, Causal Arrows, Networks.
-- Matt Huyck (email)
Regarding the question about generating diagrams for TeX:
There is a package for LaTeX called "TikZ" which exposes several small "languages" in the form of TeX macros for
creating different kinds of graphics. Each tiny language is a well-crafted set of TeX macros directly related to the graph at
hand. For example, the finite state automata portion of TikZ has primitives like "node" and "edge" and quantifiers such as
"state" and "accepting". Position can be finely controlled, but connecting different elements is done largely by the software
itself, allowing the user to define graphical objects in relative terms such as "right of", "northeast", and "bend left".
Some other pros of TikZ are things like "foreach"; instead of constantly laying down repetetive graphics or copy-pasting as
you would in a program like Visio, TikZ leverages language designed to be close to English in order to allow you to
quickly and easily express quantities in your graphics. Overhead, such as precise positioning of lines to link graphical
elements, is handled by the software instead of burdening the user. In essence, TikZ gives you what I think is the best
diagramming tool available, natural language, letting you express things like "create 100 light green nodes vertically, move
right and create 100 light blue nodes vertically, then for each green node, draw a line to the corresponding blue node",
instead of making you point and grunt with a mouse over and over.
If you have a standard LaTeX installation, TikZ and the underlying PGF library may already be installed. If not, they can
be obtained here:
The author, Till Tantau, includes a lengthy manual which helps as a reference, though I must say that introductory material
is a bit lacking, mostly due to the immensity of the two packages.
Several beautiful examples of the diverse things TikZ can do (with TeX source code) are enumerated here:
TikZ is a vast and complex work, but learning it is worth the effort if TeX is your preferred method of composition. As I
said, introductory material is a bit lacking; I find the best way to learn TikZ is to check the manual to see which sub-
language of TikZ macros is most applicable to the graphic you wish to draw, read the section a few times, and then peruse
texample.net for similar graphics to act as a base.
-- Jorden Mauro (email)
Starting with LaTeX (and TeX) can be a bit daunting for some, and it takes a bit of a mental shift to go from GUIs to text
"commands". There's a useful software package called LyX that gives you a GUI where you get most of the advantages
of LaTeX in a convenient way:
It's then possible to learn how to do things "manually" as needed or desired.
-- David Magda (email)
I have read Prof. Tufte propose several times that the ideal would be to have a document
editor, instead of simple text editors. I imagine a document editor being a software that
lets one typeset text, include tables with the possibility of doing calculations directly on
them, include and edit images; basically integrate the functions of your regular MS Office
package into a single program.
Is something like that being tried anywhere? Do you think it will be feasible, or even
desirable, in the future?
I think it would be great to type a document and be able to do calculations directly on it
(I've heard people use Excel that way, but it seems a less than optimal solution), but I
imagine that the computer requirements to do something like that must be quite high.
I would love to hear your opinion.
-- Javier (email)
Something like the document editor does already exist in the form of Emacs with Auctex plus Sweave. There are various options, but essentially you typeset an article or book with a simple set of commands and, in newer TeX distributions, you have instant preview. With R/Sweave and xtable, you can do complex statistical calculations and insert them directly in tables in your document. It is iterative in that it has the compose, compile, preview cycle and as such the biggest 'drawback' is that it is not WYSIWYG, however I am not sure if that WYSIWYG is the best interface in this case. That is not to say visual design is not critical, simply that direct visual manipulation, which is often what people mean by WYSIWYG is not the only way to do visual design - e.g. typographic design prior to the computer was often iterative in the same way that TeX proceeds; change the leading/command, preview the page, change it again, preview the page etc.
In addition, it may be difficult for the WYSIWYG application to know if you want to do a calculation or to simply represent the equation you are entering. That implies a mode change ( text to calculate) or extra command. So we have the need to change modes implicit in the design from representation to action, this is in part the reason for different applications - one calculates, another produces text etc. How you change this 'operational' context depends on many factors -interface design, CPU power, historical trends in OS/Application design.
In Unix the functions were all present and we could pipe calculations together (using Awk), draw graphs (using grap) and typeset a document (using troff). The fundamental idea was data being operated on by the operating system to produce whatever was needed. The applications were designed to interact and the whole was greater than the sum of it's parts - but it could hardly be said to be user friendly. With Dos, windows and Macintosh, the limited memory and CPU speed meant that switching operational contexts (calculate, page layout etc) required shifting code in and out of memory. The easiest way to do that was to encapsulate code into applications. Early on the models for applications were similar to one tenet of Unix - do one thing well, but lost the other tenet of being able to talk to one another. That was easy to understand since, in a sense, the applications were never in the same room at the same time to talk to one another. The lack of multi-tasking meant that communication was via disk files. The biggest break with these application based software models was the NeXT OS that tried to replicate the UNIX command line environment in the NeXT GUI. It did this by making sure that applications offered 'services', an attempt to replicate the convenience of unix pipes in a GUI. It's unfortunate that services have become a little used aspect of OSX but it may offer the best path to the WYSIWYG Tufte Document editor by way of offering services that will interpret or alter the text or image under the cursor in an RTF editor, or InDesign, or better yet a WYSIWYG TeX editor ( the tex language has a much richer command set for producing beautiful books than rtf or InDesign). This is still in the future, but Emacs+AucTeX+Sweave/R is here now and so the Tufte editor is already here if you don't need direct visual manipulation of objects in your document.
-- John Walker (email)
The One True Document Editor
Poster suggested one grandiose program to typeset text, perform mathematics, pivot
tables, project slides, and generally be the One True Document Editor for any page-
I humbly submit that such an environment was in fact available before the advent of
the WYSIWYG editor. In the UNIX text editing system, all data is in ASCII (later UTF-8
in Plan 9), and the writer has at hand a wide variety of customizable tools, to slice and
dice the data or text, and to then recombine them, in any way conceivable, without
relying on which features a GUI programmer saw fit to make available via drop-down
This text editing system also supports the generation of (La)TeX documents, so far the
best (maturity and depth) and most widely available (free for Windows, Linux, MacOS)
tool for typesetting mathematics and integrating graphics with technical papers.
Evidence of its utility may be found in its widespread use by academia for publishing
The UNIX text editing system, and (La)TeX, uses encoded source to generate
documents, instead of trying (usually poorly) to both display the final document and
support editing at once. The advantage of this approach---text-based encoding with
separate generation and presentation steps---becomes apparent when one must make
widespread structural changes which the GUI tool does not support, or other
transformations of the text which may be automated in text form, but usually aren't in
commercial tools since they're too rare for publishing houses to justify including and
-- Jason Catena (email)
As it happens I taught myself LATEX this summer to get some lecture notes in shape. Having originally used the LATEX Book class I have now moved to the memoir class and can thoroughly recomend it. The attached is a two page spread chosen pretty much at random and it shows that you can integrate text, math and figures easily with a pretty professional looking book layout that is the default in memoir.
The learning curve is reasonable and all the fancy headers, figure numbering, contents etc etc defaults are well chosen. The TEX set up on a PC was easy and free - I use the LED editor and the MikTex 2.7 package.
This is typeset onto B5 paper in PDF format and I have now found a pretty good quality short print run digital printers in the UK (this is not POD which is generally low quality, the shortest print run is 50 copies) to produce final book output. I'll keep you posted how the whole process goes.
PS The attached JPG is deliberately low resolution - its mainly to show the two page spread.
-- Matt R (email)
Here is a nice interview with Robert Bringhurst, author of the book 'Elements of typographic style'(http://www.typebooks.org/i-r_bringhurst.htm). He comes over as a passionate and uncompromising person dedicated to high quality in typesetting and book design more generally.
-- Matt R (email)
| Threads relevant to typography, book design, and publishing:|