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

List:       calligra-devel
Subject:    Re: Review Request: Moving anchor strategy into text shape
From:       Pierre Stirnweiss <pstirnweiss () googlemail ! com>
Date:       2011-01-27 10:49:40
Message-ID: AANLkTinzWYX4-zuWbdxMbF4-MDjA_6EfDnG+w5g7_5pw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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

[Attachment #5 (text/html)]

<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;">Well as i \
said it&#39;s going to be abstracted away, and we are creating a layout<br>

engine for ODF after all. Meaning that a lot of the layout is quite specified<br>
how should look.</blockquote><div><blockquote class="gmail_quote" style="border-left: \
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If all a \
user wants is layout of text, then kotext is handly<br>

a match anyway. And yes there might be a little overhead in terms of memory<br>
footprint, but it&#39;s actually not that much.<br>
<br>
And we gain so much by having a shared library in terms of easier, smaller and<br>
more maintainable code. And the cells and layer coordinates you talk of, are<br>
actually going to be supplied by the application with the exact same<br>
abstraction as the pages of a words document.<br>
<br>
Casper<br>
<div><div class="h5">_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br> \
</div></div></blockquote> </div><div>There must be something I am missing here.<br>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.<br> Now \
you are telling me that layouting gets drawn inside kotext and will be reabstracted \
later?<br><br>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.<br> <br>Pierre<br><br> </div><br></div><br>



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


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