Alfredo Braunstein wrote:
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.

Well, all stl containers use unsigned size type... But Qt uses signed index... As we use STL containers I think it makes sense to use size_t.


Btw, drawing performance is very good, it is almost usable now on remote X
over my adsl link (and it really wasn't before).

Good, performance was the whole purpose of the cleanup :-)


One small problem I've noticed. leftMargin is very complex,

Don't tell me...

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....

I think we should. Why don't we want to do this auto hfill if the par is empty? In any case, I aim at getting rid of the singlePar optimization. Not sure I'll have to finish before 1.6.0 though...

Abdel.


Reply via email to