I have a number of 300 dpi photos in my database to print certificates. Now that I've updated to FM 12 from FM 10 these images are printing very poorly. Anyone else having this issue and does anyone know what to do about it?
Check the format of the images stored in the container fields. FM has suggested that the PNG file format has best quality compatibility with 12, and there have been reports that PICT images perform badly.
This upgrade is a file format change, which may affect images as well. Past FM file format changes have actually changed compatibility with other formats before.
There are also reports that PDFs output from FM12 render images more like GIF quality that full resolution. It seems that the screen-image thumbnails are sometimes output rather than the original image quality. (When and why this may happen is not yet clear.)
One idea might be to enter Preview mode prior to printing to see if it affects the quality sent to the printer.
Another possible work around: design a layout for printing where EVERYthing is on an oversize layout at 300% of the size needed for printing, then do page/printed setup at 33% when actually outputing to print/PDF. This might cause the screen rendering of any thumbnail to produce and send higher quality DPI info to the printer.
There seem to be several image quality issues with the move to 12, and we'll either have to await updates or find work-arounds.
Thank you Stephen,
I did try a png format and didn't really help. I did do something else though that did make the image come out okay. I eliminated the container field and put the jpg file directly into the layout. This seems to work fine. It must have something to do with how FileMaker handles images in the container fields. It will be some work to replace all these, but not the worst thing that could happen.
Thanks again for the advice.
I have found image as well as text quality to be very extremely poor in FMP 12, whether printed or saved as pdf. The source material and its resolution doesn't seem to matter.
For what you can see on the layouts, PNG has always looked best to me. If you are a Windows user. Corel Draw X5 gives the best png output, especially with things like transparency, which were not always rendered properly in earlier versions of this drawing/bitmap app and similar products.
Thank you allegro, but the only thing that really seems to work it placing the image on the layout directly. I guess by the time I have all my images placed on the layouts instead of in container fields - they'll have fixed the bug. So goes life . . . but I still love FileMaker.
I think we may find that the new containers have an issue with always generating thumbnails (screen rez) when we sometimes need print quality.
You have gotten print quality instead of a thumbnail by going straight to the layout instead of a container field. However, a lot of systems have employed containers for printing graphics, and I expect to keep hearing problems regarding print quality on those.
Stephen's estimation that you're printing the thumbnail instead of the full size image would be my first guess too. I asked engineering about this, and they recommend that you disable thumbnails to see whether that changes the behavior. Click here for instructions for how to do that.
They also asked whether you might be willing to send us a copy of your database? We only need one record with a single sample image to try and reproduce the error. You can send it to me as an attachment in a private discussion if you don't want to post it here publicly (just choose New > Discussion above, and then invite "tech_liaison" to join).
Stephen also mentioned PPP (poor PICT peformance) above, and I'd like to remind everyone following this discussion that FMI announced in section 11 of the FileMaker 11 Release Notes that the PICT format would begin being deprecated starting with the next full version release - we now know that as 12.
I changed the settings on thumbnail images, but the print quality is still the same. I'm headed up to Alaska for a couple of weeks, so I don't know if I'll have time to prepare the database to send in, but I'll see what I can do. Thanks for your help.
By the way, I also noticed that it now takes a photo of 135 px from Photoshop to fill a container of 100 px in FM 12. I've been incerting 100px X 100px photos into my address book for years, but now I have to create 135px X 135px images to fill the same space.
Keep in mind that fields, as with all layout objects in FM12, are measured in Points, not pixels. Still, I would not expect the image size requirement to change in FMPro. I would expect it to change in FM Go due to the different screen resolutions of iOS devices. That was part of the reason for the pixel-to-Points change in measuring FM12 layout objects.
Dave, we're seeing this now too, and for several of our clients it's an absolute show-stopper. In one example we have a solution used by an art appraiser that generates pdf-based reports for their clients. The stored images are 300 dpi jpegs, sized much larger than used on the reports (typically 4 x 6 or 1200 x 1800 dpi displayed inside a 2.5 inch box on the page).
I've changed the settings as you recommended, but the quality difference between a report generated in FM 11 -vs- 12 is stunning. In 11 the images are very clear and you can zoom in past 200%; in 12 they're pixelated and the details are lost at 100%,
We've had them try generating the PDFs in multiple ways -- Save As PDF in FM, Print/Save as PDF in Mac OS, and Print As PDF using Acrobat as the printer. No difference in quality in any of these approaches.
Any advice? We have some pretty upset clients...
Museum Data Solutions
Fixed it on my end. Had to write a script to export all of the container fields, then reimport them. Once that was done the quality was back to full -- with the thumbnail settings toggled off.
Thanks Dave... the script idea worked fine... I just add the steps at creation of my maps, so there is no extra time consumed. Of course I wonder how it will work in FM GO on iPad... will test later as I don't have a iOS printer.
I did do some tests with thumbnail on and off... turning them off makes the biggest difference. PNG is best quality, but makes for larger files by a bunch.
I have app that makes google maps of stuff on our property. Using max quality, is over 1mb per image.
jpg at lower scale and smaller size is less than 100k. So for most screen use, and considering file sizes, I just use lower settings... when it's time to print, I up scale and run your script... takes less than 1 second to re-get the image and do the write and read back to the container.
After a more critical test suite, I really can't see the difference in exp-imp the image... the biggest diff is in no thumbnails. I saved a bunch at different settings and with PDF zoomed in to 400% so I can see the pixels... they are a perfect match in either case.
In summary, thanks to all for the suggestions, esp the thumbnail issue. I think that is the key to restoring image quality.
When you set zoom level to 400 %, FileMaker 12v2 seems to use use the containers in higher resolution when printing and saving as pdf.
I suspect this is the same result I was suggesting for the larger layout printed with a fractional page-setup. The larger screen size forces FM to create higher-rez thumbnails, which then get used in the print output.
At this point, is still feels like a work-around to get the type of print quality we used to expect automatically. I used to use FMPro to output catalog contents to PDF for sending direct to a commercial press. All of the old layouts and process for that has to be re-programmed to deal with the new screen-rez output of FMP12.
It appears that getting the actual screen-rez displayed up to a high enough level of detail for printing is the trick to use for now.
I would hope that at some point in the near future, FM will give us an option in the Inspector panel to allow setting an individual contained field on a layout to output higher-rez for print without having to change the file-wide thumbnail options. That would give us the ability to decide which fields get high-rez output at the layout level.
Retrieving data ...