PdfPig

s (like tables , headings, and illustrations) and getting their coordinates is far easier using vision models than trying to infer those structures by examining hundreds of PDF line, text, glyph, and other low-level PDF objects. I feel those commentators have never tried to extract high-level structures from PDF object models. Try it once using PdfBox, Fitz, etc. to understand the difficulty. PDF really is a terrible format!

another excuse not to do anything on it this coming month. Discussions on this topic feel a lot like "technical solutions to social problems"; by which I mean "well in the ideal world a perfectly logical person would do x, y, z so the system should reflect that". And while a stalebot is the archetypal technical solution to a social problem it at least works with how maintainers work. Sometimes in life you want to ignore a problem and have it go away. When you can't do that, e.g. government bureaucracy, work stuff, social obligations, that's where stress comes from. And asking volunteer maintainers to add a whole new source of stress in their life falls apart when people get busy, or their life circumstances change, or they get ill or tired or whatever. Yes, in a perfect world the issue backlog would be sacrosanct and perfectly groomed/prioritized. But we're just fleshy sacks of chemicals and we're not perfect. Unrealistic expectations from users are the cause of maintainer burnout. Because GitHub closed issues are still viewable and searchable (I'd guess most people search it through a search engine not the terrible inbuilt search) I'd disagree that they're deceiving users somehow.

bviously). It's ultimately become too successful and as a result developers are stuck handling cases where it's being used for entirely the wrong purpose but I can't see a way to another format gaining purchase for the correct purpose (perhaps it's like JavaScript in that way, it has huge adoption because it was first, not because it does all jobs well). Perhaps a content-first format which also handles presentation well could gain a foothold if it came with a shim for PDF viewers and software to use but I dread to think how much effort that would be. [0]:https://github.com/UglyToad/PdfPig [1]:https://github.com/UglyToad/PdfPig/wiki/Document-Layout-Anal...

s taught. [0]: https://github.com/UglyToad/PdfPig

butor can be found here [1]. With the rule based approaches I've been experimenting with you can use certain information from the common producers to normalize certain features. For example line spacing and font size have a well defined relationship, as do whitespace size and font size (though this is a fuzzier relationship and goes out the window entirely for justified text). An example where you rely on non-locality to parse a document, in this SEC filing there are both key values and a table: https://www.sec.gov/Archives/edgar/data/1428796/000110465920... For the values following the subheading "Institutional Investment Manager Filing this Report:" the left hand column are keys for the right hand values. At the bottom of the document there's a table containing the columns "Form 13F File Number" and "Name". Now you could use a couple of rules to infer the difference between the key-values and the table: 1) The keys in a key value list end in ':'. 2) The keys in a key value list have a different font/color to the values. Both of those rules hold true here but not in all or even most documents. For this reason you need to use the whole page to deduce the type of these sections, rather than immediately surrounding features/pixels as an ML algorithm might. [0]: https://github.com/UglyToad/PdfPig/blob/master/src/UglyToad.... [1]: https://github.com/BobLd/PdfPigMLNetBlockClassifier

f what content stream parsing involves, this is how I currently do it: https://github.com/UglyToad/PdfPig/blob/master/src/UglyToad....