Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

LiveCycle Designer 8.2 Update

I wasn’t sure I could actually blog about this update due to licensing issues but hey, they just did on the LiveCyle Blog. I guess it’s all in the wording.

In particular, this 8.2.1 SP2 update resolves a nasty bug where your form would grow to multiple megabytes in size due to a processing instruction (PI) being repeated thousands of times for a particular field. The PI looks like this (though the value, ‘aped3’, may differ):

<?templateDesigner StyleID aped3?>

Thankfully, this bug doesn’t occur often but when it does, the most common symptoms are:

  1. reduced performance when working in Designer;
  2. form file bloat (into the multiple MBs); and
  3. crashes when working in Designer with the form open.

If you can’t update Designer due to your licensing agreement and you come across this bug, you’ll need to go to the XML Source and look for a processing instruction like the one quoted above. It’ll be there many, many times. Just delete all occurrences. If your form is saved as an XDP, then you can exit Designer and open it in Notepad (or some other text editor) and delete it that way as well. Then re-open it in Designer.

Updated: March 28, 2009

Posted by Stefan Cameron on March 17th, 2009
Filed under Bugs,Designer,LiveCycle
Both comments and pings are currently closed.

18 Responses to “LiveCycle Designer 8.2 Update”

  1. Patxitron on May 13th, 2009

    Hi Stefan, great blog.

    i’ve created a pdf form with LiveCycle Designer and I’m able to populate pdf form with xml data and show in the browser. I use this code (I’m working with asp and SQL Server 2005. xml is getting from a sql server database):

    response.write “<?xml version=” & Chr(34) & “1.0” & Chr(34) & ” encoding=” & Chr(34) & “ISO-8859-2″ & Chr(34) & ” ?>”
    response.write “<?xfa generator=” & Chr(34) & “XFA2_0″ & Chr(34) & ” APIVersion=” & Chr(34) & “2.2.4333.0” & Chr(34) & “?>”
    response.write “<xdp:xdp xmlns:xdp=” & Chr(34) & “” & Chr(34) & “>”
    response.write “<xfa:datasets xmlns:xfa=” & Chr(34) & “” & Chr(34) & “>”
    response.write “<xfa:data>”
    response.write “<TopmostSubform>”

    response.Write “<Name>Paul</Name>”

    response.Write “<Surname>Weller</Surname>”

    response.Write “<Band>The Jam</Band>”

    response.write “</TopmostSubform>”
    response.write “</xfa:data>”
    response.write “</xfa:datasets>”
    response.write “<pdf href=” & Chr(34) & “” & Chr(34) & ” xmlns=”& Chr(34) &”” & Chr(34) & “/>”
    response.write “</xdp:xdp>”

    It plays ok.

    Now, I want to populate the same pdf (for example) and send it to the printer but I don’t want its to be shown in the browser.

    Can you help me?


  2. Stefan Cameron on May 19th, 2009


    Nice code! When you say you want to “send it to the printer”, I assume you mean without showing it to the user. If that’s the case, then I’m quite certain you’ll run into some security measures in Acrobat/Reader that would prevent printing unless specifically requested (i.e. mouse click) by the user.

    I think the best you could do is show the PDF in the browser and somehow issue a print command to Acrobat/Reader. For instance, you could configure your form to print on the Layout:Ready event (basically, when the form shows-up, the Print dialog will be displayed so that the user can click on the Print button).

  3. sottoj on July 29th, 2009

    sc-is there a status code and how to return it to the workflow after an xdp form has been populated with data. this is a batch workflow and i want to do this in script.
    thank you

  4. Stefan Cameron on August 6th, 2009


    Please see my response in comment #10 here.

  5. Erin Klein on September 1st, 2009

    I’m still at a point where code scares me and I haven’t been successful in getting upgraded to 8.2.1 yet. So I have to fix this bug manually. I was wondering, do I just delete the line from the code, or should I delete everything in the set (for example:


  6. Erin Klein on September 1st, 2009

    Sorry — my example didn’t post with the rest of my question, so here it is again (hopefully it works this time):

  7. Stefan Cameron on September 1st, 2009

    Erin Klein,

    Your sample code still didn’t make it through. Please make sure you replace any “less-than” symbols (<) with the HTML code &lt; otherwise it won’t make it through…

  8. Erin Klein on September 2nd, 2009

    Can you tell I’m a total newbie? Hopefully the third time is the charm…

    What I’m wondering is if I only need to delete just the one line of code: “

    Or if I need to also delete any of the code around it:

    It seems like something similar to the longer code above always appears around the StyleID line, which is why I’m wondering if more than just the Style ID line is unneccessarily repeating.

    Another question: what should the reasonable file size increase be once a form is completed if the only data gathered are in text and check box formats (no graphics)? I have a 704KB form with hundreds of fields in it. When completed in Reader 8.0 with data entered into 10 fields, it’s coming in at 1.33MB. I don’t know if that’s a reasonable increase, or if it should still be smaller.

  9. Erin Klein on September 2nd, 2009

    Okay, fourth time:

    Single line: “?templateDesigner StyleID apcb2?”

    Long code:
    “edge stroke=”lowered”/”
    “color value=”255, 255, 255″/”
    “?templateDesigner StyleID apcb2?””/border”

  10. Stefan Cameron on September 11th, 2009

    Erin Klein,

    If your form file becomes very large at design-time and you see many duplicated lines that look like

    <?templateDesigner StyleID apcb2?>

    in the XML Source view, then you should delete all the duplicates except one.

    When saving the form at runtime (in PDF format) after filling it, it’s normal for the PDF to grow slightly in size because it stores lots of information (state deltas and data) related to what the user has done to/with the form.

  11. vlada on September 24th, 2009

    Hi, I have problem with populating PDF from web using XDP.

    If line in XDP is then file is open and populated with data correctly.

    if I copy the file rozhodnuti1.pdf to we server and change line in XDP to then file is open but NO populated with data.

    Do you have some ideas ot recommendation?
    I use Acrobat Reader 9.1.3

    Best Regards, Vlada

  12. vlada on September 24th, 2009

    Hi, I have problem with populating PDF from web using XDP.

    If line in XDP is <pdf href=”./rozhodnuti1.pdf” xmlns=””/> then file is open and populated with data correctly.

    if I copy the file rozhodnuti1.pdf to we server and change line in XDP to <pdf href=”” xmlns=””/> then file is open but NO populated with data.

    Do you have some ideas ot recommendation?
    I use Acrobat Reader 9.1.3

    Best Regards, Vlada

  13. Stefan Cameron on September 28th, 2009


    What I tried, with success, is this: Submit XDP data from a PDF that I was previewing in Designer, save the XDP file to a folder on my web server, move the PDF to some folder on my web server, change @href in the <pdf href=”…” …/> node in the XDP to be an absolue URL to the location of the PDF on my web server and hit the XDP in my browser. What happens for me is the referenced PDF is loaded with XDP data merged-in.

    The only difference I can think of between my situation and yours is that when you view a PDF from the web (i.e. using the PDF plug-in), you’re using Reader to view that PDF and Reader cannot import data unless the PDF is enabled to do so using LiveCycle Reader Extensions.

  14. Duane on October 6th, 2009

    Hi Stefan,

    This bug has been around for quite a while – I remember it from the Designer 7 days. It had a patched version of Designer that fixed it, but seemed to re-emerge in 8. (And naturally Adobe only released the patched version to customers who complained about this exact behavior and had a support agreement)

    For the benefit of any reading the blog, I’ll post here a perl script that we use to clean our XDP files (since in some cases we’ve found hundreds of thousands of lines of code that need to be stripped out). This leaves one instance of the tag and removes all repeated instances.

    Download perl (I use strawberry perl). Then from command line run perl <> <yourxdpname.xdp> It will create a new xdp file with a “new” prefix.

    The actual templateDesigner tags can vary (ex. “aped3” or “apcb1”) so you can just add extra if clauses for any specific tags affecting your xdp file.


    #use strict;

    use DirHandle;

    my $sourcefile = shift;
    my $outputfile = “new” . $sourcefile;

    open SOURCEFILE, “$sourcefile” or die;
    open OUTPUTFILE, “>$outputfile” or die;

    $flag = 0;
    foreach $line (<SOURCEFILE>) {
    if($line=~ /<\?templateDesigner StyleID aped2\?>\n/) {
    if($flag == 1) {
    $line=~ s/[\t]*<\?templateDesigner StyleID aped2\?>\n//gi;
    elsif($line=~ /<\?templateDesigner StyleID aped3\?>\n/) {
    if($flag == 1) {
    $line=~ s/[\t]*<\?templateDesigner StyleID aped3\?>\n//gi;
    elsif($line=~ /<\?templateDesigner StyleID apcb1\?>\n/) {
    if($flag == 1) {
    $line=~ s/[\t]*<\?templateDesigner StyleID apcb1\?>\n//gi;
    else {
    print OUTPUTFILE $line;

    close SOURCEFILE;
    close OUTPUTFILE;

    Hope that helps
    – Duane

  15. Duane on October 6th, 2009

    On the issue of XDP bloating … I’ve been coming across an issue lately where PDF size is about 500Kb, but XDP size is in the 70MB to 100MB size.

    We are not seeing any extra tags – in fact the XML Source looks identical to our other forms which only expand to about 2.5MB in XDP format (which is what we expect).

    This occurs on very limited forms. Deleting Data Connections and removing images does not help.

    Same symptoms – poor performance in Designer (sometimes it can’t even be opened on some machines), takes a long time to view XML Source, crashes Designer.

    Just wondering if anyone has experienced this, and might have ideas as to what other areas we should investigate as a possible cause.

    – Duane

  16. Stefan Cameron on October 12th, 2009


    Thanks for posting that script! I’m sure it’ll help a lot of people.

    As for the other XDP bloating issue, I’ve never heard of this outside of the processing instruction bug. If it’s not that, then large, embedded images and/or schemas could be the cause, but you say you removed all images and data connections…

    Looking inside the XDP using Notepad (or some other text editor), can you see any repeating nodes? Perhaps many processing instructions that look like “renderCache” (seeing some is normal but perhaps these are being repeated like the StyleID processing instructions)?

    Otherwise, I would encourage you to provide Adobe with these XDPs so they can be further investigated.

  17. Pieter on November 10th, 2009


    I have a similar issue but not with XDP’s. This is a PDF. My base file was 35kb. After adding numerous fillable fields and testing it many times the size grew to 13MB. If I open it in Livecycle and save it, it grows and grows.
    I’m on

    Any ideas?


  18. Stefan Cameron on November 15th, 2009


    If you can’t install the update because your support license doesn’t permit you to, then just go into XML Source view and delete all of the occurrences of the processing instruction, as I described in this post…