[
https://issues.apache.org/jira/browse/PDFBOX-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson resolved PDFBOX-2205.
---------------------------------
Resolution: Fixed
This is now fixed, presumably by PDFBOX-2262.
> (Graphics) Operator Refactoring
> -------------------------------
>
> Key: PDFBOX-2205
> URL: https://issues.apache.org/jira/browse/PDFBOX-2205
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel, Rendering
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Fix For: 2.0.0
>
>
> I'm in the process of porting a fairly complex program which uses the 1.8 API
> over to 2.0, as a way of finding out where the rough edges in 2.0 are. The
> app which I'm porting hooks into many of the graphics operators and
> subclasses PageDrawer to get access to the PDF's graphics state.
> It turns out that this doesn't work very well, especially in 2.0 where more
> of the PageDrawer's state is private and we have the additional complexity of
> transparency groups.
> The main issue is that the graphics operators are coupled to PageDrawer, but
> I'm not interested in the AWT rendering, I just need a way to hook into the
> graphics operations - subclassing the operators has proven to be a poor
> solution as there are cases where calling super.process() doesn't provide
> enough flexibility.
> So here's my solution: in the same way that text processing was recently
> factored-out into PDFTextStreamEngine for end-users to subclass, I'd like to
> do the same with graphics operations. Instead of the graphics operators being
> coupled to PageDrawer, which is only one possible implementation of graphics
> handling, we can move the methods which the operators call up into a new
> subclass of PDFStreamEngine, let's call it PDFGraphicsStreamEngine. This
> class can then be subclassed by anyone interested in hooking into the
> graphics operations, including PageDrawer.
> With the new callbacks for text handling already in PDFTextStreamEngine and
> the addition of new graphics callbacks in PDFGraphicsStreamEngine, most of
> the time it shouldn't be necessary for end-users to need to override the
> operator classes to get access to the information they need, which would be a
> huge benefit :)
> This will involve a bunch of changes to operators, so I'll take the chance to
> do some general cleaning up while I'm at it: the operator classes haven't
> received much attention for a while. With more callbacks in PDFStreamEngine
> et al, we're moving towards a point where the operator classes are becoming
> almost an internal part of the PDFBox API: might be something to think about
> for the future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
