John Levon wrote:
> Not sure it's random, given the nubmer of times it's been discussed.
I mean, I'm sure you know it's not the only open bug in current cvs.
(emoticon elided)
> If you missed out the long discussions, then sorry, I had assumed they
> were somewhat unavoidable.
I've probably ignored it as it's probably chinese if you don't know the
terminology nor the code. Sorry.
>> 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.
Thanks for your explanation. I will ask you some questions, if you think
that this has been already discussed please be so kind to point the
relevant thread to me.
> 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.
Note that I'm not discussing display() insets here. I.e. we don't know a
priori if it will need the full row.
> 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')
Why would anyone want to waste the 75% of the screen!?? I think it's really
silly to represent %col in a wysiwyg way. Then full row insets are already
represented by the display() bool.
> o how much space is actually left on the current line
I don't know if this is really needed.
> 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.
Used? In 1.3.x times we didn't have this problem, because the were no
"natural-width" insets. I could go back to 1.3.x behaviour right now by
switching all inset->display to true.
> The "should I break the line" function then becomes something like:
>
> if (char->ideal_width(remaining_width, max_width) > remaining_width)
> break_line();
So what is your ideal_width? What kind of heuristic optimization does it?
For instance, given the following, where the size of the inset [I] is yet
to be decided, what does ideal_width return? (suppose of course that it's
*not* a full row inset; nowadays full row insets are only displayed math
and tables IIRC; it's simply a "natural width" inset as all
insettext-derived ones in today's setup)
blah blah blah [I] blah
blah blah blah blah blah bla
> 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.
The only real problem I see with the current implementation is the inset
placement in the first position of the first indented line of a paragraph.
It is probably easy IMHO to find a quick solution for that without changing
the overall scheme...
[for instance, a "solution" that would work reasonably well in most (all?)
cases is to add this 'special casing': a single char on a row, if it's
wider than the avail width the we could draw it without using the row
indent: it's anyways better than what we do now: to make it exceed to the
right]
Alfredo
