Talk:Line wrap and word wrap

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)

Linear-time implementation of Knuth-Plass

Today, an anonymous editor without explanation blanked the link to my linear-time implementation of Knuth-Plass, and (when I reverted the change as possible vandalism, as anonymous unexplained blanking is usually considered to be) admin Davidgothberg repeated the blanking, on the basis of my conflict of interest, still with no content-based explanation of why removing that link is an improvement. As WP:COI states, "Editing in an area in which you have professional or academic expertise is not, in itself, a conflict of interest. ... When in doubt, defer to the community's opinion." So here I am, deferring to the community's opinion. I don't feel strongly either way about whether the link should stay or go. What I do feel strongly about is that the decision should be made on the basis of what's best for the article and not who made what edit when. So can I see some content-oriented discussion, please, about whether to include it? I will abstain from further input on this issue, myself. —David Eppstein (talk) 17:09, 30 April 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 language–parsing 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)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Line wrap and word wrap. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070930015603/http://www.nabble.com/Initial-soft-hyphen-support-t2970713.html to http://www.nabble.com/Initial-soft-hyphen-support-t2970713.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:54, 16 May 2017 (UTC)