A particularly nasty PDF about tabula-extractor HOT 4 CLOSED

For the record, I used these parameters:

tabula -p 4-15 -c 47,150,256,310,375,431,504 -a 65.57142857142857,40.43571428571428,938.7642857142856,557.3571428571428 ~/Desktop/54013-1027504503-3.pdf

BTW, it uses the new --columns/-c parameter, that still lives in its own branch

from tabula-extractor.

Page 4 looks fine, but the rest are weird. I thought I had solved the problem a month or so ago where "words" wouldn't be split if they overlapped a vertical ruling. This'll have to take some more in-depth analysis, which I don't want to do write this second. :)

from tabula-extractor.

One problem is that PDFBox renders the page at some set width that may differ from a given PDF viewer's 100% zoom width of the PDF. So that'll throw off any vertical ruling locations that you give it. I've solved this for Dollars for Docs by letting the user specify the measured width of the page, which is turned into a "scale factor" -- i.e. page.width / measured_width -- to scale the user-provided vertical ruling locations into their location on the PDFBox page. This easy to implement, but I haven't implemented it yet here except in a very hacky, test-case kind of way.

I got better results by implementing that by changing line 65 in bin/tabula to be

Tabula::Ruling.new(area[0], vr * (page.width / 820), 0, page.height)

and running

bundle exec tabula -p 7 -c 50,195,340,410,500,575,650,750 -a 65.57142857142857,40.43571428571428,938.7642857142856,557.3571428571428 54013-1027504503-3.pdf > output.xls

But we still have the problem on some pages. I'm not quite sure what the issue is exactly; I'll keep looking. (Perhaps we can work on this as we refactor, since the extractor, as we both know, needs that refactor really bad.)

from tabula-extractor.

Fixed in 90e2e87

Need to write test case. Leaving this issue open.

from tabula-extractor.