You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Brian Carrier <ca...@digital-evidence.org> on 2009/04/14 17:37:18 UTC
Default Parsing Behavior
Currently, when PDFBox encounters a PDF file that does not meet spec
or the spec variations that PDFBox has been modified to support, it
throws an exception. Justin and I recently added a notion of
"forcing" PDFBox to parse when it is parsing objects. We are
realizing though, that it is going to get messy if we want to push
that notion of forcing all the way down into parsing objects (it is
going to require a lot of changes to make the "force" value available
to all levels of the stream parsing). In many of the cases where
PDFBox throws an exception, Adobe reader simply works around the issue.
So, the question is if we should continue the default behavior of
throwing exceptions.... There seem to be three options:
1) We push the force variable to the lowest levels of parsing to
ignore corrupt objects when the variable is set.
2) We add a new logging design that differentiates between warning
and error. When corrupt objects are found, we ignore them and make
an error log entry. This approach would not require the force variable.
3) We continue the current design of throwing exceptions for all
corrupt things.
Thoughts?
brian
Re: Default Parsing Behavior
Posted by Daniel Wilson <wi...@gmail.com>.
Since we're discussing an event subsystem, this is a good time to mention
what I am missing in the logger() setup we currently have -- in hopes that
if we implement something more sophisticated it addresses these
shortcomings.
In a static method, I cannot call logger() because it is non-static ...
because it instantiates a Logger object. If any new event subsystem could
be available from static methods, that would be very helpful.
On Tue, Apr 14, 2009 at 3:05 PM, Dexter Mishra <de...@gmail.com>wrote:
> Hi I am relatively new to PDFBox. I am using it for some internal
> purpose (Well very briefly I changed the parser to also parse comments
> on some conditions and then get the text.). I agree with Jeremias . I
> have also started building a PDF debugger based on PDFBox. Well in
> some cases user may leave up with minor errors, but when printing he
> will needs errors reported. Imagine I fire a 100 page PDF and find out
> its messy.
>
> any way let me know guys if I can help you.
>
> On 4/14/09, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> > When I read this, it immediately reminds be of what I built in FOP: an
> > event subsystem that, instead of throwing exceptions, calls an interface
> > method and someone else decides (in a central listener) what to do with
> > the event, whether to throw an exception, to invoke some compensating
> > action or to simply log it. Add to that full l10n for the message
> > generation.
> >
> > Documentation: http://xmlgraphics.apache.org/fop/trunk/events.html
> >
> > The events package in FOP Trunk:
> >
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/events/
> >
> > Might be overkill for PDFBox. I don't know. Just thought I would throw
> > it in the round. If you guys find that interesting I'm sure we could
> > generalize
> > that part to a more suitable location. It's already built so it has
> > minimal dependencies on FOP.
> >
> > Basically, this would be a deluxe variant of Brian's #1. Anyway, I think
> > the case is pretty similar to the FOP one: In FOP, some people want an
> > exception when a referenced image can't be found, others simply want a
> > log entry. Even others want such an event so they can properly display
> > in their GUI. On the PDFBox side, I guess, the text extraction people
> > will want as much error recovery as possible. They can live with small
> > problems in a PDF. PDF printing people might want to know if something is
> > fishy about a PDF and there's a chance that the output will not look as
> > expected. I've recently been experimenting with PDFBox as a potential
> > PDF validation facility (I'm currently looking into PDF/A-1a in FOP). In
> > such a case I would want to have each and every error PDFBox finds but
> > would like PDFBox to continue if it has found one. Of course, this might
> > add a bit of complexity but could also cater to various needs.
> >
> > I'm curious what you think.
> >
> > On 14.04.2009 17:37:18 Brian Carrier wrote:
> >> Currently, when PDFBox encounters a PDF file that does not meet spec
> >> or the spec variations that PDFBox has been modified to support, it
> >> throws an exception. Justin and I recently added a notion of
> >> "forcing" PDFBox to parse when it is parsing objects. We are
> >> realizing though, that it is going to get messy if we want to push
> >> that notion of forcing all the way down into parsing objects (it is
> >> going to require a lot of changes to make the "force" value available
> >> to all levels of the stream parsing). In many of the cases where
> >> PDFBox throws an exception, Adobe reader simply works around the issue.
> >>
> >> So, the question is if we should continue the default behavior of
> >> throwing exceptions.... There seem to be three options:
> >> 1) We push the force variable to the lowest levels of parsing to
> >> ignore corrupt objects when the variable is set.
> >> 2) We add a new logging design that differentiates between warning
> >> and error. When corrupt objects are found, we ignore them and make
> >> an error log entry. This approach would not require the force variable.
> >> 3) We continue the current design of throwing exceptions for all
> >> corrupt things.
> >>
> >> Thoughts?
> >>
> >> brian
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
>
Re: Default Parsing Behavior
Posted by Dexter Mishra <de...@gmail.com>.
Hi I am relatively new to PDFBox. I am using it for some internal
purpose (Well very briefly I changed the parser to also parse comments
on some conditions and then get the text.). I agree with Jeremias . I
have also started building a PDF debugger based on PDFBox. Well in
some cases user may leave up with minor errors, but when printing he
will needs errors reported. Imagine I fire a 100 page PDF and find out
its messy.
any way let me know guys if I can help you.
On 4/14/09, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> When I read this, it immediately reminds be of what I built in FOP: an
> event subsystem that, instead of throwing exceptions, calls an interface
> method and someone else decides (in a central listener) what to do with
> the event, whether to throw an exception, to invoke some compensating
> action or to simply log it. Add to that full l10n for the message
> generation.
>
> Documentation: http://xmlgraphics.apache.org/fop/trunk/events.html
>
> The events package in FOP Trunk:
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/events/
>
> Might be overkill for PDFBox. I don't know. Just thought I would throw
> it in the round. If you guys find that interesting I'm sure we could
> generalize
> that part to a more suitable location. It's already built so it has
> minimal dependencies on FOP.
>
> Basically, this would be a deluxe variant of Brian's #1. Anyway, I think
> the case is pretty similar to the FOP one: In FOP, some people want an
> exception when a referenced image can't be found, others simply want a
> log entry. Even others want such an event so they can properly display
> in their GUI. On the PDFBox side, I guess, the text extraction people
> will want as much error recovery as possible. They can live with small
> problems in a PDF. PDF printing people might want to know if something is
> fishy about a PDF and there's a chance that the output will not look as
> expected. I've recently been experimenting with PDFBox as a potential
> PDF validation facility (I'm currently looking into PDF/A-1a in FOP). In
> such a case I would want to have each and every error PDFBox finds but
> would like PDFBox to continue if it has found one. Of course, this might
> add a bit of complexity but could also cater to various needs.
>
> I'm curious what you think.
>
> On 14.04.2009 17:37:18 Brian Carrier wrote:
>> Currently, when PDFBox encounters a PDF file that does not meet spec
>> or the spec variations that PDFBox has been modified to support, it
>> throws an exception. Justin and I recently added a notion of
>> "forcing" PDFBox to parse when it is parsing objects. We are
>> realizing though, that it is going to get messy if we want to push
>> that notion of forcing all the way down into parsing objects (it is
>> going to require a lot of changes to make the "force" value available
>> to all levels of the stream parsing). In many of the cases where
>> PDFBox throws an exception, Adobe reader simply works around the issue.
>>
>> So, the question is if we should continue the default behavior of
>> throwing exceptions.... There seem to be three options:
>> 1) We push the force variable to the lowest levels of parsing to
>> ignore corrupt objects when the variable is set.
>> 2) We add a new logging design that differentiates between warning
>> and error. When corrupt objects are found, we ignore them and make
>> an error log entry. This approach would not require the force variable.
>> 3) We continue the current design of throwing exceptions for all
>> corrupt things.
>>
>> Thoughts?
>>
>> brian
>
>
>
>
> Jeremias Maerki
>
>
Re: Default Parsing Behavior
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
When I read this, it immediately reminds be of what I built in FOP: an
event subsystem that, instead of throwing exceptions, calls an interface
method and someone else decides (in a central listener) what to do with
the event, whether to throw an exception, to invoke some compensating
action or to simply log it. Add to that full l10n for the message
generation.
Documentation: http://xmlgraphics.apache.org/fop/trunk/events.html
The events package in FOP Trunk:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/events/
Might be overkill for PDFBox. I don't know. Just thought I would throw
it in the round. If you guys find that interesting I'm sure we could generalize
that part to a more suitable location. It's already built so it has
minimal dependencies on FOP.
Basically, this would be a deluxe variant of Brian's #1. Anyway, I think
the case is pretty similar to the FOP one: In FOP, some people want an
exception when a referenced image can't be found, others simply want a
log entry. Even others want such an event so they can properly display
in their GUI. On the PDFBox side, I guess, the text extraction people
will want as much error recovery as possible. They can live with small
problems in a PDF. PDF printing people might want to know if something is
fishy about a PDF and there's a chance that the output will not look as
expected. I've recently been experimenting with PDFBox as a potential
PDF validation facility (I'm currently looking into PDF/A-1a in FOP). In
such a case I would want to have each and every error PDFBox finds but
would like PDFBox to continue if it has found one. Of course, this might
add a bit of complexity but could also cater to various needs.
I'm curious what you think.
On 14.04.2009 17:37:18 Brian Carrier wrote:
> Currently, when PDFBox encounters a PDF file that does not meet spec
> or the spec variations that PDFBox has been modified to support, it
> throws an exception. Justin and I recently added a notion of
> "forcing" PDFBox to parse when it is parsing objects. We are
> realizing though, that it is going to get messy if we want to push
> that notion of forcing all the way down into parsing objects (it is
> going to require a lot of changes to make the "force" value available
> to all levels of the stream parsing). In many of the cases where
> PDFBox throws an exception, Adobe reader simply works around the issue.
>
> So, the question is if we should continue the default behavior of
> throwing exceptions.... There seem to be three options:
> 1) We push the force variable to the lowest levels of parsing to
> ignore corrupt objects when the variable is set.
> 2) We add a new logging design that differentiates between warning
> and error. When corrupt objects are found, we ignore them and make
> an error log entry. This approach would not require the force variable.
> 3) We continue the current design of throwing exceptions for all
> corrupt things.
>
> Thoughts?
>
> brian
Jeremias Maerki
Re: Default Parsing Behavior
Posted by Daniel Wilson <wi...@gmail.com>.
Something like #2 is in place. You'll find a fair number of logger().info
calls in the rendering side. See PDFBox/exceptions/LoggingObject.java for
setting of the app's logging level.
Daniel Wilson
On Tue, Apr 14, 2009 at 11:37 AM, Brian Carrier <
carrier@digital-evidence.org> wrote:
> Currently, when PDFBox encounters a PDF file that does not meet spec or the
> spec variations that PDFBox has been modified to support, it throws an
> exception. Justin and I recently added a notion of "forcing" PDFBox to
> parse when it is parsing objects. We are realizing though, that it is going
> to get messy if we want to push that notion of forcing all the way down into
> parsing objects (it is going to require a lot of changes to make the "force"
> value available to all levels of the stream parsing). In many of the cases
> where PDFBox throws an exception, Adobe reader simply works around the
> issue.
>
> So, the question is if we should continue the default behavior of throwing
> exceptions.... There seem to be three options:
> 1) We push the force variable to the lowest levels of parsing to ignore
> corrupt objects when the variable is set.
> 2) We add a new logging design that differentiates between warning and
> error. When corrupt objects are found, we ignore them and make an error log
> entry. This approach would not require the force variable.
> 3) We continue the current design of throwing exceptions for all corrupt
> things.
>
> Thoughts?
>
> brian
>
>