Re: [pdf-devel] ASCII85Decode implementation

[gerel]

 > Date: Sat, 08 Mar 2008 20:39:09 -0300
 > From: <address@hidden>
 > 
 >  > Date: Sun, 9 Mar 2008 10:01:10 +1100
 >  > From: "Cirilo Bernardo" <address@hidden>
 >  > Content-Disposition: inline
 >  > 
 >  > 
 >  > Yes, such streams are invalid, they may exist, and they should
 >  > probably not be supported.  The safest thing to do is reject that
 >  > stream altogether, and this is what is stated in the PDF
 >  > specification. If there is a bad PDF writer in existence somewhere,
 >  > people should not waste time working around its faults.  If you try to
 >  > accommodate such problems then you are deliberately ignoring the
 >  > specification and inviting bad coders to produce more bad code because
 >  > they know someone else will put in all the effort to work around it.
 >  > In the rare cases where a file may be partially corrupted and a copy
 >  > cannot be obtained elsewhere, recovering information should be left to
 >  > specialists, not to the PDF library.   Even in the future if someone
 >  > complains "But you can't view files created by FaultyPDFWriter 2.0 and
 >  > 90% of people use that software" that is no excuse to cater to bad
 >  > software.  The question then is: do you want to trust your documents
 >  > to software which is not producing correct output?
 >  > 
 >  > So although I am guessing that your intent is to produce a more robust
 >  > library, the simplest solution (drop the stream) is in fact the best
 >  > and most robust, even if end-users may scream and say "oh but if they
 >  > only accepted '~' for EOD rather than requiring '~>' as in the
 >  > standards, then I could see this picture that is meant to display on
 >  > page 2".  Personally, I think supporting bad streams is simply
 >  > circumventing the PDF design for reliability.
 >  > 
 > 
 > IMHO, your arguments refer to the _cause_ and the _consequence_ of a possible
 > solution to a specific scenario in case we encounter a bad formatted PDF 
 > file.
 > 
 > The cause being an incorrect or abscent size length for a stream, and the
 > consequence being one possible solution to the problem, that is, an 
 > incremental
 > reading of the stream contents in order to obtain its size.
 > 
 > So, the possibility to do an incremental reading as the scheme that jemarch 
 > has
 > described is a feature we need.
 > 

BTW, the standard defines what are the minimum requirements for the library, if
we choose to fix some errors encountered while interpreting a PDF file, that
is not against the standard. Instead, it makes the library more robust as Ralph
said, since we're doing more work than the standard asks for.

-gerel