Hi,
I've send it directly to you. But don't worry, Adobe Reader is still the
"gold standard" for us :-)
Tilman
Am 13.07.2014 18:43, schrieb Leonard Rosenthol:
Would be curious to see such a file...
On 7/13/14, 7:15 AM, "Tilman Hausherr (JIRA)" <[email protected]> wrote:
[
https://issues.apache.org/jira/browse/PDFBOX-2205?page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060084#co
mment-14060084 ]
Tilman Hausherr commented on PDFBOX-2205:
-----------------------------------------
It gets weirder: Acrobat Reader has the "wrong" rendering.
(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.2#6252)
