Similar project

[dxe4]

Hello,

I just found your library. I am building something similar. i was just wandering if you want to make a team? You can check it here https://github.com/papaloizouc/jsonTOxls. I am using XlsxWriter i believe its a very good api. Let me know if you are interested.

[mkasa]

Hi, Charalampos.

Your work looks very similar to mine, and I am pretty interested in creating a team if both of us can save some efforts for developing new features and/or maintenance (bug fixes). Especially, having an embedded web server (Web API) and conditional formatting are really nice (I wanted to implement them next if I had time!).

I know XlsxWriter has a very good API and of course I checked it before I started to implement json2xlsx. It looks like XlsxWriter has more features and better documents, although openpyxl is not well documented as XlsxWriter (but still understandable at least after reading a bunch of posts in the forum (and sometimes reading source code)). The only reason why I did not use XlsxWriter and chose openpyxl instead is that XlsxWriter has no "xlsx reader" compatible to it. It will not be any problem with the current features, but another feature I want to implement in the future was very difficult to realize with XlsxWriter.

This project originated from my frustration. I repeatedly copy-and-paste figures in console logs to Excel files to create tables in scientific papers. Every time I update an analysis program, I had to copy-and-paste hundreds times. I developed json2xlsx to automate this process. Yes, it works well, but still I think one issue need to be addressed. Formatting Excel worksheets with domain specific languages is still a pain especially for those who are not good at programming (e.g., students in Biology). If we can give a "template" Excel file for formatting (to make output look like the template), we would be able to avoid using tedious DSL to specify cell formatting. At least I personally do not like to specify something like "a cell with a thick border on top and a thin border on left", "a cell with width ... width ... uh... uh... 100px can accomodate 10 digit values with comma?", or "a cell with lightyellow background and with font 'MS PGothic (Japanese font)'".

Let's get back to the main story. So, having a "reader" library is a "must" for me. XlsxWriter failed in this point. If it can read a cell formatting now, please let me know. I have not checked it long. Xlrd/wt had a severe incompatibility in cell formatting so I threw it away, too. I have not checked it long either, but it needed a significant engineering to fix it, so I bet the problem still exists.

[dxe4]

Hi, i can understand that. Its still not able to read files but i believe its a very good api. I was also thinking about asking the developer for an auto re-size columns feature. Maybe you should post an issue and ask if he can make a "reader" for the api. Personally i have used 5 different api's for xls writing and i always get annoyed, xlsxwriter was the only api i liked so far. i also checked the developers profile and he has several projects for excel so i believe he is a person you can trust on that. I am planning to stick to xlsxwritter, but i just thought if we do the same work maybe we could stick together. If i were you i would consider the possibility of 1 api for writing 1 for reading but of course its personal choice. Thank you for your reply. If you think xlsxwriter could be useful for you feel free to contact me any time. When i started this project i made a research as well and for what i am doing it seems to be the best library so i'll probably stick with it.

[mkasa]

Agreed. My code does not use anything specific to a particular writer library and porting to another library may not take so long, so I am willing to move to xlsxwriter (or whatever) if it supports read operation. I already considered "1 API for writing, 1 API for reading", but cell styles are heavily incompatible across libraries so we need a code like (it's just an imaginary example):

def convert_borderstyle(st):
    if st == A.Border.UPPER_THIN: return B.Style.Border.BORDER_THIN_UPPER
    if st == A.Border.LEFT_THIN: return B.Style.Border.BORDER_THIN_LEFT
    ... blah blah blah

It is a great pain for me to write this kind of code. I estimated that the conversion code would be almost half size of the reader library (or even more for some pair of reader/writer), so I would rather implement a new reader for myself (and maybe send a pull-req). The situation may have changed now, so I would appreciate it if anyone let me know a way to avoid this. I am still interested in merging both codes and I would be happy if both road maps are realized with the merged single code base.

[dxe4]

Still xlsxwritter is not able to read but thats fair enough because the name is writer anyway. I am not sure if i can help you make an excel reader because i have a full time job and i just spent my free time on python at the moment, but i guess if the project is interesting i can spent most of my free time on it. I guess moving the formatting to a different api would probably be a separate project and a lot of code so it worths writing a reader, you also gain some experience by writing a reader. Maybe we can make a research and see how much effort is required to create a reader.

[mkasa]

I asked him directly, and got the answer: "no plan for XlsxReader." I also have a full time job and json2xlsx is developed using my free time, so things may go slowly but yes, anyway, the research is a good point to start with. This month I am too busy, so I'll see it later.

[dxe4]

ok that's good i'll add some conditional formatting and mergin on my library, and i'll try to start an excel library around 10th of july.

[dxe4]

Just in case you are interested, i have just added a big example in client/examples/example4.xlsx and example4.json with conditional formatting and merging.