[GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp
adrien.monteleone at lusfiber.net
Thu Aug 9 09:00:21 EDT 2018
> On Aug 9, 2018, at 7:37 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> For reports on the other hand it's not important what Gtk+ implements as the
> reports are html rendered via webkit (essentially a built-in webbrowser) so
> the W3C css rules matter here..
Can’t believe I didn’t remember that. This makes the solution much easier. I’m generally not a fan of table layouts, but being this is tabular data, it’s probably the most semantic approach. In that case, the columns feature of CSS3 wouldn’t come into play. But they will be useful with respect to multi-vs-single column presentation. Setting a 2-column preference would set a CSS rule for 2 columns and then set a rule for the second column data to be in column ‘2’. Each section of the report would have to be its own table for that to work. I don’t think floats are needed. (and would only move the sections around based on the width of the report window anyway)
>> My guess would be to set classes on the accounts for the column position and
>> set left margin or padding on the classes accordingly. (I think Geert
>> mentioned something along these lines in an earlier reply)
> That's indeed what I had in mind, but I haven't tried myself either. So I
> can't tell how feasible it is anyway. I don't see an issue for accounts as
> they are left-justified. I don't know for the right-justified amounts though.
> People with more html/css experience may want to share their views here.
I’ve yet to generate an HTML table via code (certainly not scheme) but I’ll take a crack at it with PHP and see what works, then that could be translated. I should think padding-right rules could be used on the amounts that are right-justified.
All of this now makes me curious to start examining the current HTML being generated for reports to see what’s at play.
More information about the gnucash-devel