Dear pdfbox-devs,
a co-worker and i are currently developing a service for searching and
replacing content in pdf documents based on pdfbox. We started our
project with the 1.8.2 version of pdfbox and just trying to migrated to
1.8.8 recently.
On changing to version 1.8.8 we are running into troubles with pdf
content concerning inline images. Our code study of the differences
between those versions of pdfbox led us to the handling of the EI
operator as reason of our troubles.
In version 1.8.2 the method parseNextToken() of the
org.apache.pdfbox.pdfparser.PDFStreamParser does an unread of the EI
token on inline images. In newer versions this unread of the EI token
doesn't exist anymore with the following comment “// the EI operator
isn't unread, as it won't be processed anyway”.
As a consequence the token sets of a document containing an inline image
delivered by the PDFStreamParser can't be used to (re)render a valid pdf
document by the ContentStreamWriter.
The reason is the missing token for the EI operator. Maybe, that the EI
token doesn't trigger any further processing, but it is still necessary
to represent the delimiter in the token sequence.
On the other side if a inline image should be part of a pdf page and is
inserted as a token set manually, the EI token must also be present in
the token set, so that the ContentStreamWriter is able to create a
correct pdf document.
From our point of view there are two simple approaches to get a more
consistent internal representation of pdf documents with pdfbox
concerning inline images. Either represent the EI operator as a token
(revert to handling in version 1.8.2.) explicitly or extend the
writeObject method in the ContentStreamWriter to append the EI operator
implicitly.
Furthermore in our specialization of the PDFTextStripper, the ability to
access the base-class properties from there was a limiting factor. Are
there some reasons that the properties
org.apache.pdfbox.util.PDFTextStripper::startBookmarkPageNumber
org.apache.pdfbox.util.PDFTextStripper::endBookmarkPageNumber
org.apache.pdfbox.util.PDFTextStripper::pageArticles
org.apache.pdfbox.util.PDFTextStripper::characterListMapping
org.apache.pdfbox.util.PDFStreamEngine::streamResourcesStack
org.apache.pdfbox.util.PDFStreamEngine::page
are really necessary to be private, or is it enough restrictive to be
protected so that they can be accessed in derived classes?
Best regards,
Lukas Schober
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
