Resulting styles.xml doesn't match the one in the .jar

[Zezombye]

My program works fine in eclipse: it generates the document with the desired font, and visible table borders (which are for some reason hidden by default).

However once exporting to .jar I've had consecutive problems, which I resolved until this one.

First, the resulting .jar didn't have a styles.xml, so it generated the document with the default font, etc. Fix was to manually add the styles.xml into the jar.

Next, the parser failed on the header. In the line

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

it threw an exception after the '>'. Fix was to remove the header, because in xml 1.0 it is optional. There was absolutely no reason for the parser to throw that exception because the file is exactly the same as the one in the git (which manages to get parsed).

Finally, it generated the doc without throwing any exception. However, when opening the doc, Word refuses to open it, saying it is corrupted. Upon looking I discovered that, for some reason, the styles.xml included in the doc had an empty rFonts attribute.

So basically, the styles.xml in the jar is:

Code: Select all

<w:styles xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
  <w:docDefaults>
    <w:rPrDefault>
      <w:rPr>
        <w:rFonts w:asciiTheme="Times New Roman" w:eastAsiaTheme="Times New Roman" w:hAnsiTheme="Times New Roman" w:cstheme="Times New Roman" />
        <w:sz w:val="24" />
        <w:szCs w:val="24" />
        <w:lang w:val="en-US" w:eastAsia="en-US" w:bidi="ar-SA" />
      </w:rPr>
    </w:rPrDefault>
    <w:pPrDefault>
      <w:pPr>
      <w:spacing w:line="240" w:lineRule="auto" />
      </w:pPr>
    </w:pPrDefault>
  </w:docDefaults>
...

and the resulting styles.xml is:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:styles xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" ... xmlns:ns32="http://schemas.openxmlformats.org/drawingml/2006/lockedCanvas">
    <w:docDefaults>
        <w:rPrDefault>
            <w:rPr>
                <w:rFonts/>
                <w:sz w:val="24"/>
                <w:szCs w:val="24"/>
                <w:lang w:val="en-US" w:eastAsia="en-US" w:bidi="ar-SA"/>
            </w:rPr>
        </w:rPrDefault>
        <w:pPrDefault>
            <w:pPr>
                <w:spacing w:line="240" w:lineRule="auto"/>
            </w:pPr>
        </w:pPrDefault>
    </w:docDefaults>
...

Notice the empty w:rFonts attribute that, I assume, triggers an exception in Word's parsing.

Why does it remove that attribute?

Also I'd like to thank you jason for the work you're providing

[jason]

So you are working with docx4j source code, but relying on Eclipse to create a jar from it?

That's not recommended. The supported ways of building docx4j are to use mvn or ant.

I've never seen any of the issues you mention. To understand what's going on, would need details about your environment.

[Zezombye]

I've got two versions of the same project (with the exact same code). One uses the git (which is normally updated to 3.3.0), the other uses the .jar provided (which is in 3.2.2).

In the git project, running from Eclipse works fine. However exporting to .jar produces the issues I mentioned (styles.xml not included, parser failing on header, rFonts empty).

In the other project, running from Eclipse produces the "parser failing on header" issue. Removing the header in the styles.xml (in the docx4j jar) produces the same empty rFonts problem. But, to my surprise, exporting this project to .jar works perfectly fine.

So : the project using the git works fine in eclipse, once exported it produces the parser problem. Whereas for the project using the docx4j jar, it produces the parser problem in eclipse, but not once exported.
Note that I didn't mix up the two projects while exporting, because I included a version number to differenciate the projects, and it doesn't change in eclipse and after exporting.

This is all very weird, but well, it works now.