mirror of
https://github.com/RGBCube/serenity
synced 2025-07-25 03:07:43 +00:00
87112dcbdc
https://llvm.org/devmtg/2022-11/slides/TechTalk5-WhatDoesItTakeToRunLLVMBuildbots.pdf has an xref table that starts like so: ``` xref 0 214 0000000002 65535 f 0000924663 00000 n 0000000003 00000 f 0000000000 00000 f 0000000016 00000 n 0000000160 00000 n 0000000263 00000 n ``` This is a list of objects in the PDF file. The lines ending with 'f' mean that this object is "free", that is it's not stored in the file. In this file, objects 0, 2, 3 are free. For free objects, the first number is the offset of the next free object: Object 0 refers to object 2, 2 to 3, and 3 back to 0 (since it's the last free object). The lines ending with "n" are actual objects; here the first number is a byte offset to where that object is stored in the file. Furthermore, the file contains ``` /Outlines 2 0 R ``` in its root object, meaning that object 2 stores the page outlines. Since object 2 is set as free, there is no object 2. But the spec says that an invalid object reference is just the null object. This patch makes us return null objects for references to free objects, and it also makes us treat a null object as /Outlines value the same as not having /Outlines in the first place. Fixes #23023 -- we can now open that file. (We don't render it super well, but only for already-known reasons.) Since I found it a bit confusing: XRefTable has two related methods here: 1. has_object() returns if an object was explicitly listed in an xref table. The first number right after `xref` is the start index. So if an xref table were to start with `10`, we'd implicitly create 10 trailing objects for which has_object() would return false 2. is_object_in_use() returns true if an object that was in a table (i.e. one where has_object() returns true) was listed with 'n' and false if it was listed with 'f'. DocumentParser::parse_object_with_index() should probably return a null object for the `!has_object()` case as well instead of VERIFY()ing that has_object() is true. But I haven't seen this in the wild yet, so keeping as-is for now. |
||
|---|---|---|
| .. | ||
| Fonts | ||
| CMakeLists.txt | ||
| ColorSpace.cpp | ||
| ColorSpace.h | ||
| CommonNames.cpp | ||
| CommonNames.h | ||
| Document.cpp | ||
| Document.h | ||
| DocumentParser.cpp | ||
| DocumentParser.h | ||
| Encoding.cpp | ||
| Encoding.h | ||
| Encryption.cpp | ||
| Encryption.h | ||
| Error.h | ||
| Filter.cpp | ||
| Filter.h | ||
| Forward.h | ||
| Function.cpp | ||
| Function.h | ||
| Interpolation.cpp | ||
| Interpolation.h | ||
| Object.h | ||
| ObjectDerivatives.cpp | ||
| ObjectDerivatives.h | ||
| Operator.h | ||
| Page.cpp | ||
| Page.h | ||
| Parser.cpp | ||
| Parser.h | ||
| Reader.cpp | ||
| Reader.h | ||
| Reference.h | ||
| Renderer.cpp | ||
| Renderer.h | ||
| Value.cpp | ||
| Value.h | ||
| XRefTable.h | ||