Cédric Bosdonnat - OOXML

Asian phonetic guide exported in Docx

2010-05-10T15:42:00+02:00

The asian phonetic guide is a useful feature when learning an asian language. Last week I worked on writing it in the docx files. The feature is now happily sitting in the docx-fixes02.diff patch in the go-oo git repository. Here are some screenshots of the feature in Word and OpenOffice.org for those eager to see what it is.

Phonetic guide in OOo

Phonetic guide reopened in word

The phonetic guide configuration options in OpenOffice.org and Word aren't the same. What is working here is the export of the text with it's usual properties and the alignement of the pronounciation. Note that the characters on the above sample are grouped in the OOo dialog, but not when opening Word's dialog: this comes from the different color setting applied to one of the characters.

When testing this code, I also discovered a strange compatibility issue between Word 97 and Word 2007 when opening the .doc version of the file:

For Word 97, the field for the ruby text in the doc file needs to be { EQ \* jc0 \* "Font:Arial" \* hps12 \o(\s\up 10(kong3zi); 孔子 ) }*
For Word 2007, the field for the ruby text in the doc file needs to be { EQ \* jc0 \* "Font:Arial" \* hps12 \o(\s\up 10(kong3zi), 孔子 ) }*

Then when saving a file with a phonetic guide in Word 97 and opening it in Word 2007, all the fields need to be changed to have commas as function parameters separator (instead of semi-colon).

Windows 7, Office 2010 and user freedom

2010-05-07T11:49:00+02:00

As I needed to perform some tests on Windows 7 and Office 2010 these days and I had two interesting surprises.

Office 2010 asks the user to choose between ODF and OOXML as default storing format.
Windows 7 asks which Web browser to use / install

Here are two screenshots to show these choices... they may be biased but at least they are existing.

Office 2010 format choice

Windows 7 browser choice

I hope more people will then install Firefox on Windows and make it their default web browser.... but the most interesting point is about Office 2010: OpenOffice.org marketing centered on ODF support won't make the difference by now. We need to focus much more on:

innovating features. Copying what Office 2010 does is good to ensure compatibility, but we need to keep adding some useful features that aren't yet in Office 2010 for users to find something interesting in the OpenOffice.org product.
the values of open source and community as that's our main differenciator. How could we as a community show to the users that they have something to gain to contact us and be part of the adventure?

Asian layout export improved

2010-04-29T15:27:00+02:00

I recently had a look at the .docx export of the document grid for asian characters. It was not implemented at all and the .doc export was buggy. After some time constantly not skipping a word in the OOXML specifications, I finally had a working implementation and could fix the .doc export. Here are some screenshots to help you understand what I'm writing about. Mind the number of asian characters per line...

The layout in OOo

The buggy layout in Word

The layout in Word after the changes

The fix is already available on the master branch of ooo-build git repo.

Docx import: the unacceptable regression!

2009-09-05T11:14:00+02:00

You may remember that I have started my first CWS some times ago to upstream my docx import changes. I had to quickly rebase it to dev300-m56 as the 3.2 feature freeze is nearing and the QA of a CWS could take quite some time. After a hard time working on that rebase, I uncovered a serious issue: any docx containing a picture or a shape make OOo crash on import. It turns out that Kendy has already reported that issue (i104155). This is clearly a regression from the upstream.

How does it comes QA didn't uncover this enormous regression?

As a developer I have some sample documents to test the features I am improving and I open each of these documents to check if everything goes nicely. When doing the QA of big changes like those ones, a set of OOXML documents should be used to test potential regressions. This has apparently not been done this time. How does it come that no Docx document with a picture or a shape in it has been loaded during the QA of a CWS changing the import of OOXML shapes?

I don't blame the developer introducing the regression here as this can happen to any one of us... but the way the QA is done!

Numbering imports in docx files

2009-05-13T18:11:00+02:00

Here are some hot news from the docx import front. I am currently working on the numberings and outline import. There were several problems:

the outline styles weren't defined
the numbering layout properties weren't properly set
the suffix and the number of parent levels weren't correctly set.

As usual here are some screenshots to better understand the problem. You can find the sample document attached to this issue. I have added an other interesting screenshot to compare with the import of the same file converted to .doc by Word 2007.

The file in word

Import without the patch

Import of a .doc file

Imported using OdfConverter

Import with the fixes

The patch isn't yet committed to the master branch as it is still experimental and not complete...

Docx shapes import: with text

2009-04-22T10:39:00+02:00

Importing the text inside the shapes from docx files is a complex problem in OpenOffice.org. Most of the problem comes from the fact that there are two text engines in OOo like in older versions of Word:

the Writer text engine used in the text documents and in the text frames
the edit engine used in Draw / Impress and for the shapes content in Writer.

The edit engine is supporting only simple formatted text, whereas the Writer text engine is supporting other objects like tables, pictures, etc. In Word 2007 any shape can contain any piece of content: not only text. The problem when importing is then: how to import the shapes containing complex text? A short term solution is to create a text frame for any rectangle shape containing text and keeping shapes for anything else. Some data could then be lost, for example if an ellipse shape is containing a table. A long term solution would be to get rid of the edit engine and use the writer engine everywhere...

I managed to create the shape or frame depending on the docx input and to set the text in it. There is a really annoying thing with the text frames and shapes: their UNO APIs are completely different: then all the work with the shape properties have to be done another time with the frame properties... Couldn't at least the fill / line properties be the same for both TextFrame and Shape services ?

Here are some screenshots showing the import of a docx file with shapes containing text. There is no screenshot for the OdfConverter as the generated odf document makes OOo crash!

The original document

Imported with a non fixed OOo

Imported with the fixed OOo

Shapes in Writer

2009-04-01T11:51:00+02:00

I'm currently working on importing the shapes' content of docx files in OpenOffice.org and I found some troubling differences between OOo and Word on this point.

A shape Word can contain text, tables and other objects. A shape in OOo can only contain text; to have a table inside a shape you need to create a frame and then insert the table. The old doc import filter is importing all the rectangle shape containing text as frames as there is no difference between a textbox and a shape in .doc files. The problems comes for the other shapes: e.g. an ellipse contains a table in Word will be imported as an ellipse shape in writer without the table. Data are lost here! Would it be worse an effort to have shapes handled and laid out like frames?
A shape in Word can be rotated, and when the background is filled with a picture, this one is also rotated with the shape (in fact this is an option). A shape can be rotated in Writer, but the picture can't be rotated. This leads to some ugly results when importing such .doc file. Why can't a Writer shape be rotated in the same way than draw shapes? Even for a user, it's fairly complicated to rotate a shape in Writer...
In Writer, even the UNO API can set custom bitmaps as the background of shapes, but there is nothing in the UI to select a custom picture as the shape background. Isn't that strange?

Here are two screenshots showing a .doc file in Word and OpenOffice.org to better see the above differences.

Shapes in word

Shapes in OpenOffice.org

Docx shapes import: first steps

2009-03-27T18:02:00+01:00

One of the other big areas for improvement in the docx files import is the import of the shapes, text boxes and other VML stuffs. The fact is simple: there is no shape imported yet! The challenge here is to reuse and expand some code of the oox module in order to share it with the import of xlsx and pptx. After some time investigating how things are working in the VML import code of oox and the writerfilter, I found that the XML tokens between the two modules were using the same constants but not the namespaces.

After having fixed this tokens issue, I managed to import some shapes. After some hacks in the oox and the writerfilter module, here are some results for the import:

Shapes in Word 2007

Shapes imported with OdfConverter

Shapes imported in OOo with some hacks

There are still a lot of things to do here, including:

Create text frames where a rectangle shape can't be enough
Complete the VML import

This is a first step and I hope to show more progresses soon.

docx nested tables import

2009-03-24T15:58:00+01:00

The last weeks have been quite hard: I was working on difficult parts of the writerfilter and sw code. I was working on a patch to import the nested tables in the docx files. As you will be able to see it, the import is much better, even thought it is not yet perfect. As usual, here are some screenshots to help you understand what has changed.

Nested tables in Word 2007

Nested tables imported by OOo without patch

Nested tables imported using OdfConverter

Nested tables imported by OOo with the all docx import patches

Of course, in the above screenshots, the one of the non-fixed OOo doesn't include any of the previous docx import patches I previously mentionned, whereas the one with the fixed OOo includes them all.

Last docx import fixes

2009-03-13T16:15:00+01:00

I had no time to write a post for each new fix I made this week, then here is a summary of what happened. Don't blame me for providing screenshots only for some very visible points instead of every fix.

Changes tracking import

This was and is still a big area for improvement. I first fixed what I saw easily in some example documents but it's quite hard to find every single bug in there. If you find others, please don't hesitate to leave me a message or some issue either on IZ or Novell's bugzilla. Here is a list of what have been fixed for the changes tracking:

When inserting a footnote or endnote, the imported redline was completely wrong
When there are several changes on the same piece of text only one was imported
The added / removed paragraphs weren't imported
The changes weren't shown by default in OOo when opening a document with changes
The changes weren't tracked in OOo as the documents settings weren't read at all. The settings.xml import has been fixed / started, but it currently handles only this property.

There are some points to be aware of if you want to try to find other changes tracking issues:

Compare with what is imported by OOo when opening the same file in .doc: OOo doesn't support all the changes tracks of Word: checking what the .doc import does is a quick way to check if OOo can usually handle this kind of change.
Open the "Review & Approve" dialog in OOo and compare these entries with the changes in Word: OOo isn't showing the changes in the same way than Word and there might be some display problems.

Page number alignement

There where problems of page numbers alignement in some cases: this came from a too large minimum width of the frame. By defining this constant to 0, the frame is now fitting to its content automatically (i#93786)

Page borders import

The page borders weren't imported at all: it is now fixed. Here are some screenshots to better understand what happened. The test document is attached to the issue i#00176.

Page borders in Word 2007

Page borders imported in OOo

Page Borders imported with OdfConverter

Page borders import fixed

A CWS for all those fixes

As it starts to make a small amount of changes to the code, I have also created a CWS to up-stream the changes: writerfilter32bugfixes01.

Pictures in docx import

2009-03-04T18:12:00+01:00

As I explained it in a previous post, I am working on fixing docx import in OpenOffice.org. I have fixed a bug on the pictures import recently. The patch fixes the issues i#97645 and i#96021. The i#96021 issue fix isn't complete yet, because it has something to do with shapes import which aren't working at all. The patch has been committed to go-oo trunk. As one of the fixes isn't complete, I still haven't submitted it to the upstream.

Here are some screenshots to show the differences:

Picture in Word 2007

Pictures import in OOo without the patch

Picture import in OOo using OdfConverter

Picture imported in OOo with the patch

Thanks again Andrew for providing your useful reference document and pointing out the bugs.

OOXML tables import in docx files fixed

2009-02-20T19:10:00+01:00

Thanks to Andrew Ziem in his post A Better Office .docx converter, I have discovered a place needing many improvements in OOo. I started to fix the border problem exposed in Andrew's document, but then found that the table styles weren't imported. This problem is now fixed in go-oo trunk and a patch has been submitted on IssueZilla.

The best way to understand the problem is to consider the following screenshots. To show how important these styles are, simply consider that the simple-black-border tables in word are using a style.

The document in Word 2007:

Tables in Word 2007

The document opened by OpenOffice.org (dev300m40):

Tables in OOo without the fixes

The document opened by ooo-build using the OdfConverter:

Tables in OOo using OdfConverter

The document opened by OpenOffice.org with the fixes:

Tables imported by OOo after fixes

As Andrew pointed it, there are still other places of improvements in the docx files import; I will continue to fix them: many thanks Andrew!