[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483530#comment-14483530
]
John Hewson commented on PDFBOX-2692:
-------------------------------------
-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-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
