Forum Discussion
Word on the web: support section PageSetup in Office.js
Please make Section.pageSetup (Word.PageSetup) available in Word on the web, as it is on desktop. It is WordApiDesktop 1.3 today,
This would empower an add-in running in Word on the web cannot get a section's layout: whether it uses a different first page header/footer, how it starts (new page, continuous, odd, even), or its orientation and margins.
Scenarios:
Several common kinds of add-ins need to know the page layout of each section, and behave differently (or wrongly) in Word on the web because they can't read it:
1. Required text on every page. Document-management, compliance and legal add-ins stamp a document ID, confidentiality notice or disclaimer into headers/footers. To guarantee it appears on EVERY page, the add-in must know which header/footer types each section actually displays (first page, odd/even) and, combined with whether each part is linked to the previous section, whose content each page shows. Without this, a title page or even pages can silently go without the notice.
2. Formatting and pre-flight checks. Court filings, publishers and corporate style guides require specific paper size, margins and orientation. A checker add-in can do this on desktop but not on the web.
3. Inserting content that fits the page. Add-ins that insert tables, images or charts need the section's orientation, page width and margins to size content correctly -- e.g. a wide table going into a landscape section.
4. Continuous sections. A continuous section shares a page with the one above it, and that page shows only one set of headers/footers. Add-ins placing per-section header/footer content need sectionStart to know which pages a section really owns.
Workarounds:
Document.getFileAsync(Office.FileType.Compressed) returns the real .docx with the correct section properties, This however needs to fetch the entire document as compressed, unzip and parse the document. Not only can the docx be large but may lag the true state of the document.
context.document.body.getOoxml() (Partia) - Can be used to get the OOXML and code can parse the to find the sectPr information. However, in word online this won't work for the last can't be used for the last section. The ending sectPr always has some default values not the current document. To read the proper values for the last SecPtr getFileAsync() needs to be used.
1 Reply
Hi rogergrambihler, you're reading the situation correctly — this is a gap in the API surface rather than something wrong in your code.
Per Microsoft Learn's Word JavaScript API requirement sets documentation, Section.pageSetup sits in the WordApiDesktop 1.3 requirement set, and that set is listed as not applicable to Office on the web. The web side is covered by the cross-platform WordApi sets (WordApi 1.1 through 1.9) plus WordApiOnline 1.1, so there is currently no supported Office.js call that returns a section's page setup in Word on the web.
For an add-in that has to run on both, the practical approach is to test for the capability at runtime with Office.context.requirements.isSetSupported('WordApiDesktop', '1.3') and only call section.pageSetup when it reports true. On the web you then fall back to the OOXML routes you already described, accepting their trade-offs: getFileAsync with the compressed document always carries the real section properties but means fetching and parsing the whole file, and getOoxml gives you the sectPr for a section except for the final section, where Word on the web returns defaults.
Since this is a parity request rather than a bug, the route that actually moves it is the Microsoft 365 feedback channel. I would log it there with your four scenarios, especially the compliance stamping and court-filing pre-flight cases, because those show why a workaround that only reads stale or partial data is not enough.
