[
https://issues.apache.org/jira/browse/PDFBOX-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401281#comment-15401281
]
John Hewson edited comment on PDFBOX-3353 at 7/31/16 6:16 PM:
--------------------------------------------------------------
{quote}
When you make a class private / protected you lock down that class and those
who need a quick fix could realize this and try to work around it.
{quote}
Firstly, this is just not true. Checkout PDFBox from SVN and make your bugfix.
It's easy to have maven point to your local patched PDFBox.
Secondly, we've had very bad experiences with this sort of thing. Pretty much
everything used to be public and we found that we couldn't make any significant
changes to "internal" APIs without someone opening a bug on JIRA saying that we
broke their private subclass bugfix. This is an open source project and
everybody benefits from bug fixes being pushed upstream, not privately hoarded.
As such we've taken an deliberate approach of encouraging that and preventing
private hacks. Without this it simply becomes impossible for PDFBox to make
progress - when everything is public then every change is a breaking change.
We're happy to help members of the community, but we're not going to make bad
changes to PDFBox just so that those who have chosen to subclass to make bug
fixes rather than contributing those fixes back to the community can avoid
having to change their code. "I chose to do my own private thing rather than
share with you and now I want you to make harmful changes so that I don't have
to bother to fix my own code" is not valid reasoning.
Contribue your fix. Or don't. But don't ask us to break something just to
satisfy your private legacy code.
was (Author: jahewson):
{quote}
When you make a class private / protected you lock down that class and those
who need a quick fix could realize this and try to work around it.
{quote}
Firstly, this is just not true. Checkout PDFBox from SVN and make your bugfix.
It's easy to have maven point to your local patched PDFBox.
Secondly, we've had very bad experiences with this sort of thing. Pretty much
everything used to be public and we found that we couldn't make any significant
changes to "internal" APIs without someone opening a bug on JIRA saying that we
broke their private subclass bugfix. This is an open source project and
everybody benefits from bug fixes being pushed upstream, not privately hoarded.
As such we've taken an deliberate approach of encouraging that and preventing
private hacks. Without this it simply becomes impossible for PDFBox to make
progress - when everything is public then every change is a breaking change.
We're happy to help members of the community, but we're not going to make bad
changes to PDFBox just so that those who have chosen to subclass to make bug
fixes rather than contributing those fixes back to the community can avoid
having to change their code. "I chose to do my own private thing rather than
share with you and now I want you to make harmful changes so that I don't have
to bother to fix my own code" is not valid reasoning.
> Create appearance streams for annotations
> -----------------------------------------
>
> Key: PDFBOX-3353
> URL: https://issues.apache.org/jira/browse/PDFBOX-3353
> Project: PDFBox
> Issue Type: Task
> Components: PDModel, Rendering
> Affects Versions: 1.8.12, 2.0.0, 2.0.1, 2.0.2, 2.1.0
> Reporter: Tilman Hausherr
> Labels: Annotations
> Attachments: SquareAnnotations.pdf, showAnnotation.java
>
>
> Create appearance streams for annotations when missing.
> I'll start by replacing current code for Ink and Link annotations.
> Good example PDFs:
> http://www.pdfill.com/example/pdf_commenting_new.pdf
> https://github.com/mozilla/pdf.js/issues/6810
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
