Re: various problems reported by David Kuehling

[David Kuehling]

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

> I guess David has found lots of problems, and for the most part he's
> found workarounds for them.  I'm just going to try to explain (not
> excuse) what has been happening.

Thanks for your answer.  I printed the poster today (on 16 sheets of A4,
still have to glue it together...), and looking back, I definitely spent
more time on content than I spent on fighting with Lout :).  Lout's
graphics abilities came in very handy.  With some factorization (`def')
the lout-source was even quite readable.

>> Unfortunately Lout seems unable to handle page sizes much greater
>> than A3.

> Lout uses 32-bit integers to represent the sizes of things; one cm is
> represented by the number 567 (one point is 20).  There is also a
> short length used for the gaps between things, and other distances
> expected to be short (e.g. character metrics).  It ought to be ample.
> I should look into this and perhaps get rid of all short lengths.
> No-one cares about memory any more.

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

>> Seems like Lout broke the lines twice First just
> normally, and then a second time to break lines that were still too
> long.

> 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.  This would happen in unconstrained two-column text
within a constrained box, something like:
 
  12c @Wide {
    ||.3ce # left margin
    {  
      column one 
    } ||.5ce { 
      column two 
    } 
    ||.3ce {}  # right margin
  }

Lout would have to split the available space (12c-2*0.3c) into two
columns and when it does so should make sure that the resulting widths
don't conflict.

>> Even if I change this to 50c @Wide @Scale..., the output looks
>> excactly the same, and Lout does not output any kind of error or
>> warning.

> Presumably you don't have those 50c, and Lout is cutting them back to
> something smaller.  It doesn't given a warning when it does that.  It
> would be nice if it did, but there are cases where it is the natural
> thing to do, and then the warnings look funny, so I took them out.

This is similar to the above problem.  Even if I set this to smaller
sizes which actually made sense, Lout would still cut the size to
something that was about half the available width of the box.  The
source was something like:

  18c @Wide {
    ||.3ce # left margin
    12c @Wide @Scale @IncludeGraphic {...}   # left column
    ||.5ce
    { some text }   # right column
    ||.3ce {}  # right margin
  }

Lout seemed to not be able to calculate, that the right column of text
should be set to 18c-12c-0.5c-2*0.3c = 4.9c.  It always limited the left
column's size to presumably 8.45c.  

>> @CD 12c @Wide @Scale @IncludeGraphic{ "plots/cca-schema2.eps" }

> With a display, you make everything a lot harder for Lout behind the
> scenes.  On its first attempt it allocates no space at all, so later
> on when the display arrives and tries to squeeze in, it's going to be
> hard to fit it in.

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

  {
    ...some text...
    <display won't work here>
  }
  //.5ce
  {
    ...some text..
  }

> 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...  Also, what makes this difficult is, that Lout doesn't
have arithmetic.  I can't define the width of the box as a constant
somewhere and then just use it within formulas to derive the width of
paragraphs etc.  That's why I liked the idea of specifiying some widths
of container boxes, margins, of one column etc. and let Lout figure out
the other widths by simple substraction.

Is there the possibility that what I have found is actually a bug?  I
could try to construct some minimal source that reproduces the
problem...

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