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-ge...@telenet.be <mailto:janssens-ge...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
