SaveToString corrupt with Image
Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: I need help - I can help
Forum Description: Problems and solutions while programming with the Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=982
Printed Date: 01 Jul 25 at 1:47AM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com
Topic: SaveToString corrupt with Image
Posted By: piehl
Subject: SaveToString corrupt with Image
Date Posted: 22 Oct 08 at 8:38AM
Hello Forum,
I m using the iSEDQuickPDF.dll 5.11 (file version 4.42.1.1) in a C# ASP WebApplication.
A generated pdf can either be saved as a file or directly displayed into the web browser.
To display a pdf into browser, I used a MemoryStream (no physical file needed!).
Unfortunatly, the SaveToStream method is only available in Delphi, so I found the following workaround:
First I invoke the method SaveToString,
afterwards following the conversation from string to byte[]
string sPdf = QuickPdfNativeMethods.SaveToString();
MemoryStream mem = new MemoryStream(System.Text.ASCIIEncoding.ASCII.GetBytes(sPdf));
This already works,
provided that no Image is placed into the document!
Using SelectImage(AddImageFromFile/String(...)); and DrawImage();
produces a corrupt stream rather a corrupt or early ending string via SaveToString();
Is this behaviour a already known?
How can I get a String (Stream) from my active document containing a Image?
Using latest version 6.02 Beta throws an exception when caling SaveToFile.
Thanks for help
Regard Torsten Piehl
|
Replies:
Posted By: Ingo
Date Posted: 23 Oct 08 at 1:17AM
Hi Torsten,
first a warm welcome here!
SaveToFile is a really main function - so i don't think that it's a problem with the version 6.02 itself. Perhaps you want to publish the relevant piece of code here - so we can have a look?
In the library section we have a dll-version 5.22, too. Perhaps you want to try it. Actually few members from this forum are working a lot on the library. Digital signing, aes-encryption and better rendering are main points. Soon we'll upload new compiled versions - so please stay tuned.
Best regards,
Ingo
|
Posted By: piehl
Date Posted: 24 Oct 08 at 6:13AM
Hello Ingo,
hello Forum
first of all, thanks for your fast reply.
The following piece of code demonstrates the problem I have.
The code is placed in a C# WebApplication and wil be invoked by clicking a LinkButton.
int docId = QuickPdfNativeMethods.NewDocument();
QuickPdfNativeMethods.SetMeasurementUnits(MeasurementUnit.Millimeters);
QuickPdfNativeMethods.SetOrigin(Origin.TopLeft);
QuickPdfNativeMethods.SetPageSize("A4 Landscape");
QuickPdfNativeMethods.DrawText(10, 10, "Hello World:");
// ** optional including image
int imgId = QuickPdfNativeMethods.AddImageFromFile(@"images\example.jpg", 0);
QuickPdfNativeMethods.SelectImage(imgId);
QuickPdfNativeMethods.DrawImage(50, 50, 113, 52);
// **
QuickPdfNativeMethods.SaveToFile(@"C:\Temp\Test.pdf")
string sPdf = QuickPdfNativeMethods.SaveToString();
Either generation without including a image
Everything works fine.
Output is a Test.pdf and a sPdf string for further Web operations
Or generation with including a image
v5.11: generates a correct Test.pdf file, but a incorrect string calling SaveToString()
v5.22: generates a correct Test.pdf file, but a incorrect string calling SaveToString()
v6.02: generates a correct Test.pdf file, throws an exception caling SaveToString()
I compared the output string with an image, against the output string without an image (v511, v522)
The following difference attract attention:
string without image:
"%PDF-1.4\n%âãÏÓ\n1 0 obj\n<<\n/Type /Pages\n/Count 1\n... ...\n>>\nstartxref\n818\n%%EOF\n"
string with image:
"%PDF-1.4\n%âãÏÓ\n1 0 obj\n<<\n/Type /Pages\n/Count 1\n... .../Image\n/Width 113\n/Height 52\n/ColorSpace /DeviceRGB\n/BitsPerComponent 8\n/Filter /DCTDecode\n>>\nstream\nÿØÿà"
- the string without an image is longer than the one with an image.
- the string with an image seems to be truncated.
I hope I gave all necessary information to reproduce or to exclude the behaviour.
Best regards
Torsten
|
Posted By: DELBEKE
Date Posted: 24 Oct 08 at 5:24PM
|
I am not an expert in C, but it seem to remember that string in C stop with the first nul char.
The data for an image file can contain null chars, perhaps it's the problem.
|
Posted By: piehl
Date Posted: 27 Oct 08 at 5:14AM
Hi DELBEKE,
you are right,
that´s my assemption too.
Thanks
|
Posted By: piehl
Date Posted: 30 Oct 08 at 9:07AM
Thats what I found out:
Review,
trying to get my PDF as a stream for displaying in C# Web Application.
Using the SaveToString method to convert the given string into a stream.
Problem, if the pdf contains an Image, the method SaveToString provides an truncated string.
More precisely,
it depends on the Image format!
Irrespective of the mode how an Image was added,
from file or from string,
you get a different behaviour depending on the Image fomat being added.
Using a bmp,
- the pdf file works fine.
- the pdf stream can be open, but the colors were decreased.
Using a jpg
- the pdf file works fine.
- the SaveToString() returns a corrupt string.
Conclusion,
SaveToFile() works fine independend of the image format.
SaveToString() can not handle jpgs and produces an unreadable pdf format.
SaveToString() can handle bmps but influences the colors of the image.
For more information,
I ll be at your command,
best regards,
Torsten
|
|