Charles Petzold

The Book Pipeline

March 5, 2006
Back in NYC

How is it possible that a thousand-page book hits the streets only a few months after an author finishes writing it? The simple answer is that the publisher (Microsoft Press, in my case) doesn't wait until the author finishes writing before starting the editing and production process. It's a pipeline. I submit chapters in sequence as I finish them, and then my editors get a crack at them. They turn on the Track Changes feature in Microsoft Word and start editing. My grammar is repaired, obscurities are clarified, transitions are smoothed, and passive voice is eliminated. A technical editor checks out the code and the technical content of my discussions.

At that point, the edited .DOC files are returned to me for "author review." My basic job now is answer questions that may have been left as comments in the file, to make sure that editing didn't alter the meaning of what I was saying (which happens only occasionally), and to check that the code still works. These author reviews are important because it's the best time for me to make substantial changes. The next time I see the chapters, they are PDF files that look just like the final book. I am discouraged from making major changes, and I can't actually change the files. Any fixes I see I need to describe in words ("Page 5, Paragraph 3, First Line: Change 'horizontal' to 'vertical'.")

I have now reviewed the edits of the first seven chapters. Those of you who are following my progress on the book (and perhaps biting your fingernails as much as I'm biting mine) can track my progress in the Table of Contents section on my Applications = Code + Markup page.

The most disturbing thing that can happen during author reviews is to discover broken code. Programs that worked fine when the chapters were originally submitted no longer work, and the code now has to be fixed. Sometimes it's a good thing. I knew that the TextRange class used in conjunction with the RichTextBox document had acquired handy Load and Save commands, so making that change was a pleasure.

I also knew that the DatePicker control was being removed from the first release of WPF, so I had to change a program that used that control to a TextBox and DateTime.TryParse. Not quite the same!

I personally think it's scandalous that WPF has no date or time controls. Fortunately they haven't removed the feature where you can use XAML to set the current date and time in a button and then swing it like a pendulum.

In checking out programs in Chapter 6, I discovered that the Name property defined by the FrameworkElement class had somehow acquired a bunch of restrictions. The text string cannot contain embedded blanks, it cannot begin with a number, etc. Of course, the Name property is used in XAML as a variable name for objects, but I was using it in straight code, where it's used to locate elements through the FindName method. (Perhaps they've tried to overload the Name property with one too many uses.)

The scariest problem involved a program in Chapter 1 called GrowAndShrink.cs (and here's the GrowAndShrink.csproj project file). This program simply increases the Width and Height properties of the window by 10% when you press the Up key, and decreases them by 10% when you press Down. The window is kept centered on the screen.

If your display resolution is set to 96 DPI, the program works fine. With 120 DPI, however, it makes sudden jumps in size. In the course of exploring this problem, I wrote ClickToMakeBigger.cs (and the ClickToMakeBigger.csproj project file), with the following method:

The program displays the current values of these four properties in its client area. This program also works fine on 96 DPI displays, but does strange things with 120 DPI. I don't know what the problem is, but pixel dimensions are getting mixed up with device-independent sizes. It's surprising that a bug with such basic properties isn't having more of an effect throughout the system.