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