Patxitron,

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).

sottoj,

Please see my response in comment #10 here.

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

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.

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.

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

If line in XDP is <pdf href=”./rozhodnuti1.pdf” xmlns=”http://ns.adobe.com/xdp/pdf/”/> 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=”http://server.com/rozhodnuti1.pdf” xmlns=”http://ns.adobe.com/xdp/pdf/”/> 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

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 <yourperlfile.pl> <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.

#!/usr/bin/perl

#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;
}
$flag=1;
}
elsif($line=~ /<\?templateDesigner StyleID aped3\?>\n/) {
if($flag == 1) {
$line=~ s/[\t]*<\?templateDesigner StyleID aped3\?>\n//gi;
}
$flag=1;
}
elsif($line=~ /<\?templateDesigner StyleID apcb1\?>\n/) {
if($flag == 1) {
$line=~ s/[\t]*<\?templateDesigner StyleID apcb1\?>\n//gi;
}
$flag=1;
}
else {
$flag=0;
}
print OUTPUTFILE $line;
}

close SOURCEFILE;
close OUTPUTFILE;

Hope that helps
– Duane

Duane,

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.

Pieter,

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…