Storing graphics in container fields

[Jalz]

Hi Guys,

Just have a really quick question. I've drawn my layouts using the FileMaker tools (i.e. the rectangle lines and oval) so that it uses the minimum amount of space.(Im trying to avoid using "proper" graphics as I've been told its what slows my applications network performance down)

Once I finshed my design, I thought I'd place them in my preferences table and store them in container fields, so I then cut and pasted the objects into global fields. The problem is I "think" the cut and paste has converted my graphics into "normal" graphics instead of vectors. (Im not sure but when I go to do 400% layout my lines started to look jagged around the oval shape when Im looking at them from a container, but the original looks perfect if its not in containers)

Can anyone confirm or deny whether advise me storing graphics in container fields the way I've done will give me no more benefit than if I had created my design in photoshop. (im thinking of all those painful hours gone to waste)

Thanks

Jalz

[BrentHedden]

Unfortunatly, I beleive you are correct in your thoughts. In all the technical books, whitpapers, etc... that I've read, I've never heard of a container field keeping the vector graphic settings. That is, when you copy/paste a layout object into a container field.

[mr_vodka]

Yes Brent is correct.

FM stores the graphics as raster. I had a huge problem with this at my last company where they did everything in Illustrator and still wanted to keep the vector quality in the Database.

[Jalz]

Ah ok,

So when the Guru's (filemakermagazine) say you should try and avoid using graphics, and keep the design clean by using the filemaker native tools to create as much of the layout as possible, are they copying and pasting the "vector" graphics on each layout?

Seems like drawing the graphics in PS and storing them once in a container field in say the preferences file would be acceptably as fast as storing multiple vector graphics on say 20 layouts? Im thinking about a background image.

[BrentHedden]

More than likely, they are copying the layout objects (vector graphics) from one layout to another. Or, just copying the current layout and making changes to the copy.

I've created a solution simular to what you have done (having a "graphics" table with containers, and then referencing button graphics to these container fields). I've never experienced a slowdown with any clients.

I'm sure that they are advising against this practice if either 1) you have a really old/slow network 2)You are using high-resolution graphics 3) you have 30+ users on at the same time.

If you're using these graphics strictly as buttons/icons, I would suggest keeping the DPI and resolution of the graphics very low, or even the same as your screen (72 dpi is the norm, I beleive ). It's a waste of FM resources to have a huge graphic in a container only to shrink it down on the actual user layouts.

If you have graphics that you're actually printing, I would increase the DPI to no more than your printer can handle (most have a max of 300 DPI). It seems senseless to store a graphic at 1200 DPI, looks great on screen (very slow though), then printing it out is less than desirable, unless you have a high-quality "photo" printer.

[DarrylO]

Just my .02, but I totally agree with BH. If you're using these graphics strictly as design or interface elements, AND will not be printing them (other than in documentation), I recommend using them at 72dpi.

However, if you're building a catalog of image files, you should store only a reference to the actual file on your hard disk.