Post without Account — your post will be reviewed, and if appropriate, posted under Anonymous. You can also use this link to report any problems registering or logging in.
Phil, "any" is literally ANY, width can be 1-2-3-4-8, but also 5-6-7-9-10-...1000-..., etc. to PDF architectural integer limit (2**32 - 1). What's an integer (byte offset of an object, in particular) so many bytes long -- it's beyond comprehension and hardware capabilities and practical requirements. See the H.21 end-note in "PDF Reference, sixth edition", which explicitly states that the Reference, itself, does not impose ANY limit on offset byte width. I don't know what you mean by "reading documentation correctly" and finding there allowed widths of 1-2-3-4-8.
So, a Reader, theoretically and nominally, must cope with any width, but practically -- see what I said in August about a fix, just a character insertion.
However, you raised a valid concern about 32-bit Perls compiled without "USE_64_BIT_INT", regardless of them being worth any effort. Then, again, I'm repeating myself, have a look at sister packages, how they handle the issues -- quite differently from each other (and PDF::API2), but BOTH can cope with ANY widths of arbitrary size, not just 1-2-3-4-8, and regardless of Perl being 32bit/64bit (of course, as long as integer to be decoded fits 32/64 bits, as applicable, -- i.e. byte string may have leading zeroes).
Quotewhat happens for just 'Q' (as the original code was)The original code was tested, if ever, using big-endian CPU
what happens for just 'Q' (as the original code was)
QuoteWhy is 'Q' treated differently, and I need to give the byte order explicitly??? Because it's documented so. By design. How is that "Perl issue"?
Why is 'Q' treated differently, and I need to give the byte order explicitly?
It's matter of POV -- the N/V (n/v) pairs are peculiar exception, all other relevant templates require explicit byte order modifier to work in portable manner.QuoteIs a Parent entry mandatory for a KidThe Reference has comprehensive Index, I don't think there are any ambiguities where and which entries are required. There are trees of slightly different breeds. E.g., items of Pages Tree, Name Tree (your example), Outlines tree(-like structure) require (1) both Kids/Parent, (2) Kids only, (3) Parent only entries, respectively. Evolving standard (as PDF was) can finish eclectic, which is OK as long as everything is clearly documented.
Is a Parent entry mandatory for a Kid
The "afhacked2.pdf", IIRC, was shown to be horribly broken EXACTLY w.r.t. parental relationship in a tree, why would you pick it up as example to investigate.
$_ = 'bytes'; $i = hex unpack 'H'.(2*length), $_; # PDF::Tiny@b = unpack 'C*', $_; $i = 0; ($i <<= 8) += shift @b while @b; # CAM::PDF
...index. Can you recommend a better PDF reference?
I take it that it's OK to refer to an object that's on the Free List, and it will just be ignored?
Quote"sister packages"In general terms:Code: [Select]$_ = 'bytes';$i = hex unpack 'H'.(2*length), $_; # PDF::Tiny@b = unpack 'C*', $_; $i = 0; ($i <<= 8) += shift @b while @b; # CAM::PDF
$_ = 'bytes';$i = hex unpack 'H'.(2*length), $_; # PDF::Tiny@b = unpack 'C*', $_; $i = 0; ($i <<= 8) += shift @b while @b; # CAM::PDF
Quote...index. Can you recommend a better PDF reference?https://en.wikipedia.org/wiki/PDF leads to https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf
QuoteI take it that it's OK to refer to an object that's on the Free List, and it will just be ignored?See page 64, link above. If object definition is missing (I think it doesn't matter if number is in Free list), then reference refers to null object. If null object is allowed in particular place, definition absence appears to be "ignored". E.g. if /Font entry in graphics state dict is null, then no font is set by gs operator invocation, just wait until Tf operator. Otherwise, I guess it depends on severity, either "ignored" so as not to disturb a user, or reported as error.
This still doesn't address the problem of what to do if the result doesn't fit in a 32-bit (4-byte) integer (i.e., it overflows -- does Perl switch to double without losing precision?)