(Ted Harding) <[EMAIL PROTECTED]> wrote:
> On 03-Sep-06 Gunnar Ritter wrote:
> > .ds a \ \h'-1u'
> > .ll \w'some\*a text and a \(br'u
> > some\*a text and a \(br
> > some text and a \(br
> >
> > (The box rules should not align.)
> >
> > Gunnar
>
> That's an interesting comment. I've tried tracing the consequences
> in the source code, but got lost!
It is as simple as I wrote. The line which is passed to
possibly_break_line() is expected to end with a space
character that had been added by space_newline() before.
This is why the width of its last character is substracted
when it is considered whether to spread it. If a zero-width
space is added to the line, the code does not work anymore.
> To follow up on the observation that prompted my original post.
> I've done an experiment.
In the short, self-contained example above, it can be seen
that the critical distance is exactly the width of a space
character under these conditions (remove the "\h'-1u'" and
the second line is not spread anymore). This is consistent
with the observation in the source code.
> Now, 1235u + 4265u = 5500u, or 5.5p; and I am working with 11pt
> text, so the range over which I can vary the unstretched line
> length is pointsize/2 (or 0.5m). And, for what it is worth, I'm
> using the defaults for \n[.ss] and \n[.sss], namely 12/36m.
>
> 0.5m is not a big margin. However, it is not clear why this is
> the critical value.
Your example ends with "ff.)", which is a sentence-end character
followed by a transparent character. space_newline() will add
twice the size of a space character in this case (it includes
the sentence end space).
The width of a single space character in the -Tps TR font is
250/1000 font units or 0.25m. Thus the critical width in your
example is 0.5m or twice the size of a space character, again
consistent with the observation in the source code (under the
assumption that you used TR or another font with the same
space width).
The only difference is that your example includes a sentence
end space but mine does not. This can be confirmed by
.ds a \ \ \h'-1u'
.ll \w'some\*a text and a \(br.)'u
some\*a text and a \(br.)
some text and a \(br.)
which also causes the box rules to align.
> (And I'd like to reiterate that I regard this behaviour, up to
> a point, as desirable.
Looking at the source code, it certainly qualifies as a bug.
This is not a typographical statement - different opinions on
this can be found in the typographical literature.
> Certainly in a paragraph, if the last line
> is almost as long as the full line, then it will look better if
> stretched to fill, so that you don't get a nasty little notch at
> the bottom right-hand corner. But I'd like to have some control
> over the value -- of X -- at which it happens!)
Yes. Control over this clearly is desirable.
I would suggest to fix the bug in the source code and to otherwise
use the groff code I posted on Thu, 31 Aug 2006 19:53:18 +0200 if
this is desired as a feature.
Gunnar
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
