Problem with printed image

[Scott24x7]

Hi all,
I've run into a weird issue with an image on a form.

In the report form the image looks like this:



But when the form is output to either a PDF or a printed file, it looks like this:


The globe shaped logo looks TERRIBLE. I've tried making different sizes for the logo, different print densities, they all end up looking terrible when output.
Does anyone know why, and does anyone know a way to fix it?

 

[mjcmkrsr]

Hi,

It might be related with the file format *.BMP or *.JPG or ... and also how you store the pictures BLOB/MEMO.

Please find some demo code attached

hth

MarK

 

[Scott24x7]

Thanks Mark.
The image is fixed on the form in an image control, so is a file stored directly on disk. It's not stored in a memo or a BLOB general field.
It is a .jpg though. I'll try using something else like .PNG or .TIF and see if that fixes it.

 

[Chris Miller]

But when the form is output to either a PDF or a printed file...

1. What other "printed file" do you mean? XPS?
2. Whats the dpi of the original image file, the dpi of your display and the dpi of the output file (PDF/other)
3. What about zooming in when finally displaying the PDF/other file?

For best results you either have all dpis matching and therefore finally have 1:1 the same image resolution and size as when viewing the image 1:1 or you have vector graphic formats, like SVG. I'm not even sure it's documented what image formats can be printed with an OLE Control, as you don't use the image control in an FRX, for which formats are documented as mainly BMP, GIF, JPG, PNG but also still EMF, WMF and TIFF, where TIFF also is only an image container format with the actual image being GIF or BMP, I think. (I withhold talking about ICO or CUR formats, but they surely don't fit the need of printing a logo)

The best you can do is preprocess the image so the dpi fits especially the final file dpi, you may configure that and regarding PDF a PDF printer driver or converter should allow to configure the PDF dpi, too and even more important, whether and what compression and quality is used for images.

 

[Scott24x7]

Hi Mark and Chris,
So, I did have the DPI matching across as you mentioned. However, I was using a .PNG with transparent background. When I changed that to a .jpg with a white background, the result improved. I made a couple further modifications because the image control seemed to think the image was larger than it was (the size was 66 x 66 pixels, with 0 border, so it was oddly clipping about 4 pixels on right and bottom with the control set to "clip", and if it was set to resize of either option, it didn't look right. I padded the image out by adding 6 pixels all around it increasing the size to 78, and now it looks reasonably better. Still not quite as sharp on the form, but much much better.
I had been trying to fix this through the control, and by resizing the .PNG, it hadn't occurred to me that the transparent background would be the main culprit.
Thanks heaps.

 

[tomk3]

if you do EBV , TOPAZ has tools to upscale a photo with impressive results which may give better printouts

 

[Chris Miller]

The two posted images are jpg, can you add the original png zipped in an attachment? I'd be interested to see how this comes out. I remember VFP9 without SP a) introduced the ability to work with PNG (might also be VFP8, not 100% sure) but b) PNG alpha channel had issues at least on forms and those were fixed with VFP9 SP1.
So there is a possibility this PNG issue still has a bug within reporting.

Since on paper white means transparent (no ink, no toner, etc) it becomes unnecessary to have apha channels (transparency) in any image, unless it overlaps with another image and then I'd always prefer JPG as the older format, even though for logos PNG promises better quality with grahpical images as logos are.

Anyay, I'd like to see whether I can reproduce this and find out what's messed up.