Spanning Sizes Last Column Too Wide about asciitable HOT 2 OPEN

I've ran into the same issue and the root cause is that Threads is a valid column with a valid width on its own. That width is stored by the CWC for column 3, because Threads is actually column 3, spanning column 2. All other rows of column 3 are smaller than Threads, hence all rows in that column get the length of Threads.

Spanning etc. seems to be applied later, because instead of handling Threads as a column on its own, its width in theory is the width of all columns it spans, 2 and 3 in your example. As long as Threads fits into the space of those two columns, which is the case here, column 3 could be stored with its own width being smaller than Threads.

At least for cases in which column width is known to be constant, this problem can be worked around by simply setting a maximum width on the calculator:

cwc.add(0, 0).add(0, 0).add(0, 0).add(0, 0).add(0, 26).add(0, 26);

┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                          Übersicht empfangener Messgeräte.                                                          │
╞═════════════════════════════════╤═════════════════════╤═══════════════════╤═══════════════════╤══════════════════════════╤══════════════════════════╡
│ Ableseunternehmen (Benutzer-ID) │ Liegenschaftsnummer │   Datensammler    │ Anzahl Messgeräte │   Beginn des Zeitraums   │    Ende des Zeitraums    │
╞═════════════════════════════════╪═════════════════════╪═══════════════════╪═══════════════════╪══════════════════════════╪══════════════════════════╡
│                               1 │ Real estate mööp 01 │ 00-00-00-00-00-01 │                 1 │ 1970-01-01T00:00:00.000Z │ 1970-02-01T00:00:00.000Z │

vs.

┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                             Übersicht empfangener Messgeräte.                                                              │
╞═════════════════════════════════╤═════════════════════╤═══════════════════╤═══════════════════╤══════════════════════════╤═════════════════════════════════╡
│ Ableseunternehmen (Benutzer-ID) │ Liegenschaftsnummer │   Datensammler    │ Anzahl Messgeräte │   Beginn des Zeitraums   │       Ende des Zeitraums        │
╞═════════════════════════════════╪═════════════════════╪═══════════════════╪═══════════════════╪══════════════════════════╪═════════════════════════════════╡
│                               1 │ Real estate mööp 01 │ 00-00-00-00-00-01 │                 1 │ 1970-01-01T00:00:00.000Z │ 1970-02-01T00:00:00.000Z        │

Not sure if there's a good alternative implementation possible in the CWC: One could collect all(!) widths of individual columns instead of only the maximum ones, including the width of spanned columns simply being 0. Afterwards one could search the result of all columns for the maximum width of all columns and store those in some map of column index to width. Then one could iterate all widths of all rows again and look for spanning columns and calculate their true width using the formerly stored individual maximum columns width. And that's where things get tricky in my opinion: Individual rows might contain multiple spanning columns. All rows might contain spanning columns only at different positions etc.

from asciitable.

I'm attaching a PoC of a different CWC following the line-length approach of CWC_LongestLine as well, but taking the width of spanned columns into account. This works for the above table in my case without setting a maximum width manually, which makes things more flexible for changing content. Maybe someone is interested to review and optionally add it to the project. Didn't provide a PR because I'm not sure about names, if it's worth it etc.

VwrDvResultsCwc.java.txt
VwrDvResultsCwcStringifier.java.txt

from asciitable.