Where NOT to break a line in citation output?

By Anonymous on Sat, 01/18/2014 - 23:20

Forums

I am in the process of setting up some fairly sophisticated templates for generating formatted citations in a source centric software application. I am planning on incorporating non-breaking spaces and hyphens at the template level. I have my own opinion, but would be very interested in the opinions of others as to where line breaks would be inappropriate in a sample source listing and citation such as:

New York. New York County. 1850 U.S. census, population schedule. Digital images. Ancestry.com. http://www.ancestry.com : 2013.

   1. 1850 U.S. census, New York County, New York, population schedule, New York Ward 15, Western Half, p. 38‑B (stamped), 76 (penned), dwelling 316, family 586, line 39, Ann Dougherty; digital image, Ancestry.com (http://www.ancestry.com : accessed 10 March 2013); citing NARA microfilm publication M432, roll 552.

I can't keep the URLs from turning into links on this post, but they would not be published that way.

Thank you for your input.

Paul Harris

Submitted byEEon Sun, 01/19/2014 - 09:45

Paul:

From a citation standpoint, there is just one basic rule that involves nonbreaking spaces; it relates to URLs and it's followed by most citation manuals. I quote here from EE 2.37:

LINE BREAKS & PUNCTUATION
When it is necessary to break a URL at the end of the line, we should not hyphenate the line break. If a URL contains a hyphen, we do not break the line immediately after the hyphen. A break may be made between syllables or after a colon, slash, or double slash. However, if we need to break the line near any other embedded punctuation mark, then we place the punctuation mark at the start of the next line.

The writing world also has two other longstanding rules:

  • When a name has a middle initial (e.g., John Q. Public), we don't break the line between the first name and the initial. Those two stay together.
  • When we break a word, the break should fall between syllables

Another consideration is typographical. Few readers appreciate great rivers of white space between words of text or extremely ragged right margins. The more rules we build into a system, the more likely we are to infringe upon the canons of good typesetting.

Submitted byPaul Harrison Sun, 01/19/2014 - 11:14

Thank you for your prompt response. I am aware of the three primary rules that you point out because I have read EE. I guess my question lies more in the typographic area, as well as the use of numbers with unit labels. I suppose I was looking for more rules!

For example, which, if any, of the following would be recognized as inapproprate or confusing if found in print?

   1. 1850 U.S. census, New York County, New York, population schedule, New York Ward 
15, Western Half, p. 38‑B (stamped) ...

or

... population schedule, New York Ward 15, Western Half, p. 
38‑B (stamped), 76 (penned) ...

or

... population schedule, New York Ward 15, Western Half, p. 38‑
B (stamped), 76 (penned), dwelling 316, family 586, line 39, ...

or

... New York Ward 15, Western Half, p. 38‑B (stamped), 76 (penned), dwelling 
316, family 586, line 39, ...

or

... image, Ancestry.com (http://www.ancestry.com : accessed 10 
March 2013); citing NARA microfilm publication M432, roll 552.

Submitted byEEon Sun, 01/19/2014 - 12:28

Paul,

Some people crave rules. Some people hate them. Software engineers do seem to fit into the first group. Those of us with a humanities background do lean toward only what is essential for clarity.

From the standpoint of what's essential vs. what maintains aethetics, EE would just "go with the flow" in all cases but one:

... population schedule, New York Ward 15, Western Half, p. 38‑
B (stamped), 76 (penned), dwelling 316, family 586, line 39, ...

In this case "38-B" is all part of the same page number. If you can write code to prevent hyphenation in the middle, that's good. Very good.