here's a quick review of my proofing system... the best overview is to look at this screenshot:
you can see there is plenty of room for buttons, which can perform a wide multitude of actions... if you've got a cinema-screen, you can see it live:
proofers compare the scan against an .html-field. (the scan is on the left; the .html is in the middle.) if a change needs to be made, that change is done using the text-field, there on the right, which then generates as its output the .html-field in the center. the edit-field is not "what you see is what you get". but it's what creates the .html, so its representation _should_ be output that essentially matches the scan. of course, the users who don't have cinema screens can't have all three fields displayed simultaneously, so you'll have to swap the .html-field and edit-field as needed. the initial proof is with the .html-field, and the proofer clicks an "edit" button if necessary, which swaps out the .html-field for the edit-field, and the swap is reversed once the text gets edited... and yes, everything we need to represent _can_ be entered with a plain-text edit-field. lines of poetry can be indented with the correct number of spaces. even paragraph indents can be entered with spaces. likewise, i prepend "> " to the lines of a blockquote. a centered line of text is prefaced with _one_ space. headers have 4 (or more) lines above, and 2 below... (different header levels have 4, 5, 6, etc. lines above.) tables are discerned by their multiple internal spaces. once you commit to this methodology, you find that it's rather easy to create a simple way to make it work. likewise, the code that converts the text-field into the .html-field is rather straightforward and easy to create. if you need any help with any of these things, just call... -bowerbird