# officer builds Word and PowerPoint files from R output

> officer lets R code write into.docx and.pptx documents, adding images, tables and text into an existing document whose styles and properties are preserved, and it can read a document back into a data frame. The repository records a custom licence that GitHub cannot classify, and it is built as a foundation that flextable, officedown and rvg sit on top of.

**davidgohel/officer** — :cop: officer: office documents from R

- Repository: https://github.com/davidgohel/officer
- Website: https://ardata-fr.github.io/officeverse/
- Stars: 700 · Forks: 119
- Language: R
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/davidgohel-officer

## Writing into a document rather than exporting a picture of one

The package's pitch is corporate reporting with minimum hassle, and the mechanism is what makes it interesting. The officer package lets R users manipulate Word (.docx) and PowerPoint (*.pptx) documents, and in short one can add images, tables and text into documents from R. An initial document can be provided, and the contents, styles and properties of the original document will then be available. That word available carries the design. The output is not a rendered page that R draws and saves, it is the office file itself, and the formatting of what you insert is decided by the document you started from rather than by a set of arguments. So a report that must match an existing corporate template is produced by reading that template, inserting R output, and writing the file back, and the template stays the single source of truth for look. The package also supports the writing of RTF documents and basic manipulation of Excel (.xlsx) workbooks, with the RTF path being the one that exists because it is what the underlying implementation can produce. The audience is the analyst or statistician whose deliverable is a .docx or .pptx and who would otherwise paste a chart image into a document by hand.

## Four kinds of content for Word, and the print function that writes it

The Word side is where the package has the most detail, and the four content types are worth separating because each has a different styling rule. Images are produced as png or emf files and added into the document, either as a whole paragraph or inside a paragraph. Tables are added as data.frames, with the format defined by the associated Word table style. Text is added as paragraphs or inside an existing paragraph, with the format defined by the associated Word paragraph and text styles. Field codes are added inside paragraphs, and the README explains that field codes are an old feature of MS Word to create calculated elements such as tables of contents, automatic numbering and hyperlinks. That last one is the feature that most differentiates this from a plotting export, because a table of contents computed by Word is a real Word table of contents, and it updates when the reader presses the key. Generation is done with the print function, which is the pattern the whole package follows. The read side exists too. docx_summary() reads and imports the content of a Word document into a data.frame, handling paragraphs, tables and section breaks, and docx_comments() reads the comments of a Word document and organises the results into a data.frame. The import functions are what let a build pipeline check what it produced.

## PowerPoint mirrors Word, with a different styling model

read_pptx() reads an initial PowerPoint document, an empty one by default, and lets you modify its content later. The three content types match the Word set. Images are produced as png or emf files and added in a slide, tables are added as data.frames with the format defined by the associated PowerPoint table style, and text is added as paragraphs or inside an existing paragraph, with the format defined in the corresponding layout of the slide. That last clause is the difference worth pausing on. In PowerPoint the formatting anchor is the slide layout, not a paragraph style, which means the same call produces different results in a title slide and a content slide. A PowerPoint document also lets you set a slide as selected and reach a particular shape, and remove it or add text, which is what makes template driven decks possible from R. Generation is with the print() function, as in the Word case. The reverse direction is pptx_summary(), which reads and imports the content of a PowerPoint document into a data.frame and handles paragraphs, tables and images. The pair of read and write functions for each format is a deliberate symmetry, and it is the symmetry that makes the package useful in a pipeline that has to verify its own output.

## Installing from GitHub or from CRAN

Two routes are given, and the difference is which version you get. The development version comes from GitHub.

```r
devtools::install_github("davidgohel/officer")
```

The latest version on CRAN is a different command.

```r
install.packages("officer")
```

The CRAN install needs no extra tooling, so it is the sensible default for most users, and the GitHub route is for anyone who needs a change that has not been released yet. The repository layout shows an ordinary R package. There is a DESCRIPTION file, a NAMESPACE, an R/ directory, a man/ directory for documentation, a tests/ directory, an inst/ directory, a _pkgdown.yml for the documentation site, and a README.md that is generated from README.Rmd, with a comment in the file saying the Rmd should be edited instead. The documentation is split across two sites, with the help pages in a bookdown at ardata-fr.github.io and the manuals at davidgohel.github.io, and the package's own topic list includes PowerPoint, Word and CRAN, so the audience is R users producing office documents. The release history on record is 0.5.2 on 2023-01-27, 0.5.1 on 2023-01-06 and 0.5.0 on 2022-12-21, while the last push was on 2026-10-14, which is the usual CRAN pattern of a stable published version with a moving development branch.

## officer is a base layer, and the ecosystem sits on it

The extensions section of the README is the clearest statement of the project's role, and it is why a reviewer should look at more than the package itself. The flextable package brings a full API to produce nice tables and use them with packages officer and rmarkdown. The rvg package brings an API to produce nice vector graphics that can be embedded in PowerPoint documents or Excel workbooks with officer. The mschart package combined with officer can produce native office charts in PowerPoint and Word documents, and the officedown package facilitates the formatting of Microsoft Word documents produced by R Markdown documents. So officer is the layer that owns the file, and four packages extend it in specific directions. That has two consequences for adoption. The first is positive, since a table produced by flextable and a chart produced by mschart land in the document through the same officer mechanism, and you do not have to choose between rich tables and native charts. The second is a constraint, and the maintainer states it plainly in the pull request policy: officer's internals are shared with several downstream packages including flextable, officedown and rvg, and changes that look local often have wider implications. Anyone planning to depend on officer for a long-lived product is depending on that whole stack, and on a maintainer who will ask for an issue before a pull request.

## Contributions are gated, and the licence needs reading

The contribution policy is unusually explicit and is worth knowing before you plan to send a patch. Before writing any code, you are asked to open an issue describing the change and the reason for it, and the proposal needs to be discussed and explicitly validated by the maintainer before work starts. Pull requests for features that have not gone through this step will not be considered, no matter how well crafted. Once a proposal has been agreed, the maintainer invites you to open a PR for that specific change, and unsolicited pull requests that bypass this step are closed. The stated reason is that officer's internals are shared with several downstream packages, and aligning on the design in an issue first saves time on both sides. When invited, you are asked to include the new functions with code and roxygen tags including runnable examples, documentation updates including a vignette section if relevant, and corresponding tests under tests/testthat, and to run rhub::check_for_cran() locally before submitting, with CI running the full check suite on the pull request. Bug reports go through GitHub issues, and the issue form requires a reproducible example, a reprex, and the output of sessionInfo(), and reports missing those elements are closed without further response. On the licence, the repository records a custom licence that GitHub cannot classify, with both a LICENSE and a LICENSE.md file at the root, so the terms are in those files and your own review should cover them before you put the package inside a commercial reporting product.

## Conclusion

officer suits an R team whose reports are Word or PowerPoint files and whose charts come out of R, because it writes into a real document template and keeps that template's styles rather than exporting an image of a page, and the round trip back into a data frame is there when you need to check what is in a file. It is the wrong tool if you want a single self-contained HTML or PDF pipeline, since the output format is the office document itself, and it is the wrong tool if your team is not prepared to work in Word's style model, because the formatting is defined by the associated Word or PowerPoint styles rather than by arguments you pass. Before you adopt it, read the LICENSE and LICENSE.md files in the repository, because the licence field is recorded as a custom one that GitHub cannot classify, and pin the version, since the newest release on record is 0.5.2 from 2023-01-27 while the repository itself was pushed on 2026-10-14.

## FAQ

### What can the officer R package do with Word and PowerPoint files?

It reads an initial Word or PowerPoint document, an empty one by default, and lets you add images, tables, text and Word field codes into it while the contents, styles and properties of the original document remain available. Files are written with the print function.

### How do I install officer?

From GitHub with devtools::install_github("davidgohel/officer") for the development version, or from CRAN with install.packages("officer") for the latest published release.

### Can officer read a Word document back into R?

Yes. docx_summary() reads and imports the content of a Word document into a data.frame, handling paragraphs, tables and section breaks, and docx_comments() does the same for comments. On the PowerPoint side pptx_summary() handles paragraphs, tables and images.

## Sources

- [davidgohel/officer on GitHub](https://github.com/davidgohel/officer)
- [Issues](https://github.com/davidgohel/officer/issues)
- [Project website](https://ardata-fr.github.io/officeverse/)
- [README](https://github.com/davidgohel/officer/blob/main/README.md)
- [Releases](https://github.com/davidgohel/officer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/davidgohel-officer