<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Anyway there will not be that much interaction between the layout and loading.<br>
So I guess we could make it into a separate text-layout library. But first I<br>
would like a usecase of someone not wanting the full blown layout after having<br>
loaded everything into a library that loads all sorts of formatting<br>
information.<br>
</blockquote></div><br>Well, our main differentiating factor and selling point as always been: look we have a set of very light weight and very modular libraries you can use/combine to build your own application with. Now we are pulling into kotext, layouting logic of shapes, probably header and footer and so on.<br>
I don't think all the use cases of "rich text" really need this full blown stuff. Laying out formatted text along a line could be done using kotext and its own layouting "plug-in". Applications which would want to draft very simple text files (for drafting very simple reports, a very basic word processor for low age education...) probably wouldn't want all the handling of other shapes logic. You say Tables will benefit, for text inside a cell? But will the text-run-around logic be really the same as in the word processor?<br>
<br>The point is that I think we should be keeping a set of very light weight, purpose specific and modular libraries. If we would have thought monolitic from the begining, stuff like calligra mobile wouldn't have been possible at all. After all, at the time koffice2 started: "running a office suite on a mobile phone? is it really a realistic use case?"<br>
<br>Pierre<br>