Multi-page invoices

[R. Victor Klassen]

CSS allows us to a) forbid an object from being broken at a page boundary, [which is the most egregious error] and b) force a page break before an object.   What it doesn't do (that I can find) is create a repeated head matter for the top of every subsequent page (which would normally be an abbreviated version of what's on the first page), or create an abbreviated footer for the bottom of every page (page numbering).

So creating an invoice (or whatever report) without pages breaking in the middle of table cells is doable.  Making a professional looking multi-page invoice is more challenging.

As far as platform independence, ideally, there would be a query to the system to know the page size.  In practice, a hack that would work, but be less pretty would be to allow the user to set the page size as part of firing off the invoice running system.   And only slightly less pretty would be to assume USLetter, since that's a little shorter than A4, and would result in a little extra margin on A4 but would work for both.  Then it wouldn't work for A3 or B sizes, or for USLegal - in the sense that it wouldn't fill the page.   Not much of an issue for invoices.  For invoices, it also wouldn't work for smaller sizes, which might be an issue for some folks.


On 2013-03-02, at 4:13 AM, Geert Janssens wrote:

> Op 02-03-13 03:48, Mike Alexander schreef:
>> --On March 1, 2013 4:50:28 PM +0100 Geert Janssens <janssens-geert at telenet.be> wrote:
>> 
>>> That's about all I have. I had hoped for a better outcome, but it
>>> seems we're rather stuck with two nasty bugs.
>> 
>> I haven't looked at this at all, but would it be possible to use the eguile report code for this?  If so you should be able to use CSS easily.  I don't really know if this would help solve the problems or not.
>> 
>>          Mike
>> 
> Thanks Mike, I had been thinking of it, but forgot to mention it eventually.
> 
> Yes, using the eguile code will help us fix one part of the issue. It would indeed be much easier to insert css code in it. And the good news here is that we already have an eguile based invoice report. So there is very little left to do on the gnucash side for this particular use case.
> 
> The bug in webkit remains though. It will have to be worked around by postprocessing (with for example wkhtmltopdf) or our print process will have to bypass webkit. In theory what R. Victor Klassen proposed could work as well: pre-process the html code before handing it over to webkit. But I'm not sure that's easily accomplished in a cross-platform manner. In essence that would be like rewriting large parts of an html renderer.
> 
> Geert