Re: proposal for inter-word spaces

[Tom Gordon]

Jeff Kingston wrote:
> 
> Here is my proposal for new options to control the way that Lout handles
> spaces in its input.  Please let me have your comments soon.
> 

I can live with your proposal:  I would use "compress" with "nosentences",
since compression is more important to me than obtaining extra space between
sentences.

But I would be happy with a solution which gave me both options, and I have a 
suggestion
which might work.

You write:

> 
> Please note that when "compress" is on there would be no easy way to end a
> sentence in the middle of a line and get the two spaces.  Compress would
> reduce any number of spaces to one, and "sentences" would not apply.  In
> other words, Lout would not distinguish between the cases
> 
>     Dr. Kingston
>     I came. I saw. I conquered.
> 
> and the spacing would be appropriate for the first case, not the second.
> I believe that any attempt to distinguish these two cases automatically
> is doomed to runaway complexity, and most of my correspondents seem to
> agree.  In English practically speaking you would either have to use
> "sentences" and end every sentence at end of line, or else type an
> explicit "&2s" between sentences, most likely with the help of a macro like
> 
>     macro "~" { &2s }
> 
> that would go in your mydefs file.  In short, "compress" is problematic.

Since the "punctuation white space" combination is MUCH more frequent between 
sentences than in other places, why not adopt the reverse convention, as in TeX:
A punctuation symbol followed by white space is assumed to terminate a sentence 
and
will be compressed to an intersentence gap (i.e. two spaces).  To defeat this 
assumption,
one could use a token, preferably "~", meaning, "this particular punctuation
symbol white space combination does not terminate a sentence."

For example 

        Dr.~Kingston

I can appreciate that these special rules are not very elegant from an system 
designer's
point of view.  Both the "~" character and the punctuation character would have 
to
be handled specially. ~ could not be implmented as a Lout macro, since it would 
need
to be handled during the compression pass, not afterwards during normal Lout 
processing.

Which raises the issue, would compression have a significant performance 
penalty?

Yours,

Tom Gordon

-- 
Dr. Thomas F. Gordon
GMD, FIT-KI; Schloss Birlinghoven
53754 Sankt Augustin, Germany
email: address@hidden
http://nathan.gmd.de/persons/thomas.gordon.html
phone: (+49 2241) 14-2665