Multi-page invoices

[Geert Janssens]

Op 28-02-13 13:45, R. Victor Klassen schreef:
> Plan? Given how little familiarity I have with the code, the first part of the plan was to simply figure out where things are happening.  As a 0th step I should probably compile it.  (I have the downloaded the source).  In terms of level of involvement in the larger system, I'm thinking I would at least like to get this working before seeing whether to become a full-class developer, with ability to check code in.   If I can keep everything small and well-contained, I would then submit it as a patch.
>
> Having looked at the HTML, I can say it is the best-looking machine-generated HTML I've ever seen.
>
> I could look into the possibility of CSS, but I'm somewhat pessimistic.   HTML is really not designed for print.  As far as I can tell, the usual way of dealing with print is to re-render targeting the print device.  Doing this "right" is not something I would want to tackle.   At least not at this point.
>
> My situation is that I have roughly 30 years of software development behind me, mostly C++, and C before C++ was stable.   I left my position at Xerox a bit over a year ago, and have been doing a bit of Mac development, and mostly helping my son start a business.   It is that business that needs professional looking invoices, running into two pages.   Preferably by mid-summer.   We start to get busy in April, so I may wind up stuck with the awk solution.  But it's worth a shot.
>
> Given your description of the structure of report writing, it looks like one option is to modify the HTML when going to the printer.  Is it webkit that converts it to PDF or is that a function within the gnucash source?  If it is within gnu cash, that would be a place to do something different. Otherwise it would be a matter of modifying the HTML.   What it requires is knowledge of the height of cells within the table, and of the header material, which in turn depends (I presume) on the point size selected by the user.  That and the length of the page - which, ideally, is queried from the system.  I know where to look to find that on a Mac, but not how it would be done in a portable manner.   Then it is a matter of spitting out the first page header, as many lines as fit on a page, subject to having at least some minimum number on the second page, if it is required, and a page footer; then iterating over subsequent pages with an abbreviated header, contents, and footer.
>
> I would not expect to generate "page n of N" - only "page n".  And I would have to think about what the minimum work solution would be for starters.
>
> But first I'll look at CSS, and see what I find.
>
> Any pointers as to where to find what would be appreciated.

Hi Victor,

Your step 0 (compiling the code) should be relatively easy. From your 
background I presume you want to work on a mac. There are fairly 
detailed build instructions for OS X on the GnuCash wiki [1]. If you get 
stuck here, I'm fairly confident John will be able to help you out.

Then regarding the reports itself, we're looking at a pretty complicated 
issue.

I spent the best part of the day trying to understand how the GnuCash 
report code generates its html. The output may be the best machine 
generated HTML you've ever seen, the source code is probably the most 
complicated and messy way to achieve this I have ever seen. Sorry for my 
frustration vent here...

My idea was to do a fast proof of concept, setting some css parameters 
on the table and table rows that should ensure the rows are not split 
while printing. I found this on a stackoverflow question [2]. 
Unfortunately I just can't get the code to add some custom css or at 
least a class specifier for me. There are even comments in the code that 
suggest row style is lost. So going the css route in the current guile 
mess can not be advised so someone new to the code I'm afraid.

And then even if it were possible to fix our css issue, you would 
stumble upon the webkit bug again I shortly mentioned before [3]. the 
bug was filed in 2005 and anno 2013 it's still not marked as resolved. A 
patch is waiting in the bug report, but no one seems to look after it.

So it doesn't look good in that direction. The bug report does mention a 
tool wkhtmltopdf which apparently is  a tool that can generate pdf files 
from html using webkit. This tool has been patched to no longer have the 
bug. So *if* the css worked properly in our code, this tool could have 
been used to convert the generated html into a pdf that could properly 
be printed. It would still be an additional step to the current gnucash 
workflow.

To answer one of your questions, it's currently indeed webkit that 
renders the html for printing. This is so regardless of whether you 
print to a printer or to pdf (new feature in the development series).

Alternatives to solve your problem could be
a. your awk script
b. the optional python bindings have some code to convert invoices to 
latex. That will probably give better looking printe results. I have not 
used is myself, so I can't say much about it. Just giving you pointers.

That's about all I have. I had hoped for a better outcome, but it seems 
we're rather stuck with two nasty bugs.

Geert

[1] http://wiki.gnucash.org/wiki/MacOSX/Quartz#Building
[2] 
http://stackoverflow.com/questions/8712677/how-to-apply-css-page-break-to-print-a-table-with-lots-of-rows
[3] https://bugs.webkit.org/show_bug.cgi?id=5097