3 ms·

Why are all the amounts values negative?

46 points by 4pkjai 2mo ago

engkimo 2mo ago
This is a great example of why a PDF’s text layer is not necessarily the same as its visible content. I’d be cautious about making “non-black means invisible” the general rule. A possible middle ground between raw text extraction and full OCR would be to render the page, map each extracted glyph’s bounding box back to the rendered pixels, and discard glyphs that have almost no contrast with their local background. That would preserve the exact embedded text for visible characters while using rasterization only to determine visibility. Has anyone tried this kind of hybrid approach?
- 4pkjai 2mo ago
  I agree with you, it's not safe to have a rule saying "non-black means invisible". I should have made it clear in the blog post, but the first thing I do when processing a PDF is I identify the document_type. Then I run special rules for that document_type. So the "non-black means invisible" rule only applies when processing this document_type.
- qingcharles 2mo ago
  I was converting some PDF documents recently and I noticed a few pages were missing their text. I wondered if the text was white-on-white. I got Claude to check it, and I was partially right. The original (image) text layers were gone, but the OCR layer remained. Lost all the font data, but most of the text was recoverable.
happymellon 2mo ago
Does this end on a cliffhanger? Did they try one method, and what was the feedback?
- 4pkjai 2mo ago
  I did try method number two, and it worked. I should update this post.
  - putlake 2mo ago
    Is it not dangerous to ignore text based on its color? For this particular case it might work but looks like you have a generic service that is supposed to work with any bank statement.
    - 4pkjai 2mo ago
      Yes it’s not a safe general rule. I can do it because I first classify the statement into a document_type and then run special code for specific document_types.
TZubiri 2mo ago
OCR the PDF. It's the ground truth, and it's not like it's more complex than parsing a pdf, at this point, the technology for OCR might even be better than PDF parsing, which is full of accidental instead of natural complexity.
- 4pkjai 2mo ago
  I don’t really understand how OCRing a PDF could be more accurate than reading the text nodes. Another thing to consider is OCR works well for English but not so well for other languages.
  - defrost 2mo ago
    As the article stated, in this specific case the bank used an "invisible" character (a minus sign) to assist in alignment .. which resulted in errors when parsing the text nodes by layout. OCR of a digital image generated from those PDF draw commands only operates on the visible portions that are rendered. Another case to be considered .. FOI requests for documents from "pain in the arse" government departments or law firms can result in "digital documents" that are deliberately generated to be difficult to process (go figure) .. eg: filled with circular and spaghetti draw commands that "print correctly" but are a nightmare horror show to parse. ( "technically compliant" is a legally compliant "fuck you" )
    - TZubiri 2mo ago
      I've had a non technical user ask me how to convert a document to PDF so that it's not editable or copypasteable by someone else. And also ask me how to edit a pdf. PDF is used as DRM by obfuscation by non technical users, it's a sort of emergent phenomenon that occurs hundreds of times per day. And it turns out it's a quite effective tool at that, if anything it associates a cost to editing/copying/automatic processing. In terms of technically compliant, a PDF is as much of a sensible requirement as USB or String types. It checks the box, but it's likely that there's a lot of additional work into integrating two systems that input and ouput these envelope protocols/encoding, because they are purposefully too broad.
  - 2mo ago
deepsun 2mo ago
Why not skipping all the minus signs unless they do not immediately precede a number. I see all the minus signs are after the number, not before, so just skip if they are not before. Preferably in the same BT/ET block as the number.
- nhinck2 2mo ago
  The trailing minus signs are true negatives.
  - TheRealPomax 2mo ago
    Some trailing minus signs are true negatives, but it depends on the color which ones are and which ones aren't (and someone got paid for that. Amazing).
- TheRealPomax 2mo ago
  That's the problem: what you see and what is actually in the PDF are not the same thing: the actual text in the PDF has a minus sign on both. The entry that you see as "$110.00-" is withdrawal, and its minus sign is very much real. However, the entry that you see as "$1,527.57" also has a minus sign. but you don't see it because it's been given the same font colour as the background. So we have two identically formatted piece of data, where only the text colour offers a clue on what's real and what isn't. Absolutely insane.
  - lazide 2mo ago
    A little disappointed Timecube isn’t somehow referenced. Same vibe.
rmunn 2mo ago
I was expecting something about double-entry accounting and how it can (initially) be non-intuitive whether to mark a given entry as a debit (-100) or credit (+100), especially for liabilities (when you enter a credit card payment in your ledger, the signs aren't what you might intuitively expect when you haven't wrapped your head around the system yet). Instead I get a nice blog post about a knotty little problem caused by someone's abuse of semantic markup for style purposes. Shows that HTML doesn't have a monopoly on that issue. PDFs are already bad enough as a format for extracting data from, we don't need dumb HTML-inspired tricks on top of that. Nice job finding the issue and explaining it clearly, OP. Thanks for an interesting writeup.
- m463 2mo ago
  I always liked 99.57CR
kazinator 2mo ago
> But how wide is the minus sign? It depends on the font size, maybe it’s hard to predict. If you use a real minus sign, and not an ASCII hyphen, it should be the same width as the corresponding plus sign in any reasonable font. Use a plus sign and make that invisible. Here is an idea: columns of figures should use a monospaced font. You don't just want right or left edges to align, but all corresponding digit positions should align: 12,345 + 4,001 = ------- 16,346 This consideration overrides any nonsense about whether a space is the same width as a minus.
globular-toast 2mo ago
If anyone sent me data in PDF format I would immediately reject it and ask for a more suitable format. This isn't because I know anything about PDF, it's just intuition. Why don't more people come with this intuition? I feel the same way about basic security principles.
- netsharc 2mo ago
  The domain name of this blog post should give you a clue why OP shouldn't follow your intuition.
  - globular-toast 2mo ago
    Sure, but my point was more that if enough customers found it ridiculous and complained rather than resorting to magic converters you'd think the banks would be forced to up their game.
bountyodds 2mo ago
[flagged]

46 points by 4pkjai 2mo ago

This is a great example of why a PDF’s text layer is not necessarily the same as its visible content. I’d be cautious about making “non-black means invisible” the general rule. A possible middle ground between raw text extraction and full OCR would be to render the page, map each extracted glyph’s bounding box back to the rendered pixels, and discard glyphs that have almost no contrast with their local background. That would preserve the exact embedded text for visible characters while using rasterization only to determine visibility. Has anyone tried this kind of hybrid approach?

4pkjai 2mo ago
I agree with you, it's not safe to have a rule saying "non-black means invisible". I should have made it clear in the blog post, but the first thing I do when processing a PDF is I identify the document_type. Then I run special rules for that document_type. So the "non-black means invisible" rule only applies when processing this document_type.
qingcharles 2mo ago
I was converting some PDF documents recently and I noticed a few pages were missing their text. I wondered if the text was white-on-white. I got Claude to check it, and I was partially right. The original (image) text layers were gone, but the OCR layer remained. Lost all the font data, but most of the text was recoverable.

happymellon 2mo ago

Does this end on a cliffhanger? Did they try one method, and what was the feedback?

4pkjai 2mo ago
I did try method number two, and it worked. I should update this post.
- putlake 2mo ago
  Is it not dangerous to ignore text based on its color? For this particular case it might work but looks like you have a generic service that is supposed to work with any bank statement.
  - 4pkjai 2mo ago
    Yes it’s not a safe general rule. I can do it because I first classify the statement into a document_type and then run special code for specific document_types.

TZubiri 2mo ago

OCR the PDF. It's the ground truth, and it's not like it's more complex than parsing a pdf, at this point, the technology for OCR might even be better than PDF parsing, which is full of accidental instead of natural complexity.

4pkjai 2mo ago
I don’t really understand how OCRing a PDF could be more accurate than reading the text nodes. Another thing to consider is OCR works well for English but not so well for other languages.
- defrost 2mo ago
  As the article stated, in this specific case the bank used an "invisible" character (a minus sign) to assist in alignment .. which resulted in errors when parsing the text nodes by layout. OCR of a digital image generated from those PDF draw commands only operates on the visible portions that are rendered. Another case to be considered .. FOI requests for documents from "pain in the arse" government departments or law firms can result in "digital documents" that are deliberately generated to be difficult to process (go figure) .. eg: filled with circular and spaghetti draw commands that "print correctly" but are a nightmare horror show to parse. ( "technically compliant" is a legally compliant "fuck you" )
  - TZubiri 2mo ago
    I've had a non technical user ask me how to convert a document to PDF so that it's not editable or copypasteable by someone else. And also ask me how to edit a pdf. PDF is used as DRM by obfuscation by non technical users, it's a sort of emergent phenomenon that occurs hundreds of times per day. And it turns out it's a quite effective tool at that, if anything it associates a cost to editing/copying/automatic processing. In terms of technically compliant, a PDF is as much of a sensible requirement as USB or String types. It checks the box, but it's likely that there's a lot of additional work into integrating two systems that input and ouput these envelope protocols/encoding, because they are purposefully too broad.
- 2mo ago

deepsun 2mo ago

Why not skipping all the minus signs unless they do not immediately precede a number. I see all the minus signs are after the number, not before, so just skip if they are not before. Preferably in the same BT/ET block as the number.

nhinck2 2mo ago
The trailing minus signs are true negatives.
- TheRealPomax 2mo ago
  Some trailing minus signs are true negatives, but it depends on the color which ones are and which ones aren't (and someone got paid for that. Amazing).
TheRealPomax 2mo ago
That's the problem: what you see and what is actually in the PDF are not the same thing: the actual text in the PDF has a minus sign on both. The entry that you see as "$110.00-" is withdrawal, and its minus sign is very much real. However, the entry that you see as "$1,527.57" also has a minus sign. but you don't see it because it's been given the same font colour as the background. So we have two identically formatted piece of data, where only the text colour offers a clue on what's real and what isn't. Absolutely insane.
- lazide 2mo ago
  A little disappointed Timecube isn’t somehow referenced. Same vibe.

rmunn 2mo ago

I was expecting something about double-entry accounting and how it can (initially) be non-intuitive whether to mark a given entry as a debit (-100) or credit (+100), especially for liabilities (when you enter a credit card payment in your ledger, the signs aren't what you might intuitively expect when you haven't wrapped your head around the system yet). Instead I get a nice blog post about a knotty little problem caused by someone's abuse of semantic markup for style purposes. Shows that HTML doesn't have a monopoly on that issue. PDFs are already bad enough as a format for extracting data from, we don't need dumb HTML-inspired tricks on top of that. Nice job finding the issue and explaining it clearly, OP. Thanks for an interesting writeup.

m463 2mo ago
I always liked 99.57CR

kazinator 2mo ago

> But how wide is the minus sign? It depends on the font size, maybe it’s hard to predict. If you use a real minus sign, and not an ASCII hyphen, it should be the same width as the corresponding plus sign in any reasonable font. Use a plus sign and make that invisible. Here is an idea: columns of figures should use a monospaced font. You don't just want right or left edges to align, but all corresponding digit positions should align: 12,345 + 4,001 = ------- 16,346 This consideration overrides any nonsense about whether a space is the same width as a minus.

globular-toast 2mo ago

If anyone sent me data in PDF format I would immediately reject it and ask for a more suitable format. This isn't because I know anything about PDF, it's just intuition. Why don't more people come with this intuition? I feel the same way about basic security principles.

netsharc 2mo ago
The domain name of this blog post should give you a clue why OP shouldn't follow your intuition.
- globular-toast 2mo ago
  Sure, but my point was more that if enough customers found it ridiculous and complained rather than resorting to magic converters you'd think the banks would be forced to up their game.

bountyodds 2mo ago

[flagged]