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