Speaker 1: If you open a PDF in like a plain text
Speaker 1: editor and you hit the space bar just one single
Speaker 1: time and then you hit save, the entire document just shatters.
Speaker 2: Yeah, it becomes completely unreadable.
Speaker 1: Which is wild. I mean, this is the single most
Speaker 1: universally used digital format on the planet. We all use
Speaker 1: them every single.
Speaker 2: Day, right for you know, signing employment contracts, or reading
Speaker 2: those really dense academic research papers, or even just downloading
Speaker 2: concert ticket exactly.
Speaker 1: We just expect them to work. You want it to
Speaker 1: look identical on a tiny smartphone screen or a giant
Speaker 1: desktop monitor, and you never really question the architecture underneath.
Speaker 2: Which is honestly a minor miracle when you really think
Speaker 2: about it.
Speaker 1: It totally is. So today's deep dive takes us inside
Speaker 1: that invisible architecture. Using our main source today, which is
Speaker 1: O'Reilly's book Developing with PDF by Leonard Rosenthal, we are
Speaker 1: going to literally pop the hood on the portable document format.
Speaker 2: Yeah. And to really understand how you know digital ink
Speaker 2: is made, you have to look at the official standard.
Speaker 2: It's known as ISO thirty two thousand, and it is
Speaker 2: this massive, highly technical specification. I'm talking nearly one thousand
Speaker 2: pages detailing everything from coordinate geometry to cryptography.
Speaker 1: Yeah, let's be totally honest with the listener here for
Speaker 1: a second. The ISO thirty two thousand standard is incredibly dense.
Speaker 1: I mean it reads like a stereo manual written biomthematician.
Speaker 2: Oh. Absolutely, it's not a light beach read.
Speaker 1: Definitely not. Yeah, but our mission today is to translate
Speaker 1: that impenetrable specification into an accessible, hopefully mind blowing exploration
Speaker 1: of what is actually happening when you double click that
Speaker 1: file on your desktop.
Speaker 2: I think the best place to start is by just
Speaker 2: well throwing out everything you think you know about how
Speaker 2: the format works.
Speaker 1: Okay, laid on me.
Speaker 2: So when you look at a PDF, it appears to
Speaker 2: be a flat piece of paper on your screen, right,
Speaker 2: like a digital photocopy.
Speaker 1: Just a fixed image of a page.
Speaker 2: But under the glass it is something entirely different. It's
Speaker 2: actually a highly complex, mathematically precise graph like database.
Speaker 1: Okay, let's unpack this. If a PDF isn't a single
Speaker 1: flat painting, I want you to imagine it more like
Speaker 1: a massive bucket of digital lego bricks.
Speaker 2: That is a great way to visualize it. Actually, in
Speaker 2: the internal architecture, those lego bricks are.
Speaker 1: Called objects objects. Okay, yeah, And.
Speaker 2: The original TOAD name for Adobe's Acrobat software, and this
Speaker 2: whole underlying object system was COS, which stands for Carousel Object.
Speaker 1: System parcel object system. That sounds like a piece of
Speaker 1: bulky hardware sitting in some nineteen sixties boardroom.
Speaker 2: It really does have a retro ring to it, but
Speaker 2: the system itself is incredibly robust. Inside this carousel there
Speaker 2: are exactly nine types of objects doing all the heavy lifting.
Speaker 1: Only nine, just nine.
Speaker 2: You have your standard programming staples, so the null object
Speaker 2: which just represents a missing value, booleans which handle your
Speaker 2: true or false statements, and strings for sequences of text characters.
Speaker 1: So it's essentially just a basic programming environment. I'm assuming
Speaker 1: we have numbers floating around in the bucket, Well.
Speaker 2: Oh, we do. Numeric objects come in two forms. You've
Speaker 2: got integers, which are whole numbers, and then real numbers,
Speaker 2: which have decimal points, right, And there is a fascinating
Speaker 2: quirk here with those. While the format can theoretically handle
Speaker 2: massive sixty four bit numbers, the specification actually highly recommends
Speaker 2: capping real numbers at just four decimal places.
Speaker 1: Wait, really, only four decimal places for a format that's
Speaker 1: used in like high end graphic design and architecture. That
Speaker 1: seems painfully low. Why limit the precision?
Speaker 2: It's a deliberate trade off. It's all about reliability versus
Speaker 2: file size. You see, different computer processors and operating systems
Speaker 2: handle complex floating point math slightly differently.
Speaker 1: Ah, So a MAC and a PC might disagree on
Speaker 1: a super long decimal.
Speaker 2: Exactly by forcing a hard limit of four decimal places,
Speaker 2: the format ensures a coordinate doesn't get rounded up on
Speaker 2: a MAC and rounded down on a PC.
Speaker 1: So you sacrifice extreme mathematical precision to guarantee that a
Speaker 1: graphic designer's layout doesn't shift by a millimeter when I
Speaker 1: open it on my phone.
Speaker 2: You hit the nail on the head, got it?
Speaker 1: Okay? What other their bricks are in the bucket?
Speaker 2: Well, we have name objects, which are unique sequences of
Speaker 2: characters use for fixed values. Then we get to the containers.
Speaker 1: The things that hold other things, right.
Speaker 2: Array objects which are ordered lists of other objects, and
Speaker 2: dictionary objects, which are collections of key value pairs.
Speaker 1: Okay, that makes sense.
Speaker 2: And finally you have the heavy lifters, the stream objects.
Speaker 1: What goes into a stream That sounds.
Speaker 2: Intense streams hold massive blobs of raw data. So this
Speaker 2: is where you'd find an embedded font file, or a
Speaker 2: highly compressed photograph, or even the actual drawing instructions for
Speaker 2: a page.
Speaker 1: Oh wow.
Speaker 2: Yeah, And unlike dictionaries, streams can be run through filters
Speaker 2: to compress them, which is why a PDF with one
Speaker 2: hundred high resolution photos doesn't just immediately crash your hard drive.
Speaker 1: So these nine types of objects are all floating around
Speaker 1: in the bucket. Do they just sit there independently or
Speaker 1: do they interact?
Speaker 2: Oh? They interact constantly, which brings up the crucial difference
Speaker 2: between direct and indirect objects.
Speaker 1: Okay, break that down for me.
Speaker 2: So a direct object is written inline exactly where it
Speaker 2: is needed in the code, but an indirect object is
Speaker 2: given a unique ID number and a generation number a
Speaker 2: generation number. Yeah, so instead of placing the object data
Speaker 2: directly into a page, you just write a reference to
Speaker 2: its ID, like a three zero object.
Speaker 1: It wait, generation number? What does that actually mean?
Speaker 2: Well, in that reference three zero object D, the three
Speaker 2: is the ID and the zero is the generation number.
Speaker 2: But what is wild is that in modern PDFs that
Speaker 2: generation number is almost always zero, like always.
Speaker 1: Why included in the specification at all. If it's constantly zero,
Speaker 1: that seems redundant.
Speaker 2: It's totally a fossilized relic of nineteen nineties programming logic.
Speaker 2: Oh really yeah. In the early days, engineers thought that
Speaker 2: if you edited a document, the software might override an
Speaker 2: object directly in its original place on the hard drive.
Speaker 1: I see, So a new version of object three would
Speaker 1: become generation one, then generation two exactly.
Speaker 2: But as we will discuss later, the format it a
Speaker 2: totally different way of saving changes. We never overwrite objects
Speaker 2: in place anymore. So the generation number just sits there
Speaker 2: at zero, basically a ghost of an abandoned idea.
Speaker 1: That is fascinating, But I'm still kind of stuck on
Speaker 1: why we are separating things into indirect objects in the
Speaker 1: first place. I mean, why not just write the file
Speaker 1: logically from top to bottom like a normal word document.
Speaker 1: Why give everything an ID number and scatter it around.
Speaker 2: Think about a fifty page corporate report, right, okay, Every
Speaker 2: single page has a complex high resolution company logo in
Speaker 2: the top right corner. If you wrote the file top
Speaker 2: to bottom, you would have to embed the massive data
Speaker 2: for that image fifty separate times.
Speaker 1: Oh man, the file size would be.
Speaker 2: Astronomical precisely with indirect objects. The PDF stores the image
Speaker 2: data exactly once, assigns it an ID number, and then
Speaker 2: the code for all fifty pages just references that one
Speaker 2: indirect object, so it just.
Speaker 1: Points back to the original brick in the bucket.
Speaker 2: Yes, it saves massive amounts of storage space and processing.
Speaker 1: Okay, so a PDF is a giant bucket of indirect
Speaker 1: objects cross referencing each other. But if it's just a
Speaker 1: jumbled bucket, how does a computer assemble a fifty page
Speaker 1: document so instantly? I mean has to have some kind
Speaker 1: of highly precise map, right, It.
Speaker 2: Has a very precise map, and it's dictated by a
Speaker 2: rigid four part file structure. You have the header, the body,
Speaker 2: the cross reference table, and the trailer.
Speaker 1: Let's break those down. The header obviously sits at the very.
Speaker 2: Top right, starting a bite zero of the file, it
Speaker 2: announces the file type, usually with percent pdf dash, followed
Speaker 2: by the version number.
Speaker 1: Okay, simple enough.
Speaker 2: But immediately after that there is a very bizarre second line.
Speaker 2: It usually looks like a string of garbled characters, like
Speaker 2: a lower case A with a circumflex and with a
Speaker 2: tilled a capital I with an a mellot.
Speaker 1: Honestly, if I saw that in a file's code, I
Speaker 1: would just assume it was corrupted.
Speaker 2: Most people would. What's fascinating here is that those weird
Speaker 2: characters are intentionally placed there to trick your computer's operating system.
Speaker 2: Trick it how early system would try to automatically detect
Speaker 2: if a file was simple ASKI text or a complex
Speaker 2: binary file by counting high order ASKI values.
Speaker 1: Let me translate that for a second to make sure
Speaker 1: I'm falling. ASKI is basically plain unformatted keyboard text, like
Speaker 1: typing a basic email. So the computer might see the
Speaker 1: underlying code of a compressed image, think it's just weird text,
Speaker 1: try to read it as text, and accidentally scramble the data.
Speaker 2: You nailed it. If it thought the file was plain text,
Speaker 2: it would corrupt the binary streams. So the PDF format
Speaker 2: throws those specific high order garbage characters into the very
Speaker 2: first few bites.
Speaker 1: That's hilarious.
Speaker 2: It's essentially shouting at the operating system, I am a
Speaker 2: binary file. Do not try to read me as text,
Speaker 2: or you will break my formatting.
Speaker 1: A built in defense mechanism against early computers.
Speaker 2: That is so clever. So after the header is the
Speaker 2: body which holds all the lego brick objects we discussed.
Speaker 2: Then comes the map you mentioned, the cross reference table.
Speaker 1: Yes, and this is the core of the format's speed.
Speaker 1: The cross preference table provides the exact binary byte offset
Speaker 1: for every single indirect object in the file. Byte offset yeah,
Speaker 1: tells the computer object number seven is located exactly six
Speaker 1: hundred and thirty one bytes from the very beating of
Speaker 1: the file. Wait pause, exact byte offsets? You mean the
Speaker 1: computer is literally counting microscopic units of data, bite by
Speaker 1: bite from the very top of the file, just to
Speaker 1: find where a font or an image lives.
Speaker 2: Yes, it is an incredibly rigid mathematical grid that.
Speaker 1: Sounds impossibly fragile, which actually brings to mind a scenario
Speaker 1: I bet a lot of our listeners have experienced. Say
Speaker 1: you're trying to open a PDF, but you accidentally open
Speaker 1: it in Microsoft nopad or some other plaintext editor. Oh boy, right,
Speaker 1: you see a sea of gibberish, but mixed in you
Speaker 1: spot the title of your document in plaintext. You notice
Speaker 1: a glaring TYPEO. You think, well, I'm already here. I'll
Speaker 1: just delete that extra letter and hit save. But if
Speaker 1: you do that, the entire PDF breaks completely.
Speaker 2: We have all been tempted to do it, and it
Speaker 2: always ends in disaster.
Speaker 1: So why does fixing a simple type destroy the document?
Speaker 2: It goes right back to that cross reference table. Remember,
Speaker 2: it measures the distance to every object down to the
Speaker 2: single byte. If you delete a letter in notepad, or
Speaker 2: even just add a single invisible space, you have shifted
Speaker 2: every single bite that comes after it.
Speaker 1: Oh wow, so the map is completely misaligned. Yes.
Speaker 2: When the PDF reader goes to look for object seven
Speaker 2: at byte six thirty one, it hits byte six thirty
Speaker 2: or six thirty two. Instead. The object isn't where the
Speaker 2: map says it should be.
Speaker 1: It just gives up.
Speaker 2: Basically, the reader gets confused, throws a fatal error, and
Speaker 2: refuses to open the.
Speaker 1: Document, which begs a rather massive question. If exact byte
Speaker 1: offsets are so delicate that an invisible space destroys the
Speaker 1: entire map, well, how on earth do we ever edit
Speaker 1: or save a PDF? I mean, I fill out PDF
Speaker 1: forms and save them all the time without the file imploding.
Speaker 2: That brings us to the fourth section of the structure,
Speaker 2: the trailer. The trailer sits at the very end of
Speaker 2: the file and tells the computer where to find the
Speaker 2: cross reference table.
Speaker 1: Okay, it's a bottom.
Speaker 2: Right and this bottom heavy set up allows for a
Speaker 2: brilliant workaround called incremental updates.
Speaker 1: How to incremental updates bypass the byte offset.
Speaker 2: Problem by never touching the original data. Instead of rewriting
Speaker 2: the massive, fragile file and risking the corruption of all
Speaker 2: those delicate offsets, a PDF saves your changes by simply
Speaker 2: appending a new body section, a new cross reference table,
Speaker 2: and a new trailer directly to the very end of
Speaker 2: the file.
Speaker 1: It just tacks the new edits onto the very bottom.
Speaker 2: Yes, and that new trailer contains a specific piece of
Speaker 2: code called the prev key short for previous. It points
Speaker 2: backward to the old trailer, so it reads it in reverse,
Speaker 2: kind of when you open the file, the computer reads
Speaker 2: it from the bottom up. It sees the newest map, first,
Speaker 2: applies your new changes, and ignores the outdated objects.
Speaker 1: Here's where it gets really interesting. Wait. If I delete
Speaker 1: a highly sensitive paragraph from a document, say a company's
Speaker 1: confidential financial projection, and I hit save, the old data
Speaker 1: isn't actually erased.
Speaker 2: This raises an important question, and you've hit on a
Speaker 2: major security flaw that catches people off guard. All the time.
Speaker 2: That deleted text might just be uncollected garbage.
Speaker 1: Ureuly, anyone can find it.
Speaker 2: Yes, because the viewer just reads the newest table at
Speaker 2: the end of the file, the old data vanishes from
Speaker 2: your screen. It looks deleted.
Speaker 1: Because the new map just doesn't point to it anymore.
Speaker 2: Exactly, But if you only performed a standard save, that
Speaker 2: old text is sitting perfectly intact in the file's history,
Speaker 2: buried higher up in the original body section. Anyone with
Speaker 2: a basic understanding of PDF structure can dig through that
Speaker 2: digital trash and extract your confidential data.
Speaker 1: Note to self, always use an official reaction tool. Don't
Speaker 1: just hit backspace and assume it's gone. Oh, that is terrifying.
Speaker 2: It is definitely a risk.
Speaker 1: But this appending system creates a glaring logistical issue. Right
Speaker 1: if the trailer and the cross reference table the actual
Speaker 1: map to the document are located at the very bottom
Speaker 1: of the file, how do PDSs load on the Internet.
Speaker 1: Shouldn't a web browser have to download a massive one
Speaker 1: hundred megabyte file completely before it can find the map
Speaker 1: and show your page one.
Speaker 2: Well, in the early days of the Internet, that is
Speaker 2: exactly what happened. Really, yeah, it was a miserable user
Speaker 2: experience just staring at a blank screen while a massive
Speaker 2: file trickled down through dial up. To fix this, the
Speaker 2: format introduced linearization, which is more commonly known as fast WebView.
Speaker 1: How does linearization cheat the system?
Speaker 2: It fundamentally reorders the objects. It takes all the objects
Speaker 2: needed to render just page one, so the specific fonts, text,
Speaker 2: and images for that page, and groups them together at
Speaker 2: the very top of.
Speaker 1: The file ah I see.
Speaker 2: Crucially, it places a partial cross reference table and a
Speaker 2: special trailer right there at the beginning.
Speaker 1: So instead of handing me a one thousand paid book
Speaker 1: where the index, the glossary, and the first chapter are
Speaker 1: scattered everywhere, it basically rips out chapter one, staples a
Speaker 1: mini index to the front of it, and hands it
Speaker 1: to me to read while the rest of the heavy
Speaker 1: book is still printing in the background.
Speaker 2: That is a perfect analogy. It allows for instant streaming
Speaker 2: of the document and to manage the rest of those
Speaker 2: one thousand pages efficiently. The PDFU utilizes a page tree.
Speaker 2: The central hub of the document, which is called the
Speaker 2: document catalog, points to this tree structure.
Speaker 1: Why use a complex tree, though, why not just as
Speaker 1: simple chronological list? Page one, page two, page.
Speaker 2: Three, because a simple sequential list an array is a
Speaker 2: total nightmare for memory usage on large documents. Oh so,
Speaker 2: if you have a thousand page manual formatted as a
Speaker 2: simple array and you want to jump to page eight hundred,
Speaker 2: the computer's memory would have to load and parse the
Speaker 2: data for the first seven hundred ninety nine pages sequentially
Speaker 2: just to find the location of page eight hundred.
Speaker 1: Oh that would bring a phone or an older tablet
Speaker 1: to a grinding holt exactly.
Speaker 2: So, the page tree is designed as a balanced tree.
Speaker 2: The nodes branch out mathematically, and the specification recommends no
Speaker 2: more than twenty five to fifty pages per leaf of
Speaker 2: the tree, so.
Speaker 1: It's clumped into smaller sections.
Speaker 2: Yes, this means your device can navigate down specific branches
Speaker 2: and jump directly to page eight hundred instantly, completely bypassing
Speaker 2: the need to process the hundreds of pages that come
Speaker 2: before it. It is an incredibly elegant piece of software engineering.
Speaker 1: Okay, so we have the file structured, it's mapped with
Speaker 1: exact byteox sets, it's linearized for the web, and we've
Speaker 1: navigated the balance tree to our specific page. But the
Speaker 1: page is still blank. How does the actual visual content,
Speaker 1: the charts, the graphics. How does that get drawn onto
Speaker 1: the screen?
Speaker 2: Well, to draw anything, you have to establish a coordinate
Speaker 2: system on a computer screen. You usually talk in terms
Speaker 2: of pixels or dpi dots per inch. This is known
Speaker 2: as device space, right, But the core mandate of a
Speaker 2: PDF is that it must look identical on a cheap
Speaker 2: seventy two dpi monitor and a high end six hundred
Speaker 2: dpi professional printing press.
Speaker 1: That's the magic trick of the whole format.
Speaker 2: To achieve that, PDFs ignore device space entirely and operate
Speaker 2: in user space. User space, Yeah, user space is a
Speaker 2: fixed absolute mathematical grid. It defaults to exactly seventy two
Speaker 2: user units per inch, and the origin point coordinate zero
Speaker 2: zero is that the bottom left.
Speaker 1: Corner bottom left, not the top left like reading a.
Speaker 2: Book, no bottom left, just like a standard Cartesian coordinate
Speaker 2: graph from high school geometry. That takes me back on
Speaker 2: this absolute grid. The PDF defines five specific boxes to
Speaker 2: dictate how the page is handled. The most common is
Speaker 2: the media box, which defines the physical paper size like
Speaker 2: standard US letter. Then you have the crop box, which
Speaker 2: defines the visible area on your screen.
Speaker 1: What about the other three boxes.
Speaker 2: They cater heavily to professional printing. There is the trim box,
Speaker 2: which tells the physical guillotine machine at a printing press
Speaker 2: exactly where to slice the paper.
Speaker 1: Interesting, there is the bleed.
Speaker 2: Box, which gives an extra margin of printed color outside
Speaker 2: the trim box. And finally the art box, which was
Speaker 2: meant to define a specific artwork area but honestly is
Speaker 2: rarely used today.
Speaker 1: Wait is the bleed box the reason why when I
Speaker 1: try to print a colorful flyer on my home printer,
Speaker 1: I always get that annoying white border. But a professional
Speaker 1: magazine has color going all the way to the very
Speaker 1: edge of the page.
Speaker 2: Your home printer can't print to the literal edge of
Speaker 2: the paper without making a mess, so it shrinks the image.
Speaker 2: A professional press prints the color into the bleed box,
Speaker 2: pass the intended edge, and then slices it off at
Speaker 2: the trim box, leaving a flawless, borderless image.
Speaker 1: Everything is mapped out so logically, so we have our
Speaker 1: grid in our boxes, But who is actually holding the pen?
Speaker 2: The pen is controlled by content streams. These are sets
Speaker 2: of instructions derived from the PostScript language. PostScript instead of
Speaker 2: just pasting a pixelated picture of a word. Content streams
Speaker 2: use mathematical vectors to draw the literal geometric shapes of
Speaker 2: the fonts and graphics. It scales infinitely without blurring.
Speaker 1: That's why you can zoom in forever and the text
Speaker 1: stays crisp exactly.
Speaker 2: But here is the catch. It is not a fully
Speaker 2: fledged programming language. There are no variables. You cannot use
Speaker 2: if then logic.
Speaker 1: Wait, if there are no variables to store data, how
Speaker 1: does it remember what color ink it's currently using or
Speaker 1: how thick the line should be.
Speaker 2: It relies on the graphic state stack. Think of it
Speaker 2: as a memory bank for your drawing tools. When writing
Speaker 2: a content stream, you use two vital operators, a lowercase
Speaker 2: Q to push a state onto the stack and an
Speaker 2: uppercase Q to pop it off.
Speaker 1: So what does this all mean? Let me see if
Speaker 1: I can translate this without using programming terms. It sounds
Speaker 1: exactly like a quick save and quick load feature in
Speaker 1: a really difficult video game.
Speaker 2: That is a very accurate way to look at it.
Speaker 1: Yeah, So, say you were drawing a complex architectural diagram.
Speaker 1: You set your pen thickness to be really wide and
Speaker 1: your ink color to bright red. You hit lowercase qu
Speaker 1: quick save that exact state. Then you draw your big
Speaker 1: red dash line. Right now, you need to go back
Speaker 1: to drawing normal thin black text. Instead of manually writing
Speaker 1: new code to reset the color to black and the
Speaker 1: pin to thin. You just hit uppercase qu quickload. Your
Speaker 1: previous settings are instantly restored, and you keep drawing.
Speaker 2: That is exactly how it works. You push a state
Speaker 2: with Q, you pop it with Q. If you forget
Speaker 2: to hit Q, well, your red ink leaks all over
Speaker 2: the rest of the document. When used correctly, it keeps
Speaker 2: the drawing instructions incredibly lean and blazingly fast.
Speaker 1: Okay, but what happens when things overlap, like if I
Speaker 1: have text sitting over a colored background.
Speaker 2: If we connect this to the bigger picture, the PDF
Speaker 2: rendering engine operates on the painter's model because it is
Speaker 2: optimized for speed. There is no complex three D rendering
Speaker 2: engine trying to figure out depth or layers. It operates
Speaker 2: strictly on a first in, first out basis or FIFO.
Speaker 1: So it's like actual physical painting on a canvas.
Speaker 2: Yes, the software just slaps digital paint on the canvas
Speaker 2: sequentially in the exact order the instructions are written. If
Speaker 2: the code says to draw a giant red square, and
Speaker 2: the very next instruction is to draw a small blue
Speaker 2: circle at the same coordinates. The blue circle simply sits
Speaker 2: on top, and if you reverse them, reverse the order
Speaker 2: in the code and the red square completely covers the
Speaker 2: blue circle. You would never see it.
Speaker 1: It's surprisingly analog for such a complex digital format.
Speaker 2: It is elegant in its simplicity, really, But when you
Speaker 2: combine thousands of those simple instructions across a balanced page
Speaker 2: tree mapped by exact bite offsets, you get the modern PDF.
Speaker 1: Which brings us to the end of our deep dive. Today,
Speaker 1: we have gone from looking at a PDF as a flat,
Speaker 1: boring digital document to seeing it for what it truly
Speaker 1: is and mathematically precise, graph like database of objects.
Speaker 2: It really is a masterclass in file architecture and coordinate geometry.
Speaker 1: So the next time you open a PDF for a meeting,
Speaker 1: or you download a boarding pass to your phone, you
Speaker 1: will know you aren't just looking at digital paper, You're
Speaker 1: looking at a meticulously engineered machine.
Speaker 2: But before we go, I want to leave you with
Speaker 2: one final.
Speaker 1: Thought to chew on ooh lay it on us.
Speaker 2: We talked earlier about incremental updebts. How a PDF saves
Speaker 2: changes by appending new data to the end of the
Speaker 2: file rather than erasing the old data.
Speaker 1: Right the digital trash that doesn't actually get thrown away.
Speaker 2: Because of that specific mechanism, a PDF is essentially a chronological,
Speaker 2: geological record of its own creation. Oh wow, Well, every
Speaker 2: time someone hits saved during its lifespan, a new layer
Speaker 2: is added bearing the old ones. So think about it.
Speaker 2: How many of the pristine, finished digital documents sitting on
Speaker 2: your hard drive right now are secretly carrying the ghosts
Speaker 2: of all your rough drafts, your deleted thoughts, and your
Speaker 2: hidden mistakes buried right there in the code.
Speaker 1: That is a haunting thought to end on. Go check
Speaker 1: your PDFs, everyone,