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

List:       koffice-devel
Subject:    Re: KWord and "Make inline"
From:       Thomas Zander <zander () kde ! org>
Date:       2009-01-28 13:12:19
Message-ID: 200901281412.19964.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 28. January 2009 00.53.33 Pierre Ducroquet wrote:
> Hi
>
> I'm currently testing things in KWord to be sure every thing is saved in a
> document. IMHO, something not saved is just the worst thing for the user.
> He could understand a crash, a missing feature, but losing data is not
> really acceptable...

Cool! :)

> And I just saw that the Insert > Make inline action is still here.
> From an OpenDocument Text point of view, that action just doesn't make
> sense : a text document is a text flow, nothing can be out of the text
> flow... So any frame that is not inline is not saved and cannot be saved.

The terminology used in KWord is indeed not something that ODF uses, but the 
concepts can be mapped quite well, actually.
But you are indeed not the first to get caught by this one, our latest summer 
of code student had some severe problems with this too :) Unfortunately his 
mentor never corrected him.  So he ended up rewriting the KoTextAnchor class 
to something that is even more confusing and just plain wrong :(
I still have to put some time into making that sane again.
I suggest you ignore it mostly for now. Its not needed for non-inline 
frames :)

Let me explain with an example; If you insert a star on page 2 and its not 
anchored in the text this is in KWord concepts a floating frame. As opposed 
to an inline frame. So it has an absolute position relative to the first page 
in the doc.
In ODF terms this is actually an anchored frame, but it uses the concept of 
being anchored to a page. And we save the offset of this frame only to the 
page top/left in the ODF.

The fact that we have an AnchorType in KoTextAnchor of Page is therefor 
misleading and wrong; the class will never be used for that type of anchor. 
We just use that type on saving. 

> I don't know what the easiest solution would be. If we just always make
> frames inline, then we face another issue : it appears we can't move frames
> that aren't inline...

Yes, thats exactly why we don't want to have them always inline. I want to be 
able to move it freely anywhere in my doc.
Actually, we used to be able to move an inline frame to a limited degree. It 
would snap to the allowed positions like the top of the frame, top of 
paragraph. etc.
This was lost in the rewrite I mentioned above.  I should revert that soon, 
really...

> The problem so far is that I don't see how to fix it...
> Any suggestion/idea ? I don't think that issue can be post-poned after 2.0
> release...

Each non-floating frame in KWord should be saved simply as a page-anchored 
frame by the saving code.  So the KoTextAnchor is not needed for them at all.
The KoTextAnchor needs a lot of work, mostly to revert some commits which were 
made in error. Not sure if I have the stomach to do that before 2.0, though.

-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

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


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