Without a sample file that is "failing", I don't really have any suggestions.
You are welcome to open a formal support case with our Developer Support folks.
Without a sample file that is "failing", I don't really have any suggestions.
You are welcome to open a formal support case with our Developer Support folks.
Can you give me a link to open the case with development support please?
I'm not sure about "checking for extraneous bytes". The rules for PDF say that the very first bytes must be %PDF.
Some software actually allows a few (1024) extra bytes before that, but it is quite wrong, so if you have that, you can easily check for and programmatically fix it.
Hey ironsenth,
Is there a way where i can send you a file to validate or a simple code will do?.
My code is something like
Response.Clear();
MemoryStream ms = new MemoryStream(pdfarray);
Response.ContentType = "application/pdf";
Response.AddHeader("Content-Disposition", "attachment; filename=" sample".pdf");
Response.AddHeader("Content-Length", pdfarray.Length.ToString());
Response.Buffer = true;
ms.WriteTo(Response.OutputStream);
Response.Flush();
Response.End();
This code has nothing to do with the Acrobat SDK. It looks like something you are running on your server in an environment that I am not aware of the details of.
I would personally recommend that you write the same data that you are writing to the client to a local file and then try to open that up locally (on the server). Do you see the same error(s)?
So, have you actually looked at the first bytes of the file? What are they, as served?
Uninstall and reinstalled latest "reader" program but it continues to crash upon opening any PDF document. I've looked at similar cases, even created a dump file, but cannot send it as it appears too large. IT pros probably know what your instructions call out, but to us non-IT users, it's like reading Chinese.
Problem signature:
Problem Event Name: APPCRASH
Application Name: AcroRd32.exe
Application Version: 11.0.3.37
Application Timestamp: 518e18e3
Fault Module Name: AcroRd32.exe
Fault Module Version: 11.0.3.37
Fault Module Timestamp: 518e18e3
Exception Code: 40000015
Exception Offset: 000c6ab0
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: c37e
Additional Information 2: c37eace044c7ca1363ee7c4cfb11aae7
Additional Information 3: 85bb
Additional Information 4: 85bbf00149e67a2c3f6c3b46162b41ad
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\windows\system32\en-US\erofflps.txt
Our company has 27,266,949 .PDF files that we're planning to compress in order to save server space.
We don't want to compress any of the .PDF files that have embedded images as to not alter the image's state.
How can we programatically create a list to exclude from the compression process?
Let's start with the question:
You can use the Preflight feature of Acrobat to "separate" those PDFs with images from those without.
BUT…
What/how are you planning on compressing the PDFs that wouldn't allow you to choose a lossless form of compression (thus leaving the images alone)?
We’re having a challenge with finding any type of standards or guidelines in regards to altering medical images, whether using lossless or visually lossless, and have decided to factor those out completely (we believe only a very small percentage of the PDF files have embedded images – approx. 2 – 3 %).
Once we factor the PDF files with images, then we feel that we can compress the remainder of the files using lossy compression, to get the largest amount of compression, without risk.
We’re still trying to sort through this, so by all means, please let us know if we’re overlooking anything.
Thanks.
Are you using the Acrobat SDK (a toolkit for programmers)? If not I recommend you post in the Adobe Reader forum, and good luck!
Well, the only thing that lossy compression applies to is images – since the idea of lossy compression of text doesn't really make sense? (for example, you wouldn't want to drop a few 0's on your tax return refund amount, would you??)
So if you aren't going to deal with images, then it's all going to be lossless compression. And lossless is just that – LOSSLESS. I am not talking about visually lossless, but technically lossless. PDF supports a number of technically lossless algorithms for both text and images – such as Flate or LZW.
Ah, see told you we were new to this and no, my taxs already have enough digits to the balance.
Ok, so based on that, we should be able to use the preflighting tool to identify the PDF’s with images, factor them out, and then continue with lossless compression on the remaining balance.
That will give us the compression we need to save space, but also allow us to stand in the court of law (if the scenario was to ever occur) and proclaim that none of our medical images have ever been altered by compression.
Sound like a reasonable plan?
Sounds good to me.
Thanks man, you’ve helped to change the direction of tomorrow’s meeting for sure.
Adobe Reader xi
Hi
We are using Adobe Reader.
Regards,
Jim
Hi I have this Active reports and I’m using AcroPDF as my report viewer. Whenever I generate report using PDF file, and then clicking on the print button of the file’s toolbar, I encountered “Flattening” progress message.. And it really takes time to load. What exactly is this? How can I prevent this thing? Can I just disabled the print button only? I want to handle it programmatically if possible.
thanks
PDDoc is not available with Adobe Reader, only with Adobe Acrobat
However the PDF is being generated is adding some significant transparency to the document. Is there some sort of watermark on the page.
And the printer type you are printing to doesn't support transparency so it has to be flattened..