Spacing between sentences?

[ERD50]

But the browser has to do cyber-editing, because it has to break up paragraphs into lines that will just fit into a box whose size differs depending on the dimensions you've assigned to your browser window.n As you watch some text, try resizing the browser window, and you will see how the text is "re-flowed" into new screen lines.n It's just what browsers do.n And part of the line breaking process (I mean dividing a paragraph into screen lines) is discarding of certain spaces, since after you have a screen line, you don't want to display any space that originally separated the first word of the line from the preceding word, nor a space that originally separated the last word of the screen line from the following word.

So the browser has to edit, and it has to discard some spaces.n You want to change the way it edits, so that it will display all of the sequences of spaces that wind up on the screen interior to a line.n Your proposal assumes that there is some global editing command available that tells the browser that.n I don't think there is.

Just for fun, I put two full word spaces between sentences in what I typed above, so we could see what your proposal, if it were feasible, would give us.

Sure, but that is just a matter of deciding when to start a new line to fit the width of the box. But that doesn't mean it needs to remove any white spaces. Let's see if this crude example works (use a fairly wide box), and I'll substitute "-" for " ".:


Here-is-some-
text.--It-is-in-a-
very-narrow-
box.


Here-is-some-text.--It-is-in-a-wider-
box.

So it line breaks when the next full word does not fit on the line. No typed white space removal required. That how my text editor does it when I resize the width.

-ERD50

 

[GregLee]

That how my text editor does it when I resize the width.

I doubt that very much.. The spaces at the ends of lines in your example, which you represent with hyphens, are of course not visible, so there is no point in having them there, and leaving them there will reduce the number of words per screen line, overall, and hence increase the number of screen lines required for some paragraphs, to no purpose.. I've seen and written some line breaking code in my day, and it just doesn't work the way you think it does.

 

[ERD50]

I doubt that very much. ....

Unless I'm misunderstanding what you are saying, it appears to work exactly as I described. Some screen shots of my text editor:

But actually, I'm not concerned with the wrapping, that would mess up a table of data anyhow. But the spaces within the width should be preserved (like the double space in my previous example, which were mid-box)

-ERD50

 

[GregLee]

Unless I'm misunderstanding what you are saying, it appears to work exactly as I described. Some screen shots of my text editor:

I appreciate the effort you've gone to here, but I don't understand your reasoning.. Why have you concluded that the interword spaces in the original text are shown at the ends of lines in the gedit screens?. I'm not saying you're wrong, maybe gedit does put those interword spaces on screen at the ends of lines, but how can you tell?. Do you think that if the spaces at the ends of lines had been removed that in some cases there would have been room for another word at the end of the line?

 

[ERD50]

I appreciate the effort you've gone to here, but I don't understand your reasoning.. Why have you concluded that the interword spaces in the original text are shown at the ends of lines in the gedit screens?. I'm not saying you're wrong, maybe gedit does put those interword spaces on screen at the ends of lines, but how can you tell?. Do you think that if the spaces at the ends of lines had been removed that in some cases there would have been room for another word at the end of the line?

I think we're getting sidetracked with the end-of-line space or no space. That isn't my concern.

My concern is to be able to simply use a mono-spaced font to display a few columns of data and pad it with spaces to have it all align for easy reading. For that, it is assumed that the text box is opened wide enough to view the columns w/o wrapping, or it is all jumbled no matter what else you do. Here's the same text, but the auto delete of the spaces used for padding messes it up, only the 'code' tags preserve the spaces, and make it easy to read.


Some numbers: 100,000 10,000 1,000
Other #'s: 99,999 9,999 999

Some numbers: 100,000  10,000   1,000
Other #'s:     99,999   9,999     999

I'd like it to work as it does with the 'code' tags, but those create other minor issues.

-ERD50

 

[GregLee]

I'd like it to work as it does with the 'code' tags, but those create other minor issues.

I think that is a very reasonable proposal.. You, Felici, and I are all in agreement that with a monospaced font, the typographically best way to separate sentences is with two spaces, and, as you point out, having gone that far, we could easily just retain all multiple spaces within a line and gain the ability to do tabular alignment in simple cases.. And without the "code" tags.. But we still have the problem that it appears to be impossible to do this by just modifying the forum software.

 

[RunningBum]

So..... have you gotten an adequate answer? If not, and to summarize the preceding posts, the forum software strips out the extras. You can use white characters if you really need more space but all that unoccupied space increases scrolling for
readers

Yep, and I kinda stopped following this! I can live with it.

 

[rescueme]

As to the OP's question, and based upon my primary education being provided by the "penguins" (e.g. nuns), I was always instructed to use punctuation in a manner that would allow the writing to be read out loud, with the punctuation being used to tell the reader how to speak.

That meant two spaces between sentences (along with the period), two lines between paragraphs(two "CR"'s or carriage returns - for the old folks), and speech stress being provided by underlines.

Exclamation points at the end of the sentence were only used to express excitement in the utterance (such as an organism, which was frowned upon by my instructor ).

Anyway, that's what "sister said" ....

 

[ERD50]

...we could easily just retain all multiple spaces within a line and gain the ability to do tabular alignment in simple cases.. And without the "code" tags.. But we still have the problem that it appears to be impossible to do this by just modifying the forum software.

I disagree that it is impossible for the forum SW to do this.

When I enter this text into LibreOffice, and export it as html, my browser displays it with all multiple spaces retained, just as it appears here (specify a fixed font in the Word Processor):

XXXXXXXXXXXXXXXXXXXX:123456Next
With 6 spaces intact:      Next
With 2 spaces intact:  Next
With 1 spaces intact: Next

If the page created by LibreOffice can do it with standard html, so can the forum SW.

-ERD50

 

[kombat]

Yes, the forum SW does not remove them from what you type. And yes, the browser does not display them. But, the browser does so because it is following the commands (or lack of commands) that are listed on the page that the forum SW produces. I don't know enough about the details of html commands to know if this is the default, or if it must be stated explicitly to retain the spaces.

Yes, this is the default (as it should be), and yes, it must be stated explicitly to retain the spaces. The forum administrators would do this by specifying particular CSS properties to override the browser default. Personally, I don't think they should (and frankly, I'm not even certain what specific CSS properties would accomplish this - I'm merely assuming it's in there somewhere).

No, I don't want any 'tricks' applied,

Overriding the default behaviour with obscure CSS settings would be a "trick."

I just want the forum SW to embed the command into the web page that it produces to tell the browser to display the consecutive white spaces as they were typed.

I disagree. As I said before, there's a very good reason that such formatting is left up to the individual browser, and it's because the author cannot be certain what kind of device the content will be displayed on. The spacing you're asking for would probably look fine in your browser, on your computer, with your particular monitor resolution. But how would it look on an iPod? A Kindle? A PS3? The programmers who wrote the browsers for all those various platforms know how best to render text, so it doesn't make sense to try and override them. If anything, you should be hounding the authors of FireFox (or whatever browser you're using) to provide a user-configurable setting that would allow you to specify you want double-spaces preserved. Other users could leave it as the default. It would be up to the individual user. As it should be.

 

[GregLee]

Browser and forum software is evolving all the time to make the text we use to have these conversations more expressive and more pleasing to the eye.. The forum software here seems quite advanced, to me, and has better facilities for displaying links and graphics than I've seen elsewhere.. But there is lots more that could be done.. Look at some of the math and other technical entries in the Wikipedia; the authors of the Wikipedia software have worked hard to produce some remarkable results.. I expect some of that advanced formatting to make its way down to our local browsers soon, so we can all use it.

 

[ERD50]

Yes, this is the default (as it should be), and yes, it must be stated explicitly to retain the spaces. The forum administrators would do this by specifying particular CSS properties to override the browser default. Personally, I don't think they should (and frankly, I'm not even certain what specific CSS properties would accomplish this - I'm merely assuming it's in there somewhere).



Overriding the default behaviour with obscure CSS settings would be a "trick."



I disagree. As I said before, there's a very good reason that such formatting is left up to the individual browser, and it's because the author cannot be certain what kind of device the content will be displayed on. The spacing you're asking for would probably look fine in your browser, on your computer, with your particular monitor resolution. But how would it look on an iPod? A Kindle? A PS3? The programmers who wrote the browsers for all those various platforms know how best to render text, so it doesn't make sense to try and override them. If anything, you should be hounding the authors of FireFox (or whatever browser you're using) to provide a user-configurable setting that would allow you to specify you want double-spaces preserved. Other users could leave it as the default. It would be up to the individual user. As it should be.

Thanks for the reply (I'm also guessing that CSS comes into play here, but I'm over my head on this stuff).

But I'm not following how having this displayed (pretend the code box does not exists:

Some numbers: 100,000  10,000   1,000
Other #'s:     99,999   9,999     999

versus having it show up like this:

Some numbers: 100,000 10,000 1,000
Other #'s: 99,999 9,999 999

is going to be affected by whether I view it on my computer, iPad or other device. If my screen is not wide enough to display the columns, it's getting jumbled regardless. And in a post like this, I'm not going to be normally putting together 80 char wide columnar data. Just little notes. The downside seems small compared to the upside.

I see greglee's post - I agree, if the user could over-ride the default, it would probably be best. I don't know if a user can define their own CSS for a site? Seems I've seen references to that, but it is beyond my present (very limited) knowledge (but I like to learn).



-ERD50

 

[M Paquette]

Thanks for the reply (I'm also guessing that CSS comes into play here, but I'm over my head on this stuff).

But I'm not following how having this displayed (pretend the code box does not exists:

Some numbers: 100,000 10,000 1,000
Other #'s: 99,999 9,999 999

versus having it show up like this:

Some numbers: 100,000 10,000 1,000
Other #'s: 99,999 9,999 999

is going to be affected by whether I view it on my computer, iPad or other device. If my screen is not wide enough to display the columns, it's getting jumbled regardless. And in a post like this, I'm not going to be normally putting together 80 char wide columnar data. Just little notes. The downside seems small compared to the upside.

I see greglee's post - I agree, if the user could over-ride the default, it would probably be best. I don't know if a user can define their own CSS for a site? Seems I've seen references to that, but it is beyond my present (very limited) knowledge (but I like to learn).

-ERD50

It will vary with the precise details of the computer font installed on the particular device. You could take things to the extreme and specify within the code for the web page that the content be rendered with 12 point New Times Roman, and there would still be room for variations, as for example between the TrueType font layout meta programming within different versions of New Times Roman as shipped for different devices. (Yes, most typefaces include not just glyphs and their layout information, but also include a sort of program that is run by text layout code to determine just which glyphs should be used, and how those glyphs should be permuted.)

To get the desired behavior for whitespace the user content will have to be specified to appear as a fixed width font with no layout options, forcing one glyph per encoded character with no permutations or layout options possible.

If the intent of the HTML generated for the site is to support presentation on multiple devices, with varying layout and no guarantees of what specific font implementations are present, I'd have to say that folks trying to do page layout with varying whitespace character counts are not going to be particularly successful. This just might be part of why the HTML "table" tag was developed.

http://www.w3schools.com/html/html_tables.asp

 

[ERD50]

It will vary with the precise details of the computer font installed on the particular device. You could take things to the extreme and specify within the code for the web page that the content be rendered with 12 point New Times Roman, and there would still be room for variations, as for example between the TrueType font layout meta programming within different versions of New Times Roman as shipped for different devices. (Yes, most typefaces include not just glyphs and their layout information, but also include a sort of program that is run by text layout code to determine just which glyphs should be used, and how those glyphs should be permuted.)

To get the desired behavior for whitespace the user content will have to be specified to appear as a fixed width font with no layout options, forcing one glyph per encoded character with no permutations or layout options possible.

If the intent of the HTML generated for the site is to support presentation on multiple devices, with varying layout and no guarantees of what specific font implementations are present, I'd have to say that folks trying to do page layout with varying whitespace character counts are not going to be particularly successful. This just might be part of why the HTML "table" tag was developed.

HTML Tables

Yes, I just find it odd that if I go to the trouble of specifying a mono-spaced font (which is not the default, so I'm taking a specific action), and it is in a posting text box (not general page layout stuff) that it doesn't also preserve the spaces.

Tables are fine, but they take a little extra work to get the "|" char in there.

Some numbers:	100,000	10,000	1,000
Other #'s:	99,999	9,999	999

Some numbers: |100,000 |10,000 |1,000
Other #'s: |99,999 |9,999 |999

-ERD50

 

[GregLee]

Yes, I just find it odd that if I go to the trouble of specifying a mono-spaced font (which is not the default, so I'm taking a specific action), and it is in a posting text box (not general page layout stuff) that it doesn't also preserve the spaces.

I agree with you here.. Since mono-spaced fonts are ugly, there's a good chance that when a user specifies Courier New, he's doing that because of an alignment issue.. So the browser ought not to sabotage his efforts by making alignment essentially impossible for ordinary paragraphed text.

 

[East Texas]

Sigh... it was all so much easier in 9th grade typing class. "Put one and only one space after the punctuation ending a sentence 'cause I said so..." and that was that.

 

[M Paquette]

I agree with you here.. Since mono-spaced fonts are ugly, there's a good chance that when a user specifies Courier New, he's doing that because of an alignment issue.. So the browser ought not to sabotage his efforts by making alignment essentially impossible for ordinary paragraphed text.

It's an interesting point. The HTML specification leaves the interpretation of sequences of white space separating "words", or "sequences of non-white space characters" to the user agent (such as the browser) to identify such words and lay them out according to the conventions of the particular written language (script) and target medium.

The layout operation may include putting space between words, although conventions for inter-word spacing vary from script to script. The HTML 4 specification, Section 9, specifically calls for user agents to collapse input white space sequences when producing output inter-word space, except when within a PRE HTML element, used for preformatted text.

If you wish to have all agents preserve input white space sequences when a fixed pitch font is selected, in effect declaring all uses of fixed pitch fonts to be PRE elements, you'll want to lobby the HTML Working Group. Note that what you are requesting is the codification of an implicit behavior, currently obtained by explicit means, the PRE tag. Given that HTML tightly adheres to an explicit ontology I would suggest that you may have some work ahead of you.

There's a friend of mine that used to be on one of the W3C committees lurking here. Perhaps he'll chime in...

As an alternative, you might lobby for the phpBB folks to modify the software so as to force all fixed point content to always be bracketed with the PRE tag. The CODE metatag does something like this, selecting both a fixed point representation and adding the pre-formatted markup.

 

[GregLee]

If you wish to have all agents preserve input white space sequences when a fixed pitch font is selected, in effect declaring all uses of fixed pitch fonts to be PRE elements, ...

As I understand the proposal, for portions of text in a monospace font, not all white space would be preserved, only space characters, and word wrap would not be disabled.. We might ask ERD50 what he'd like to do about TAB characters.

 

[Nords]

I have had a keen interest in the one space or two debate that winger referenced, as I learned to type on a typewriter (old fart) and thus put 2 spaces between sentences. The youngsters, okay anyone under 40, learned the 1 space that is the convention now. I'll never get the hang of it, I suspect.

Bahahahahaha!
And put me down as another oldie who learned how to type on a MANUAL typewriter. I will never adjust to the one space after a period...muscle memory is permanently fused to add a double space on every device I use.

I think the good news is that we can type any content we want (I'm a two-space dinosaur too) and let the software worry about the formatting.

It's also probably safe now for me to throw out the spare Pica and Elite balls that go with my IBM Selectric...

Now I'm worried that people on other forums are going to find out what we discuss all day, and make fun of us.

I'd rather get teased for shaving a space after a period!

 

[ERD50]

We might ask ERD50 what he'd like to do about TAB characters.

Now that's another can of worms!

I've always somewhat disliked tabs. The problem seems to be, unless the 'ruler' that was used when the tabs were generated is carried with the text, the output is an unknown. So I would not even want to use tabs in a post, unless it included the ruler (if that's the right term for the tab spacing thingee).

One of the links MP provided seems to agree with me:

We strongly discourage using horizontal tabs in preformatted text since it is common practice, when editing, to set the tab-spacing to other values, leading to misaligned documents

.

If the original author set the tab to 12 spaces, how can the output know that? I think some text export functions convert the tabs to their equivalent spaces, so the original intent is preserved, but I'd need to test that.

-ERD50

 

[Meadbh]

Get a life, people!

 

[Sarah in SC]

I think the good news is that we can type any content we want (I'm a two-space dinosaur too) and let the software worry about the formatting.

It's also probably safe now for me to throw out the spare Pica and Elite balls that go with my IBM Selectric...

I'd rather get teased for shaving a space after a period!

Yes it is safe to throw out your pica balls. And the elite balls, though I'd check
with DW first.

 

[TromboneAl]

Organism?

 

[GregLee]

... The forum administrators would do this by specifying particular CSS properties to override the browser default. ... The spacing you're asking for would probably look fine in your browser, on your computer, with your particular monitor resolution. But how would it look on an iPod? A Kindle? A PS3?

I ran across a reference which may have some relevance to these issues.. It is a description of two methods for using Knuth-Plass justification on the Kindle, and (I gather) could be used for some browsers.. From the article by Kevin Lynagh, Kindle typography:

Figure 2: Knuth & Plass justified text, rendered by setting the CSS word-spacing property for each line. Note that the right margin is very slightly ragged; this is because WebKit ignores subpixel word-spacing values. Text from The Frog Prince, by the Brothers Grimm.

I suppose you'll be wondering what justification has to do with spacing between sentences.. Here is the relevance.. Knuth describes text as boxes (letters, words, and so on) stuck together with glue (white space) with associated penalties.. At the end of the sentence, the glue can be stretched out more, with a lower penalty, than the glue between words, with the consequence that, typically, the glue (white space) between sentences will come out wider than the glue between words.. This will be true even if paragraphs are not fully right justified.. So, if you can justify using Knuth-Plass, you can also turn off full justification if you want, but still get extra space between sentences in most cases.

 

[haha]

Get a life, people!

It must be that time sometimes weighs heavily.