Print quality - Image control vs. ActiveX
bhammer
contains side-by-side an Access Image Control and a LeadTools ActiveX
(OCX) image control. The on-screen display quality of the same JPG
file (1600x1200) is excellent in both controls, but different when
printed or PDF'd. Printed size for both is 2-inch x 3-inch. Problem is
the Access control prints nicely (hi res), but the ActiveX control
prints at 96dpi.
I've gone through this with the LEADTools tech rep and they concluded
that Access is doing this. The ActiveX control has 200 or so
properties available including horiz and vert resolution, but each
print attempt has the same 96 dpi output. I believe Access is taking
the screen resolution, or similar, at spooling time.
My question is this--how can I alter the way Access "reads" the
ActiveX image at print time?
Brad
Access Developer
you use another Image Control to render the picture instead of an ActiveX.
My experience over the years is that creators of .OCX typically never tested
them with Access / VBA, but only with the separate Visual Basic product, and
some version(s) of C or C++, and you could not count on them working
properly -- the creators and vendors just assumed they'd work with anything
that used .OCX.
My last experience with Leadtools was in the mid-1990s, using Access 2.0,
and we had to hire a C++ programmer to create us some code we could call to
display properly using the Leadtools product. I'd have thought after the
experience they had with our project, they'd have tested future generations
with Access / VBA, but sounds as if they did not.
For more on displaying different types of image files, see
http://accdevel.tripod.com.
Larry Linson
Microsoft Office Access MVP
"bhammer" <bhamme...@gmail.com> wrote in message
news:a9c40ae1-c626-4b14...@k10g2000prh.googlegroups.com...
bhammer
The reason I'm using the OCX control is that it's faster than the Access image control when producing reports containing a few hundred images, but the printed image quality is barely acceptable (96dpi). And now I think I know why:
After some testing, I discovered that the printed output dpi (for the OCX control) is taken (by Access? or by Windows?) from the setting of the screen resolution, just like a screen capture. I determined this by setting my screen dpi to 96 and then 120 and printing jpegs of various pixel deminsions to PDF, zooming in and counting the printed "pixels" between a scaled pair lines. I counted 96 and 120 squares per inch in the OCX image no matter what the dimension of the image file was. The Access image control, on the other hand, took the pixels from the image file and fit (resized) them into the box of the image control. For example, a 1600x1200 image into a 2.7-inch tall image control produced 1200/2.7 = 444 dpi (squares of color per printed inch). So the dpi varied depending on the jpeg dimensions.
It's obviously faster to spool and print the 96dpi OCX images than the 444dpi Access images. I just wish there was a way to set the scaling of either image control to scale to, say, 200dpi as a compromise between decent quality and quicker speed. Alas! Is this not possible?
Brad
Access Developer
from all things Access" to focus on other areas of interest, but he posted
some incredibly useful (and free) controls, code, and examples. That may be
one approach.
Without using the graphic filters (see the file Images.doc from the ZIP
ImagesA2K.zip from http://accdevel.tripod.com), you can display .bmp files.
At the cost of processing each file separately (some graphics software will
allow you to run "batches"), you could resize the picture files to the DPI
(the dots per inch you are going to use on your printer) and size you wish,
and save them in .bmp format for "printed report files". That would make
your reports run faster, but, of course, you'd have to pre-process the
images (which you could possibly do at some low-usage time on your machine).
It may be "obviously faster to spool and print the 96 dpi images", but I
doubt that I have ever wanted to _print_ images at 96 dpi. To quote from a
character in a book I read, "If it's not correct, it doesn't matter how fast
it is."
Larry Linson
Microsoft Office Access MVP
"bhammer" <bhamme...@gmail.com> wrote in message
news:e2b68328-cc2e-4cb3...@glegroupsg2000goo.googlegroups.com...
bhammer
Using BMP files instead of JPGs I don't think is really an option for me, but I'll think about it. I understand that the LeadTools OCX processes the images into bitmaps anyway, I just wish I could control the output to bump-up the output dpi. The Access control puts-in too much dpi for a not-that-large image file--wasting processing time and RAM.
Regarding printing, I really don't want to print at 96dpi, but that's all the OCX can do! Using the Access control gets me better image quality, but I don't want to reduce the image dimensions due to the need to view & zoom the images in the user forms, so there is a trade-off. I'm using relatively small photos 1600x1200 already.
Brad
bhammer
I also reminded myself during testing of the fact that the Access image control overflows the memory buffer after about 50 images. So anyone out there trying to design reports with large numbers of photos, consider the LEADtools ActiveX image control. It's not free, but it works.
Brad
Access Developer
having something at his site for converting to .bmp "on the fly" and then
displaying the .bmp.
Larry Linson
Microsoft Office Access MVP
"bhammer" <bhamme...@gmail.com> wrote in message
news:087c66e8-8ea6-4c30...@glegroupsg2000goo.googlegroups.com...