We have received a set of documents from the Danish government that they consider the featureset that should be available in order to say OOo and KWord are compatible enough for their taste.

The docs can be found in svn here as 'DanskTestnn.odt' Here is an overview of whats is missing in trunk (to become 2.1) today (12-Oct 2009)

Doc 3 has several data fields. Data fields are essentially KoVariable instances (See KoVariableFactory api docs). The tricky bit is that the information comes from the meta-data of the document. Which is read and stored in KoDocumentInfo. At this time I'm not sure how a variable plugin would access that info. ps. plugins should live in the koffice/plugins/ dir structure.

Doc 8 has 3 vector drawings; they are loaded by kword and I see (selectable) frames in the document. But the actual content is not visible. Not sure why not.

Doc 8 has several paragraph-anchored at the start of one paragraph. The design of the KWAnchorStrategy didn't consider that usecase. It assumes at most one paragraph-anchored shape per paragraph. So this fails and it should get fixed. The code will likely only touch KWAnchorStrategy. Though I'd love to see plenty of unit tests added here ;)

Doc 10 has a Table Of Contents. We currently don't have any component that loads this. In svn we still have an koffice/plugins/variables/TOCVariable, which is not the right design for the concept, but it likely is a great first step to getting basic viewing capabilities for this up and running fast. In the long term we need to find a proper way of adding this to libKoText, likely after we get support for things like sections and protected (aka uneditable) regions.

Doc 11 has a comment. I suggest to implement (if we don't do that already) it as a KoInlineObject. Initially we can just add it in KoText; but I hope we can move it to be a plugin later. The comment would obviously not be visible at all in the normal text. So the inlineObject would just contain the text and not paint anything. I think the quickest way to do visualization of the comment is to create a new docker that listens to the current cursor position (see KoCanvasResourceProvider and KoCanvasObserver) and whenever the cursor changes paragraph it updates which comments there are in the new-current-paragraph.

Doc 11 has recorded changes which should be visualized. AFAIK loading of changes is already implemented, visualisation is also implemented. They are likely buggy since going to 'Tool->Record' should show these changes, but it doesnt. This should be debugged. Note that trunk is in the middle of a heavy refactor for this stuff, so its not easy to figure out what its supposed to be. Some of the concept are in flux.

This page was last edited on 6 December 2010, at 17:58. Content is available under Creative Commons License SA 4.0 unless otherwise noted.