Re: too small inter-word spacing

[Joerg van den Hoff]

On Sep 04 2008 (Thu,  8:09), Jeff Kingston wrote:
> Michael Piotrowski <address@hidden> wrote:
> > For example I have used
> > 
> >   @InitialSpace {compress +0.25s}
> > 
> > for some documents where I found the interword spacing too tight.

is this somewhere in the docs? I did'nt find it. and it seems not to
work for me at all: is this request honoured only at the beginning of 
a document or also interspersed with the text?

> 
> This works in simple cases, but it has the problem that Lout returns
> to the width of a space character every time there is a change of font.
> 
> Joerg van den Hoff <address@hidden> wrote:
> > I understand that at some point always a threshold will be tripped
> > (this would happen with groff, too) but why is hyphenation not used?
> 
> The algorithm used by Lout (following TeX) is to first try setting the
> paragraph without hyphenation, then, if the badness value of the result
> is above a certain threshold, to try again with hyphenation.  So if
> hyphenation is not used, that will be because the threshold was not
> reached.
> 
> > C 32 ; WX 250 ; N space ; B 0 0 0 0 ;
> > 
> > would you mind a short hint on the meaning of the last 4 numbers
> 
> These represent the bounding box of the space glyph.  Since the
> glyph is blank the box has zero size, but the important thing is
> the WX field, which (in PostScript) determines how far to the right
> the next character will be placed, and (in Lout) also determines
> the ideal inter-word spacing.

ah, thanks.

for your information: I tried this out for a 1 1/2 page document (some
600 words), comparing the typesetting of the ~ 10 paragraphs in `groff'
and `lout'. empirically, I got to some extent similiar line breaks (and
word spacing) in Paltino Roman when increasing the space width from
250 to 375, i.e. by 50% -- that's quite a bit. of course groff is not
some kind of gold standard how it has to be done, but `groff' is at
least a very decent typesetting system. and seems to use, on average 50%
larger inter-word spacing than lout. mh.

and as an accidental observation: if one increases the space width to
something nonsensical such as 1250, the postscript output does no longer
maintain the correct A4 pagewidth of 595 points (I think), but, for this
value of 1250, the pagewidth is increased substantially, namely to 765.
where the text still occupies the original space, but the right page margin
seems increased. probably not important, but
is this possibly indication of a bug somewhere?


> 
> On thinking it over, though, it's likely that you are happy with
> the ideal spacing but not happy with Lout's willingness to compress
> it quite a lot in preference to hyphenation.  In that case, what

exactly. but, as it seems from my playing around with the space width above,
lout is nearly always compressing spaces quite a bit (even
compared to groff, which very probably does exactly the same itself, so
that's "compressing relative to compressed groff spacing, not to ideal
spacing"). is this right? are spaces always compressed, never expanded?

> you need to change is not the width of the space character but
> the compressibility.  You can do that by changing the value of
> the constant MAX_SHRINK in file z14.c and recompiling.  I think
> the current value,
> 
>     #define MAX_SHRINK 4
> 
> means that Lout is willing to shrink a space character to 1/4 of
> its usual width (with a penalty, of course).  So if you reduce
> it to 3 or 2 you should get less shrinking.  Alternatively, you
> could increase SQRT_TIGHT_BAD so that Lout is willing to shrink
> just as much, but gives a higher penalty when it does.  Or both.
> 
> Yet another possibility is to reduce HYPH_BAD, the threshold for
> trying hyphenation.

thank you very much for this information. 
I'll carefully save this mail hoping to try it out some time soon.
but "custom-compiling" my own version sure is 'ultima ratio'.

> 
> You'd be mad to adjust these parameters on the basis of the
> results of one paragraph.  Do it on an entire document so you
> can see the global effect.

sure. and customizing by recompiling is not quite the right approach
for joe user anyway. 

I also believe that such low level fiddling with central aspects of the
typesetting should best be avoided on the user side anyway. the problem
I see presently is that in the comparison "lout vs. groff (and heirloom
troff -- another very fine classic troff implementation plus very nice
improvements) vs. TeX" I don't encounter similar corner cases  of really
bad tight spacing. in view of the fact that lout apparently completely(?)
adopts the TeX algorithm I find this all the more surprising.

so, while I think I understand your explanation what's going on (trade
off between space compression and activation of hyphenation), I then
would draw the conclusion that the current settings are not really lucky
(no offense meant -- I'm defintitely impressed by what I've seen from lout
up to now): 

compression down to 1/4 of usual width seems near to what's
happening in my example: looking at the usual average space width in
formatted output and mentally taking 1/4 of that is quite near the
inter-letter spacing and that seems not to make much sense to me:
inter-word spacing should always be clearly discernable larger than
inter-letter space. otherwise the reader at times really has
difficulties to decide where the word boundaries are.

I realize that these settings always have to find a compromise so that
it's looks alright (or, rather, good, but not optimal) everywhere.
but I really would argue from what I've seen up to now (admittedly a
sample of limited size) to change the MAX_SHRINK define (and maybe the
others: you definitely know better than me) in the official lout
version. do you think this is worth contemplating?

another idea: do you think it's worth to allow the user in the standard
setup files to choose between, say, "tight spacing" (which might be the current 
behaviour)
and "loose spacing" which would select an accordingly modified set
of parameters (converting, e.g., the current defines to two-valued arrays,
where the user selection leads internally to selection of first or
second component). "loose spacing" would/could then make lout behave more
similiar to the other formatters (troff, TeX) in this respect, which
at least would do no harm.

compared to giving the user direct access to the
current `#defines', controlling the line breaking and spacing via user-settable 
parameters
this approach would have the advantage that the users can't mess up the
typesetting completely ;-). 

"nonsense", "impossible", or "easier said than done"?


anyway, many thanks for lout,


joerg


>  
> Jeff