On Wed, Mar 10, 2004 at 10:15:11PM +0100, Alfredo Braunstein wrote:
> Good for you. Well as I've started fixing drawing problems only a short time
> ago, I've probably missed it at that time. But you really expect me to
> remember your random solution to a random bug?
Not sure it's random, given the nubmer of times it's been discussed.
If you missed out the long discussions, then sorry, I had assumed they
were somewhat unavoidable.
> btw, your solution seems to be to pass w - x_position_of_inset as maxwidth
> (is it?).
That's *part* of the solution.
> I find it bogus. It can end up with an output like:
>
> <------------- w ------------>
> ablah bblaj blah [ert]
> +-----+
> | this|
> | is |
> | ridi|
> | coul|
> | ous.|
> +-----+
> balh blah blah.
No, because such an ERT wants the full screen and will tell the core
code that; the line breaking code will break before the ERT, and it all
works mostly automatically.
The important thing that really needs to be represented in the code is
that there's a difference between these three values :
o how wide is the box
o what width does a char want (for full width insets: 100%, for
minipage etc. (eg 25%), for others, 'natural width')
o how much space is actually left on the current line
Until they're represented again, things just won't work. I don't think
anyone has ever understood how they used to be represented (it was an
astonishingly complex feedback system of insets' maxWidth() methods) but
now we have a chance of making it reasonably simple.
The "should I break the line" function then becomes something like:
if (char->ideal_width(remaining_width, max_width) > remaining_width)
break_line();
Note that it might be more useful to pass in "indent value" rather than
"remaining width", where "indent value" is the width of the list bullet
and space, or the parindent, etc. I'd have to implement it to see.
But the general scheme remains the same, I think.
regards,
john
--
"Spammers get STABBED by GOD." - Ron Echeverri
