On Jul 18, 2008, at 19:24, Bill Harrelson wrote:
Hi Bill
Thanks. Guess I just have to wait, and tell the users they have to
check print scaling when they print.
I tried patching a pdf file by hand to include the directive, and,
as you predicted, got file corrupted errors (although that could be
for a variety of reasons, so it's not conclusive.)
In theory PDF is editable by hand, but remember that it's still a
binary format, so it's /very/ sensitive to things like editors adding
linefeeds or screwing up the raw bytes due to implicit byte-to-char
conversion... You'd actually almost need a Hex editor to get it
completely right.
Anyway, I ran a test out of curiosity. It doesn't crash or give
corruption warnings on my end (Adobe Reader 8 for Mac), and checking
the document properties, the entry even seems to be correctly
recognized (meaning Reader does not rely on the PDF file version to
process the ViewerPreferences). Also, adding totally nonsensical
entries, which would generate PDF like '/Foo /Bar' (strictly speaking
not incorrect, just meaningless) did not have any damaging effects.
In the end, if it works, it works, I guess, so I'm not so sure
whether it's worth investing time into making things like that
impossible, BUT... if the user would specify something like
'<pdf:name key="Foo">[[Bar</pdf:name>', the file does get corrupted,
since the content is not a valid PDF name. Some degree of validation
is necessary to prevent this stuff from happening. The square
brackets should either be escaped (to '#5B'), or made illegal (i.e.
if necessary, the user should do the escapes himself). Maybe it would
make sense to have PDFName itself not allow invalid names to be
created. At any rate, additional logic for PDF parsing capabilities
seems to belong in the fop.pdf package, rather than on the side of
the extension.
Ultimately, it's also meant to reduce maintenance on our end. If the
PDF Reference evolves and allows new features, the extension should
make those available to the users with us having to add only a
minimal amount of code. None in case of the PrintScaling entry, since
there is already generic support for PDF names. Nice example of the
potential benefits, as opposed to the dangers described above.
I'm currently still planning to look into making a few modifications
to the format, and building in some safeguards (basic validation, if
you will). If you want to stay informed, add yourself to the CC-list
in Bugzilla #45390, and you'll be among the first to receive updates
on the status of the patch.
Cheers
Andreas
