10 Replies Latest reply on Dec 30, 2014 7:36 PM by smith7180

    Unusual Data formatting behavior


      Once in a blue moon I encounter an image that when inserted into a container and displayed on a layout will display at a fraction of it's original size.  It doesn't matter if I choose "Enlarge image to fit" or  "Reduce image to fit" or "Crop to frame"  All yield the same "small image".  If I optimize for images it's small.  If I optimize for interactive content it's even smaller.  This happens in my database, and it happens in a blank database with just one record and one container field.  Until now every example has been an image I don't have the rights to share, but I finally found a public image on Wikipedia that does this (it's a detail of the Mona Lisa's eyes):




      Choosing "Reduce or Enlarge image to fit" solves the problem.  However I'd like to stick with reduce image to fit as images are only ever reduced in my solution, and I twice read (though I unfortunately did not write down the source in my notes) that filemaker doesn't generate storable thumbnails for containers set to "Reduce or Enlarge image to fit."


      I would love to be corrected on that fact, but even so, I'd like to know if anyone is experiencing the same issue with that image.




        • 1. Re: Unusual Data formatting behavior

          You don't say what version or platform you are using, but my test of your issue in FMAdv13 on OSX Mavericks (10.9.5) shows the same behaviour when the field is set to "Enlarge image to fit" as well as "Reduce or enlarge image to fit". This is as I expected and have experienced always. As I understand it the following summary is what happens—I have always found the last option best for most purposes:

          Crop to frame—will show only a portion of an image which is larger than the container frame

          Reduce image to fit—will reduce an image which is larger than the container frame but not affect one which is smaller

          Enlarge image to fit—will enlarge an image which is smaller than the container frame but will leave a larger image full size, thus displaying only a portion of one which is larger (same as cropping)

          Reduce or enlarge image to fit—will always display the whole image (in proportion if this is set) regardless of the size of the original image or how it is stored; in other words it will reduce a larger image OR enlarge a smaller one, whichever applies


          The other point I'd make is that these settings only apply to a specific instance of the container field, not to its contents and I don't believe they have any impact on thumbnails (which are generated to suit the setting chosen). Nor are they affected by the storage method you choose. The attached file shows five instances of the same field, with different settings chosen and your mona lisa image embedded. This shows how the settings apply to a smaller-than-the-field image; in the empty second record try inserting a large image to see the difference for the larger-than-the-field case.

          • 2. Re: Unusual Data formatting behavior

            Check the resolution of the images in question. They are probably set to higher resolution, where the images that behave as you expect are probably 72dpi. The Mona Lisa image you attached is at 300dpi. I made copy and changed the resolution to 72dpi. I then put each one into container fields set to "reduce to fit". Attached is a screen shot of the result. Same image, same pixel dimensions, different resolutions.

            300 vs 72.png

            • 3. Re: Unusual Data formatting behavior
              Stephen Huston

              Some images, including the one you provided via your link, have embedded size information. I opened this JPG in Photoshop and found that it is displaying in FMP12 at that size because it is sized at 300dpi, which displays the "print size" correctly in FMP. On the web, unless the size is specified otherwise in the HTML, browsers display images at screen resolution, making them fill a larger part of the screen in a browser than in FMP12, which honors any size settings embedded within the image itself.

              • 4. Re: Unusual Data formatting behavior

                Good points from both Todd and Stephen. For comparison, here is my file again this time with three different versions of the image:

                Record 1—the original image

                Record 2—image resized to 72dpi but not resampled

                Record 3—image resized to 72dpi and resampled

                • 5. Re: Unusual Data formatting behavior
                  Stephen Huston

                  Those all look as I would expect for the various field settings and image sizes after editing. Expected behaviors.

                  • 6. Re: Unusual Data formatting behavior

                    This really illustrated the issue- thanks Keywords for both this and your first example file. 

                    • 7. Re: Unusual Data formatting behavior

                      Thanks Stephen, wish I could give two correct answers!  Had to go with the first reply though

                      • 8. Re: Unusual Data formatting behavior

                        This was the issue. Thanks!

                        • 9. Re: Unusual Data formatting behavior

                          You could always mark Stephen's answer as helpful.

                          • 10. Re: Unusual Data formatting behavior

                            It don't get that option when I click actions.  Maybe one can only do that once a day?  Otherwise I'd mark both of yours as helpful.  Best I could do was "like".