I need help - I can help - user copying image results in offset banded image

Print Page | Close Window

user copying image results in offset banded 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=2160
Printed Date: 29 Sep 24 at 12:31AM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: user copying image results in offset banded image

Posted By: danmh57
Subject: user copying image results in offset banded image
Date Posted: 18 Feb 12 at 5:09AM

Using 7.26 we resize an original PDF to a smaller size, add a header and footer, and serve by stream.

The original document is text based and has an image embedded in the document.

We take the original document, load it into QuickPDF, resize the original document to allow a header and footer to be placed above and below the original document, and then stream the resulting document.

The resulting PDF looks great, and prints as expected. The image is in the proper location in the document and appears correct in color and placement. No abberations.

But, when a end-user attempts to copy the embedded image, the resulting image is offset and has black borders. The original PDF document does not have this problem.

It appears that resizing the original is interferring with the origin of the resulting copied image.

Thank you for any response on this matter.

Dan

Replies:

Posted By: edvoigt
Date Posted: 18 Feb 12 at 11:59AM

Hi,

I guess, because of missing details inside the PDF.

In every image object inside a PDF there are some PDF-properties like this

/Height 720 /BitsPerComponent 8 /Subtype /Image /Width 1143

In your case there are new scaled values, because this is the source for show-size. On the other hand in the image object are real image data as stream. The most imageformats have a header, which contains some describing informations and there is the original size. So every "normal" PDF-viewer uses this both sources as base to calculate imagedata for viewing under look on zoom-value.

So I assume, that it is a problem as first of the program in which your end-user copies the embedded image. This program seems to use the original format and puts the lesser picture in it, so goes a smaller image on a black background. But, who (end-user) takes images from any assembled source (like PDF) has ever the risk, to get it not in original quality, when using a wrong tool.

What follows from this?

You may say: no errors on our side. It is a cosmetical question, coming up on wrong use of PDF. A PDF is not to be used as imagetransfercontainer. It has only the job to display or print exactly a content in given layout. For this job it is made.

But there is a possible contradiction. You may everytimes use a big image and draw it very small in PDF. All such pictures should have this end-user-problem. This has to be tested first. So it is too a question about end-users kind of copy making.

All I was writing here may be wrong. With Enfocus Browser you may get more infos and come to other conclusions.

Werner

Posted By: danmh57
Date Posted: 21 Feb 12 at 1:04AM

Thank you edvoigt. You are correct, PDF was not engineered as an image-transfer-container. We did not know our documents were being used as image sources, but have since found end users using the documents in ways we never intended. Now, it has become the defacto use, and we are left trying to find resolution to something we never intended.

Like everything we all deal with, user's are the driving force for many a late night trying to satisfy.