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

List:       koffice-devel
Subject:    Re: Review Request: bug fix "Text displayed at wrong place in this
From:       "Thomas Zander" <zander () kde ! org>
Date:       2010-05-14 14:20:05
Message-ID: 20100514142005.24562.52609 () localhost
[Download RAW message or body]



> On 2010-05-14 12:12:18, Thomas Zander wrote:
> > To be honest, I'd not go for either :)
> > The problem here is really that ODF has a ridiculous amount of choice (that I \
> > have a really really hard time justifying) and this is a problem because it turns \
> > up in our public API. The class should be easy to use first. 
> > So, there are 3 conflicting things;
> > * we want to be able to load and save *all* ODF properties.
> > * we want to create a really nice and useful API for developers to program to
> > * we want to provide a nice user interface with selected options for the user.
> > 
> > Thinking about this longer my conclusion has to be that changing the design as it \
> > is now (with 7 and 6 items) and going for the either of the suggestions you made \
> > is not going to work for either my second or 3rd point. So how to make sure we \
> > can still load/save this stuff? 
> > I suggest to move the 4 enums you propose to be defined on the private. Leave the \
> > 2 enums as they are in SVN intact. The loading saving code can store the values \
> > on the private so roundtripping will work. This would be in addition to the two \
> > existing enums already stored on the private with less options. 
> > I know you will ask me now; how then will we support all 90 horizontal alignments \
> > and 50 vertical ones and my answer simply is; we don't.  I'm open to find the \
> > most common ones saved in existing ODF files to see if we can add those to the \
> > public API or just map them onto there with some precision loss but supporting \
> > all of them is not something I think makes a whole lot of sense to me. 
> > What do you think?
> 
> Matus Hanzes wrote:
> I just did not understand why koffice created his own attribute \
> "koffice:anchor-type" when all the functionality can be rewritten into odf without \
> loss of information. That is why I have made this patch. I just wanted to support \
> odf and make the koffice output odf compatible. 
> But after you explained to me that koffice is "not going to be driven by the ODF \
> specification" I realized that I was wrong. 
> So if understand it right the Diff r2 is the solution that you want ?
> 

yes, diff r2 is indeed very close to the suggestion I wrote 2 hours ago :)
Sorry for not making that connection myself.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3699/#review5667
-----------------------------------------------------------


On 2010-05-07 15:20:10, Matus Hanzes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3699/
> -----------------------------------------------------------
> 
> (Updated 2010-05-07 15:20:10)
> 
> 
> Review request for KOffice.
> 
> 
> Summary
> -------
> 
> To place draw objects properly in kword document I needed to add more support for \
> anchoring in kword.(style:vertical-pos,style:vertical-rel,style:horizontal-pos,style:vertical-rel)
>  I tried to make anchoring backward compatible.
> 
> Comments are welcome.
> 
> 
> Diffs
> -----
> 
> trunk/koffice/kword/part/KWPageStyle.h 1123976 
> trunk/koffice/kword/part/KWPageStyle.cpp 1123976 
> trunk/koffice/kword/part/KWPageStyle_p.h 1123976 
> trunk/koffice/kword/part/KWPageTextInfo.h 1123976 
> trunk/koffice/kword/part/KWPageTextInfo.cpp 1123976 
> trunk/koffice/kword/part/frames/KWAnchorStrategy.h 1123976 
> trunk/koffice/kword/part/frames/KWAnchorStrategy.cpp 1123976 
> trunk/koffice/kword/part/frames/KWFrameLayout.cpp 1123976 
> trunk/koffice/kword/part/frames/KWTextDocumentLayout.cpp 1123976 
> trunk/koffice/libs/kotext/KoTextAnchor.h 1123976 
> trunk/koffice/libs/kotext/KoTextAnchor.cpp 1123976 
> trunk/koffice/libs/kotext/opendocument/KoTextLoader.cpp 1123976 
> 
> Diff: http://reviewboard.kde.org/r/3699/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matus
> 
> 

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