0

I want to provide PDF redaction functionality by deleting contents within rectangular area. I use code from here: iTextSharp - Crop PDF File (C#)

static void textsharpie()
    {
        string file = "C:\\testpdf.pdf";
        string oldchar = "testpdf.pdf";
        string repChar = "test.pdf";
        PdfReader reader = new PdfReader(file);
        PdfStamper stamper = new PdfStamper(reader, new FileStream(file.Replace(oldchar, repChar), FileMode.Create, FileAccess.Write));
        List<PdfCleanUpLocation> cleanUpLocations = new List<PdfCleanUpLocation>();
        cleanUpLocations.Add(new PdfCleanUpLocation(1, new iTextSharp.text.Rectangle(0f, 0f, 600f, 115f), iTextSharp.text.BaseColor.WHITE));
        PdfCleanUpProcessor cleaner = new PdfCleanUpProcessor(cleanUpLocations, stamper);
        cleaner.CleanUp();
        stamper.Close();
        reader.Close();
    }

On some PDF documents this works incorrectly by changing the coordinates of some trimmed text lines (see attached images)

Before redaction:enter image description here

After redaction: enter image description here

Has anyone else encountered this problem?

Community
  • 1
  • 1
Narek Malkhasyan
  • 1,332
  • 1
  • 12
  • 22
  • 1
    Share the PDF and we'll fix the bug in iText 7 (we might not fix such bugs in iText 5 anymore). – Bruno Lowagie Jun 15 '16 at 12:43
  • Thanks a lot for your response, please find the PDF here: https://www.dropbox.com/s/n644ufroa29m7lj/Redaction%20Sample.pdf?dl=0 . Can you please fix the bug also in iTextSharp? – Narek Malkhasyan Jun 15 '16 at 13:50
  • Nope, we only fix bugs in old versions for customers. Are you a customer? If so, contact support. – Bruno Lowagie Jun 15 '16 at 13:53
  • @Bruno *we might not fix such bugs in iText 5 anymore* - you are aware that this will very likely cause forks of itext 5 to appear with fixes for bugs like this? In particular as the cleanup functionality in iText 7 has become closed source... – mkl Jun 16 '16 at 04:15
  • @mkl people made the same threats when we moved from MPL/LGPL to AGPL. The truth is that maintaining a fork is hard work, too hard for people who don't want to pay for software. Also: any fork would need to be AGPL. If someone would want to use such a fork in a closed source environment, a commercial license with iText Software would be needed. (Last year we won a law suit against a German company that thought otherwise.) – Bruno Lowagie Jun 16 '16 at 05:41
  • @Bruno That's no threat, in particular I myself have no intention of doing so. And not merely because it means a lot of work but because iText 7.0.x indeed is a substantial improvement compared to iText 5.5.x! Still there are many projects depending on iText 5.5 which won't quickly be ported to iText 7 (if they will at all), and if already now (so short after iText 7 has been released) bug fixing in iText 5 is limited, those projects are likely to fork their own iText 5 for the fixes they need; and consequentially those projects might require others using them to also use their iText 5.5 fork. – mkl Jun 16 '16 at 08:33
  • @Narek I just applied your sample code to your sample PDF but nothing extraordinary can be observed. If this was a JIRA issue, I'd mark it *Resolved / Cannot reproduce* now. – mkl Jun 16 '16 at 11:09
  • 1
    @Narek Ok, after ***changing** your code* to actually redact an area with text content, I could reproduce your issue. Next time please supply sample data which reproduces the issue of your question as is. That been said, your issue is the iTextSharp pendant of [this issue](http://stackoverflow.com/a/35453025/1729265) of iText, and it can be resolved by fixing `PdfCleanUpContentOperator.WriteTextChunks` in iTextSharp.xtra just like explained in that answer using the equivalent iTextSharp calls. – mkl Jun 16 '16 at 12:29
  • @mkl Thank you very much, this resolved the issue – Narek Malkhasyan Jun 17 '16 at 06:24

0 Answers0