[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352005#comment-14352005
]
Andreas Lehmkühler edited comment on PDFBOX-2692 at 3/10/15 5:59 PM:
---------------------------------------------------------------------
IMHO we are not done here. The conclusion is based on Johns opinion and not on
a consensus (Maruan, Daniel and myself are open to the request). The answer to
this request depends mostly on opinions when to expose apis or when to avoid to
do so.
Furthermore I can't agree to the technical reason not to open the class
{quote}
Remember that every single public or protected method or field, and the order
in which those are called and modified are part of an implicit public contract
when subclassing is used. Far better to delegate plug-in functionality via
tightly controlled interfaces.
{quote}
Most of the API is already public as those methods are inherited from
PDFGraphicsStreamEngine and PDFStreamEngine. Even the order of calling those
methods is part of PDFStreamEngine and not of PageDrawer. There are 4 methods
which are public and would be exposed:
- drawBufferedImage: isn't called anywhere -> make it private
- drawPage: should be public (inherited, interface or move to
PDFGraphicsStreamEngine), so that one can use its own PageDrawer in PDFRenderer
- -getRenderer: isn't used anywhere- removed
- drawTilingPattern: should be moved to PDFGraphicsStreamEngine as it is
similar to all those other methods handling graphics operations
was (Author: lehmi):
IMHO we are not done here. The conclusion is based on Johns opinion and not on
a consensus (Maruan, Daniel and myself are open to the request). The answer to
this request depends mostly on opinions when to expose apis or when to avoid to
do so.
Furthermore I can't agree to the technical reason not to open the class
{quote}
Remember that every single public or protected method or field, and the order
in which those are called and modified are part of an implicit public contract
when subclassing is used. Far better to delegate plug-in functionality via
tightly controlled interfaces.
{quote}
Most of the API is already public as those methods are inherited from
PDFGraphicsStreamEngine and PDFStreamEngine. Even the order of calling those
methods is part of PDFStreamEngine and not of PageDrawer. There are 4 methods
which are public and would be exposed:
- drawBufferedImage: isn't called anywhere -> make it private
- drawPage: should be public (inherited, interface or move to
PDFGraphicsStreamEngine), so that one can use its own PageDrawer in PDFRenderer
- getRenderer: isn't used anywhere -> remove
- drawTilingPattern: should be moved to PDFGraphicsStreamEngine as it is
similar to all those other methods handling graphics operations
> 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
> 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: [email protected]
For additional commands, e-mail: [email protected]
