An alternative approach for auto column widths

[jtrim-ons]

Is your feature request related to a problem? Please describe.
Automatically calculated column widths don't take account of numeric values in columns, and sometimes don't quite match the width of the widest text in a column.

Describe the solution you'd like
Auto column widths calculated by summing the widths of the Arial characters that make up a string.

Describe alternatives you've considered
I've tried to implement a prototype of this in the PR linked below.

I measured Arial characters using JavaScript, and modified the calculation function in wrappers.py to use these character widths.

I've also changed the code to measure widths of numbers, assuming no more than 3 decimal places. I thought this might be useful if a column contains big numbers but has a very short heading.

Calculating the width of a string by adding up the widths of individual characters isn't completely accurate. For example, the width of 'Ta' is less than the the sum of the widths of 'T' and 'a'. However, the simple approach seems to do a good job. If you wanted, there might be a really accurate way to measure string width by looking at the width of each character when it appears after each other possible character.

Another possibility would be to use Pillow to find text widths. I think this would be slower.

Additional context
N/A

[jtrim-ons]

It looks like an AutoFit feature was added to XlsxWriter recently that uses a similar approach. I'm not sure if this works well enough to do the job? (It might have a hard-coded font and size, I think.)

[gisellerosetta]

To add to this, feedback has been that setting column widths (and row heights) isn't easy. Perhaps we can investigate a manual option too?

[gisellerosetta]

Potentially cross over with the thread in #125

[gisellerosetta]

DoD:

• The auto column width calculation is updated based on calculations of the length of string characters.
• The calculation accounts for numbers as well as characters such as ., and ensures columns are wide enough for the widest value or header.
• The implementation is efficient and does not significantly slow down table generation.