Abdelrazak Younes wrote:
>> --- lyx-devel/trunk/src/TextMetrics.cpp (original)
>> +++ lyx-devel/trunk/src/TextMetrics.cpp Sun Sep 2 20:05:37 2007
>> @@ -155,7 +155,7 @@
>> Dimension const old_dim = dim_;
>> // reset dimension.
>> dim_ = Dimension();
>> - size_t npar = text_->paragraphs().size();
>> + pit_type const npar = text_->paragraphs().size();
>
> It's probably time to make pit_type unsigned...
I don't know if I'd like that. The fact is that even if one want to store
non-negative values, one normally wants to have integer operations, not
operations in Z mod 2^{32}. Where you may get unexpected results like pit -
1 > pit, for no real apparent gain.
>> if (npar > 1)
>> // If there is more than one row, expand the text to
>> // the full allowable width.
>> @@ -1776,10 +1776,14 @@
>> || bv_funcs::status(bv_, end) == bv_funcs::CUR_ABOVE)
>> return;
>>
>> - if (beg.pit() < par_metrics_.begin()->first)
>> + if (beg.pit() < par_metrics_.begin()->first) {
>> beg.pit() = par_metrics_.begin()->first;
>> - if (end.pit() > par_metrics_.rbegin()->first)
>> + beg.pos() = 0;
>> + }
>> + if (end.pit() > par_metrics_.rbegin()->first) {
>> end.pit() = par_metrics_.rbegin()->first;
>> + end.pos() = end.lastpos();
>> + }
>
> Oups... thanks!
No prob ;-)
Btw, drawing performance is very good, it is almost usable now on remote X
over my adsl link (and it really wasn't before).
One small problem I've noticed. leftMargin is very complex, and indentation
of a paragraph depends of various condition on previous ones. For instance,
look at TextMetrics.cpp:352 and the comment above it.
// A manual label par (e.g. List) has an auto-hfill
// between the label text and the body of the
// paragraph too.
// But we don't want to do this auto hfill if the par
// is empty.
if (!par.empty())
++nlh;
It means that adding one char to an empty par (for instance with the
Labelling layout) may affect indentation of deeper paragraphs below it:
this is ignored by the current single par optimization (no idea about the
previous code though). I wonder if one could eliminate this special case
anyway....
A/
