Header Footer Not in merged document when using type FIRST

[sparkynarf2003]

Hi,

I am merging 3 docx files into 1 and then converting it to pdf.
Whilst adding a header and footer (objects retrieved from other docx files) into the body i set the following:

headerReference.setType(HdrFtrRef.DEFAULT); // FIRST / DEFAULT / EVEN
footerReference.setType(HdrFtrRef.DEFAULT); // FIRST / DEFAULT / EVEN

// SectPr
SectPr sectPr = objectFactory.createSectPr();
sectPr.getEGHdrFtrReferences().add(headerReference);
sectPr.getEGHdrFtrReferences().add(footerReference);

I use:
wordprocessingMLPackageBody.getMainDocumentPart().getJaxbElement().getBody().setSectPr(sectPr);
not:
wordprocessingMLPackageBody.getMainDocumentPart().addObject(sectPr);

because the body i am merging the header and footer into already has a SectPr.

When i use DEFAULT the resulting merged docx file looks fine meaning that page 1 and page 2 contents are on their own pages like the body was before merge and the header and footer display on all the pages. The resulting PDF file however is on one page and the header and only half footer are displayed.

If i use FIRST or EVEN then the header and footer do not show in office when you open the merged word document (no error messages pop up and i dont see any conflicting rId's in the xml either) and the resulting PDF is all on one page again and it does contain the header and half the footer again.

Has anyone run into a problem where the docx looks fine but pdf cuts off the footer?
-and or-
has anyone encountered the problem i am having with type as FIRST or even where the merged doc does not show the header or footer but the converted PDF does indeed show it but half of its contents?

Thanks in advance
Sean

[jason]

Hi Sean

I've committed some changes in http://dev.plutext.org/trac/docx4j/changeset/1177 so that page properties are read from the docx section, and used.

However in relation to your footer getting chopped in half, there is an issue:

Code: Select all


   /* From http://msdn.microsoft.com/en-us/library/aa537167(office.11).aspx
    *
    * In Word, the size of header and footer areas can change dynamically.
    * The central region of the page increases or decreases when the contents of a side region changes.
    * The XSL-FO format has no means to express dynamically changing header and footer areas.
    * In the XSL-FO format, side regions must have fixed dimensions, regardless of their actual contents.
    *
    * That article goes on to say:
    *
    *    Consequently, you must reserve the space for headers and footers manually by adjusting page margins.
    *   
    * (that is, in the Word document).  We don't require that.
    *
    * Instead, this class allows headerExtent and footerExtent to be
    * set as required (in TWIPS).  In due course (when we have an algorirthm for amount of
    * space occupied), it may be possible to do this automatically.   
    *
    */


You ought to be able to manually adjust the page margins in your Word document; or you can programmatically reserve enough space in the PageDimensions object setHeaderExtent/setFooterExtent object (in TWIPS).

hope this helps .. Jason

[abcconsulting]

Jason,

It looks like header/footer sizes are no longer read from the docx properties. I think it defaults to 12mm since 2.7.1, last stable version that worked for me was 2.7.0 Reversing http://www.docx4java.org/trac/docx4j/changeset/1567 brings things back to normal. Is there a better way to calculate the margins going forward?