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.

 

[Scott24x7]

tomk3 it has nothing to do with scale. I have the original image at a quality of 3000 x 3000 in EPS, entirely uncompressed. All of the smaller images are created by reducing it to whatever pixel size. The point is, the original image looks fine in the designer, but when sent to PDF, it was horrendously distorted. As I mentioned, this was mostly resolved (to a level that I care about) by changing it (the same image) from a PNG to a JPG (just a resave in Photoshop, no other alteration). The PNG however was transparent background (as the original), and the JPG of course makes that background white.
No other changes were made.

 

[Scott24x7]

Hi Chris, I kind of misspoke when I wrote the original reply regarding "But when the form is output to either a PDF or a printed file, it looks like this:" what I meant by "or a printed file", is I mean printed to a printer. I didn't try to output it to XPS, that might have been an interesting experiment.
I can go back and try it if I get time.

 

[Chris Miller]

Yes, it all seems to depend on hat PNG Photoshop creates, that VFP does not fully support somehow.

As EPS is a vector format, you needed to convert it to PNG or JPG first, perhaps it would have given better results even as PNG when keeping the large pixel resolution.
I read about the EPS format and saw a question on Stack Exchnage why it requires a ppi/dpi specification hereas SVG, another vector graphics format, does not. It does make sense to be able to rassterize it, printers, even those driven by postscript (and EPS is encapsulated postscript) will print rasterized images only. A ppi/dpi resolution won't tell the size , that's then given by the actual physical dimensions of the paper and the area within the printable area in a report, or by a resolution as you say it's 3000x3000 in your case. It's all dynamically changable anyway, if an image with a legacy density of 96dpi is displayed on screen, 96 pixels will be 1 inch on a display with 96 dpi resolution, that's right, but when you design a report, VFP or not, the size of what you design there will determine the physical size in inches (or cm/mm, whatever) anyway, and then everything needs to scale anyway and becomes overridden anyway, therefore.

If you rasterize it's making it harder to resize and then you can get artifacts as your second image shows. It would really be nice if VFP reports would support a vector graphics format, I think there may be a way to embed EPS with some OLE class that would actually forward that 1:1 to a postscript capable printer (driver) and otherwise make it a jpb for the printer driver to resterize it from the original vector format. You would get best results that way. I don't know such a control, but that would perhaps be worth looking for, even only to get a better PDF result.

In a way a font is a vector graphics format, too. In small font sizes rasterized characters are used, but for larger font sizes a font outline is defined in so called splines, sort of mathematical curves, that's why you also don't see any artifacts in any font size. But this kind of vectors (splines) are insufficient to handle any vector graphics, it's a limited format specifically adjusted for font design.

 

[Scott24x7]

Chris,
That's an interesting point. I might remake a .png without transparent background essentially not having multi-layers and see how that looks on the output.
Like I mentioned, the .JPG was a vast improvement (at least it was fundamentally "round" and not "fuzzy") and see if that turns out any better. I did try the image at both 300dpi and 72dpi (old photoshop default) but the result was the same in both cases with the transparent .png.