[GNC] Report - Income Statement - Layout problem

[Christopher Lam]

Please be aware that GnuCash is a volunteer effort. In so many (20+) years
of users there have been no complaints about this particular layout issue
in the Income Statement. A fresh pair of eyes, however, found this genuine
layout issue. The Multicolumn Income Statement report in the Experimental
menu may be more suitable; it is much more capable and has a more
conventional layout.

Meanwhile, now that this is now known, and Adrien has kindly found the root
cause, it is likely that the developers will be able to fix the Income
Statement.

On Wed, 23 Mar 2022 at 13:49, Carl-Kensaku HERBORT <it at digiene.ch> wrote:

> Hello,
>
> Thanks to everyone for your help and time.
>
> It is a shame that it is so complicated to make the Income Statement
> report look normal, like the Balance Sheet report, which also has two
> sections (Assets and Liabilities) that have no problem at all.
>
> I already have to use two separate software: an ERP/CRM for invoicing
> and daily accounting and GnuCash for heavier monthly/yearly accounting,
> mainly to produce the Income Statement Report and Balance Sheet report
> (or so was my plan). I didn't know that GnuCash was not made for that
> and that a third software (or SCHEME/HTML coding & modifications) was
> needed just to get even basic reports that all SME business need.
>
> I guess there is a first for everything: I am giving up.
>
> Again, thanks a lot to everyone who took on their free time to answer my
> questions.
>
> Have a nice day
>
> Best regards
>
> --
> Carl-Kensaku HERBORT
> DIGIENE
> Case postale
> CH-1002 Lausanne
> Suisse
>
> +41 (0) 21 320 22 66
>
> Le 22.03.22 à 05:24, Adrien Monteleone a écrit :
> > 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.
> >
> > _______________________________________________
> > gnucash-user mailing list
> > gnucash-user at gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > If you are using Nabble or Gmane, please see
> > https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>