Zero-Shot Local Document Parsing with Gemma 4: Treating PDFs as Images Treating PDFs as images and feeding those images to Gemma 4 dissolves the scanned-versus-digital distinction that makes every text-extraction pipeline fragile. Fix that. # Introduction Run pdfplumber on a scanned invoice, and you get nothing. Run it on a multi-column research paper, and you get a stream of text that has lost every spatial relationship the layout encoded. Run it on a filled PDF form, and you get the field labels concatenated with the values in reading order, with no way to tell which belongs to which. Text-extraction tools have one assumption baked in: the PDF has a selectable text layer. The moment that assumption fails — scanned documents, image-only PDFs, complex form layouts, anything with merged table cells — the tools fail silently. You get empty output or garbled text, and the failure mode gives you no signal about what went wrong. The image approach sidesteps this entirely. Render each PDF page to a high-resolution image. Feed that image to a vision-language model. Ask it what you need in plain language. No optical character recognition (OCR) pipeline, no layout parser, no template matching per document type. The model reads the page the way a human reads a printed page. Gemma 4, released by Google DeepMind on April 2, 2026, with a full Apache 2.0 license, lists Document/PDF parsing as an explicit capability alongside OCR, chart comprehension, handwriting recognition, and screen understanding. It runs entirely locally. No API key, no cloud call, no data leaving your server. The project thread through this article is a local document intake pipeline that processes supplier invoices, extracting vendor name, invoice number, line items, totals, and due date, and outputs structured JSON. It works on scanned and digital PDFs alike. # Why Treat