On Thursday 27 January 2011 11:49:40 Pierre Stirnweiss wrote: > > Well as i said it's going to be abstracted away, and we are creating a > > layout > > engine for ODF after all. Meaning that a lot of the layout is quite > > specified > > how should look. > > If all a user wants is layout of text, then kotext is handly But do you really see this as a realistic use case? I mean yes one might want that , but rarely without wanting the full blown layout too.
Anyway there will not be that much interaction between the layout and loading. So I guess we could make it into a separate text-layout library. But first I would like a usecase of someone not wanting the full blown layout after having loaded everything into a library that loads all sorts of formatting information. > > > a match anyway. And yes there might be a little overhead in terms of > > memory footprint, but it's actually not that much. > > > > And we gain so much by having a shared library in terms of easier, > > smaller and > > more maintainable code. And the cells and layer coordinates you talk of, > > are > > actually going to be supplied by the application with the exact same > > abstraction as the pages of a words document. > > > > Casper > > _______________________________________________ > > calligra-devel mailing list > > calligra-devel@kde.org > > https://mail.kde.org/mailman/listinfo/calligra-devel > > There must be something I am missing here. > We have already: kotext providing an abstracted interface for layouting > lines (koTextDocumentLayout IIRC). one implementation of that interface is > in the textShape (Layout). The text within a line is already drawn/layouted > by Qt text engine. > Now you are telling me that layouting gets drawn inside kotext and will be > reabstracted later? > > If the purpose is to also have a shared layouting implementation without > the bloat of textshape/texttool,... then I think a better solution would > be to provide one in its own library which would depend on kotext. That > way you can keep kotext clean of higher level layouting, such as > lines/shape. Which would still allow for simpler use cases. > > Pierre _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
