On Wed, Feb 25, 2004 at 11:19:54AM +0100, Alfredo Braunstein wrote:
> I've spent a bit of time today trying to figure out our current "cosmetic"
> drawing problems with floats. This is my understanding of the situation
> (can be wrong):
>
> Under 1.3.x open floats used to fill the full row.
> Right now there is a half-baked solution to have things like
>
> blah blah [inset] blah blah
> +------------------------+
> | text |
> +------------------------+
> blah blah blah blah blah blah blah blah blah
Which is better than the original IMHO but not perfect.
In fact, I'd prefer
> +-----+------------------+
> blah blah |inset| text | blah blah
> +-----+------------------+
> blah blah blah blah blah blah blah blah blah
I.e. 'inline' even the expanded version as long as possible by
dropping that space between the 'inset button' and the text by
basically 'incorporating' the button in the text and shifting
the text up by one line (so similar)
> Keeping this new behaviour IMHO would mean we have to fix:
>
> 1) to compute the row fill/separator fill size *out* of
> redoParagraphInternal in a second pass: we need a first pass to compute the
> maximum row width in the inset and then after that we can compute fills.
This would be sensible in any case as this breaks the algorithm into
intellegible chunks (and is, btw, closer to what TeX does, which usually
helps...)
> This is the current one-pass code (redoParagraphInternal):
>
> do {
> Row row(z);
> rowBreakPoint(pit, row);
> z = row.endpos();
> fill(pit, row, textwidth_);
> prepareToPrint(pit, row);
> setHeightOfRow(pit, row);
> row.y_offset(pit->height);
> pit->rows.push_back(row);
> pit->width = std::max(pit->width, row.width());
> pit->height += row.height();
> } while (z < pit->size());
>
> 2) to make LyXText::fill to use the lyxtext width instead of the rightMargin
> which is doc-absolute.
The whole margin business is a bit ... right now (and always was, as far
as I can tell), isn't it?
> 3) possibly other cosmetic details (?)
See my 'inline the not-inlined' proposal above.
> Possibly the best way to solve all this is to not store the row fill in the
> row, but it's complementary value (i.e. the real minimum space needed by
> the row, and possibly the number of separators. Right now row.fill=amount
> of aditional space to spread around, and row.fill_separator=fill/number of
> separators).
Why not. As long as it works ;-)
> Then all needed quantities can be computed in the second step (or at the end
> of the first step).
Fine with me.
> [There may be also a simpler solution, given that special fill separators
> widths etc are only needed for "block" formatting *when* there is at least
> a paragraph that breaks. In such cases we could just make the inset fill
> the full row. A bit special-cased for my taste, but probably simpler.]
>
> But I'm wondering... is it really useful/wanted?
Having an understandle line breaking algorithm certainly will not hurt.
I'd guess one of the reasons why it was so complicated so far is that
Inset::width() calls have been _really_ expensive in some cases as they
triggered the update() machinery. Nowadays, width() is comparatively
easy, so we could do that twice or even three times if that helps
to simplify the 'driver code'.
Andre'
