I'm trying to decrease size of my rpt file. The problem is in image. When I remove image, file is about 50KB size large. When I add image, it increases to 600KB.
I reduced resulution of my image. It has only 12KB. I tried to use JPG, PNG, TIFF. With bigger image, size of rpt file is growing (for 200KB image it is about 2MB rpt)
Do you have any solution to this problem?
Regards,
-- Marcin Krupowicz
Hai,
Try Inserting the image as an OLE object instead of as a picture object
Related
I am trying to reduce the size of a crystal report , where in I have converted the image from PDF to BMP and then inserted as an OLE object in to the crystal report. In doing so , The color (Black and white) was still rich and the words in the image are clear.
Using CR 2008
However, The crystal report size is increased to more than 8 megs , which is a lot for the report with a single page.
I have searched online on how to reduce the size of the CR , I have found one answer where , Use photoediting tools , the image to GreyScale and add as OLE object , however in doing so , the image resolution has gradually decreased.
I am still looking for a solution where I can decrease the size of the CR to less than 3 megs with out compromising the image quality in the report.
P.S: My first question on StackOverflow. :)
Do not convert to another format because Crystal manages the image internally as bitmap.
Reduce color depth. For example, convert from full color to grayscale.
Load the rpt in Crystal and go to
File, Report Options...
And turn on the checkbox for 'Retain Original Color Depth'.
If you need to resize the image, do so outside Crystal. Resizing an image inside Crystal can cause it to consume more memory.
I only stumbled across this question as you had Reporting Services tagged (I've now removed that tag from your question). I'm no Crystal Reports person but I suspect most of the file size is in the BMP. BMPs are uncompressed so they are big, especially compare to other file formats.
You should be able to convert to a PNG or JPEG with low compression and this will reduce the size of the image considerably. Play around with different compression levels when saving to see what works best but I would start at about 90%.
If you need a free (Windows) tool where you can set the compression when saving an image, try paint.net ( https://www.getpaint.net/ ) It's completely free, open source and simple.
I've got an RTF file with an embedded image in it. The image is scaled by 2/3, or 0.67. It displays correctly in Word, but when the file is printed it consistently displays by ignoring the scale setting.
The source image is a PNG with dimensions 297x117 (pixels). The image was originally encoded as follows:
{\pict\pngblip\picw7858\pich3096\picwgoal4455\pichgoal1755\picscalex67\picscaley67
<Hex-encoded PNG image>}
The original picture width/height is calculated as (w,h) * 2.54 * 1000 / 96 (twips).
The original picture width/height goal is calculated as (w,h) * 1440 / 96 (twips).
A twip is 1/1440 inch and 2.54 is the number of centimetres in an inch.
I edited it to try setting the size manually. I multiplied all of these values by 2/3 and removed the \picscale[xy]67 instructions:
{\pict\pngblip\picw5239\pich2064\picwgoal2985\pichgoal1176
<Hex-encoded PNG image>}
However, it still seems to only use the size of the PNG (297x117) when printing it. The screen display and the print result both appear unchanged from before.
Other than manually rescaling the image and re-embedding it into the RTF, can I get the printed version to respect the scaling?
UPDATE
I did try embedding an image resized to 2/3 of the previous dimensions, but the printed image is still 50% larger than the on-screen image (the extra area gets cropped). The only difference is that it was much lower resolution.
I also tried the same image in a Word document and it printed perfectly, so it's definitely a difference between .docx and .rtf files. Is it perhaps a dpi setting in the PNG image?
Windows 10 updated itself last night, and now I can't replicate the problem. All old files that previously had this problem, no longer have this problem. Go Microsoft!
It appears to be this update that resolved the issue: https://support.microsoft.com/en-au/help/4093112/windows-10-update-kb4093112
Addresses an issue with printing content generated by ActiveX in Internet Explorer
There's no more information about this, but it is related to printing.
I'm using iText 5.5.4 for creating PDF from Java, and it's a great library.
This is not an issue or wrong behaviour. It's only a curious fact, that I'm trying to understand.
I have a three-page PDF, with header, footer, tables, etc.
Its size is 96KB.
I have added a 4th page with a 950KB JPEG image. It fits in an A4 page dimensions.
Adding 96KB + 950KB + 4th page metadata + others(header, footer) , I expected the new PDF was about 1.15MB
But the final size was 1.41MB
So, I have these two questions:
Is there anything wrong in my estimate? Why does image addition imply such overload?
If I scale the image to 75% with iText, the new resulting PDF also is 1.41MB of size. Does PDF include the original JPEG image, despite of the reduction?
I insist: the behaviour is right. It's only my own curiosity.
Thanks a lot.
EDIT: I don't have permission to share the image. My code to add an image to PDF is:
public Document addNewElement(Document input, String imageFilename) throws DocumentException {
try {
input.newPage();
Image image = Image.getInstance(path + imageFilename);
input.add(image);
} catch (MalformedURLException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
return input;
}
Scaling an image with iText doesn't reduce or increase the number of pixels of an image. The size of the image inside of the PDF is independent of the scaling factor you use. The only thing that changes is the perceived resolution. If you have a picture of 300 by 300 pixels, and you scale it to one by one inch, the resolution will be 300 dpi. If you scale it to two by two inches, the resolution will decrease, but the size of the image bytes will remain the same.
The increase of size of a PDF when you add an image depends on the type of image.
If you add a PNG file, iText will decode the PNG into pixels, create a bitmap, and add the compressed bitmap instead of the PNG, because the PDF specification doesn't have native support for PNG.
If you add a transparent image (e.g. a transparent GIF or PNG), iText will add two images: the opaque image as well as an image mask that defines the transparent parts. Why? Well, that's how transparency is defined in the PDF specification.
... (The behavior of all of the different types of images is described in one of my books. If you want to know more, I could look it up, or put it on the official web site if it's not already there somewhere.)
If you add a JPG, an exact copy of those bytes will be present in the PDF. It will be wrapped inside a stream object, causing some overhead, but no as substantial as a quarter megabyte.
Reading your question, I assume that you are adding a JPEG, but the increase of the file is much higher than you expect. We should take a look at the original PDF and your code to give a conclusive answer. I'll take one guess though. Suppose that the original PDF was compressed using the compression introduced in the PDF 1.5 specification (compressed objects + compressed XRef table), and you don't tell the stamper that you want the final result to use that compression, iText may create a PDF that only uses compression as defined in the PDF specifications prior to PDF 1.5. That cause is totally unrelated to you adding an image, but it could result in a difference of a quarter of a megabyte.
We are using Crystal report XI, have to show image on the report, right now we are able to show the images. here my problem is we are cropping the image with a fixed width and height then converting the image into binary array (one way to display images on report) in this way images are blurred. Reason to do like this is we may have big size images also for that we are cropping images. Is there any way to display images with fixed size in the report.
Note: We may have small and big images also finally we need to display with a constant size on report.
Regards,
Chakradhar.
Why don't yo store the pictures as binary in the database and save yourself the conversion when inserting them into the report? You would need a BLOB column in your database in order to be able to insert the pictures into your database. Alternatively you could insert the images as OLE objects instead of pictures and also decreasing the color depth and using the bitmap format (.bmp) will help you keep the file size down.
I am using GhostScript to convert large batches of PDF to PDF to reduce file size. The original PDFs vary in size and quality. Where there is a low quality, small file size (<350kb) PDF the output from Ghostscript is often poor.
Is there a way I can get GhostScript to ignore files below a certain size and just pass them through without downsampling?
Current settings:
SearchablePDFSetting=-dColorImageResolution=120 -dMonoImageResolution=38 -dMonoImageDownsampleType=/Average -dOptimize=true -dDownsampleColorImages=true -dDownsampleGrayImages=true -dDownsampleMonoImages=true -dUseCIEColor -dColorConversionStrategy=/sRGB -dFIXEDMEDIA -dDEVICEWIDTHPOINTS=596 -dDEVICEHEIGHTPOINTS=834
Thanks,
Vix
The pdfwrite device can already pass images (not files) through without downsampling, there is no way to 'pass through without changing' a file. If you want to not process files below a certain size, then don't process them.
To avoid further downsampling of images, you need to add the 'xxxxImageDownsampleThreshold' parameters (one each for Mono, Grey and Color). If you set this to (eg) 1.5 then images which are up to 50% higher resolution than the target resolution won't be downsampled.
Note that you haven't (apparently) set a GrayImageDownsampleResolution, you haven't set the downsample type for Color or Gray images and a MonoImageResolution of 38 looks pretty ugly to me.
The default Gray image filter is DCT (JPEG) as is the Color filter. If the original image was DCT then applying a second round of DCT compression will result in ugly artefacts, especially if the image is not downsampled. I would suggest you change the filter type to FlateEncode.
All these options are documented in ps2pdf.htm in the Ghostscript doc folder.
Add the option:
-dPDFSETTINGS=/screen
This "selects low-resolution output similar to the Acrobat Distiller 'Screen Optimized' setting."