Here's an update on my "zero markup" experiment. The idea was to create a document in UTF-8 text with no markup. A program then "sees" what a human would see: poetry blocks, epigraphs, block quotes, footnotes, etc. and render the other-than-text output accordingly. I wrote enough code to produce three books that are currently in smoothreading at DP. The goal was to make something that would be very easy for post-processors to use, especially at DP where the backlog is significant. I'm not claiming success on this one, though it does work. For one thing, the plain text cannot represent things like font size changes. Having the title line in a larger font on the title page is an example where that would make a visible and welcomed difference. The zml approach, taken purely, will have no "rend" attribute on an element. I allow the user to add presentation hints to any line that is centered, but it feels like I'm breaking the rules. There are other complications. As it's written, it generates valid and attractive HTML and the text can go up as well to PG without modification. But I suspect the HTML wouldn't make it through the PG ebook chain that creates the .epub and .mobi files. I cannot make any single HTML that is correct as input to both epub and mobi generators without resorting to a very low common denominator (such as nbsp's for poetry). I could have the generator make 3 separate files to be used for HTML and as inputs to epub and mobi generators. But PG understandably won't take that nor will they take actual .epub or .mobi files, also for good reasons. My choices are (1) abandon this and use RST for what's going to PG, or (2) find out what HTML will make it through PGs epub and mobi creating software so it doesn't fall out and use the text version instead. DP has a project underway to define the HTML subset that makes (2) work, which is very important to their PPers, most of which will not use PG-RST. PG-RST also isn't a good solution to produce books for other-than-PG repositories, such as for PG Canada. Bottom line: I have written a generator that takes a UTF-8 PG-submittable text and generates HTML--but that HTML is good, right now, only on a browser and not as a suitable input for any ebook-reader generators. I don't know where I'm going with this from here, if anywhere. --Roger