Review Request: Moving anchor strategy into text shape

C. Boemann cbo at boemann.dk
Thu Jan 27 10:57:03 GMT 2011


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



More information about the calligra-devel mailing list