Re: various problems reported by David Kuehling

[Jeff Kingston]

> I thought something like this.  Still 100cm = 56700 is far less than
> 2^32.  Or is this actual 16.16 bit fixed point arithmetic?

As I say, it needs looking into.

> > Yep, this will happen if there are two @Wide symbols giving
> > conflicting information about how much space there is.  Not pretty but
> > then it doesn't often happen either.
> 
> But there were no conflicting information.  That's why I thought this
> would be a bug.

If Lout decides at an outer lever to give so much space to a column,
then it is just as though it had enclosed the column in a @Wide symbol
of that width.  And it decides this purely on the basis of the unbroken
width of the columns concerned: the algorithm for allocating available
space to columns does not know that a wide (because unbroken) paragraph
is a lot easier to break than something enclosed in 20c @Wide { ... }.
This is why the advice is to fix your problems by making wide things
narrower, rather than narrow things wider.

> That means displays cannot work within an object without a fixed
> vertical size?  For example within vertical concatenation?

Just the opposite.  Most objects lie in a "body text" galley, i.e.
running text of fixed width but no particular height, not yet inserted
into pages, and so they find that there is infinite vertical space
available to them, but only limited horizontal space.

> > As for general advice, I would say that the fastest way to get exactly
> > what you want in these circumstances is to enclose every paragraph of
> > text in a @Wide symbol, and make sure that everything adds up to
> > something that will fit.
> 
> I would aggree, but sometimes this just seems to be impossible.  Take,
> for example, @ShadowBox.  If you set a width by something like @Wide
> @HExpand @ShadowBox, how would I calculate the available inner width?
> The default inner margin is defined in units of `f', which will vary
> with font size...

If your aim here is to prove that Lout is not perfect, I agree with
you.  If your aim is to get your document laid out, then my advice
is as follows.  If the whole assembly is a column (by which I mean,
something that Lout has to make a choice about as to how much
horizontal space to allocate to it), then enclose the whole assembly
in a @Wide that will work.  If there are columns inside the box,
and you are not happy with the allocation of space to those columns
that Lout is making, then enclose those columns (the wider ones anyway)
in @Wide.  It's true that it's hard to work out how much space you
have to play with there.  You probably are going to have to supply
a margin value for @ShadowBox that you can calculate with, i.e. in cm.
You don't have to live with the 0.3f default margin, or whatever it is.

> Is there the possibility that what I have found is actually a bug?

Not in the allocation of available width.  I would call not being
able to handle pages larger than A3 a bug.

Jeff Kingston