Color, Personalization, and Content/Presentation Separation

In 2001, I published my first two-color book. In it, I used red text to focus readers' attention on particular parts of code examples. Since then I've received a steady trickle of comments about my use of color, including this from a recent missive:

Nearly 10% of the male population (and a much smaller fraction of the female population) is one form of color-blind or another. By far the most common is basic red-green color deficiency where reds and/or greens are harder to detect/less vibrant colors.

The dark red chosen as a highlight color in Effective C++ has nearly the same intrinsic darkness as the black it is meant to contrast with and is not an especially vibrant shade of red. As such it is not easily distinguishable from the main text (at least by this particular color deficient male).

Goal #1: I'd like to avoid this problem. Being a software person, I'm going to give in to my inclination to generalize and assume that any given set of color choices is going to be problematic for some portion of my readership.

Consider next syntax highlighting of code. If you use vanilla Visual Studio, you're used to your code being colored in a certain way. If you use vanilla Eclipse, you're also used to your code being colored in a certain way, but probably not the same way. If you use Emacs or some other text or programmer's editor, you're probably used to your code being colored yet another way. I assume that all these code editing environments give you the ability to customize how syntax highlighting is performed, meaning that what you're used to seeing in your editor could be unique to you. If you read a book on a device supporting color, you'd probably prefer that the colors you see match the colors you are used to seeing. Goal #2: I want you to be able to do this.

Addison-Wesley and I recently released PDF versions of my books, and, like many other publishers, we eschewed restrictive DRM in favor of personalization: when you buy a PDF, each page shows your name. The idea is that you're a lot less likely to post your PDF to the world if everybody can see your name, so we do that instead of imposing technical restrictions on what you can do with the PDF you buy.

The need to personalize an ebook for each purchaser means that some kind of time-of-sale processing has to occur, so my feeling is that we might as well go ahead and generate a custom copy of the book at that point. (This is what I think should happen for Fastware! It's not what's done for the PDF versions of my current books.) And as long as we're going to do that, we might as well let you specify how color should be used. By default you might get black text on a white background with red highlighting and Eclipse-style syntax formatting, but if you want yellow text on a black background with green highlighting and syntax highlighting that we allow you to painstakingly specify on a construct-by-construct basis, what the heck, we'll generate it for you. It's not like the software cares what the output looks like, and I'm not about to tell you what works best for you.

For this to be practical, I think there has to be a physical separation of book content from presentation information, much as web page content tends to go in .html files and presentation information tends to go in .css files. From the point of view of me choosing software in which to author Fastware!, I think this rules out programs like FrameMaker, Word, and Writer, because, as far as I know, there is no practical way to get them to automatically (i.e., without human intervention) generate PDF from a document using some custom specification of how formats/styles for paragraphs/characters should be rendered. If that's true, I think we're pretty much talking markup-based approaches, notably LaTeX and DocBook.

Is this a valid conclusion?