# Talk:Line wrap and word wrap

(Redirected from Talk:Word wrap)
WikiProject Typography (Rated Start-class, Mid-importance)
This article is within the scope of WikiProject Typography, a collaborative effort to improve the coverage of articles related to Typography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start  This article has been rated as Start-Class on the quality scale.
Mid  This article has been rated as Mid-importance on the importance scale.
WikiProject Computing / Software (Rated Start-class)
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start  This article has been rated as Start-Class on the project's quality scale.

## Greedy Algorithm Pseudocode

That naive algorithm is indeed naive, it doesn't work properly: Assume the line width to be 6 and that you have two words three letters long. It seems to ignore the space between them and will output 7 letters on one line even though it can break the word. This may have been true once, but it is no longer; however, there remains a bug: if we are considering a word of length L and there are L characters left on the line, we will add the word plus a space, overflowing the line by one character. 128.95.41.178 21:36, 6 February 2007 (UTC)

## Insert line breaks where?

While it's nice to calculate the optimal cost, that's not what we're really interested in. It isn't clear how one can use this algorithm to determine where to insert line breaks. Can I get a hint? — indil 01:02, 15 September 2006 (UTC)

## Where is the "optimal" algorithm used?

I initially implemented the "optimal" algorithm for wrapping a small amount of text in a bitmap image. The article seemed to suggest that the greedy algorithm yielded word wrapping inferior to the recursive algorithm, so I decided to use the recursive one. Unfortunately, the article failed to mention that the word wrapping you get with most word processors uses the greedy algorithm. I added a line to mention this fact and hopefully save everyone else working with this stuff some time.

My question is: Where is the recursive algorithm used?

indil 09:23, 22 September 2006 (UTC)‡

## Common usage

This page should mention the commonly-used number of columns for wrapping in documents, email, etc. —Preceding unsigned comment added by 72.213.54.227 (talk) 12:52, 6 January 2008 (UTC)

## An interesting feature

It seems that one of the standard implementations of line-wrapping code treats + as a "breaking" character - which is perfectly sensible for words like "hue+cry", but a bit unfortunate for "c++". (I've put a screenshot here as a demonstration). Other than hyphens, what other characters exhibit this behaviour? Shimgray | talk | 12:17, 19 August 2009 (UTC)

### You should box the "c++"

The name represents pretty well what's wrong in c++. Here we saw it again. Anyway you shouldn't leave it for the line-wrapper as-it. Make a box around it if you can. And if you can't.. well you should find a tool that can if you are bothered by it.

## The dawn of word wrap

Here's a pre-computer reference to an automatic word wrap system.[1] Western Union developed a "page printer control unit" in 1955. This was to to handle printing on page printers of content which came in without line breaks. The algorithm was "CR-LF is inserted following the first space character encountered after 58 characters have been tallied. If a space does not occur by the time 70 characters have been counted, CR-LF will be inserted following the 70th character." This is even simpler than the "minimum length" algorithm, but doesn't require buffering the text. WU had to build this out of relays, so the algorithm had to be simple. --John Nagle (talk) 05:24, 7 April 2013 (UTC)

Nice find. I added a brief history section for this. —David Eppstein (talk) 14:37, 7 April 2013 (UTC)

## Undiscussed merge of hard and soft return

Two and a half hours is nowhere near long enough a discussion period for page merges! Andy Dingley (talk) 00:14, 5 June 2013 (UTC)

True, but it seems ok for the B part of WP:BRD. If you want to R, we can then start the D part. —David Eppstein (talk) 01:06, 5 June 2013 (UTC)

## How desirable is a line break or indent after a hard return?

"With a hard enter, paragraph-break formatting may be applied (either indenting or vertical whitespace)"
or
"With a hard enter, paragraph-break formatting *should* be applied (either indenting or vertical whitespace)"?
In other words: are you allowed / is it considered good style to just hit enter in a document and keep on typing to distinguish sections of a paragraph (sub-paragraphs)? Or is it preferable to make a clear distinction between paragraphs (by indenting or a white line).
Example:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute
irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. <=== like so
Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt
mollit anim id est laborum."
<=== preferable paragraph distinction
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
PizzaMan (♨♨) 20:23, 26 October 2014 (UTC)
Short answer: It is preferable to make a clear distinction between paragraphs (usually by first-line indent, vertical space, or a little of both; occasionally by other methods, such as the run-in heads used in this reply). It is considered poor style to fail to make a clear distinction, but you are allowed, in the sense that no police officer is coming to arrest you if you don't. But yes, it's bad form. At best, it makes the reader's brain work a little harder than necessary for no good reason; beyond that, it can make the reading tedious and frustrating, wasting the reader's time and effort and pissing him/her off. So if you intend a paragraph break semantically, show it visually. That's the right way to do things, even if it's not the only way that's lawful.
Longer answer: Doing it at all (for aforementioned reason) is the first step (versus failing to do it). That's whether to do it. As for how to do it, there are various ways, any of which is better than nothing—but some are smarter/better ways and some are dumber/poorer ways. The smart ways are machine-readable; the dumb ways are human-readable but not machine-readable. (Talking about machine readability in the markup languageparsing sense—never mind that with sufficient AI, anything human-readable would also be machine-readable.) For example, in Word or Wordperfect, you could do it by typing 2 manual line breaks in a row, but that's not the smart way, because the computer doesn't know that semantically you intended a paragraph break, which should have been marked with a hard return. Doing it with 2 hard returns in a row is a perfectly cromulent way of doing it, and is by far the most practical way in many environments (most text editors and online text fields). In word processing and professional XML and HTML, the 2-hard-returns trick is not the right way to do it (there it is properly done with the pure logic of paragraph-level formatting applied to a single hard return), but even in those environments, it's good enough for anyone who doesn't know any better—gets the job done and way better than sticking the reader with no clear indication. HTH. Pinnate foliage (talk) 23:54, 27 October 2014 (UTC)
Thank you. I agree with all you said. The only question that remains, is if we should replace "may" with "should" or "should preferably" in the article.PizzaMan (♨♨) 16:21, 6 November 2014 (UTC)
Ah, I see. Besides the meanings of "may" as in "allowed" and "should" as in "preferred", there is also the idea of "can" (as in "makes it possible"). I decided to change the wording in the article to "can (and should) be applied". Pinnate foliage (talk) 02:34, 7 November 2014 (UTC)