<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [Patch] Skip XRef gaps in PDFDoc save methods" href="https://bugs.freedesktop.org/show_bug.cgi?id=107057#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [Patch] Skip XRef gaps in PDFDoc save methods" href="https://bugs.freedesktop.org/show_bug.cgi?id=107057">bug 107057</a> from <a class="email" href="mailto:haxtibal@posteo.de" title="Tobias Deiminger <haxtibal@posteo.de>"> Tobias Deiminger</a> <pre>(In reply to Albert Astals Cid from <a href="show_bug.cgi?id=107057#c9">comment #9</a>) > No, on save you always use DoNotTryToRecoverIfNone, it's what you're doing > with your patch code, no? Yes, that's perfectly fine, the code in saveXXX can always look like xref->getEntry(i, DoNotTryToRecoverIfNone). I meant this: If we have a different problem besides "none" during saveXXX (say "offset mismatch"), we actually do want to start recovery, is it? That's how the current patch behaves. The getEntry API is not explicit about other error scenarios. The enum for example contains no DoNotTryToRecoverIfWrongOffset. My comment was about if this is consistent and understandable for other programmers. My own answer would be "no" to consistent, and "yes" to understandable. I'm currently working on grasping XRef::readXRefUntil, only then I can provide an updated patch.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>