You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I obtain <</Type /Page/Resources [3 0 R [1 0 R 2 0 R]]/XObject <</X2 2 0 R>>>>
when I expected <</Type /Page/Resources [3 0 R 1 0 R 2 0 R]/XObject <</X2 2 0 R/X1 1 0 R>>>>
Besides the missing X1, the array is not properly extended. This has an impact on the example PDF merging code if merging 3 PDFs. Notice that if I swap the merging order, I instead obtain: <</Type /Pages/Resources [3 0 R 1 0 R 2 0 R]/XObject <</X1 1 0 R>>>>
The array now merges correctly, but X2 is still missing.
EDIT: Actually, I implemented code that does what I expected and was surprised (for 1sec) to see the outcome was <</Type [/Pages /Pages]/Resources [1 0 R 2 0 R 3 0 R]/XObject <</X1 1 0 R/X2 2 0 R>>>>
So this might not be such a trivial matter after all. Maybe all I need is to check that the value is the same and not make an array in such a case, but it could have other consequences.
Attempting to impl
DCTDecode
support uncovered an issue withDictionary::extend
which does not merge sub dictionaries recursively as anticipated.The text was updated successfully, but these errors were encountered: