<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Sign PDF with digital signature"
href="https://bugs.freedesktop.org/show_bug.cgi?id=99416#c50">Comment # 50</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Sign PDF with digital signature"
href="https://bugs.freedesktop.org/show_bug.cgi?id=99416">bug 99416</a>
from <span class="vcard"><a class="email" href="mailto:huj@froreich-bioscientia.de" title="Hans-Ulrich Jüttner <huj@froreich-bioscientia.de>"> <span class="fn">Hans-Ulrich Jüttner</span></a>
</span></b>
<pre>(In reply to Adrian Johnson from <a href="show_bug.cgi?id=99416#c49">comment #49</a>)
<span class="quote">> (In reply to Hans-Ulrich Jüttner from <a href="show_bug.cgi?id=99416#c48">comment #48</a>)
> > I think that re-reading a document which just has been written with poppler
> > and writing it again whithout changes should produce an identical document.
>
> Should does not mean it always will. It introduces a constraint on poppler
> that prevents any future changes that alter that assumption.
>
> I still have not seen a good explanation for why the you think the signing
> should work this way.</span >
We simply have different ideas about the in memory representation of a PDF
file.
In my opinion the bytes on disk should be reproducible from the in memory
representation whenever possible. Especially when dealing with signatures
this is desirably. If some time in the future one wants to support multiple
signatures on PDF documents with the second signature after the ByteRange
of the first one, then the first signature should not be invalidated by
writing the document with the second signature.
In your opinion the bytes on disk need not be reproducible from the in memory
representation.
<span class="quote">>
> > But with the multiple spaces in the ByteRange on disk this would not be the
> > case. Moreover, multiple spaces separating objects in PFD files are not
> > allowed by more restrictive standards like PDF/A.
>
> Then we can use '0's. But in any case we don't support PDF/A.</span >
Leading '0's on the numbers in ByteRange would be even worse. These numbers
then probably would be mistakenly read as 0 by at least some PDF software.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>