Open numeralnathan opened 7 years ago
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.
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
Here's a table rendered by AsciiTable and CWC_LongestLine renderer. Each cell has a left and right padding of 1. The "Threads" header spans Count and Max columns. Notice how the Max column is wide enough to fit "Threads" with a left and right padding of 1. Please size the Max column to be smaller.
If the Count and Max columns are sized too small to fit "Threads", then both columns should be widened larger by an even amount.