𝗦𝘁𝗼𝗽 𝗣𝗮𝗿𝘀𝗶𝗻𝗴 𝗣𝗗𝗙𝘀 𝗮𝘁 𝗥𝗲𝗻𝗱𝗲𝗿 𝗧𝗶𝗺𝗲

Most developers build PDF extraction tools the wrong way.

They try to guess document structure from the visual output. They render a page to a canvas and look at pixel positions. They use computer vision to find columns or tables.

This approach is backwards.

A PDF already contains the structure you need in the operator stream.

A table is not just a set of pixels. It is a set of path operators like moveTo, lineTo, and rectangle. Zone boundaries are encoded in the CTM stack. You do not need to reconstruct what is already there.

Stop using visual heuristics. Use the source data.

I previously tried using De Casteljau subdivision for bounding boxes. I rejected it during testing.

De Casteljau is a subdivision algorithm. You split curves until the segments are small enough. This works for rendering, but it is bad for bounding boxes.

You have to choose a tolerance. If the tolerance is too loose, the box is wrong. If it is too tight, you waste resources on recursion. There is a better way. An analytical solution using the quadratic formula is exact. It does not recurse. It does not allocate segments.

The same logic applies to zone detection.

Many tools calculate zone boundaries by finding the midpoint between two text groups. This is a visual guess. It is not structural.

If you use midpoints, sub-pixel rounding will place regions in the wrong zones.

The fix is simple. Use the top edge of the bounding box. A region belongs to a zone based on where it starts. Use the actual Y-coordinate of the top edge.

Building a real PDF extractor is harder. You must:

This is more work than pixel-based guessing. But it produces deterministic results.

A pixel-based tool gives different results at 100% zoom than it does at 150% zoom. It is pattern-matching visual artifacts, not extracting structure.

If you do not parse the operator stream, you are building a demo. It might work on your test files, but it will fail on real user uploads.

The path through the operator stream is difficult. You must understand the fill and stroke state machines and the PDF specification. But you only have to learn it once. Then it works for every PDF.

رینڈر ٹائم پر PDF پارس کرنا بند کریں: منظم اخراج (structured extraction) کے لیے ایک بہتر آرکیٹیکچر

رینڈر ٹائم پر PDF پارس کرنا کارکردگی (performance) کو تباہ کر دیتا ہے۔ اگر آپ ایسی ایپلی کیشن بنا رہے ہیں جو PDF سے ڈیٹا پر انحصار کرتی ہے، تو آپ کو اس طریقے سے کام کرنا بند کر دینا چاہیے۔

مسئلہ

PDFs کو کبھی بھی ڈیٹا کے ذرائع (data sources) کے طور پر ڈیزائن نہیں کیا گیا تھا۔ انہیں دستاویزات کی بصری نمائندگی (visual representations) کے لیے ڈیزائن کیا گیا تھا۔ ایک PDF پرنٹر کو یہ بتاتی ہے کہ صفحہ پر سیاہی کہاں رکھنی ہے، نہ کہ یہ کہ ڈیٹا کیسے منظم ہے۔

جب آپ رینڈر ٹائم پر PDF پارس کرتے ہیں، تو آپ کلائنٹ (براؤزر) سے بھاری کام کرنے کو کہہ رہے ہوتے ہیں۔ اس کے نتیجے میں درج ذیل مسائل پیدا ہوتے ہیں:

بہتر طریقہ: ایکسٹریکشن ٹائم پارسنگ (Extraction-time Parsing)

جب صارف دستاویز دیکھ رہا ہو تب اسے پارس کرنے کے بجائے، اسے اس وقت پارس کریں جب دستاویز اپ لوڈ یا انجیسٹ (ingest) کی جا رہی ہو۔

آرکیٹیکچر

  1. انجیسشن (Ingestion): PDF آپ کے سسٹم میں اپ لوڈ کی جاتی ہے۔
  2. ایکسٹریکشن پائپ لائن (Extraction Pipeline): ایک بیک اینڈ ورکر PDF کو اٹھاتا ہے اور مواد نکالنے کے لیے Unstructured، AWS Textract یا LLMs جیسے ٹولز کا استعمال کرتا ہے۔
  3. منظم اسٹوریج (Structured Storage): نکالا گیا ڈیٹا ڈیٹا بیس میں JSON جیسے منظم فارمیٹ میں محفوظ کیا جاتا ہے۔
  4. سرونگ (Serving): جب صارف کو ڈیٹا کی ضرورت ہوتی ہے، تو آپ کی API PDF کے بجائے JSON فراہم کرتی ہے۔

فوائد

نتیجہ

ایڈج (edge) پر PDF کو ڈیٹا کے ذرائع کے طور پر استعمال کرنا بند کریں۔ پیچیدگی کو بیک اینڈ پر منتقل کریں اور اس کے بجائے منظم ڈیٹا فراہم کریں۔