[
https://issues.apache.org/jira/browse/PDFBOX-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855503#comment-16855503
]
Michael Klink commented on PDFBOX-4554:
---------------------------------------
{quote}[~jpyeron]> But the length would be shorter in the above case.{quote}
Which doesn't make any difference.
When the signed ranges of some revision are extracted, you'll get the same
result, no matter if you only present the revision itself or the full outer PDF.
{quote}There are other situation, out of the scope of PDFBox, where the byte[]
is not starting at zero - in those cases, each of the signed version would
start at the SAME, non-zero offset.{quote}
There surely are.
If one starts adding methods for such use cases, though, I would propose
switching the base data type away from {{byte[]}} entirely. Keeping the
{{byte[]}}, e.g. by using your approach, there simply will be the next person
who says that he has his PDF separated in segments throughout the byte array
with some data in-between requiring yet other addition parameters, etc, etc, ...
My preference would be streams (which should be reset-able as you correctly
remarked) but the PDFBox development's mileage may vary...
> operations taking a byte[] need to allow for offset and length too
> ------------------------------------------------------------------
>
> Key: PDFBOX-4554
> URL: https://issues.apache.org/jira/browse/PDFBOX-4554
> Project: PDFBox
> Issue Type: Improvement
> Reporter: Jason Pyeron
> Priority: Major
>
> Without this, massive amounts of memory must be copied/allocated to "trim"
> byte[].
> See forthcoming pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
