jmcnamara / XlsxWriter

A Python module for creating Excel XLSX files.
https://xlsxwriter.readthedocs.io
BSD 2-Clause "Simplified" License
3.66k stars 631 forks source link

feature request: custom `default_col_width` [HAS PATCH] #1024

Closed tobwen closed 1 year ago

tobwen commented 1 year ago

Feature Request

summary

Excel changed the column width from 8.43 to 10.71 on most systems. I've tested more than 35 machines in German locale with Excel 2010 and Excel 365 and all were 10.71 here.

To sync the column width between Xlsxwriter and Excel, I first used an ugly workaround: worksheet.set_column(0, 16383, 10.71). But then I thought: let's do it better. Let the user decide about the default.

solutions

I've created two different approaches, since I don't know which style or way you'd accept.

variant 1: function

worksheet.set_default_col_size(10) https://github.com/jmcnamara/XlsxWriter/compare/main...tobwen:XlsxWriter:default_col_width-variant1

variant 2: config

worksheet.default_col_size = 10 https://github.com/jmcnamara/XlsxWriter/compare/main...tobwen:XlsxWriter:default_col_width-variant2

variant 3: config via setter

worksheet.default_col_size = 10 No code now, but I'd use a setter. This doesn't seem to be common in XlsxWriter now.

todo

  1. I'm aware that the value 8.43 is hardcoded at various places. This also should to be dynamic, not a big isse.
  2. Add to docs,
  3. Add tests.

request

Please tell me, which way to go.

jmcnamara commented 1 year ago

Excel changed the column width from 8.43 to 10.71 on most systems

I don't think that is correct, at least not on all systems. Here is 8.43 in a recent EU locale version:

Capture

I first used an ugly workaround: worksheet.set_column(0, 16383, 10.71)

If you wish to set the overall width to 10.71 then I think that is probably the best thing to do.

So, since the width hasn't changed in all versions to a new standard value, and because there is an easy way to change the widths via the standard interface, and also because I haven't had any other requests like this, I'll pass on this suggestion.

Thanks for the input.

tobwen commented 1 year ago

I have to admit that I'm a little disappointed that you just closed the feature request as "completed". I was happy to have provided a useful additional feature and then you throw it into the trash. I assumed that this is an open source project where others can participate, especially if they ask in advance HOW you, as the maintainer, want something to be implemented and they even offer to write tests and documentation.

Especially BECAUSE there seem to be differences between different Excel versions, I think the ability to let users freely define the default width is a great feature that expands the feature set. If he doesn't need it, he doesn't need to use it.

The solution to iterate over thousands of columns is pretty inefficient because my solution works for XLSX specs and is set only once per worksheet.

I'm of course grateful for your library and care, but disappointed by this action. If my time permits, I will continue to update my fork.

jmcnamara commented 1 year ago

I have to admit that I'm a little disappointed that you just closed the feature request as "completed".

I apologise if I left you angry/disappointed. It wasn't my intention.

I didn't close it as "Completed". GitHub does that. I just closed it. For me this is more of a "Won't Fix".

especially if they ask in advance HOW you, as the maintainer, want something to be implemented and they even offer to write tests and documentation.

That is fine but you didn't ask if it "should" be implemented. "How", to me, is a secondary discussion. And for me the answer to the "should" part is still no, for the reasons I gave above.

jmcnamara commented 1 year ago

I've tested more than 35 machines in German locale with Excel 2010 and Excel 365 and all were 10.71 here.

For reference could you attach a newly created and unmodified file created with a German locale version of Excel 365.