Multi-page invoices

[Geert Janssens]

Op 02-03-13 14:26, R. Victor Klassen schreef:
> 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).
It can, provided you are using css version 3. There are special css 
attributes for this (see [1] for an example). Now I don't know if our 
version of webkit supports these. That would have to be investigated.
>
> 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.
>
That really depends on what webkitgtk supports in css3 features.
> 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.
>
GnuCash uses Gtk's printer api, which should be cross-platform [2]. I'm 
pretty sure you will find some function in there that can tell you the 
appropriate page size (and margins) at the right time in the print workflow.

Geert

[1] 
http://stackoverflow.com/questions/9729461/creating-page-headers-and-footers-using-css-for-print
[2] http://developer.gnome.org/gtk2/2.24/Printing.html
>
> 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 <mailto: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
>