Re: various problems reported by David Kuehling

[David Kuehling]

>>>>> Jeff Kingston <address@hidden> writes:

>> 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.

I now understand.  The design description also clarifies this quite
well.  Still I see no reason for the double breaking, as all size
parameters where known to Lout when it decided which width to allocate
to the two columns.  It must have miscalculated.  Or there is something
I did wrongly in my document.  I'll look into it again...

>> 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.

The galley flushing algorithm makes my head hurt.  So I suppose this is
because the box' content was included in a @VExpand, thus there was no
more space for inserting something into the display's galley?  Anyway
around that, ie. having a box of fixed (outer) height and still being
able to insert something into the free space, using galleys?

>> 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.  

Sorry if what I wrote sounded too negative.  I'm just trying to get an
impression of Lout's worst-case behaviour.  Want to be sure I understand
the limits, when I'm going to implement japanese support later on...

> 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.

If this is how Lout works, then I can't complain.  I still have some
hacky ideas about how a column could automatically be set to the
remaining widths.  If I can find some time, I'll give it a try.

>> 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.

Note sure were the limit is.  A2 definitely failed.  But some sizes
between A2 and A3 seemd possible.

Thanks for your help,

David Kühling
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40