I thought so at first too, but then saw that there is a border setting added (I think I noticed it set to 8 pixels or something similar). When I zeroed those, the border went away.
Is that what you are talking about?
Thanks, Ron. But I don't think that's what I'm referring to. If you can see the images in my post, you'll notice the gray graphic that's behind the column headers. In FM12 the graphic field containing that graphic formats properly by filling the entire field. In FM13 the graphic field is not resizing the field content to fill the entire field; instead it's displaying the content in it's original size.
it is not an autosizing issue is it?
or maintain original proportions checked on Data Formatting?
Is the field in the header section or part of it in the header? I noticed that problem in the header, when I accidentally moved a field so it overlapped the header area. It does not though occur in the main body.
OK. Thanks for all your thoughts. I managed a fix ... although I don't know exactly what was wrong. The graphic image which was populating the container field was a gradient produced in AI and then saved as a jpeg. I have multiple images like this throughout the system and they were all working except for this one image. So, I recreated out of AI and that caused the "Reduce or Enlarge Image to fit" to work like it was supposed to work.
I assume when the file was converted from 12 to 13 the image got corrupted in some way.
Thanks to all.
Just curious… is there a reason you are doing it that way, instead of using a gradient in FileMaker? My understanding is that native FM elements almost always are more efficient. And even more now, if it is an element that you use a lot in your design, if you make it part of your style, then it only has to load the info once as part of the CSS.
Great question ... and thanks for watching out for me. This solution was built before that was available, and it's VERY large. I will in the near future switch to the internal gradients.