[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-dev
Subject:    Re: PDF full screen mode...
From:       Andreas Delmelle <andreas.delmelle () telenet ! be>
Date:       2008-07-19 10:48:53
Message-ID: 57438D94-BB07-4827-AE78-788721B2B5F8 () telenet ! be
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]