On Wednesday 14. July 2010 22.37.07 Carlos Licea wrote:
> He thinks that while valid, this solution is unacceptable as we would
> still  produce non-standard ODF documents.
> 
> We are, right now, in a minor deadlock.
> 
> In essence we have 2 ways to accomplish the exporting of the comments:
> 1)We take my first approach, in which we put the comments in 
> presentation:notes. This is bending the rules. But kind of works.
> 
> 2)We take the other approach and create a new koffice:comment (or
> presentation  comment) element meant to be used inside a draw:frame with
> the following attributes:
> 1)Author 
> 2)Date
> And just one child: text:p.
> This is not against the rules but is just, obviously, not standard.
> 
> I'd appreciate the comments of the rest of the community to best solve
> this  problem in the quickest possible way.

I don't want to use "unacceptable" as an argument as thats too strong, but I do 
think Thorsten has a good point.

If our filters create ODF that is only actually parsable by KOffice and would 
likely require us to create reading code in KOffice and a new feature to show 
this too. All for MSOffice interoperability. Also this KOffice-only feature would 
be saved out in a koffice-only manner which means we are essentially hindering 
interoperability and adding a lot of maintenance because the MSOOXML spec is 
pretty darn huge and filled with this kind of stuff.

In my opinion; the fact that MS created a feature that doesn't cleanly map to 
ODF should in my opinion mean we find the closest possible standardized 
representation and use that. Which has the advantage of that document being 
usable for KWord and OOo and many other ODF readers including MSOffice.

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