[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14485862#comment-14485862
]
John Hewson commented on PDFBOX-2692:
-------------------------------------
[~pslabycz] and [~danielwilson] have both provided some further details on
their use cases which clearly show a need for subclassing PageDrawer. It's
apparent that there are benefits to this approach which outweigh my previous
concerns.
We need to keep the public API as small as possible, and not expose any of the
genuine (and unstable) implementation details which are subject to (often rapid
and breaking) changes, such as Glyph2D, TilingPaint, and TransparencyGroup,
_however_ we can provide stable APIs and/or interfaces for interacting opaquely
with these objects if necessary. Let's try to enable as many concrete use-cases
as possible.
One lesson which we need to take into account from 1.8 when allowing
subclassing is to make sure that our APIs are robust against future changes.
PageDrawer and its internal classes are still works-in-progress, it's common
for methods to gain extra parameters and for the relationships between its
internal classes to change in significant ways. We'll need to make some changes
to ensure that PageDrawer can continue to evolve while still being
backwards-compatible with end-user's subclasses. As Andreas noted, most of
PageDrawer's API is inherited from PDFGraphicsStreamEngine, so this isn't such
a big challenge.
Any solution _must_ enable the use-cases discussed above, these are:
- Replacing the color of a given object
- Custom rendering of annotations
- Replacement of glyph drawing with Graphics2D.drawGlyphVector()
I'd also like to suggest my own use-case:
- Drawing glyph bounding boxes (would be very helpful for debugging)
I'm going to start working on this, if everybody's happy.
> 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
