Jargon related to The Guidelines
Organizations and specialized activities develop their own sets of specialized terminology, or jargon, and DP is no exception to that. Accordingly, we have developed some FAQ-like Jargon Guides you can access in order to learn some of our lingo.
The LONG DP Jargon Guide, and the Jargon Guides related to The Guidelines, User Roles, and Workflow contain acronyms and terms you will likely encounter as a new volunteer at DP.
Other Jargon Guides contain terms that are a bit more specialized. The Group Activities Jargon Guide will become especially relevant to you if you start using Jabber. The remaining Jargon Guides shown in the Jargon Navigator box relate to the specific activities mentioned in their titles.
If you come across an acronym or term that isn't mentioned in one of these Jargon Guides, please ask about it in one of the DP forums.
Detailed suggestions on how best to add and edit Jargon-related information can be found at Help:Jargon.
See also the actual, authoritative Proofreading Guidelines and Formatting Guidelines, and the DP Wiki pages Proofreading Guidelines Explanation, Formatting Guidelines Explanation, Proofing Examples, and Formatting Examples.
block quote
A block quotation is a long quotation (typically several lines and sometimes several pages) and is often (but not always) printed with wider margins or in a smaller font size—sometimes both.
Headers and footers contain text such as the title of the book or chapter, and the page number. If headers or footers appear in the OCR at the beginning of a project, they should be removed. A page header may contain a short summary of the page's content, which is unique to that page, so the Project Manager may ask that the unique header be retained in proofing.
"clothing"
Clothing refers to the process of removing spaces or intra-paragraph line breaks from around hyphens or dashes.
Hyphens or dashes which have spaces or intra-paragraph line breaks on either side of them are referred to as unclothed or naked. Occasionally the terms "partially-clothed" or "half-unclothed" are used to refer to dashes which are clothed on one side but not the other, such as might be the case with a dash at the beginning or end of a line of poetry.
"complete sentence"
On occasion, the phrase "complete sentence" can be used in Forum postings as a kind of shorthand reference to the "entire sentence or paragraph, ... phrase, title, or abbreviation" concept referred to in the (especially Formatting) Guidelines.
For example, you might see something like the following in a Forum post:
- The closing italics tag () would go after the colon in "General Information:" since it's a complete sentence.
Use of the "complete sentence" phrase in this manner is discouraged because it is inaccurate (or at least, inexact), and can be confusing to new DPers since "General Information" is not a sentence in a grammatical sense. It has been suggested that either "complete entity" or "complete expression" might be better used to relatively-generically refer to the Guidelines' general concept of "entire sentence or paragraph, ... phrase, title, or abbreviation."
diacritical mark/diacritic
Diacritical marks, sometimes referred to as diacritic marks or the "short-hand" term diacriticals, are small marks found above or below a basic character which change the pronunciation of that character. For example, the acute accent over the "e" in the character "é" is a diacritical mark.
Characters with diacritical marks may be proofed different ways in DP projects. If the needed character is available in an active character suite, it may be directly input or selected from a picker. If it is not in an active character suite it should be represented by the method described in Proofing Guidelines—Characters with Diacritical Marks.
ellipsis
An ellipsis (plural ellipses), also called a "period pause," is a typographical mark made up of three or four dots, usually used to indicate that something is missing from a text.
This Wiki page assumes you are proofing or post-processing an English project. The rules for ellipses are different for languages other than English.
Proofing
Ellipses are one of the few instances where volunteers may be asked to enter something in the proofing rounds different than what is on the printed page. Proofers should carefully review the Period Pause section of the Proofreading Guidelines and the examples given there.
However, there are some situations not covered by the Guidelines. See this discussion thread for many examples. Below are some examples of how people have solved these complex ellipsis issues, but remember: most of these situations are unusual enough that you should ask in the project discussion thread and leave a **note for the postprocessor.
Line and page breaks
Because an ordinary mid-sentence ellipsis acts as a word, with a space before and after, no special treatment is needed for a three-dot ellipsis that occurs at the beginning or end of a line or page. Treat it as you would any other word.
I turned around ... and there she was!
is fine, and so is:
I turned around ... and there she was
However, if a line ends with closing punctuation and the next line of the same paragraph starts with an ellipsis, you need to bring the ellipsis up to the previous line to join it into a four-dot ellipsis:
I turned around. ... That's when I saw her.
should be proofed as:
I turned around.... That's when I saw her.
In some older texts, the three dots of the ellipsis itself may be split across lines:
You trowed I was some copper coin . . . I am a knight of Spain!
In this rare case, the ellipsis needs to be joined together on the first line.
Page breaks
When an ellipsis comes at the beginning or end of the page, the rules are the same, but what proofreaders need to do may be different.
Because we don't move text or punctuation from page to page, if an ellipsis needs to be moved up from the first line of a page to the last line of the previous page, do not move it yourself; leave a [**note], on both pages if possible, and the postprocessor will rejoin them. Leave a full [**note]; do not simply use an * as you would for a dash that needs joining.
Ambiguous sentence endings
The Guidelines say to add a fourth dot when an ellipsis comes at the end of a sentence. But it's not always clear whether that's the case, for example, when the word following the ellipsis is "I" or a proper noun, or the start of a new line in poetry, where it would would be capitalized either way:
The only solution is to try to figure out the intent of the author. If the author themselves used a mix of three-dot and four-dot ellipses, this can give you a strong hint; otherwise you are going to have to use your best judgment. Remember: because the postprocessor has the final say, always leave a **note if there is any ambiguity.
What does it mean to end a sentence?
Final punctuation does not always require a complete sentence. When the sentence is cut off, as by an interruption, most PMs and PPs interpret that as "the end of a sentence," requiring a fourth dot. So, in:
"Arthur," I said, "I don't think you understand...." "I understand perfectly!" he broke in.
the first sentence gets four dots even though it was interrupted rather than "finished". However, some project managers do not agree, so if there's any doubt, ask and leave a note.
Ellipsis + closing quote
A closing quote does not count as an "ending punctuation mark" under the Guidelines. A sentence that ends with an ellipsis, then a closing quote, may also need a fourth dot added, just as it would if it weren't quoted.
Closing quote + ellipsis
When an ellipsis happens after a closing quote:
of lying." ... They
opinions differ as to whether there should be a space between the closing quote and the ellipsis; ask in the project discussion and leave a **note. However, there is general agreement that the ellipsis should not be moved inside the quotation--leave it outside, with three dots, and a space afterwards.
Ellipsis followed by non-closing punctuation
This is common in bibliographies, for instance:
The means of preserving beauty ...; by a lady, &c. London, Crosby & Co., 1811.
Because the ellipsis only combines with closing punctuation, it is a three-dot and not a four-dot ellipsis; but the Guidelines also don't allow spaces before punctuation like commas and semicolons, because otherwise they might wrap to the start of the next line. So there is definitely no space afterwards; PMs disagree on whether to put one before; ask in the project discussion and leave a [**note].
"Final" punctuation in the middle of a sentence
In older texts it is common to have something that would normally be "final" punctuation occur in mid-sentence, with no capital letter following. When this includes an ellipsis either before or after:
in the world! . . . but no one
or
within me, O nymphs . . . ! within me,
there is not a clear consensus. In most cases, the answer is to ask in the project thread and leave a **note for PP.
An easier case is when the final punctuation is a period after an abbreviation:
the last parliament, etc. ... they are of opinion that the
Here, there is no end of sentence, and there is a space between the abbreviation and the ellipsis.
Interrupted end of sentence
Another ambiguous situation:
If, in short, it is external to the terms, how can it possibly be true of them? [Is it the 'intimacy' suggested by the little word 'of,' here, which I have underscored, that is the root of Mr. Bradley's trouble?] ... If the terms from their
Here, without the bracketed aside, the Guidelines would call for the last sentence to end: "true of them?... If the terms" but due to the interruption this is not possible. The solution was to use a normally spaced three-dot ellipsis and leave a [**note] for the PP. A similar situation may arise when a bracketed footnote marker comes between the end-of-sentence punctuation and the ellipsis.
Ellipsis used for elision
Where an ellipsis is used instead of a dash to indicate letters left out of a word:
I called the next day on Mr. J... for his opinion.
treat the ellipsis as you would a dash, with no space before--but leave a [**note].
Post-Processing
The post-processor can represent an ellipsis either with three or four period/full stop characters, as in the rounds, or using the Unicode ellipsis character, "…". There are benefits to both approaches.
| using three dots | using one character |
|---|---|
|
|
The ellipsis character can look particularly bad in a monospace font when combined with a period to create a four-dot ellipse. For this reason, most post-processors prefer to use periods to form ellipses at least in the plain text version of a project.
If you do decide to use the ellipsis character, it is important that any four-dot ellipses are handled correctly; this means paying attention to whether the single period comes before or after the ellipsis character.
Ellipses in ppgen
This is a method that can be used with ppgen to generate ellipses using the ellipsis character in HTML and three single dots in the text output.
1. In the source file, represent each ellipsis with an opening curly brace, a ellipsis character, and a closing curly brace:
{…}
2. Add the following two dot commands to your source file:
.sr h §{…}§…§
.sr t §{…}§...§Using the bracketed characters in the source file will ensure that the text file will be wrapped properly, because both
{…}
and
...
are three characters wide.
Em-dash
The em-dash (—), also known as the em rule, indicates a sudden break in thought—a parenthetical statement like this one—or an open range (such as "John Doe, 1987—"). The em-dash is used in much the way a colon or set of parentheses is used: it can show an abrupt change in thought or be used where a period is too strong and a comma too weak.
The em-dash is defined as one em in width. An em is equivalent to the point size. Thus, in 9-point type an em is 9 points wide (as well as 9 points high) while the em of 24 point type is 24 points wide (and high), and so on. By definition, this is twice as wide as the en-dash in any particular font.
Monospaced fonts such as Courier or DP Sans Mono that mimic the look of a typewriter have the same width for all characters. Thus, they have only a single hyphen glyph, so it is common to use two monospace hyphens strung together--like this--to serve as an em-dash.
That is how it is done at DP. Since every project has a plain text version, the end result will be in a monospaced font. Thus the term em-dash is used to mean two hyphens --, as explained more fully in the Dashes, Hyphens, and Minus Signs section of the Guidelines.
Sometimes at DP the term "em-dash" is used to refer to a dash which is twice as long as an em-dash (like this: ——), but this would be more properly termed a "two em dash." At DP it is often simply called a "long dash."
This information was shamelessly copied, in part, from the Em-dashes section of wikipedia.
En-dash
The en-dash (–), also known as the en rule, is one en in width: half the width of an em-dash, but longer than a hyphen. The en-dash is commonly used to indicate a range of numbers, or to represent a mathematical minus sign.
- See pages 21-25
- -14° (for 14° below zero)
- For ages 3–5
- X - Y = Z
Monospaced fonts such as Courier or DP Sans Mono that mimic the look of a typewriter have the same width for all characters. Thus, they have only a single hyphen glyph, so a hyphen (-) and an en-dash (-) are represented by exactly the same character. The use of the term en-dash at DP tends to refer to the use made of it. So the above examples would all be called en-dashes. The below examples would be called hyphens.
- New York–London flight
- Mother–daughter relationship
- The McCain–Feingold bill
The en-dash, like the em-dash, is not included in our character suites, and therefore cannot be used during proofreading. In the rounds, a single hyphen is substituted for an en-dash character.
More information on hyphens, en-dashes, and em-dashes is available in the Dashes, Hyphens, and Minus Signs section of the Guidelines.
epigram
footnote
- See the Formatting Guidelines and the Library of Formatting Examples for instruction on footnote formatting.
Other pages:
 |
This is a disambiguation page. Please do not add textual content, but only links to related pages in the DP Wiki. There are multiple pages with closely-related and similar-sounding subjects. Don't be shy to tidy up and combine related pages, or break apart things that sound alike but mean different things! |
gesperrt
Gesperrt is the term used to refer to s p a c e d o u t text.
This was a typesetting technique used to emphasize a piece of text in older German (and some Italian and other languages) books. Thus, g e s p e r r t served pretty much the same purpose that italics and bold do today.
In the example below, the English phrase "Signal Post Hill" is typeset gesperrt to emphasize it as a kind of section heading in this predominantly-German work.
Latin-1
Latin-1 (or more formally, ISO-8859-1) is a character encoding standard. It defines a set of characters used for major western European languages.
The Distributed Proofreaders website used Latin-1 for processing all of its books, from its creation until May 19th, 2020. After that, it changed to the UTF-8 encoding of Unicode.
More information can be found at Wikipedia.
page header
Per the Proofreading Guideline Section on Page Headers
- Definition: The page headers are normally at the top of the page image and have a page number opposite them. Page headers may be the same all through the book (often the title of the book and the author's name), they may be the same for each chapter (often the chapter number), or they may be different on each page (describing the action on that page).
- Instruction: Remove them all, regardless, including the page number unless the Project Comments say different.
- Why would they say different? Because in some projects the information in the Page Header is useful or unique and the PM or PP wish to capture or save that information.
section header
The Formatting_Guidelines state:
Section headers are usually obvious as Titles centered between paragraphs of a page. Check the Table of Contents if in doubt. This is often linked to on the Project page, otherwise find the contents page by clicking on Images, Pages Proofread & Differences on the Project page. The page you are looking for will probably been among the first ten .png images in the first column. Project managers(PMs) will sometimes specify exceptions in the Project Comments.
Ads sometime require creative use of section headers to describe centered text.
The Formatting Guidelines state:
Some books have sections within chapters. Format these headings as they appear in the image. Leave 2 blanks lines before the heading and one after, unless the Project Manager has requested otherwise. If you are not sure if a heading indicates a chapter or a section, post a question in the Project Discussion, noting the page number.
Mark any italics or mixed case small caps that appear in the image. While section headings may appear to be bold or spaced out, these are usually the result of font or font size changes and should not be marked. The extra blank lines separate the heading, so do not mark the font change as well.
For more: see here.
sidenote
Some books will have short descriptions of the paragraph along the side of the text. These are called sidenotes.
Proofing Sidenotes
During P1, P2, & P3 rounds, proof the text and separate the sidenotes from the main text with blank lines. Sidenotes should be proofed just like any other paragraph (eg., split words should be re-joined, naked dashes clothed, etc.). Where the OCR (or the previous round) has placed a sidenote at the top of the page, there is no necessity to insert a blank line above it (though it is not wrong to do so).
Formatting Sidenotes
During F1 & F2 rounds, move sidenotes to just above the paragraph that they belong to, and surround them with a sidenote tag [Sidenote: and ], with the text of the sidenote placed in between.
Format the sidenote text as it is printed, preserving the line breaks, italics, etc. (while handling end-of-line hyphenation and dashes normally). Leave a blank line before and after the sidenote to separate it from the normal text.
If there are multiple sidenotes for a single paragraph, put them one after another at the start of the paragraph. Leave a blank line separating each of them.
If the paragraph began on a previous page, put the sidenote at the top of the page and mark it with * so that the post-processor can see that it belongs on the previous page, like this: *[Sidenote: (text of sidenote)]. The post-processor will move it to the appropriate place.
Exceptions
Sometimes a Project Manager will request that you put sidenotes next to the sentence they apply to, rather than at the top or bottom of the paragraph. In this case, don't separate them out with blank lines.
See more in the Formatting Guidelines.
For PPers
This page has some suggestions for how you might handle sidenotes in your HTML so they work well in epub/mobi.
"silent correction"
The phrase "silent correction" is often used to refer to an intentional change a proofer made to the proofed text of a page to "correct" something shown in the scanned image without leaving a [**proofreader's note] informing the post-processor that the change has been made. Another way to put it is making a change that relies on reason rather than vision without [**noting] it.
A "silent correction" other than the very few changes specifically mandated by the Guidelines (such as removing page headers/footers and end-of-line hyphens) is pretty much the worst "sin" a proofer can commit at DP.
The reason behind this is that what we really do here at DP is to transcribe basically hard-copy documents into another form (digital text), not edit them. Thus, some PPers prefer to have the project text match the historical document rather than make any "obvious corrections;" and others will make "minor" punctuation corrections, but not corrections that could just be old spelling inconsistencies; and some PPers will tend to make spelling consistent throughout the entire project; but no matter what course they choose, they are likely to leave a Transcriber's Note about the various "corrections" to the original that were and were not made, and it's hard to do that when they don't know what "corrections" have or have not been made (such as in the case of "silent" ones).
small caps
This article is aimed at post-processors who need to convert <sc> markup into a final form in an etext. During the rounds, refer to the proofreading or formatting guidelines as appropriate.
Project-level Checks
When post-processing your book, before splitting to HTML and plaintext, confirm that <sc> has been used (and closed) correctly. The best way to do this, unfortunately, is to look at each instance, using a search for <sc>.
Next, consider doing related checks, for reasons which at this moment must be all too obvious. For example, if you have some <sc>A.D.</sc>'s in your project, it's a great plan to search for just A.D. (case insensitive, so it picks up a.d. too.) Note that some common abbreviations may be used as either big or small letters. So, P.M. and p.m. may both appear quite validly in DP-era books. Our Aim Here is Match the Printer's Text!
Correct DP-internal formatting, fresh from the rounds, looks like this:
- This is Small Caps
- You cannot be serious about AARDVARKS!
- CHAPTER SEVENTY-THREE
- formats as <sc>This is Small Caps</sc>
- formats as You cannot be serious about <sc>AARDVARKS</sc>!
- formats as CHAPTER SEVENTY-THREE
[This last one trips up many formatters. Even if it looks smaller than the font elsewhere on the page, when it's a heading in ALLCAPS that's all the same size, it does not get smallcap treatment. It's a font size change, which we don't mark, and the blank lines for the heading are the only markup needed to set it apart.]
You may also see the old-DP-style <sc>a.d.</sc> - this is plain wrong according to the formatting guidelines. Uppercase these before going any further.
The Plaintext Version
Decisions, Decisions
Most of the time, you will simply change Small Caps into ALL CAPS for the plain-text file. But sometimes this will not work.
- If every other word in the book is small-capped, ALL CAPS will make it seem as if you are shouting at the reader.
- If the text uses both Small Caps and ALL CAPS, you may want to distinguish them.
- If abbreviations like "Sec" and "SEC" mean different things, you have to to distinguish them or risk losing meaning.
In situations like these, think of small caps as just another kind of text formatting, alongside italics and boldface. Pick a markup such as +, = or # that you're not using for anything else, and use it for small caps. For all small caps (as in A.D.), you will probably want to leave them as CAPITALS without further markup.
If you use characters like #This# or something similar to mark small caps, it's best to explain the meaning in a transcriber's note so that readers will know what it is.
Regexes
Most of the time the following regular expression search and replace is all that you will need for small caps in the plaintext version. It UPPERCASES all smallcap-marked text (whether it started as upper or mixed upper and lower case) and removes the <sc> tags.
Search: <sc>((.|\n)+?)</sc> Replace: \U$1
Note: The \U (capitalization) option is not available in all editors.
If you want to treat ALL SMALL CAPS differently from Mixed Case Small Caps, use the following regex to find only ALL CAPS small caps spans. This version simply removes the markup, leaving plain all caps:
Search: <sc>(\P{IsLower}+?\n?)</sc>
Replace: $1
After you've changed the all small caps, the only remaining <sc> tags should be for mixed case. If you want to insert some markers around it like =this= while keeping the mixed case, use this regex:
Search: <sc>((.|\n)+?)</sc> Replace: =$1=
Once you've also dealt with <i>, <b> and <tb>, it's worth doing a quick search for < and > to make sure all the little varmints have been seen to. You don't want them messing with the precious bodily fluids of your plaintext!
The HTML Version
There are various options here. Pick One and Stick To It. If you have a good reason to change this, do—but make it an informed decision, and if you're not sure, standardise.
CSS and HTML Background Information
CSS provides a font-variant: small-caps; option for applying small caps. You can create a class for this with whatever name you choose, such as "smcap":
.smcap { font-variant:small-caps; }
Any text marked with class="smcap" will then have the CSS small caps property, which causes lower-case letters to appear as shorter capital letters.
Another CSS option often used when handling small caps is text-transform, which allows you to display text as uppercase or lowercase while the underlying text may be different. For example:
.lowercase { text-transform:lowercase; }
Often PPers use the <span> tag for applying small caps in the HTML, but this is not always necessary. If a small-capped phrase already has markup all around it, you can apply the "smcap" class directly to that tag, as in a heading:
<h2 class="smcap">Chapter VII</h2> instead of: <h2><span class="smcap">Chapter VII</span></h2>
Usual Handling
Put both of these CSS classes into the CSS style section of your HTML file:
.smcap { font-variant:small-caps; }
.lowercase { text-transform:lowercase; }
then use both these regexes:
Search: <sc>(\P{IsLower}+?\n?)</sc>
Replace: <span class="smcap lowercase">$1</span>
followed by
Search: <sc>((.|\n)+?)</sc> Replace: <span class="smcap">$1</span>
Both regexes apply the class="smcap", but the first one applies an additional class of "lowercase" to the <sc> words/phrases that didn't contain any lower-case letters. The "lowercase" style will switch A-Z into a-z on the screen, and then when the small-caps styling is applied it'll end up as lower-case small caps. The underlying text will still be written as all-capitals (and thus people who copy and paste the HTML text will get capital letters not lower case). This way you get true lowercase smallcaps without making it a smaller font (which is prone to resizing differently to mixed case Smallcaps. Ugh!) BOTH regexes are needed, because Mixed Case Smallcaps obviously will look odd if you use the "lowercase" class on them and make them, ALL SMALLER-SIZE.
Other Situations
Lower Case
If your all-small-cap phrases seem to be a form of emphasized lower case, you may want to convert the letters to actual lower case. For example, in a linguistics text if the phrase "To have" appears at the start of a sentence and "to have" in the middle, all of the letters except for the taller capital "T" make sense as lower case letters; the book could have shown it as To have and to have or the equivalent using italics or quotation marks. If you want to lower-case the letters inside <sc> markup, use this regex:
Search: <sc>(\P{IsLower}+?\n?)</sc>
Replace: <span class="smcap">\L$1\E</span>
Note: The \L (lower-case) option is not available in all editors.
The preceding regex is not recommended for text that semantically is capitalized, as in A.D.
The <small> Tag
If your all-small-capped phrases are generally abbreviations such as A.D. you may want to mark them with the HTML <small> tag or something similar. This would be done using:
Search: <sc>(\P{IsLower}+?\n?)</sc>
Replace: <small>$1</small>
Emphasis
Since the <span> tag has no meaning unless it applies some CSS, if the reader views the text with CSS turned off the <span> will have no effect. If the small caps in your book is a form of emphasis, then you may want to consider using the <em> (emphasis) tag instead to apply small-cap styling. Here is the CSS:
em.smcap {font-style: normal; font-weight: normal; font-variant: small-caps;}
In the HTML you would use the same markup as any of the options shown above, but with an <em> tag instead of a <span>.
If CSS is turned off, then the default meaning of <em> will apply (usually italics); with CSS turned on it will appear as (unitalicized) small caps. Thus, in either case the reader will see some form of emphasis. PP and PPV Footer
"spacey quote"
The phrase "spacey quotes" is sometimes used to refer to the particular type error found in OCR texts in which quotation marks (single or double) are separated from text by spaces.
For example:
- Justice " in the hands of Madame de Meroul " Le
This is an especially important error for proofers to be on the lookout for and correct, because while a software script can be used to find quote marks surrounded by spaces on both sides, no automated tool can determine to which of a pair of letters the quotation marks really apply as well as a human being's understanding of the text's context can.
In other words, it usually takes a human being to figure out if the text should be proofed as this
- Justice "in the hands of Madame de Meroul" Le
or as this
- Justice" in the hands of Madame de Meroul "Le
thought break
Sometimes two paragraphs are separated to indicate a thought break. A thought break may take the form of a line of stars, hyphens or some other character, a plain or floridly decorated horizontal line, a simple decoration, or even just an extra blank line or two.
A thought break may represent a change of scene or subject, a lapse in time or a bit of suspense. This is intended by the author, so we preserve them in formatting by putting a blank line, <tb>, and then another blank line. (During proofreading, thought breaks can be ignored.)
In post-processing, a thought break is usually represented by a row of five asterisks in the plain text version and by a horizontal rule in the HTML version.
TOC/ToC
ToC and TOC are the standard abbreviatons used to refer to a Table of Contents.
(For post-processing advice related to ToCs, see Tables of contents.)
transliteration
Transliteration is the process of converting a text from one writing system into another in a systematic way, such as converting Greek text Βιβλος to Roman text Biblos.
- For more information, see the complete transliteration article.
unclothed dash
- Definition: Unclothed dashes are those en-dashes, em-dashes, or long dashes that occur at the beginning or end of a line or otherwise have a space on either side of them. They are considered "naked" or "unclothed" because they do not have the previous or next word snugged up against them.