Is there any way of suppressing ‘Do you want to save changes to xxx.pdf before closing’ dialog using ABCpdf

Question

We are reading the adobe form template using ABCpdf , populating form fields with values retrieved from database and amending them into a single PDF document and sending the document back as File stream in the HTTP response to the users in a ASP.net MVC App.

This approach is working fine and PDF documents are getting generated successfully. But when the user choose to open the generated PDF file and try to close it, they are being prompted ‘Do you want to save changes to xxx.pdf before closing’ dialog from Adobe Acrobat. Is there any way of suppressing this message using ABC pdf?.

Following is the code we are using to generate the PDF.

public byte[] GeneratePDF(Employee employee, String TemplatePath)
    {
        string[] FieldNames;
        Doc theDoc;
        MemoryStream MSgeneratedPDFFile = new MemoryStream();

        //Get the PDF Template and read all the form fields inside the template
        theDoc = new Doc();
        theDoc.Read(HttpContext.Current.Server.MapPath(TemplatePath));
        FieldNames = theDoc.Form.GetFieldNames();

        //Navigate through each Form field and populate employee details 
        foreach (string FieldName in FieldNames)
        {
            Field theField = theDoc.Form[FieldName];
            switch (FieldName)
            {
                case "Your_First_Name":
                    theField.Value = employee.FirstName;
                    break;
                default:
                    theField.Value = theField.Name;
                    break;
            }
            //Remove Form Fields and replace them with text
            theField.Focus();
            theDoc.Color.String = "240 240 255";
            theDoc.FillRect();
            theDoc.Rect.Height = 12;
            theDoc.Color.String = "220 0 0";
            theDoc.AddText(theField.Value);
            theDoc.Delete(theField.ID);
        }

        return theDoc.GetData();
    }

Answer 1

I ran into this problem, as well. I found a hint about "appearance streams" here:

2. The PDF contains form fields and the NeedAppearances entry in the interactive form dictionary is set to true. This means that the conforming PDF reader will generate an appearance stream where necessary for form fields in the PDF and as a result the Save button is enabled. If the NeedAppearances entry is set to false then the conforming PDF reader should not generate any new appearance streams. More information about appearance streams in PDF files and how to control them with Debenu Quick PDF Library.

So, I looked for "appearance" things in the websupergoo doc and was able to set some form properties and call a field method to get rid of the "Save changes" message. In the code sample above, it would look like this:

Edit: After exchanging emails with fast-and-helpful WebSuperGoo support about the same message after creating a PDF with AddImageHtml that WASN'T fixed by just setting the form NeedAppearances flag, I added the lines about Catalog and Atom to remove the core document NeedAppearances flag that gets set during AddImageHtml.

public byte[] GeneratePDF(Employee employee, String TemplatePath)
{
    string[] FieldNames;
    Doc theDoc;
    MemoryStream MSgeneratedPDFFile = new MemoryStream();

    //Get the PDF Template and read all the form fields inside the template
    theDoc = new Doc();
    theDoc.Read(HttpContext.Current.Server.MapPath(TemplatePath));
    FieldNames = theDoc.Form.GetFieldNames();

    //Tell PDF viewer to not create its own appearances
    theDoc.Form.NeedAppearances = false;
    //Generate appearances when needed
    theDoc.Form.GenerateAppearances = true;

    //Navigate through each Form field and populate employee details 
    foreach (string FieldName in FieldNames)
    {
        Field theField = theDoc.Form[FieldName];
        switch (FieldName)
        {
            case "Your_First_Name":
                theField.Value = employee.FirstName;
                break;
            default:
                theField.Value = theField.Name;
                break;
        }

        //Update the appearance for the field
        theField.UpdateAppearance();

        //Remove Form Fields and replace them with text
        theField.Focus();
        theDoc.Color.String = "240 240 255";
        theDoc.FillRect();
        theDoc.Rect.Height = 12;
        theDoc.Color.String = "220 0 0";
        theDoc.AddText(theField.Value);
        theDoc.Delete(theField.ID);
    }

    Catalog cat = theDoc.ObjectSoup.Catalog;
    Atom.RemoveItem(cat.Resolve(Atom.GetItem(cat.Atom, "AcroForm")), "NeedAppearances");

    return theDoc.GetData();
}

Answer 2

Today I ran into this problem too, but with a PDF with no form fields. I ran @CharlieNoTomatoes code and confirmed the FieldNames collection was definitely empty.

I stepped through the various stages of my code and found that if I saved the PDF to the file system and opened from there it was fine. Which narrowed it down to the code that took the abcpdf data stream and sent it directly to the user (I normally don't bother actually saving to disk). Found this in the WebSuperGoo docs and it suggested my server might be sending some extra rubbish in the Response causing the file to be corrupted.

Adding Response.End(); did the trick for me. The resulting PDF files no longer displayed the message.

byte[] theData = _thisPdf.Doc.GetData();
var curr = HttpContext.Current;
curr.Response.Clear();
curr.Response.ContentType = "application/pdf";
curr.Response.AddHeader("Content-Disposition", "attachment; filename=blah.pdf");
curr.Response.Charset = "UTF-8";
curr.Response.AddHeader("content-length", theData.Length.ToString());
curr.Response.BinaryWrite(theData);
curr.Response.End();