github-starred/libxlsxwriter

Fork 0

mirror of https://github.com/jmcnamara/libxlsxwriter.git synced 2026-05-15 14:15:54 -06:00

[GH-ISSUE #196] Feature request: write workbook to buffer #159

New issue

Closed

opened 2026-05-05 11:48:34 -06:00 by gitea-mirror · 10 comments

gitea-mirror commented

2026-05-05 11:48:34 -06:00

Owner

Originally created by @cruisercoder on GitHub (Sep 15, 2018).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/196

Originally assigned to: @jmcnamara on GitHub.

Are there plans to implement a write workbook to buffer option?

Originally created by @cruisercoder on GitHub (Sep 15, 2018). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/196 Originally assigned to: @jmcnamara on GitHub. Are there plans to implement a write workbook to buffer option?

gitea-mirror

2026-05-05 11:48:34 -06:00

closed this issue
added the
feature request

medium term
labels

gitea-mirror commented

2026-05-05 11:48:41 -06:00

Author

Owner

@jmcnamara commented on GitHub (Sep 15, 2018):

Are there plans to implement a write workbook to buffer option?

Not really.

It should be possible with the zlib api to create an in-memory buffer rather than a file but I haven't looked into it.

Internally the library mainly uses file descriptors to assemble the various XML file so that part wouldn't be "in-memory".

What is your use-case? Would writing to a temp file and then loading that into a buffer be a sufficient workaround?

John

@jmcnamara commented on GitHub (Sep 15, 2018): > Are there plans to implement a write workbook to buffer option? Not really. It should be possible with the zlib api to create an in-memory buffer rather than a file but I haven't looked into it. Internally the library mainly uses file descriptors to assemble the various XML file so that part wouldn't be "in-memory". What is your use-case? Would writing to a temp file and then loading that into a buffer be a sufficient workaround? John

gitea-mirror commented

2026-05-05 11:48:44 -06:00

Author

Owner

@cruisercoder commented on GitHub (Sep 15, 2018):

My use case is a REST endpoint that returns workbooks. That's what I plan to do now is to write to a temp file and then write that out or save to a data store. In a high volume setting, it would be a bit simpler and faster to just have access to the image. It might be good for testing as well as you could more simply pair it with a reader to validate the sheet. I would imagine that it should be pretty straightforward to abstract the writing calls for either a file or buffer.

@cruisercoder commented on GitHub (Sep 15, 2018): My use case is a REST endpoint that returns workbooks. That's what I plan to do now is to write to a temp file and then write that out or save to a data store. In a high volume setting, it would be a bit simpler and faster to just have access to the image. It might be good for testing as well as you could more simply pair it with a reader to validate the sheet. I would imagine that it should be pretty straightforward to abstract the writing calls for either a file or buffer.

gitea-mirror commented

2026-05-05 11:48:46 -06:00

Author

Owner

@cruisercoder commented on GitHub (Sep 15, 2018):

There's also the issue of security. We have sensitive information on the sheets the use of files creates another security vector that has to be accounted for (using encrypted mounts for example). Disk space and name uniqueness also have to be handled correctly.

@cruisercoder commented on GitHub (Sep 15, 2018): There's also the issue of security. We have sensitive information on the sheets the use of files creates another security vector that has to be accounted for (using encrypted mounts for example). Disk space and name uniqueness also have to be handled correctly.

gitea-mirror commented

2026-05-05 11:48:49 -06:00

Author

Owner

@jmcnamara commented on GitHub (Sep 15, 2018):

I'm somewhat open to the first part of this, writing the xlsx file to a buffer. I'd accept a PR for it but I'm not currently motivated to do it myself and this hasn't been a frequently requested feature, to date. I'll leave this open as a feature request to see if it has wider interest.

However, the second part, replacing the tmp files with in memory files would be harder to do portably. I should be just a matter of replacing lxw_tmpfile() with a memory buffer equivalent but I'm not aware of C option that would work on OS X/Linux/Windows. fmemopen() might or might not work.

For specific use cases it might not be too hard. In particular if the end user is using C++ or just one OS.

@jmcnamara commented on GitHub (Sep 15, 2018): I'm somewhat open to the first part of this, writing the xlsx file to a buffer. I'd accept a PR for it but I'm not currently motivated to do it myself and this hasn't been a frequently requested feature, to date. I'll leave this open as a feature request to see if it has wider interest. However, the second part, replacing the tmp files with in memory files would be harder to do portably. I should be just a matter of replacing [`lxw_tmpfile()`](https://github.com/jmcnamara/libxlsxwriter/blob/master/src/utility.c#L520) with a memory buffer equivalent but I'm not aware of C option that would work on OS X/Linux/Windows. `fmemopen()` might or might not work. For specific use cases it might not be too hard. In particular if the end user is using C++ or just one OS.

gitea-mirror commented

2026-05-05 11:48:51 -06:00

Author

Owner

@cruisercoder commented on GitHub (Sep 15, 2018):

Thanks. I will size up the work when I get some time.

@cruisercoder commented on GitHub (Sep 15, 2018): Thanks. I will size up the work when I get some time.

gitea-mirror commented

2026-05-05 11:48:52 -06:00

Author

Owner

@mewalig commented on GitHub (Aug 9, 2019):

Not sure how that translates for the other languages but for C, could this be fairly straightforward to just compile with your own custom functions for fopen, fread, fwrite, ftell, fprintf and fclose?

@mewalig commented on GitHub (Aug 9, 2019): Not sure how that translates for the other languages but for C, could this be fairly straightforward to just compile with your own custom functions for fopen, fread, fwrite, ftell, fprintf and fclose?

gitea-mirror commented

2026-05-05 11:48:54 -06:00

Author

Owner

@jmcnamara commented on GitHub (Sep 21, 2020):

Closing this since I don't see any ANSI-C OS portable way of doing this.

@jmcnamara commented on GitHub (Sep 21, 2020): Closing this since I don't see any ANSI-C OS portable way of doing this.

gitea-mirror commented

2026-05-05 11:48:56 -06:00

Author

Owner

@mohd-akram commented on GitHub (Nov 8, 2022):

fmem is a possible solution to this.

@mohd-akram commented on GitHub (Nov 8, 2022): [fmem](https://github.com/Snaipe/fmem) is a possible solution to this.

gitea-mirror commented

2026-05-05 11:48:57 -06:00

Author

Owner

@mewalig commented on GitHub (Jan 20, 2023):

@jmcnamara Out of curiosity, what ANSI-C portability issues would this have raised? Not trying to change your mind, just wanting to learn

@mewalig commented on GitHub (Jan 20, 2023): @jmcnamara Out of curiosity, what ANSI-C portability issues would this have raised? Not trying to change your mind, just wanting to learn

gitea-mirror commented

2026-05-05 11:48:58 -06:00

Author

Owner

@jmcnamara commented on GitHub (Jan 20, 2023):

@mewalig I was referring to fmemopen() style functions which afaik are not ANSI-C and which don't work on Windows.

But not impossible as you say and @mohd-akram points out the fmem library above. He also added support for writing a workbook to a buffer under the existing USE_FMEMOPEN define in PR #382. So this feature request has actually been implemented in version 1.1.5.

@jmcnamara commented on GitHub (Jan 20, 2023): @mewalig I was referring to `fmemopen()` style functions which afaik are not ANSI-C and which don't work on Windows. But not impossible as you say and @mohd-akram points out the fmem library above. He also added support for writing a workbook to a buffer under the existing `USE_FMEMOPEN` define in PR #382. So this feature request has actually been implemented in version 1.1.5.