[GNC] Report - Income Statement - Layout problem

[Adrien Monteleone]

I stand corrected, this can happen regardless of the depth preference.

The issue is entirely caused (best I can tell) by using separate tables 
for the Income & Expense sections.

Since the browser will adjust the label column to fit the content, if 
those content widths differ, you'll see misalignment.

In my case, due to some long account names, my Income section was 
slightly wider than the Expense section despite being depth limited to 
4. (the reverse of the OP's image and what I found at depth > 4)

The quickest solution is simply to put the Income & Expense sections in 
one HTML table element. This will cause the browser to size all 1st <td> 
elements on each row to the same maximum to fit the widest content. 
(effectively sizing the first column all the same)

There might be a complication with the ordering since there is a report 
option to turn off 'default Income section first' in the report.

One small additional issue, is that this approach provides no spacing 
between sections.

This can be solved by adding:

<tr><!--presentation hack to provide spacing between P&L sections-->
     <td>
          
     </td>
</tr>

after the first section's total row. (this generates a blank table row 
with content height as a visual spacer, which can be adjusted with a 
font-size declaration if desired.)

I don't like that approach, but it is quick and easy. (the report HTML 
is full of presentation hacks, and one such hack, possibly causing this 
problem, is the use of   being inserted as an account label 
indention mechanism rather than generating additional columns.)

I'm not sure of the table semantics with this approach either.

Technically, the report is a single entity, so perhaps a single table is 
better in that regard even though each section has its own subtotal.

I did play with adding cell padding-right to the first label-cell and it 
worked, but that requires some calculation based on which column will 
end up wider, and very likely a magic number or two for refinement, so 
that's likely out as a solution.

It might also be possible to calculate and add em-based padding-left to 
the account label cells, (rather than multiple   entities) but that 
doesn't really solve the variable overall column-width problem. (it just 
changes how the indention is accomplished)

Fixed-width would very likely be a mess too. (and still have to be 
calculated, and that might break on a per-browser basis)

There might still be an out playing with box-sizing and/or display 
properties but I don't really see any magic happening since the widths 
are calculated independently.

One final stretch might be to play with the size of the containers of 
the two tables, but I seriously doubt it as that affects overflow 
usually, not expanding something smaller.

Regards,
Adrien

On 3/21/22 9:47 PM, Adrien Monteleone wrote:
> For me, this only happens at depths 5,6, & ALL.