[
https://issues.apache.org/jira/browse/PDFBOX-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854549#comment-16854549
]
Michael Klink commented on PDFBOX-4554:
---------------------------------------
{quote}[~jpyeron]> 99% correct. Actually, when a pdf file is appended with
multiple signatures the byte[] is a PDF, but has 10 other historical PDFs
inside of it.
{quote}
By _historical PDFs_ I assume you mean previous (signed) revisions of the same
document (or do you mean attached PDFs?).
But each revision starts at 0. Thus, you can already in the current PDFBox
always use the bytes of the whole current PDF file as {{byte[] pdfFile}}
without having to provide {{int offset, int length}}.
Concerning the other proposed API change: If one is switching from {{byte[]}}
to something else as return type of {{getSignedContent}} (or providing an
alternative method to return signed content), the more natural choice would be
a stream based result, wouldn't it?
> 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]
