Project Comments Checklist
Here are some common issues that proofers and foofers have questions on. Many of these vary by project--or are not explicitly addressed in the Guidelines--and therefore require a PM ruling. Please address these issues, if applicable, in the Project Comments.
Proofing Issues
Unusual Characters
If any of these unusual characters appear in your projects, you should say how you'd like them handled. See the Recommended custom characters list for more.
- Mid-dots. If your project has mid-dots, please state whether they should be proofed using the mid-dot OR as a standard period. You may also want to specify how spaces before or after a mid-dot should be transcribed.
- Prime and Double Prime. These symbols (′ and ″) are used in writing coordinates, in math, and to mark units like feet and inches, or minutes and seconds. Because these symbols are not included in any palette, you will need to add them as custom characters.
- Other unusual symbols. If your project includes symbols like the multiplication sign (× ) These often occur in dimensions, as well as in mathematical formulas. Please state a preference for the × symbol from the dropdown menu, or the standard letter x (lowercase) or X (uppercase). It may be helpful to add any unusual characters used frequently in the text to the "Proj" character picker, even if they are already in one of the standard pickers.
Other Proofing Issues
- Some books use rows of asterisks instead of ellipses. It is good practice to say how you would like these handled. The most common approach is to leave them as asterisks.
Formatting Issues
Mandatory Formatting Issues
These items are specifically called out in the Guidelines or the Library of Formatting examples as things formatters should always ask about if they're not mentioned in the Project Comments. If you don't address them in your Comments, it will delay formatting and may result in inconsistent formatting.
- If the project is a book of poetry, the project comments should state explicitly whether each poem should be treated as a chapter or a section. (LOFE) In general, for any book without a table of contents or a complex or multi-level table of contents, it's a good idea to be explicit about how you'd like chapter and section breaks handled.
- If your project includes any poems with attribution, the PM needs specify whether to put the attribution in the same nowrap as the poem or in a separate nowrap. (LOFE)
- If your project has illustrations above the chapter headings, you need to say explicitly how you'd like them handled. (LOFE)
- If your project includes italicized dialogue, you should specify how punctuation should be handled around a non-italicised interruption like "he said." (LOFE)
Optional Formatting Issues
These items have a default treatment that formatters will follow unless you state otherwise in the Project Comments:
- Formatters will treat blackletter and other font changes as normal text unless you specifically ask them to use the <f> tag. (Guidelines)
- If your project includes small caps, possessive small caps (e.g. "THORPE'S") will be treated as printed or, if unclear, the possessive will be included in the inline tag. (LOFE)
- In poetry, a row of dots will be treated as a thought break unless you specifically ask for it to be treated as an ellipsis. (Guidelines)
- Any long dashes in an index will be left as is and treated as main entries. (LOFE)
Ambiguous Formatting
If there is any ambiguity about how to handle any formatting task, be explicit in the Project Comments. Otherwise you are almost certain to end up with inconsistent formatting. Example include:
- Is it a chapter break or section break? If the book has any divisions beyond simple chapters, it is better to be explicit.
- Is it a table or a list? Anything that might be interpreted differently by different formatters will be, unless you address it in the comments.
- If there are block quotations in the book that aren't clearly indented and set off by spaces, please mention it in the comments.
Other Issues
- If the page scans are larger than normal (e.g. over 100 kB) and the large size is necessary, it's good to warn people in case they're on a slow or metered connection. For instance: "Please note these images are somewhat larger than normal. There was no way to take them to less than this while maintaining clear text. The image files are less than 150k each."
- Projects with substantial handwriting should address this in the Project Comments.
- If your project includes illustrations containing text other than captions, say whether you would like that to be transcribed. The recommended approach is to include as much text as possible, to help postprocessors create useful alt text.
- All page headers will be discarded during proofing, unless you specifically say you would like proofers to treat page headers as sidenotes.
Reminders in Project Comments
Some PMs find it helpful to mention certain things in their project comments, even if it is already covered in the Guidelines. Some common examples are mentioned below. If you do include a reminder, consider adding a link to the relevant section of the Guidelines or the LOFE.
- Projects including musical notation should link to the Music Guidelines.
- Projects including metrical drama may wish to link to the appropriate section of the LOFE.
- Old-fashioned Spellings. It never hurts to emphasize how you'd like these handled. One suggested phrasing (via grythumn): "Do not modernize the spellings. Please correct long-s to regular s, but leave u/v and i/j issues alone."
- Dashes at the end of lines in poetry do not have to be clothed
- Proper treatment of fractions
Help with Project Comments
For help writing comments for your project, you can send an email to the dp-format group by following the link on this web page. One of the formatting-round experts will contact you.
See also
- the Write Project Comments section of the PM FAQ
- Common exceptions to the guidelines: for examples of exceptions to the guidelines that have been used in the past
- The Recommended custom characters list.