I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge abou

I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge about those systems - I would welcome being enlightened). … I once wrote something that processed a plethora of Word documents using Word via COM to extract data from them and shove it into a database. This is more of a ideological difference in how things should, and can, be done. For a long while, the only way to reliably edit Word documents was using Microsoft Word (half of it being undocumented, and half of it being documented as "this is supposed to do whatever Microsoft Office does"), so you effectively needed to embed Word within your program in order to reliably edit Word documents. A lot of that changed In the open source world, there are canonical tools, but traditionally it's been about the format being open and accessible explicitly so you don't need to rely on/run a third-party program to do the manipulation, rather either roll your own manipulation routines following the documented standard (thereby strengthening the ecosystem with multiple implements, hopefully) or use a library (that the canonical tool may be based on/also use). Both schemes have their advantages and disadvantages. It would be an interesting study in why/how the different ecosystems evolved to favor one over the other, how that has changed over time, and how that's influenced the size and robustness of the respective ecosystems. There's probably a lot of influence on the Windows/RPC side coming from the canonical tools being primarily interface GUI interfaces, which is then natural to want to "drive" or "control" remotely, vs "headless" interfaces that are able/meant to be scripted as a first order requirement.