FileMaker Image Management – Container Field Behavior and Much More

/5 Comments/in , , , , /by

One of my clients called this week and told me his logo got inverted when printing to a PDF. Also, the PDF file size doubled. Previously it did not occur to me to check the file he received from his designer, because I wrongfully assumed the designer gave him the appropriate file. But this brings up some interesting points about what files we should use with FileMaker and how we should use them. So, I gathered some useful information. Hope this helps you with handing your images in FileMaker and FileMaker Go.

General Image Handling

There are several different ways you can show images on a FileMaker layout:

  • Container field (Insert/Picture)
  • Place image on the layout (copy and paste from another source)
  • Show from another source in a webviewer (i.e. using SuperContainer or DocuBin)

1. Container Field

Advantages:

  1. Quick and easy. You insert an image, and voila it’s right there. If you store the file as a reference only  (suggested use if you have constant access to the hard drive the files reside on and do not plan to move or delete them) you will not bloat your database;
  2. Anyone can export it from there by right-clicking on the image and choosing “Export Field Contents”;
  3. The image can be swapped out just by inserting another image;
  4. Scan directly into a container field (by using a plug-in);
  5. You can export or email the image (file) as an attachment;
  6. Images can be cropped or resized (pay attention to maintaining proportion).

Disadvantages:

  1. You cannot do too much manipulation without a plug-in;
  2. Your database file size gets large by every image you inserted (unless stored as a reference only), therefore eventually your database will get slower;
  3. Global container fields save on close, so your file must be accessed locally, if you’d like to save a change;
  4. You can’t find or sort records, so you need to set up a calc field. See Exhibit A;
  5. You can only print the image as it is on the layout.

2. Place Image on Layout: Placing an image on the layout is not generally a good idea, unless it is your logo or  layout design (i.e. you are creating a header), but even so it’s best to use a global container field in an interface table or an image table where you load the images from when your database starts. Although, I have to mention that I see image quality differences between a referenced image in a field vs. an image pasted on the layout: in my opinion, image quality of the pasted image will be superior.

3 . Web Viewer

  • Web viewers are great for images. You can show images from a website or SuperContainer. PDF (and certain image*) files can be viewed from a web viewer. PDFs can even be manipulated (zoom, next page, etc.) on Macs. Files are not stored in the FileMaker database.
  • You cannot print from the web viewer.  You can print the layout, but that’s agains, any decent designer’s instincts.
  • There’s a great article by Geoff Coffey on Scaling Images in a Web Viewer.

Instant Web Publishing

  • Container field data cannot be entered or modified from IWP.
  • Complex or layered pictures are not rendered properly.
  • SuperContainer works with IWP.

Image Management Helpers (Plug-Ins and Tools)

  • SuperContainer (File and image management. The images are NOT stored in the FileMaker database, rather stored on a file server (can be your local computer). Has the ability to upload/download, version files.
  • CNS Image (An all-round plug-in for image handling.)
  • InsideScan (Scan directly into a container field.)
  • ExifPlugIn (Get EXIF data from pictures taken with a camera.)
  • ScriptMaster (Has basic functions for cropping, rotating, watermarking, etc.)
  • Theme Library (Themes, buttons, image manipulation)

Supported Formats for Container Fields

FileMaker Pro supports the following picture, QuickTime, and sound formats (Exhibit B)

FileMaker Supported Image Formats

General Image Suggestions

Print Quality: 300 DPI CMYK or Grayscale JPG or TIFF (if you need large, good-quality photos)

Screen Quality: 75 DPI RGB or B&W

Transparency: If you plan to use transparency, FileMaker suggests using TIFF, PNG, or JPG images. FileMaker does not recommend using the PICT (.pct) format with transparency.)

Caveats: For proper image handling, QuickTime installation is suggested on Windows.

Image Resizing and Cropping

The Preview app on Mac OS X can manipulate images: you can crop, resize, even convert them to a different format (JPG, GIF, PNG, TIFF, etc.) (Exhibit C).  Some plug-ins and the Theme Library can enhance your image manipulation experience.

Image Resizing in Preview

FileMaker Go

FileMaker Go has now the following functions for container fields (Exhibit D):

  • Choose From Library
  • Take Photo  (iOS device with camera required)
  • Get Signature
  • Paste
  • Open
  • Email

Container Field Options on FileMaker Go

SuperContainer works with FileMaker Go without programming changes. Because SuperContainer thumbnail file sizes are a tiny fraction of the full-size images, they load much faster, especially over a 3G connection.

* You can view any image that your browser (Safari on Mac and Internet Explorer on Windows) supports.

 

Top 10 Suggestions If You Want To Hack At A Database Yourself – For In-house FileMaker Developers

/0 Comments/in , , , /by

All FileMaker developers start somewhere, and that place is definitely not being a certified independent developer. I started by being an in-house developer. Working in a busy environment, all you have time for is cranking out the features that your boss needs, right away. Nobody has time to think about consequences. My job was to get that report done, no matter how many calculations I had to add so I can produce the results. Or getting that extra layout in so we can show the data on a different list. All of these things add up, and eventually they make your file larger and/or slow your database down.

As an independent developer, you start from a different perspective: data and system integrity are most important. Over the last 4 years since I’ve been developing independently I have learned a lot from fellow FileMaker developers. I had learn to to rethink how I develop and incorporate planning, design, testing and other steps to my routine. It wasn’t so much reinventing the wheel so much as making it better.

One great thing about FileMaker (aside from it being agile) is that anyone can become a developer. If you feel like you have enough skills to create what you need, feel free to get started. You can purchase volume licenses with great discounts even for a small office from us. And if you get in trouble, you can always consult with us during your project or even years later, when you realize that it’s actually far from where it could be.

Here are some conventions to follow if you start on your own. These will help you greatly down the line. Follow @zerobluetech on Twitter to ask questions.

  1. Be minimalistic:

    Create what’s needed, not more but not less. A lot of times we don’t think about the effects of what we do; what’s another calculation, right? Think again. The more calculation fields you have on a layout, the slower the layout loads. We’ve all seen layouts that said “summarizing” for over minutes. This is easily avoidable by storing data in indexed fields.

  2. Break your scripts into smaller chunks.

    Don’t write scripts that would print on several pages. By the time you write it you’ll forget what the beginning was all about.

  3. Follow a naming schema.

    There are a lot of them out there, but you can certainly invent your own. Stick to it.

  4. Comment your code.

    Comment calculations, scripts and even layouts if needed. You (and others) need to know what’s what at a later time, too.

  5. Implement strict security features.

    Steven Blackwell (@filemakersecure) cannot say this enough but people are still not listening. 🙂 If you have strict control over who can access your data, you have a much better chance of avoiding disasters.

  6. Use custom menus for controlling access.

    Take away “delete all records” from all users–then you won’t have to restore thousands of records (and lose the ones that weren’t captured in the last backup).

  7. Talking about backups:

    Back up, back up, back up.  Every 30 minutes or ever hour (depending on your storage space), but at least once a day, week and month. Save clones of your working database. In case database corruption, you can export the data and get it imported to an earlier clone and you’re back in business. Compact the clones to save disk space.

  8. Do not store images in FileMaker container fields.

    Contrary to popular belief, your database will get large and clumsy over time. Use SuperContainer and now DocuBin to manage files.

  9. Stay away from a lot of graphics.

    Do not paste large images on your layouts: they will just slow your database down. Create 75 dpi PNGs if you can. They will also preserve transparency. Or put them into container fields so the dataabse will have to load them once, as opposed to on any layout. Here I’m talking about your layout design (header, buttons), not your records!

  10. Use forums, mailing lists and friends.

    Don’t spend time reinventing the wheel. Someone already did it.

Hope this will save you guys a lot of time. Had anyone broken things down into digestible chunks I certainly would’ve not spent a lot of my evenings at work recovering data other people lost accidentally or rebuilding features because my database got corrupted. Glitches can still happen and they will happen. You can, however reduce the opportunity for things going bad.

You will run into walls, we all do. But don’t be afraid. Start working on something or modify any of the FileMaker starter files.

If you need help, feel free to contact us; we provide consulting services in the New York, New Jersey area, or to any region where screen sharing apps are accepted. First hour of consulting is free.

Also, check out our services, portfolio and products.