Browse Source

LibPDF: Fix off-by-one in Reader

With this, looking at page 2 of pdf_reference_1-7.pdf no longer crashes.

Why did it crash in the first place? Because due to this bug, CFF.cpp
failed to parse the font program for the font used to render the `®`
character. `Renderer::render()` adds all errors that are encounterd
to an `errors` object but continues rendering. That meant that the
previous font was still active, and that didn't have a width for that
symbol in its width table.

SimpleFont::draw_string() falls back to get_glyph_width() if there's
no entry for a character for a symbol. `Type1Font::get_glyph_width()`
always dereferences `m_font` in that method, even if the font has
a font program (and m_font is hence nullptr).

With the off-by-one fixed, the second font is successfully installed
as current font, and the second font has a width entry for that symbol,
so the problem no longer occurs.
Nico Weber 2 years ago
parent
commit
fe3612ebcb
1 changed files with 1 additions and 1 deletions
  1. 1 1
      Userland/Libraries/LibPDF/Reader.h

+ 1 - 1
Userland/Libraries/LibPDF/Reader.h

@@ -63,7 +63,7 @@ public:
     template<typename T = char>
     PDFErrorOr<T> try_read()
     {
-        if (sizeof(T) + m_offset >= m_bytes.size()) {
+        if (sizeof(T) + m_offset > m_bytes.size()) {
             auto message = DeprecatedString::formatted("Cannot read {} bytes at offset {} of ReadonlyBytes of size {}", sizeof(T), m_offset, m_bytes.size());
             return Error { Error::Type::Parse, message };
         }