You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "John Hewson (JIRA)" <ji...@apache.org> on 2015/04/07 23:48:14 UTC
[jira] [Comment Edited] (PDFBOX-2692) Possibility to use our own
and/or overwrite PageDrawer class
[ https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483530#comment-14483530 ]
John Hewson edited comment on PDFBOX-2692 at 4/7/15 9:48 PM:
-------------------------------------------------------------
-1 for making PageDrawer public. PageDrawer is PDFBox's implementation of PDF rendering to a Graphics2D surface, it is not a general-purpose graphics extraction API - we already have one of those, it's PDFGraphicsStreamEngine which was added specifically so that PageDrawer could be made private. PDFGraphicsStreamEngine provides all that is needed to implement sophisticated graphical and text analysis of PDF files.
However, PDFGraphicsStreamEngine doesn't support Daniel Wilson's use case, indeed it looks like only PageDrawer can do that. However, there are probably a dozen ways to achieve this without allowing PageDrawer to be subclassed - we need to think through and discuss those first. Allowing PageDrawer to be subclassed is really a "nuclear option", it works, but it could cause tremendous collateral damage if not done carefully. I'm sure we can think up something smarter than that.
Andreas' comments are a good start, here's some feedback.
{quote}
drawBufferedImage: isn't called anywhere -> make it private
{quote}
Ok.
{quote}
drawPage: should be public (inherited, interface or move to PDFGraphicsStreamEngine), so that one can use its own PageDrawer in PDFRenderer
{quote}
drawPage already is public. It can't be moved to PDFGraphicsStreamEngine as that would introduce an unwanted AWT Graphics dependency.
{quote}
getRenderer: isn't used anywhere removed
{quote}
This is needed for document-wide caching, which isn't implemented yet but will be soon. I see it was removed already (oops).
{quote}
drawTilingPattern: should be moved to PDFGraphicsStreamEngine as it is similar to all those other methods handling graphics operations
{quote}
PDFGraphicsStreamEngine should not have any AWT dependencies (other than Point2D). It provides a high-level interface which is completely free of any specific backend graphics technology.
---
I'm going to give the PageDrawer issue some thought, see if there isn't some solution which uses composition rather than inheritance, but which still provides a high degree of customisability to PageDrawer...
was (Author: jahewson):
-1 for making PageDrawer public. PageDrawer is PDFBox's implementation of PDF rendering to a Graphics2D surface, it is not a general-purpose graphics extraction API - we already have one of those, it's PDFGraphicsStreamEngine which was added specifically so that PageDrawer could be made private. PDFGraphicsStreamEngine provides all that is needed to implement sophisticated graphical and text analysis of PDF files.
However, PDFGraphicsStreamEngine doesn't support Daniel Wilson's use case, indeed it looks like only PageDrawer can do that. However, there are probably a dozen ways to achieve this without allowing PageDrawer to be subclassed - we need to think through and discuss those first. Allowing PageDrawer to be subclassed is really a "nuclear option", it works, but it causes tremendous collateral damage. I'm sure we can think up something smarter than that.
Andreas' comments are a good start, here's some feedback.
{quote}
drawBufferedImage: isn't called anywhere -> make it private
{quote}
Ok.
{quote}
drawPage: should be public (inherited, interface or move to PDFGraphicsStreamEngine), so that one can use its own PageDrawer in PDFRenderer
{quote}
drawPage already is public. It can't be moved to PDFGraphicsStreamEngine as that would introduce an unwanted AWT Graphics dependency.
{quote}
getRenderer: isn't used anywhere removed
{quote}
This is needed for document-wide caching, which isn't implemented yet but will be soon.
{quote}
drawTilingPattern: should be moved to PDFGraphicsStreamEngine as it is similar to all those other methods handling graphics operations
{quote}
PDFGraphicsStreamEngine should not have any AWT dependencies (other than Point2D). It provides a high-level interface which is completely free of any specific backend graphics technology.
---
I'm going to give the PageDrawer issue some thought, see if there isn't some solution which uses composition rather than inheritance, but which still provides a high degree of customisability to PageDrawer...
> Possibility to use our own and/or overwrite PageDrawer class
> ------------------------------------------------------------
>
> Key: PDFBOX-2692
> URL: https://issues.apache.org/jira/browse/PDFBOX-2692
> Project: PDFBox
> Issue Type: Wish
> Components: Rendering
> Affects Versions: 2.0.0
> Environment: JDK 1.8, Windows 7, PDF-Box - current trunk
> Reporter: Manfred Pock
> Assignee: Andreas Lehmkühler
> Labels: features
> Fix For: 2.0.0
>
> Attachments: pdfexample.jpg
>
>
> We use PDFBox to render PDF's. Additionally, we have the posibility to add different kinds of annotation (stamp, marks, free text, notes..) like in a wysiwyg-editor. To do this, it is necessary that we paint these annotations on our own.
> Another reason is not to paint all parts: for example we have a pdf with an embedded picture. Behind the picture we have the OCR-text to this picture. This text is only needed for searching und should not be painted.
> Thus it would be useful to use our own derived PageDrawer. As I see there are some things to change.
> a.) remove the final from PagerDrawer-class.
> b.) make some global-variables (graphics, xform, pageSize...) protected,
> c.) also some methods like setRenderingHints should be protected
> d.) maybe the possibility to say to the PDFRender which PageDrawer should be used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org