Review of illustrations by Casey
From Maze
In general, I think the strategy should be to include figures only when necessary, when they make a strong point and/or support the text substantially. I see the book has having a mixture of diagrams, photography, and screen shots.
Contents[hide] |
10 PRINT Screen Shots
Based on what I've seen, I'm assuming the visual representations of 10 PRINT running will be created through an emulator. This looses much of the feeling of the CRT, but brings clarity. We can work with the blue ink color to represent this in an approximation of the original C64 color quality.
The "Ports and Variations" section is a clear place for many of these images.
"Expanding 10 Print" should have screens to make these subtle code changes more clear to the reader.
I'm not sure the best place yet, but there should be a time lapse of the program running. This makes the generative nature of the maze creation clear to the reader who won't run the program herself.
I don't feel the lead image in the Maze chapter is needed: http://weizenbaum.mit.edu/mediawiki/index.php/File:Maze-Solve.jpg
Diagrams
Diagrams, such as those in "Algorithms and Action" section can be redrawn to be consistent with the book design. They should remain as vector files to reproduce cleanly.
Is it significant that the ASCII maps in the Mazes section are ASCII. They would be much easier to read if re-drawn. I understand that people did create ASCII versions to be able to send them around, but is that encoding significant to the substance of the chapter? From the text, the answer is "yes". These can be re-created in the mono typeface we select to match the rest of the book design. But, doesn't one make the point? Why include two?
I'm not sure what to do about the hand-drawn Zork map in the Mazes section. How will be get permission to use it and it's currently not high enough resolution for print.
Photos
Somewhere, probably the "Commodore 64" chapter, we should have some high-resolution and well-lit photos of the C64, particularly to have a macro shot of the diagonal lines. Who is the best photographer in the group? Ian? Me? FYI, the Wikipedia photo has a CC attribution license so it can be used.
What about a photo of the way the graphics look on a CRT or a video of the program running for the web?
We can run tests of the photos as blue and black duotones. I think printing them with only black is a lost opportunity to make the book feel unique.
I'm excited to take a few high resolution photos of the original program pages in the manual and run those as a full spread with the spine of the manual in the spine of our book. This gives the physical context of the program, how the program was communicated. This is the book in a book technique.
Typography
All code should be set in a monospaced font an indented. I considered using the C64 font by commissioning it (if it doesn't already exist) but I think a typeface that's more appropriate for the printed page will be better. Every time 10 PRINT reference appears in the body, it could also be in this mono font. (Maybe not, might be jarring for the reader; it's best to try and evaluate the comparison when the time comes.)
This book has many code examples, the mono font should be selected carefully.
The "Token-by-Token Explanation of the Program" section dividers could each present the full program, with blue used to highlight (a solid blue box behind the black letters at 50% blue) the token the paragraph refers to.
