pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Constantine Dokolas <cdoko...@gmail.com>
Subject Re: Dubious implementation approach with content stream OperatorProcessors and PDFGraphicsStreamEngine
Date Thu, 24 May 2018 09:08:50 GMT
Can't say about design rules, but I'm under the impression few are using
the framework as I have lately (i.e. using it to process content on the
operator level), so the impact on existing code should be minimal. Making
these fixes will be best in the long run, and I don't see why there will be
double code. Perhaps some other major fixes can be gathered to justify a
2.1.0 release, bringing more attention to the changes in behavior.

I'd like to contribute, but all I can do right now is push a revision on
Github (on my fork of the repository).

If you can post a short guide on how to setup an IDE (Eclipse, VS Code or
Netbeans) to work with the project, I'd also appreciate it.


On Wed, May 23, 2018 at 7:58 PM Tilman Hausherr <THausherr@t-online.de>

> You're right... makes we wonder if we violated some design rule. The
> alternative would be some double code, which isn't good either.
> Lets say we change this, then not only we'd have some double code, but
> some existing code by our users might no longer work...
> You can open an issue in JIRA and attach a patch / diff file there. But
> it might be a difficult decision.
> Tilman
> Am 15.05.2018 um 15:00 schrieb Constantine Dokolas:
> > Hi all!
> >
> > I'm currently implementing a library that intercepts content stream
> > operators from a document's pages in order to produce a filtered version
> > (as a different document). To this, I'm writing an extension to
> > PDFGraphicsStreamEngine (as suggested by the documentation) and using
> > processOperator() to do "my stuff".
> >
> > Certain operators (MoveTextSetLeading, NextLine, ShowTextLine and
> > ShowTextLineAndSpace), in order to trigger the (multiple) corresponding
> > events, take the shortcut of calling processOperator() for "bogus"
> > operators that are in fact *not present* in the content stream.
> >
> > I suggest the devs replace such calls with temporary OperatorProcessor
> > instantiations and process(...) calls on them. I'd be happy to contribute
> > the related changes, but I'm not sure how.
> >
> > I'd like to voice my appreciation for this project. It has solved many
> > problems for me and I greatly appreciate the devs' effort.
> >
> > Regards,
> >
> > Constantine
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
> --
There is a computer disease that anybody who works with computers knows
about. It's a very serious disease and it interferes completely with the
work. The trouble with computers is that you 'play' with them!
- Richard P. Feynman

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message