search

mjul / docjure

Read and write Office documents from Clojure
MIT License
621 stars 129 forks source link

ODS file support #110

Open avelino opened 11 months ago

avelino commented 11 months ago

.ods: OpenDocument Spreadsheet Document https://docs.fileformat.com/spreadsheet/ods/ https://www.libreoffice.org/discover/what-is-opendocument/

mjul commented 11 months ago

Thank you for your your suggestion.

I don't need it, so I am not going to build it.

If anyone wants to build it, the right approach would be build abstractions for the library features and have Excel and ODS back-ends for that. However, this might make everything much more complex, so an alternative to explore would be to built it as a separate library.

avelino commented 11 months ago

ok, i have the need and will probably implement it.

@mjul do you think it makes sense to implement inside docjure, consequently increasing the level of complexity, or do I do it outside (in a fork)?

mjul commented 11 months ago

I think the crucial question is whether or not you want to be able to translate from one format to the other.

Currently the library uses the POI Excel types as internal representation. If they were to be saved as ODS we would need to map not only data but also styles, formulas etc to be converted from one format to the other.

I believe this mapping is too much work to be worth the effort, and also not a good fit with the purpose of the library since it is mostly focused on the data.

So I am thinking it may be viable to explore something with a new V2 API for the library where the sheet is created with a specific format. For the data parts i believe this could be use the same API, and probably also for simple styling. For formula, it is an open question.

The other aspect is that there is currently some limited support for streaming large sheets rather than loading everything. How this would fit together is also an open question.

So, to decide on the extend/fork question

  1. we need to decide on the scope of how much functionality is really needed
  2. consider if we can build a new API partitioning and abstracting the features and its general structure

In relation to (2) my thoughts for a V2 has always been to have a Clojure data structure as the state rather than a raw POI object in order to provide a better way to handle e.g. styles rather than the imperative styling today. Incidentally this data structure would also allow an abstraction over the Excel / ODS backends.

avelino commented 11 months ago

great reflection and questions, I don't know how to answer them

I need to think and do some tests on how to abstract the POI data structure (make the data structure in clojure), making it possible to work with an adapter standard (xlsx via POI, ODS and any other format).

—-

to solve my current problem, I'm looking at the content type of the file and calling docjure for excel or SODS (written in java) solved my problem, but it is not an "elegant" solution as you are proposing