Bug 12035 - PDF print: Purchase order overflows incorrectly
Summary: PDF print: Purchase order overflows incorrectly
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-03 04:59 UTC by David Cook
Modified: 2020-01-05 13:36 UTC (History)
0 users

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2014-04-03 04:59:46 UTC
Currently, if you add a large number of baskets while using a "OrderPdfFormat" of "pdfformat::layout3pages" or "pdfformat::layout3pagesfr", the basket table will overlap over the bottom footer (which includes the page numbers), and the overflow will start mid-way down the new page.

This is because we've configured our PDF::Table objects incorrectly for the printbaskets() sub. 

Of course, the chances of having enough baskets in a basket group to trigger such an overflow might be quite small, so this might not happen very often. Still, it's a bug nonetheless. You can test it out by filling your database with bogus baskets; I've included some SQL at the bottom of this bug report to aid with that.

Layout Config:

layout3pages.pm,layout3pagesfr.pm:

Current config for printbaskets:

start_y =>  230/mm,
next_y  => 230/mm,
start_h => 230/mm,
next_h  => 230/mm,

Note that the "next_y" and "next_h" are the same as the "start_*". This means that they'll start midway down the page on the new (overflow) page.

My suggested replacement for printbaskets:
start_y =>  230/mm, #($start_y - $start_h = $bottom_margin), according to PDF::Table source code
next_y => ($height - 5)/mm,
start_h => 210/mm,
next_h  => ($height - 25)/mm,

I'm using the $height variable here because that's the same measurement used by some page headers in the printorders() sub in this same module. 

--

The printorders() subs are all right in all the "OrderPdfFormat" options. The bottom margin is probably too large in layout3pages(fr).pm, but better too large than too small.

layout2pages.pm:

printorders:
start_y => 285/mm,
next_y  => 285/mm,
start_h => 260/mm,
next_h  => 260/mm,

layout3pages.pm,layout3pagesfr.pm:

printorders:

start_y => 270/mm,
next_y  => 285/mm,
start_h => 250/mm,
next_h  => 250/mm,

---

[Note: the following SQL was created based on a Koha 3.8 database so YMMV.]

*Create bogus baskets:

INSERT INTO aqbasket Select null,rand() as basketname,note,booksellernote,contractnumber,creationdate,closedate,booksellerid,authorisedby,booksellerinvoicenumber,basketgroupid from kohatest38.aqbasket where basketno = 8;

*Create bogus orders:

INSERT INTO aqorders Select null, 1, entrydate,quantity,currency,listprice,totalamount,datereceived,booksellerinvoicenumber,freight,unitprice,quantityreceived,cancelledby,datecancellationprinted,notes,supplierreference,purchaseordernumber,subscription,serialid,(SELECT basketno FROM aqbasket WHERE basketno not in (select basketno from aqorders) limit 1) as 'basketno',biblioitemnumber,timestamp,rrp,ecost,gst,budget_id,budgetgroup_id,budgetdate,sort1,sort2,sort1_authcat,sort2_authcat,uncertainprice,claims_count,claimed_date from aqorders limit 1;