Sentence spacing in digital media

Summary

Sentence spacing in digital media concerns the horizontal width of the space between sentences in computer- and web-based media. Digital media allow sentence spacing variations not possible with the typewriter. Most digital fonts permit the use of a variable space or a no-break space.[1] Some modern font specifications, such as OpenType, have the ability to automatically add or reduce space after punctuation,[citation needed] and users may be able to choose sentence spacing variations.

Modern fonts allow spacing variations that the average user can easily manipulate, such as: non-breaking short spaces (thin spaces), non-breaking normal spaces (thick spaces), breaking normal spaces (thick spaces), and breaking long spaces (em spaces).

Word processors and text input programs edit

The typesetting software TeX treats horizontal runs of whitespace as a single space, but uses a heuristic to recognize sentence endings—typesetting the spaces after them slightly wider than a normal space. This is the default for TeX, although the "\frenchspacing" TeX macro will disable this feature in favor of using the same amount of space between sentences as it does between words.[2]

Computer word processors will allow the user to input as many spaces as desired. Although the default setting for many applications' grammar-checkers (e.g., Microsoft Word) is single sentence spacing, they can be adjusted to recognize double sentence spacing as correct also. A program called PerfectIt is an "MS Word add-in that helps professionals to proofread faster". The producer states that a feature was added to the most recent version of their program (as of August 2009), "to convert two spaces at the end of a sentence into one", but they have "never had any requests to convert one space into two".[3]

Some plaintext editors, such as Emacs and vi, originally relied on double-spacing to recognize sentence boundaries. By default, Emacs will not break a line at a single space preceded by a period, but this behavior is configurable (with the option sentence-end-double-space). More than one space will be preserved, but no additional space will be added automatically if it lacks. There are also functions to move the cursor forward or backward to the next double-space in the text. In Vim the joinspaces setting indicates whether extra spaces are inserted when joining lines together, and the J flag in cpoptions indicates whether a sentence must be followed by two spaces. The GNU coding standards recommend using two spaces when coding comments.[4] This also applies to software documentation in the GNU project. The optional Emacs mode LaTeX provides a toggling option French-LaTeX-mode which, if set to French, creates single sentence spacing after terminal punctuation.

Web browsers edit

Web browsers follow the HTML display specification and for programmers' convenience ignore runs of white space when displaying them.[5] This convention originally comes from the underlying SGML standard, which collapses multiple spaces because of the clear division between content and layout information.[6] In order to force a web browser to display multiple spaces, a special character sequence must be used (such as "  " for an en-space followed by a thin space, " " for an em-space, or "&nbsp" for two successive full spaces).[7] However, using a non-breaking space can lead to uneven justified text and additional unwanted spaces or line breaks in the text in certain programs.[8] Alternatively, sentence spacing can be controlled in HTML by separating every sentence into a separate element (e.g., a span), and using CSS to finely control sentence spacing.[9] This is seldom done in practice.

To specify and allow multiple spaces to be rendered without collapsing in a web browser, the HTML <pre> tag or CSS white-space property can be employed.

Character encodings edit

ASCII and similar early character encodings provide only a single space, which is breaking and fixed-width (the particular width specified by the respective font). EBCDIC, although earlier than ASCII, provided a breaking fixed-width space (SP), a non-breaking fixed-width space (RSP: "Required SPace"), and an alternate-width non-breaking fixed-width space intended for use in numeric lists with fixed-width (but not necessarily em-width) digits (NSP: "Numeric SPace"). HTML and Unicode can both record runs of consecutive spaces—including multiple-width spaces, and breaking and non-breaking spaces. HTML provides four variations on space width and one fixed-width non-breaking space: <space>, &emsp;, &ensp;, and &thinsp; (all breaking); and &nbsp; (non-breaking). In a typewriter font, <space> will equal &emsp;, but will vary according to the font designer's specification in all other fonts, whether proportional or monospace. The HTML standard also specifies display behavior, not just character encoding, so web browsers following the HTML standard will collapse multiple <space>s to a single <space>. Non-browser applications that use HTML encoding will not necessarily behave this way at display-time, e.g., later versions of Microsoft Word. Unicode provides 15 variations on space width and breakability, including: THIN SPACE &#8201; and NARROW NO-BREAK SPACE &#8239.[10] The following examples demonstrate the effect of these variations on a web browser—using space before punctuation to illustrate identical possible spacing variations following terminal punctuation. These spacing variations, combined with a standard word space, enable users to create custom sentence spacing—as alternatives to a single or double standard word space.

  • No space before the exclamation mark!
  • A no-break space before the exclamation mark !
  • A THIN SPACE (&#8201;) before the exclamation mark!
  • A NARROW NO-BREAK SPACE (&#8239;) before the exclamation mark !
  • A small-formatted no-break space before the exclamation mark !

See also edit

References edit

Citations edit

  1. ^ Microsoft 2010.
  2. ^ Eijkhout 2008. pp. 185–188. The default TeX spacing can be explicitly enabled with \nonfrenchspacing.
  3. ^ Lloyd and Hallahan 2009. See "iEditor" entry: 11 August 2009.
  4. ^ Free Software Foundation 2010. Main work: GNU Coding Standards
  5. ^ WC3 1999 9.1 White Space; Lupton 2004. p. 165.
  6. ^ How many spaces at the end of a sentence? One or two?
  7. ^ WC3 1999. 24.4. Character Entity References for Markup-Significant and Internationalization characters".
  8. ^ University of Chicago Press Chicago Manual of Style Online 2007.
  9. ^ How many spaces at the end of a sentence? One or two?
  10. ^ Korpela 2005; Unicode 2009; Sheerin 2001.

Sources edit

  • Eijkhout, Victor (2008). TeX by Topic, A TeXnician's Reference (PDF). Lulu. pp. 185–188. ISBN 978-0-201-56882-0. Retrieved 15 March 2010.[permanent dead link]
  • Free Software Foundation (12 April 2010). "5.2 Commenting Your Work". GNU Coding Standards. Free Software Foundation. Retrieved 17 May 2010.
  • Korpela, Jukka (3 May 2005). "Guide to the Unicode Standard". Characters and Encodings. IT and Communication. Retrieved 17 May 2010.
  • Lloyd, John Wills; Hallahan, Dan (10 November 2009). "Where's the Evidence to Justify Two Spaces?". Spacewaste. Wordpress.com. Retrieved 4 April 2010.
  • Lupton, Ellen (2004). Thinking with Type. New York: Princeton Architectural Press. ISBN 978-1-56898-448-3.
  • Microsoft. "Character design standards (5 of 10): Space Characters for Latin 1". Microsoft Typography. Microsoft. Retrieved 16 May 2010.
  • Sheerin, Peter K. (19 October 2001). "The Trouble With EM 'n EN (and Other Shady Characters)". A List Apart. A List Apart Magazine. Retrieved 17 May 2010.
  • University of Chicago Press (2007). One Space or Two?. University of Chicago Press. p. 984. Retrieved 8 February 2010. {{cite book}}: |work= ignored (help)
  • Unicode (2009). "Unicode Standard Annex #14: Unicode Line Breaking Algorithm". Unicode Technical Reports. Unicode. Retrieved 17 May 2010.
  • W3C (24 December 1999). "9.1 White Space". HTML 4.01 Coding Specification. W3C. Retrieved 17 May 2010.{{cite web}}: CS1 maint: numeric names: authors list (link)
  • W3C (24 December 1999). "24.4 Character Entity References for Markup-Significant and Internationalization characters". HTML 4.01 Coding Specification. W3C. Retrieved 17 May 2010.{{cite web}}: CS1 maint: numeric names: authors list (link)