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/02/25 22:04:04 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=14337192#comment-14337192 ]
John Hewson edited comment on PDFBOX-2692 at 2/25/15 9:03 PM:
--------------------------------------------------------------
PageDrawer is final by design. Its implementation details are not for public use, because if we allowed this then they would be part of our public API and this frozen, preventing us from fixing bugs or doing internal refactoring (which happens frequently). This would be a disaster for PDFBox.
It's easy for us to add further APIs to allow use cases which aren't currently supported by PageDrawer. But we need to start with a clear description of what those use cases are so that we can figure out the most appropriate API. Subclassing hacks are *never* necessary, because we can always add to PageDrawer's APIs. If you explain exactly what it is that you're trying to achieve, rather than the technical aspects of how you implement it, and we can figure out a good solution.
{quote}
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.
{quote}
Do these annotations get saved to the PDF file? Are you aware that you can add annotations using PDFBox? If you really do want to render these yourself, why not render them on the BufferedImage afterwards - what need is there to subclass PageDrawer?
{quote}
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.
{quote}
Either the text actual should be visible, or this is a PDFBox bug. Either way, no need to subclass PageDrawer.
{quote}
also some methods like setRenderingHints should be protected
{quote}
It's necessary for PDFBox to have complete control over rendering hints in order to get correct renderings of PDF files. What hints were you looking to modify?
was (Author: jahewson):
PageDrawer is final by design. Its implementation details are not for public use, because if we allowed this then they would be part of our public API and this frozen, preventing us from fixing bug or doing internal refactoring (which happens frequently). This would be a disaster for PDFBox.
It's easy for us to add further APIs to allow use cases which aren't currently supported by PageDrawer. But we need to start with a clear description of what those use cases are so that we can figure out the most appropriate API. Subclassing hacks are *never* necessary, because we can always add to PageDrawer's APIs. If you explain exactly what it is that you're trying to achieve, rather than the technical aspects of how you implement it, and we can figure out a good solution.
{quote}
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.
{quote}
Do these annotations get saved to the PDF file? Are you aware that you can add annotations using PDFBox? If you really do want to render these yourself, why not render them on the BufferedImage afterwards - what need is there to subclass PageDrawer?
{quote}
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.
{quote}
Either the text actual should be visible, or this is a PDFBox bug. Either way, no need to subclass PageDrawer.
{quote}
also some methods like setRenderingHints should be protected
{quote}
It's necessary for PDFBox to have complete control over rendering hints in order to get correct renderings of PDF files. What hints were you looking to modify?
> 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
> Labels: features
>
> 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