Plutext

Jason,

I am working with mergeFields in a docx document.
I am trying to replace a mergeField in a paragraph with a certain font, Century Gothic size 10. To do this I'm using the latest version of docx4j, 2.8.1.

After the mergeField is replaced the paragraph isn't fully Century Gothic size 10 anymore. The first style, stops after the replaced mergeField, is in Century Gothic size 10. The second part, start immediate after the replaced mergedField, is in Times New Roman size 11.

Is this normal behaviour (not implemented yet), or a bug.

I have written a unit test on the MailMerger class. I attached the file, that I used for unit testing (mailmerge.docx). The output is also attached.

Code: Select all

public class LocalMailMergerTest {

   /** The Constant TEMP_DIR. */
   private static final String TEMP_DIR = System.getProperty("java.io.tmpdir");

   /** The Constant SEPARATOR. */
   private static final String SEPARATOR = System.getProperty("file.separator");

   /** The Constant INPUT_FILE_PATH. */
   private static final String INPUT_FILE_PATH = "/mailmerge.docx";

   /** The Constant OUTPUT_FILE_PATH. */
   private static final String OUTPUT_FILE_PATH = "/output.docx";

   @Test
   public void testMailMerger() throws WordIntegrationZipFileException, Docx4JException {
      InputStream bin = null;
      bin = ClassLoader.class.getResourceAsStream(INPUT_FILE_PATH);

      LoadFromZipNG loader = new LoadFromZipNG();
      OpcPackage opcPackage = loader.get(bin);

      List<Map<DataFieldName, String>> fieldsList = new ArrayList<Map<DataFieldName, String>>();
      Map<DataFieldName, String> fieldsMap = new HashMap<DataFieldName, String>();
      fieldsMap.put(new DataFieldName("KTESS"), "880");
      fieldsList.add(fieldsMap);

      WordprocessingMLPackage result = MailMerger.getConsolidatedResultCrude(
         (WordprocessingMLPackage) opcPackage, fieldsList);

      SaveToZipFile saver = new SaveToZipFile(result);
      saver.save(TEMP_DIR + SEPARATOR + OUTPUT_FILE_PATH);
   }

}


Thx!

Timothy

Jason,

I just saw an issue on github concerning the same subject. Issue 32 is already closed, and the FieldPreProcessor class is already adjusted and commited.
When could we have the altered jar? Are you planning to make a new release soon (2.8.2)?

Thx!

Timothy

Hi Timothy

Those changes are in http://www.docx4java.org/docx4j/docx4j- ... 121024.jar

Please try it; any issues, you might reopen Issue 32.

2.8.1 was released quite recently. Ordinarily, we'd make more improvements before rolling another release. However, given the issue with nested tables in PDF/HTML output in 2.8.1, a next release could be sooner rather than later. There's https://github.com/plutext/docx4j/issues/13 which needs to be in the next release. So, it would be good to release 2.8.2 in November.

cheers .. Jasom

Jason,

I just tested the JAR with the basic document from my first post and the style remains during the whole paragraph, so thats OK.
In attachment you can find a document that doesn't open in word after the mergeField replacements. I suppose there is someting wrong with the second table (generated table code), but cannot define what it is. With version 2.8.1 of docx4j the replacements work fine and the document can be opened with word.

Thx.

Timothy

Thanks for the test case. If you can re-open issue 32 and add your finding / post a link to this topic, hopefully the author of the patch may amend it. You are of course welcome to review it yourself - you can see what was changed on github. Otherwise, I'll have a look when I get a chance.

Jason,

Is there a way to see what is wrong if a document doesn't open. In Word 2010 I just get a general error that something is wrong in /word/document.xml.

Timothy

In general, no. A docx with is valid XML may still trip up WOrd.

At a guess (from looking at the patch briefly yesterday), look for an empty w:r element.

Jason,

I found the bug. I created the table in inside a <w:r> element. I changed it, and everything is working fine.

Timothy