[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Bug: Line width in paragraphs which belong to a list
From:       Thomas Zander <zander () kde ! org>
Date:       2008-03-08 19:02:52
Message-ID: 200803082002.53248.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Florian.

I never did apply your patch. The concepts and ideas looked very 
promising! Cool stuff :)
Btw, is it in svn yet? Did you request an svn account yet?

On Wednesday 5. March 2008 13:28:39 Florian Merz wrote:
> when I tried to make my spacing tool aware of lists I noticed, that
> there seems to be a bug in the text layouting code (svn trunk from
> about a week ago):

I wrote that code quite some time ago, it would not surprise me that there 
are some bugs left :)

> To reproduce it create a paragraph and fill at least two lines
> completely up to the right border ("a b c d e f g h ..." works fine).
> Then turn this paragraph into a list. The first line will be layed out
> properly, but the second line is too wide. It seems like the
> calculation of the non-first lines doesn't take counter width and/or
> counter spacing into account.

Thanks. Good catch!
Not sure if anyone will have time to fix it soon, you may want to file a 
bugreport so it doesn't get forgotten.

> I also have a question on a different matter:
> Is there a signal, which gets emitted when a relayout of the text has
> been done?

No, there is currently not.  For completeness sake, let me give a short 
overview of the way it works now.
The layouting is done in-thread currently by doing chunking. Meaning it 
layouts about one page per event and then goes back to the event loop.
The screen is repainted all the time while layouting since we do an update 
of the shape per paregraph we finished.

> Right now I call the layout() function of the KoTextDocumentLayout
> myself, but I'm afraid this might block the user interace on bigger
> paragraphs, and this also causes the layout not to flow around other
> shapes. So I'd rather let the text engine do the layouting and get a
> notice when the results are in.

Could you give me a little overview of what you are trying to accomplish? 
I mean; what results are you waiting for ? :)
Any suggestions are appreciated, we can probably think of a good way to 
make this work :)

> I know there is an update() signal defined in
> QAbstractTextDocumentLayout, and it is emitted in QTextDocumentLayout,
> but grepping KoTextDocumentLayout revealed that it never gets emitted
> in the KoOffice implementation.

Right, we may want to emit that, Qt does it in documentChanged(), which I 
think is before any layouting is done. I guess it would be wise to follow 
that rule to have minimum surprises.

Have a good weekend.
-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]