User:Acunning40/feedback
This is mostly a collection of feedback blurbs from PMs I've sent in the past. There are also a few things from other sources like Bruce's mentoring tool.
Topics mostly for new volunteers
Intro
If you are viewing this message in your email program, some of the formatting may not come across completely. You can see the message in its original format in your Distributed Proofreaders inbox: http://www.pgdp.net/phpBB2/privmsg.php?folder=inbox
Hi ***,
:Welcome: to DP! I hope you are enjoying the site. I have been looking at the ** pages you proofed in the first round of [url=**]**[/url]. It looks like you're doing very well--congratulations!
You correctly rejoined words split at the end of a line, removed the page headers, and fixed some random errors in the OCR (computer-generated) text. Well done!
There were only a few changes made on your pages during the second round (P2), which I'll explain below. At the end of my message you can also find a list of links and tips for proofing at DP.
alternate version: There were only a few changes that I made on your pages.
Top of page
Page header
During proofreading you'll often see pages that have a page number and the title or author written across the top. That's the page header, which we remove. You see, later on all the pages will be joined together into a continuous text. If we left in the page header then it would interrupt the middle of paragraphs, which would look pretty strange! An example of a page header is the phrase "" at the top of [url=]**.png[/url].
Extra blank line at top
We only put a blank line at the top of the page when it's a new paragraph. You see, later on all the pages will be joined together into a continuous text. Any blank lines at the bottom of a page are removed before that happens, but blank lines at the top of the page are kept when the pages are joined together. So if there's a blank line at the top of the page and it's the middle of a paragraph, that'd lead to a blank line in the middle of the paragraph in the final text, which we don't want to happen.
Missing blank line at top
A couple pages needed a blank line at the top--the ones that started with a new paragraph. Books usually use indentation, but for our electronic texts we use blank lines instead, so we always put a blank line at the start of a new paragraph (even at the top of a page). Later on all the pages will be joined together into a continuous text. Any blank lines at the bottom of a page are removed before that happens, but blank lines at the top of the page are kept when the pages are joined together.
Line breaks
During proofreading we keep the line breaks as originally printed (with the exception of end-of-line hyphenation and dashes as detailed in the [url=http://www.pgdp.net/c/faq/proofreading_guidelines.php#eol_hyphen]guidelines[/url]), so even if the line lengths are uneven like this it's okay:
[code]*****[/code]
Keeping the line breaks matching the original helps later proofers and formatters to be able to compare the text to the image. At the very end of the process (after the page-by-page work is complete) the text will all be rewrapped at once to make the line lengths consistent for the final ebook.
Hyphens & dashes
End-of-line hyphens
When a hyphen appears at the end of a line in the image, we move the partial word on the second line up. For example, we change this:
[code][/code]to this:
[code][/code]
We keep the hyphen for any hyphenated phrases like "well-meaning", but we remove the hyphen if it's a single word, like in this example.
End-of-line hyphens & dashes (together)
When a hyphen or a dash appears at the end of a line in the image, we move the word or partial word on the second line up. For example, with hyphens we change this:
[code][/code]to this:
[code][/code]
We keep the hyphen for any hyphenated phrases like "well-meaning", but we remove the hyphen if it's a single word, like in this example.
Similarly, when it's a dash like this:
[code][/code]we proofread it like this:
[code][/code]
At DP we call this "clothing a naked dash." :lol: We do this because later on (after proofreading is finished) each end-of-line will be converted into a space. We remove spaces around an em-dash, and if we left it at the end of the line that would be the same as leaving a space after it. You can see quite a few examples in [url=http://www.pgdp.net/c/faq/proofreading_guidelines.php#em_dashes]this section[/url] of the proofreading guidelines.
End-of-page hyphenation
When a word is split across pages, we put a * next to each half of the word, like this for the first half:
[code][/code]and in the second half:
[code][/code]
Later on the 2 portions of the word will be joined together.
Dash length
We use 4 hyphens when a dash is as long as about 4-5 letters, and 2 hyphens if it appears as long as 2-3 letters. For example, on [url=**]**.png[/url] we proofread it like this:
[code][/code]
Dash spacing
At DP we don't leave any spaces on either side of em-dashes. For example, if the text starts off like this:
[code][/code]we proofread it like this:
[code][/code]
Start/end-of-line dashes
When an em-dash appears at the end of a line in the image like this:
[code][/code]we move the word on the second line up like this:
[code][/code]
At DP we call this "clothing a naked dash." :lol: We do this because later on (after proofreading is finished) each end-of-line will be converted into a space. We remove spaces around an em-dash, and if we left it at the end of the line that would be the same as leaving a space after it. You can see quite a few examples in [url=http://www.pgdp.net/c/faq/proofreading_guidelines.php#em_dashes]this section[/url] of the proofreading guidelines.
Incorrect rejoining
Lower line
When rejoining end-of-line hyphenation, our convention is to put the word on the first line, regardless of how long it is. For example, this text in the book:
[code][/code]is proofread like this:
[code][/code]
It's just a minor point of consistency so that when later volunteers are looking back and forth between the image and electronic text they know that the hyphenated word will always appear at the end of the first line (rather than sometimes at the start of the second line).
Long lines
When moving the dash up, we'd rather not create an extremely long line like this:
[code][/code]
It's easier to compare text to image if the text is in roughly the same spot, so when joining dashes we only move as much text as we have to in order to "clothe" the dash (i.e., to get some text on each side). In this case the line breaks in the original book look like this:
[code][/code]
When you have a dash at the start of a line, what you'd do is look for the next space to appear after that dash. Wherever the next space is, that's where the new line break will be (because we treat the end of a line as the equivalent of a space). In this case there's just one word after the dash before you get to a space, so it'd end up like this:
[code][/code]
The dash and its following word get brought up to the preceding line, but the rest of the text can stay on the 2nd line. That keeps the text closer to the way it is in the image, to help with proofing, while still "clothing" the dashes so that they each have text on both sides like we want.
Rejoining across pages
When a word is split across pages, we don't move the partial word from one page to another. We want to have the text and the page image both visible at the same time. So instead, we put a * next to each half of the word, like this for the first half:
[code][/code]and in the second half:
[code][/code]
Later on the 2 portions of the word will be joined together.
-*
When rejoining end-of-line hyphenation, sometimes it may be unclear whether the author normally spelled the word with or without a hyphen. We have a special notation for this situation: you keep the hyphen and put an asterisk * after it. For example:
[code][/code]
Later on when all the pages are joined together into a continuous text, another volunteer (the "post-processor") will search for "-*" and check each case. They'll look throughout the text to see how the author normally wrote the word, and then they'll either keep or remove the hyphen accordingly to match the author's usage. Books from a century or more ago often used quite different hyphenation than we do today, so it's best to use -* whenever there's any doubt.
-* used mid-line
I noticed that you added -* in some spots in the middle of a line. We use that -* notation when we're not sure how the author normally wrote the word (with or without a hyphen). This comes up when we're rejoining words that were split across lines in the original book, since we can't tell in that situation whether the author would have written it with a hyphen or not. On the other hand, when a word is in the middle of a line, we know that the presence (or absence) of a hyphen was intentional, so the -* is not needed in that situation.
For example, if the original book has this:
[code][/code]then when rejoining the two parts we might put this:
[code][/code]
That translates to "either **-** or **". (Later on when all the pages are joined together into a continuous text, another volunteer will search for "-*" and check each case. They'll look throughout the text to see how the author normally wrote the word, and then they'll either keep or remove the hyphen accordingly to match the author's usage.)
Other punctuation
Spacey quote
Something else to watch out for when proofing is spacing around punctuation. Often the OCR software doesn't do a very good job on this--people are much better at figuring it out. ;) A common example of this is with quotation marks, which should be right up against the text that they belong with "like this." In other words, an opening quotation mark shouldn't have a space after it and a closing quotation mark shouldn't have a space before it. The OCR software might not be able to tell the difference so it may leave a space on either side like this:
[code][/code]
which would be proofed like this without the extra space:
[code][/code]
Removed too many spaces
If punctuation has spaces on both sides, remove the space on the side to which it does not belong. For most punctuation, this means there should be no space between the word preceding the punctuation and the punctuation (e.g., no space between a word and a comma, period or question mark, but the space after the punctuation is retained). For a quotation mark, the extra space could either be preceding the quotation mark (at the end of a quote), or after the quotation mark (at the beginning of a quote). So on your page, where the text is like this:
[code][/code]
that's fine the way it is; you don't need to remove the space after the comma like this:
[code][/code]
Ellipses
We treat ellipses differently depending on whether they're in the middle or at the end of a sentence. In the middle of a sentence we treat the three dots like a word, which usually means that there should be a space on either side:
[code]like ... this[/code]
At the end of a sentence we treat it like ending punctuation, with no space before it. Also, at the end of a sentence there should be an additional ending punctuation mark: a period (full stop), question mark, or exclamation point. In the case of a period that means you'll end up with 4 dots:
[code]like this....[/code]
If the ending punctuation is a different mark then you'll have something like:
[code]this...!
this...?
this!...
this?...[/code]
If there's a ! or ? then that indicates the end of a sentence, so that's fairly easy to recognize. If there are only dots then you can generally identify the end of a sentence because the next text starts with a capital letter.
Scanno
There was one OCR error remaining in the text:
[code]***[/code]changed to:
[code]***[/code]
We call that a "scanno"--a place where the computer-generated text doesn't correctly match what was originally printed. These get easier to spot as you gain more experience with proofreading.
Multiple
There were a few OCR errors remaining in the text:
[code]***[/code]changed to:
[code]***[/code]
We call these "scannos"--places where the computer-generated text doesn't correctly match what was originally printed. These get easier to spot as you gain more experience with proofreading.
Near other errors
These appeared near a *** that you fixed, and many of us at DP have noticed that if we fix one error it's easy to overlook something else in close proximity. It's often helpful to back up a few words or a line after making one correction, to avoid that problem.
WordCheck
Another thing that helps in finding scannos is our "WordCheck", which is a sort of spell check. It marks words that aren't in the dictionary but it also flags words that we know are commonly scannos, even if they might be valid words. (A few examples of that are "arid", which almost always should be "and", and "modem" that's almost always "modern".) You can find the WordCheck button in the proofreading interface, just a bit below the buttons for saving the page.
The words flagged in WordCheck are not always wrong; it's just a tool to highlight words that have a greater chance of being scannos, compared to the rest of the text on the page. :)
Font
We also have a custom DP font called DPCustomMono2 developed by one of our volunteers, which makes it a lot easier to see the difference between similar-looking characters such as ***. You can read more about it [url=http://www.pgdp.net/c/faq/font_sample.php]here[/url] and download/install it using the instructions [url=http://www.pgdp.net/wiki/DPCustomMono2]here[/url].
Printer's errors
If you come across something in the image that you think wasn't intended by the author, you should keep it as printed and add a note after it like this:
[code][/code]
The format that we use is to put the note in brackets, and put two *s right after the opening bracket. Later on another volunteer (the "post-processor") will go through the text searching for "[**" and look at each note, deciding what to do about it. Often they'll put a transcriber's note at the very beginning or end of the completed ebook notifying readers about the errors that were present in the original book, so that readers know that it wasn't our mistake in transcription.
Notes on scannos
It looks like you caught quite a few errors in the text, which is great. However, I noticed that at times you added notes like this in the text:
[code][/code]
I think you may have misunderstood a bit regarding when we leave notes in the text. In this case the "t" in the image is pretty clear, so you don't need to leave a note about that. When proofing you should always correct all scannos in the text--a scanno is a spot where the OCR software guessed incorrectly, and we need to change that so that the text matches what the author wrote. The OCR (starting text) is just there to save us from having to type in every page; we don't need to note where it was wrong.
On the other hand, if something in the original book (i.e., in the image) seems wrong, then you should leave a note about it. Generally it's better to keep the text as it was originally printed and just say in your note what you think it should have been. Occasionally it can work out better to change the text to what you think it should be, and then say what you changed in your note, but that's not too common.
For example, if the image shows:
[code]soem text here[/code]then you would normally proof this as:
[code]soem[**typo for some?] text here[/code]
However, if the image showed "some" while the OCR text had "soem", you would simply correct the text to match what the author wrote.
Note removal in feedback situation
Normally we don't remove any notes left by previous proofreaders, but in this case since the note essentially asked a question and I've now answered it, it seemed like the note didn't need to be there any longer. So the P2 proofer has removed the note from the text. (If I hadn't been writing to you about it, the proofreader would not have removed your note.)
Over PC page limit
By the way, I noticed that you did 11 pages on this project. On most projects there's no page limit and you are welcome to do as much as you want. However, the Beginners Only projects like this one are a limited resource and we want to make sure that our new volunteers have the opportunity to work on them if they choose, so the project comments said at the top:
[quote]Welcome! Please proof only 5 pages in the BEGINNERS ONLY project of your choice, then work on other projects in P1 while you wait for your feedback. This will permit our Mentors to catch up on the current backlog, and provide more timely feedback to all new proofers. Thank you![/quote]
Just a few extra pages isn't a problem in the big picture, but I'm bringing it up because the project comments sometimes do contain special instructions or other important information so I wanted to make sure that you know to review what it says on each project before you begin proofreading. It's quite possible you did see the instruction but got absorbed in proofreading and lost track of how many you'd done, or something like that--it happens sometimes. :) Anyway, I just wanted to mention that it's important to check the project comments carefully before proofreading.
Closing
- Alternate 1st paragraph: So it looks like you've made a good start at proofing! :thumbsup: Please feel free to try out another "Beginners Only" project, or any other project currently available on the P1 page, and see if anything interests you.
So it looks like you've made a good start at proofing! :thumbsup: Please feel free to try out the other projects currently available on the P1 page, if you haven't done so already, and see if anything interests you.
[b][u]General links and tips for proofing at DP[/u][/b]
If you run into anything you're unsure of you can check the guidelines, and ask questions in the project discussion any time. Also, near the save buttons in the proofreading interface is one that says "Return Page to Round", which will return the page to available--you can use that on any page if you'd like to send it back for someone else to do instead.
If you haven't found it yet, we have a [url=http://www.pgdp.net/c/faq/proofing_summary.pdf]pdf summary of our proofreading guidelines[/url]. Many new volunteers like to print that out to refer to while proofreading.
The full guidelines are [url=http://www.pgdp.net/c/faq/proofreading_guidelines.php]here[/url]. They're much longer than the summary, and have a lot more detail and examples for things that you may come across while proofing. Many people keep them open in another window while proofing to check when they aren't sure of something.
As you start to learn some of the common guidelines, you may want to try out the [url=http://www.pgdp.net/c/quiz/start.php?show_only=PQ]proofreading quiz[/url]. It can help to review what you've learned and to give you an idea of which guidelines you may still need to learn.
On future projects if you'd like feedback on anything that you proofread, you can contact dp-feedback (details [url=http://www.pgdp.net/wiki/Dp-feedback]here[/url]) for individual feedback.
As your pages move through to the next round, you can also see what changes are being made using [url=http://www.pgdp.net/noncvs/review_work_instrumented3.php?work_round_id=P1&review_round_id=P2&days=90&sample_limit=0]this page[/url]. More information about checking your "diffs" (differences) is available [url=http://www.pgdp.net/wiki/Checking_your_diffs]here[/url].
We have a DP Custom Proofing font which you can see [url=http://www.pgdp.net/c/faq/font_sample.php]here[/url]. It is ugly, but using this font helps improve proofing accuracy because it's designed to make similar-looking characters easier to tell apart.
Don't forget to check out the [url=http://www.pgdp.net/phpBB2/index.php]Forums[/url].
There's a [url=http://www.pgdp.net/phpBB2/viewtopic.php?t=6651]Feedback Poll[/url] we have set up to find out what our new volunteers think of our mentoring feedback. Please consider stopping by there and letting us know.
Please let me know if you have any questions about the above or anything else. Also please let me know if you have any comments on my mentoring feedback.
Happy proofing!
Amy
Other areas--proofing
PM-type stuff
Page limit
I was checking on the status of [url=][/url] (because the Project Manager is out of town right now) and I saw that you've been proofing on it. Thanks for your efforts! :D However, I think perhaps you didn't notice that the project comments ask P1 proofers not to do more than 50 pages on the project. On most projects there's no page limit and you are welcome to do as much as you want. However, the Newcomers Only projects like this one are a limited resource and we want to make sure that our new volunteers have the opportunity to work on them if they choose, so that's why we have a page limit in this situation.
Since I saw that you had proofed 70 pages in the project and you were still going, I cleared some of them to bring that down to 50.
Wrong WordCheck suggestions
Hi there! :D I was just taking a look at the proofers' suggestions for the good word list on [url=]title[/url] and I saw that you had made suggestions on quite a few pages. Thanks for doing that! However, one of the words that you suggested was:
[code]****[/code](You used the "unflag and suggest" button for that word on page ***.png.)
The word actually should be *** with a ** rather than a **. In some fonts it can be hard to tell those two characters apart, so you may want to consider changing what font you use while proofing to avoid mistaking one for the other in the future. We have a custom DP font called DPCustomMono2 developed by one of our volunteers, which makes it a lot easier to see the difference between those letters. You can read more about it [url=http://www.pgdp.net/c/faq/font_sample.php]here[/url] and download/install it using the instructions [url=http://www.pgdp.net/wiki/DPCustomMono2]here[/url].
You're not required to use that font for proofreading, of course! It can be very helpful though to make it easier to tell the difference between similar letters. If you can't use that font for some reason, I'd suggest that you try out other fonts to find one that you can use that also helps you to distinguish similar characters. It can make a big difference in spotting scannos.
Please let me know if you have any questions. Thanks again for proofing and for using WordCheck!
Additional language option in WordCheck
I was just reviewing the "suggestions from proofers" on [url=]title[/url], and I saw that you had suggested a lot of French words because there were some long French passages in the footnotes. I wanted to let you know, in case you weren't aware, that in situations like that you can select an additional language in the WordCheck interface. At the top of the text frame in WordCheck it says:
[quote]Dictionaries used: English. Use additional: [drop-down box appears here][/quote]
So anyway, for future reference you can add a language (like French in this case) so that you won't have to deal with so many foreign words being flagged. :)
Happy proofing!
Clearing pages
(Typically used with Silent corrections or a similar topic.)
Because most of the changes that you made would have to be put back to the way it started by the next proofreader, it makes more sense at this point to revert to the text that we had before your changes. Because of that, I've returned the pages to available. That's the easiest way we have of reverting to the previous version of the text, going back to what actually was printed in the original book. [**or different ending for the situation]
Footnotes
Accents changed to bracket-style
Hi there! :D I was just looking through the P1 proofing on [url=***]***[/url] and I noticed that you had done some pages. Thanks for working on the project!
I wanted to let you know that when there's an accent in the text, you don't necessarily have to change it from something like ê to something like [^e]. We only use bracketed markup like [=e], [s.], etc. when we have to; as much as possible we keep the symbols that are used in the original. For the more common accents such as ê, ï, and ä, we can use the actual characters directly. :)
The bracketed markup is used for characters that won't work if put directly into the proofing text box. In technical terms, we can use any [url=http://www.pgdp.net/wiki/Latin-1]Latin-1 characters[/url] during proofing but nothing else. In more practical terms, what this means is that you can use any character that appears in the drop-down boxes (A E I O U +) at the bottom of the proofing interface. The same Latin-1 characters are given in table format [url=http://www.pgdp.net/c/faq/proofreading_guidelines.php#insert_char]here[/url] in the guidelines for reference.
So anyway, during proofing it's fine to have a word like "fêted" in the text; you don't have to change that to "f[^e]ted".
I hope this helps. :) Thanks again for proofing, and please let me know if you have any questions!
Silent corrections
I saw you made a few changes in the spelling, changing "skilful" to "skillful" and "unforgetable" to "unforgettable". At DP we keep the older spellings used in books, so if it says "skilful" in the image then we keep the text as "skilful". We're preserving the original text for history, not producing a new edition, so we don't make editorial changes like that.
[then printer's errors above]
Removing mid-line hyphens
I noticed that in a few places you removed a hyphen in a phrase such as "meeting-place" or "trysting-place". We keep older spellings, accents, and hyphenation as they were printed, so I've put those hyphens back in. The hyphens that we remove for end-of-line hyphenation are only there because the printer wanted to make the lines of text line up neatly--they're not part of how the words were normally spelled. On the other hand in the middle of a line of text we know that they were intentional, so we don't want to change them.
Indexes
I wanted to let you know that you don't need to remove the blank lines between the index entries in the text. During the proofing rounds either with or without the blank lines is fine for indexes; [...]
- or
I wanted to let you know that you don't need to insert indentation in the text during the proofing rounds. That's true for any indentation, but particularly with indexes [...]
the important thing is to focus on checking the text itself for accuracy compared to the page image:
[quote="the proofreading guidelines for indexes"]Specific formatting of indexes will occur later in the process. The proofreader's job is to be sure that all the text and numbers are correct.[/quote]
(In this case the index will be formatted with blank lines between the entries so the blank lines will need to be there in the end anyway. But even if they were going to be removed, you wouldn't need to deal with doing that during the proofreading rounds.)
Anyway, that's one less thing to worry about when proofing indexes. ;)
Line breaks
You don't need to remove the line breaks in index entries that were split across lines in the original book. During the proofing rounds, apart from rejoining hyphenation and clothing em-dashes we pretty much leave the line breaks just as they appear in the image; this makes it easier for later proofers to check the text against the image. If the line breaks are removed in a long string of numbers like this:
[code][/code]
it'll be harder for the P2 and P3 proofers to keep their place than if the lines match the image like this:
[code][/code]
(When it's just a word or so it's not as big of a deal, but still if you're stopping to remove line breaks it may take your attention off of the characters themselves. And anyway, it makes more sense to treat them all the same, so since we don't want to remove line breaks in the long ones like I've shown, to be consistent we don't do it for the short ones either.)
Small caps case changing during P*
Hi there! :D I was just looking through the P1 proofing on the [url=***]***[/url] and I noticed that you had done some pages. Thanks for working on the project!
I wanted to let you know that when small capitals appear in the text, you don't need to convert their case--just leave them as they come to you (ALL CAPS, Title Case, or lower case) and check the letters themselves. For instance, near the top of [url=***]this page[/url] if the text that you get says "FREDERICK STRICKLAND" then you'd leave it that way. Similarly, if the text that you get says "Frederick Strickland" then you'd leave it that way. Either one is correct during proofing--just check the letters to make sure it doesn't say "Freberiok Sirickiand" or "FEEDERICR STRICKLAXD".
In case you're curious, the reason we do it this way is that the guidelines for small caps changed several times in DP's history, and it often seemed to be a difficult issue for many people to understand as well. It seems to work better having the case changing for small caps handled during the formatting rounds, at the same time as the markup is added.
Anyway, it's a minor thing but I just thought I'd let you know for future pages that you don't need to change the case of small capitals--that's one less thing to deal with. :D Thanks again for proofing on that project, and please let me know if you have any questions!
Formatting during P*
Hi there! :D I was looking at the pages of [url=***]***[/url] today and I saw that you proofed some pages in *** on that project. Thank you for working on it! I noticed though that you added some formatting such as [Footnote: ], [Sidenote: ], and <i> on your pages. I wanted to let you know that during the proofreading rounds you don't need to worry about those things at all. The goal of proofreading is to check that the text itself is correct, focusing on the letters, numbers, and punctuation--dealing with formatting as well can distract you from checking the text so it's better to keep the two activities separate. Once the project moves onto the formatting rounds the formatters will take care of layout and appearance. The formatters like having something to do, ;) which will only happen if formatting isn't done during the proofreading rounds.
Experienced/Inexperienced options:
- I wondered if you might have gotten mixed up about which round you were in. If so, don't worry, it happens to everyone once in a while! ;) It's a good idea to check the top of the project page just before you click the "Start Proofreading" link, to see if the current state is a proofreading or formatting round.
- It can take a while to learn which things are a proofreading responsibility and which are formatting, and we certainly don't expect people to know the difference right away! [**join to next paragraph if using this version]
In general, if you aren't sure whether something is proofreading or formatting, the first place to check is the proofreading guidelines because if the topic isn't mentioned there it usually means you shouldn't deal with that during proofreading. There are some situations though that aren't necessarily clear so please feel free to ask in the forums any time you aren't sure. We love answering questions around here! :D
In case it's helpful, here's a list of some things that should only be done during the formatting rounds, not during proofreading. Sometimes seeing it all in one place can make it easier to remember:
[list][*]adding or correcting markup for [i]italics[/i], [b]bold[/b], S[size=9]MALL[/size] C[size=9]APS[/size], [font=Courier, monospace]font changes[/font], and spaced-out text (<i>, <b>, <sc>, <f>, <g>)
[*]adding or correcting markup for block quotes, poetry, and other no-rewrap sections (/# #/, /* */)
[*]adding or correcting markup for illustrations, footnotes, sidenotes, thought breaks ([Illustration], [Footnote #: ], [Sidenote: ], <tb>)
[*]marking footnotes that continue from one page to another
[*]indentation (in poetry or anything else)
[*]changing the case of small caps (during proofreading they can be ALL CAPS, Title Case, or lower case; the formatters will change the case if necessary)
[*]adding extra blank lines for a new chapter or section
[*]aligning text in tables, and adding the lines for rows/columns if needed in tables
[*]rejoining long lines of poetry that were wrapped in the book, and rejoining lines in indexes[/list]
I hope that this makes sense. :) Thanks again for proofing, and please let me know if you have any questions or if something isn't clear!
Formatting rounds
Regular formatting in a LaTeX project
Hi there! :D I saw that you formatted some pages of [url=]title[/url] in F1 recently. Thank you for your effort! However, the project comments for the formatting rounds say:
[quote][/quote]
The project comments have links to DP's LaTeX guidelines, which will be useful if you're just starting to learn it. Formatting in LaTeX is different in many ways from regular DP formatting, so it's important to review the project comments and those documents if you haven't worked with it before at DP. If you need more information that isn't covered in those 2 documents, [url=http://www.pgdp.net/wiki/LaTeX_resources]this page[/url] may be helpful or you can ask in the [url=http://www.pgdp.net/phpBB2/viewtopic.php?t=14933]LaTeX typesetters[/url] team discussion.
If you're not familiar with LaTeX and you don't want to start learning, then would you return your pages to the round so that other F1 formatters can put in the needed markup? Thanks!