Open-source Libraries for Working with Open XML Documents (docx, xlsx, pptx) | Hacker News Reader

Open-source Libraries for Working with Open XML Documents (docx, xlsx, pptx)

github.com

124 pointschx46 comments

The actual docs for the sdk are at: http://msdn.microsoft.com/en-us/library/office/bb448854(v=of...

A link from the github page might be helpful!

The content also looks to be open sourced on Github, too: https://github.com/OfficeDev/office-content

So far this looks Windows only. I'm currently using LibXL (http://www.libxl.com/) to generate Excel documents. Anybody know of any other cross platform alternatives?

Shameless plug: we are working on a javascript solution.

XLSX/XLSM/XLSB reader/writer: https://github.com/SheetJS/js-xlsx

XLS(BIFF8)/XML(2003-4) reader: https://github.com/SheetJS/js-xls

In-browser reader demo: http://oss.sheetjs.com/

In-browser writer demo: http://tokuhirom.github.io/js-xlsx-demo/

Some other alternatives:

Python xlrd https://github.com/python-excel/xlrd , xlwt https://github.com/python-excel/xlwt , XlsxWriter https://github.com/jmcnamara/XlsxWriter

Java POI https://poi.apache.org/

I don't see any reason why it would be Windows only. All the code appears to be spec-compliant C# that doesn't use P/Invoke to call native modules or rely on C++/CLI. The only sticking point I see is the PowerShell script, and that's pretty trivial to replace since it's just a build script (you could use xbuild/msbuild, since mono supports that, or just use make)

https://github.com/OfficeDev/Open-XML-SDK/pull/3 suggests that there are issues with use in mono

In python, I've had great luck with XlsxWriter

http://xlsxwriter.readthedocs.org/

For Lua there is xlsxwriter:

https://github.com/jmcnamara/xlsxwriter.lua

Make a html, embed the images in base64 using mhtifier.py, and rename the html as doc. Word will open it without problems.

Further instructions:

http://sebsauvage.net/wiki/doku.php?id=word_document_generat...

I like that MS is attempting to take a big step into FOSS but having dependencies on their OS and their build environment is reason enough for me to dismiss this stuff. Thanks for generating some interest in the truly free libs out there.

This is obviously great but I find it annoying the instructions ask your to Set-ExecutionPolicy Unrestricted in order to run the PowerShell script. That is just lazy.

The default is Restricted, so no scripts can run at all. So they need to tell the user to change it to something.

Their choices are AllSigned (or RemoteSigned which is the same thing in this context) or Unrestricted.

If they chose the AllSigned route and then sign it with a CA certificate (e.g. Microsoft's Code Signing cert) that would work, but if the user ever made even a one character change to the script the thing will break and it might be unclear as to WHY. Plus you have to be careful not to lose your signature when sending files via certain technologies.

Alternatively they could teach the user how to set up a local CA, make a key pair set, and then install. But that too is going to break a lot as it needs to be re-signed each time the script is updated, and obviously inter-machine coding will be a PITA.

It is fairly standard practice on non-server developer machines to set it to Unrestricted. It isn't really any more dangerous than for example BAT or VBS scripts which have no such default restrictions.

You call it lazy, but the alternatives seem impractical and painful. There are scenarios where you want to enforce code signing, I just don't really feel like a developer machine is one of them.

MS screwed up with PowerShell policies. Because the default is so restrictive, corporate sysadmins are worried about altering it to Unrestricted, and signing each script is just impractical, so in practice lots of customers will just refuse to enable it.

This is like a Linux distribution shipped OpenSSH disabled by default, and if you enabled it, you'd have to sign every script you run or allow everyone to run (almost) as root.

I'm not a fan of PS (coming from Python, PS syntax is just nuts), but it's the most useful tool in the Windows world to automate tasks and deployments of all sorts... or rather it would be, if the security model weren't so inane that few people dare touching it.

I don't work for MS so consider this pure speculation:

In the past "bad guys" have used VBS to leverage a minor exploit into a full compromise. For example, they might have the ability to write arbitrary strings to the filesystem but not execute or run code. So they write out a *.VBS into the StartUp folder, and when the user reboots they have gone from a relatively minor entry into full remote control.

While VBS and BAT remain on Windows based PCs, having PS be locked down is a little irrational. However I suspect Microsoft might be looking to the future when one day they can remove both BAT and VBS (or force the user to enable/install them manually) so that it becomes harder to use such things to escalate your compromise.

Essentially they're trying to limit attack surface on 90%+ of consume grade machines, as your average consumer will never run a PS script or even care that they cannot. A lot of medium to large enterprises have an internal CA (with the CA cert already on the machines for authenticating with AD) so internally signing their network scripts is of lower cost (i.e. the infrastructure is all in place, just a single command to sign which you can automate with PS, unlike a solo developer who might not be aware of certificate issues anyway and certainly won't be running their own CA).

Your post assumes that PS hasn't been hugely successful, which is definitely not my experience. SysAdmins in the Windows worlds are all over PowerShell, they love it, and if you go read something like SpiceWorks or any other similar community 90% of the new automations are written in PS rather than VBS/BAT (it helps that all of the MS tools in Server 2012 natively support PS). I don't really think the default security restrictions are going to limit PS's popularity, they might limit it for certain niche deployments (e.g. MAKE scripts distributed over the internet) but not for internal use.

As far as you not liking PS, I understand, I really do. Most other scripting languages use strings as their fundamental unit of work (e.g. pass strings from process A to B, even over pipes it is all strings or file names which are also strings). In PS the System.Object is the base unit, and everything above that is also an object (it is classic OOP), so it really takes some getting used to. There's a lot of inheritance in there.

But once you understand the underlying concepts involve, it is quite de-mystified. However it really helps if you've come from a Java/.Net programming background since even things like overloading isn't really something you'd run across in a scripting language based largely on string transportation.

If you want to get started watch this workshop (you don't need to watch the full 4 hours(!)): https://www.youtube.com/watch?v=-Ya1dQ1Igkc

This is the most common explanation, but tbh, it doesn't cut it: the consumer market runs on Windows 7/8, whereas PowerShell is most useful on Server 2008/2012; so why can't they enable it by default on the latter?

> A lot of medium to large enterprises have an internal CA (with the CA cert already on the machines for authenticating with AD)

That's not my experience, but I guess we're both going by anecdotes here. (to be precise, in the few cases where an internal CA is actually present, the process to have anything signed is usually a bureaucratic nightmare)

My particular point of view is a vendor who comes in to deploy stuff on customer servers and is told that Powershell should remain disabled (or be enabled for installation purposes and then disabled again, which removes the possibility of automated maintenance via PS). I guess it's a political choice as much as a technical one, but that's what I've experienced; and the larger the company, the most likely that this policy is not negotiable.

I don't disagree that PS has been successful; the Windows world was screaming for a half-decent shell and PS is exactly that. I just think that it could have been much more successful had MS chosen their defaults a bit more carefully (and/or implemented a better security model).

On the syntax, what I don't like is not being object-based -- I don't particularly like the "string everywhere" approach -- but rather the over-reliance on special characters (that tends to make a PS script fairly unreadable compared to Python). It also feels more of a bash-style world than a scripting-language world, which I think is a step back from VBS/JS.

In case anyone else was wondering, the ideal 'one-time-only' approach appears to be passing '-ExecutionPolicy Bypass' when starting up PowerShell:

  PowerShell -ExecutionPolicy Bypass -File (...)

http://stackoverflow.com/questions/728143/ignore-security-wa...

I wonder why they call it Open XML. I thought it was called Offie Open XML (OOXML) and it was standardized as ISO 29500.

As it seems, this project does NOT implement the ISO standard, instead it works with the non-standard compliant versions that Microsoft Office produces. Le Sigh.

Michael Meeks' (LibreOffice developer) response https://people.gnome.org/~michael/blog/2014-06-25-openxmlsdk...

For Python there's also PyExcelerate for creating XLSX files: https://github.com/kz26/PyExcelerate

Supposedly it's the fastest, even beating out xlsxwriter.

Alternative is my Docvert http://github.com/holloway/docvert-python3 software... it works on Linux/Windows/OSX though it's mostly for reading DOCX/DOC/ODT and not for writing.

Really no mention of docx4j http://www.docx4java.org/

C# only?

Can this be used with Mono?

Not sure. I guess it's useful as a reference implementation (if it conforms to the specification that is), but not beyond that. Actual editors and office suites which could potentially use the code aren't written in C#.

The repo doesn't contain any P/Invoke or C++/CLI, so I don't see any reason why it wouldn't work with Mono.

There's a pull request for a basic mono build file - https://github.com/OfficeDev/Open-XML-SDK/pull/3

Not really. It's written in C#; the result of compiling it will be a managed library - a .dll containing a .NET assembly of CIL code. You can then load it into a .NET runtime (looks like they're working to ensure it will run in Mono as well as the Microsoft CLR) and easily call the library from other managed code, which could be C#, VB.NET, F#, C++/CLI etc. Assuming it does get to the stage where it can be run on Mono, you could embed the Mono runtime (http://www.mono-project.com/Embedding_Mono) and call it from any language with a C binding (you would have to write some C, e.g. by building a JNI wrapper for the mono runtime to expose the library to Java code - eugh). On Windows, you should be able to easily wrapper it and expose it via COM, if you wanted to use it from proper C++, or Delphi or FoxPro, perhaps.

But what do you expect? Multi-language interop for libraries is hard, though. Frankly the fact that it's natively accessible from every CLR language is pretty impressive - most Python libraries can't really be used from anything but Python, for example. Generally the approach with an open source library like this would be for someone to take on porting it to, e.g., Java.

Microsoft is making it really hard to continue to blatantly dislike them.

Just tell people you are certain they are "up to something", perhaps trying to gain our trust and catch us napping.

They are up to something, namely trying to become relevant again. When you rule the world, you can get away with all sorts of obnoxious things. When you don't, it's either play nice or go home.

I'm beginning to like some parts of Microsoft. Babylon.js and TypeScript are both pretty cool projects, and their work on Haskell, F# and the new .NET compiler is all very cool.

Really? I find it pretty easy, especially after all the "team play" revelations they've been having with NSA.

http://www.theguardian.com/world/2013/jul/11/microsoft-nsa-c...

http://techcrunch.com/2014/05/13/nsa-docs-detail-efforts-to-...

Not to mention that pushing Metro to my desktop didn't exactly win them brownie points with me, nor did being essentially the biggest patent troll around by asserting 300 patents against an open source project, and then helping Oracle in the ruling that decided API's are copyrightable.

I wrote a wishlist for Satya sometimes ago on Hal Berenson's blog (I even suggested MS withdraw the OOXML standard while not changing the format itself): http://hal2020.com/2014/03/03/satya-shuffles-his-leadership/...

I agree, but not on the basis of this.

"Note: for this first release, you must have some version of Visual Studio installed."

Until that changes, it's just another product in the Microsoft ecosystem.

Really? Because you can fix that. You can distribute those fixes. You can submit those fixes for Microsoft to consider making an official part of the release. Or you could fork it, fix it, and relicense your fork under the GPL.

I understand the order of magnitude is different, but until now the huge work made on OpenOffice/LibreOffice was on the same principle as what your are saying: "if MS doesn't do it, we'll make it ourself".

So, saying you can have it as great as you want as long as your are willing to commit to it isn't really informative.

Also I might be tainted by the years and years of Microsoft screwing with Office, but I'd wait until there is at least one or two serious players validate this project as fully working at scale until I'd give them the full credits.

Spend some time with VSTO on the client and the OOXML SDK on the server and I assure you that you'll still want to kill yourself. I just spent three months doing this and it was akin to knawing your own limbs off. The Office VSTO API is poorly designed, a mishmash of shims that barely work and are impossible to debug. The documentation is awful and their support teams don't even know how to fix problems. It's also absolutely painful making something work on Office 2097, 2010 and 2013. Its bad news when after a week you start wrapping all entry points to stop managed exceptions crashing office.

Open sourcing stuff doesn't make it magically entirely pain free nor does it make a quality product. This isn't a quality product and neither is the thing that generates the documents you will need to parse (and clean all the incongruous crap) from.

I know it's just a typo, but I hope our children will never have to suffer "Office 2097"...

Well spotted. I'll leave it in for posterity :)

However I expect our Surface 2095 will run Office 2097 and it'll still have VBA jammed in due to some legacy clients moaning that they can't run their financial app in it any more :)

If it survives the VBA-pocalypse in 2030, that is, because it interprets dates with two digit years ending in '/30' - '/99' as referring to 1930-1999...

Ah yes I'd forgotten about that. Good point!

And the iOS 39 version of Office will still be ahead of the Surface version

I'd be curious to hear - were the issues mostly with VSTO, or were there problems with the OOXML SDK as well?

Both ends equally so. We did a lot of parsing and generation and found a pile of bugs in the SDK plus the thing isn't a deep enough abstraction so you have to break it regularly.

Thanks for the insight... that's certainly disappointing.

Not really. There was no need in OOXML to begin with. Especially in the ISO mess that MS created. It was born in the old MS, which was heavily into standards hijacking and vendor lock in. So it remained the child of that idea.

Current day MS is still strongly dominated by the lock-in mentality. So this change is welcome, but they have a really long way to go to repair all the damage they caused and gain some trust.

Reply on news.ycombinator.com