Skip to content

Conversation

@vencelkatai
Copy link
Contributor

Hey,

We are using this package to generate encrypted documents and it works fine for some time now. Lately we found 1 case where opening it in Adobe Reader displays blank pages, but it still looks fine in Google Chrome for example.
Checking the PDF with qpdf gave the following warnings:

WARNING: filename.pdf (object 11 0, offset 4423): unknown token while reading object; treating as string
WARNING: filename.pdf (object 11 0, offset 4424): unexpected )
WARNING: filename.pdf (object 11 0, offset 4392): expected dictionary key but found non-name object; inserting key /QPDFFake1
WARNING: filename.pdf (object 11 0, offset 4392): expected dictionary key but found non-name object; inserting key /QPDFFake2
WARNING: filename.pdf (object 30 0, offset 52569): unknown token while reading object; treating as string
WARNING: filename.pdf (object 30 0, offset 52581): unknown token while reading object; treating as string
WARNING: filename.pdf (object 30 0, offset 52585): treating unexpected brace token as null
WARNING: filename.pdf (object 30 0, offset 52586): unknown token while reading object; treating as string
WARNING: filename.pdf (object 30 0, offset 52591): unknown token while reading object; treating as string
WARNING: filename.pdf (object 30 0, offset 52605): unknown token while reading object; treating as string
WARNING: filename.pdf (object 30 0, offset 52605): too many errors; giving up on reading object
WARNING: filename.pdf (object 30 0, offset 52608): expected endobj

Checking the mentioned objects(11 and 30) we have noticed that not all encrypted strings are escaped properly:
Both objects are the same unencrypted:

11 0 obj
<</Registry (Adobe)
/Ordering (UCS)
/Supplement 0
>>
endobj

The encrypted version:

11 0 obj
<</Registry (���N�)
/Ordering (�)�)
/Supplement 0
>>
endobj
30 0 obj
<</Registry (�+�R%)
/Ordering (�()
/Supplement 0
>>
endobj

The problem is that the /Ordering string value contains 0x29 and 0x28 which are the opening and closing parenthesis. Some readers fail to handle it and they doesn't render the document properly.

After checking the whole file I've found a couple places where the filterText call was missing and added them where it seemed necessary to escape these strings properly.

@bsweeney bsweeney added this to the 3.1.1 milestone Jan 28, 2025
@bsweeney bsweeney merged commit 3d26768 into dompdf:master Mar 24, 2025
1 check passed
@vencelkatai vencelkatai deleted the encrypted-strings branch March 24, 2025 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants