FileMaker Pro 14 offers us an exciting new database design feature: the ability to use SVG glyphs. As described below, this is a great advancement, equal in weight to the new Script Workspace and mobile browser support, IMO. But with a measly 147 default glyphs in the FileMaker app, you are quickly going to find that you need to find or create your own custom glyphs. Here is a primer to help you get started.
GLYPHS: WHAT ARE THEY?
You may not be familiar with the word, “glyphs.” It’s come into use fairly recently in the web design world, and is sometimes used synonymously with the word “icon.” But the meaning is more subtle than that.
Setting aside, for the moment, the overall meaning of an old word that has evolved over time, let’s just say that in typographical terms, a glyph is a representation of a character in a particular font. Characters, as in “you are reading them right now.” This is important to web designers, because of the ubiquity of symbol fonts that can be referenced and used on the fly in presenting pictographic elements to the user. In fact, sites like Glyphter.com allow anyone to create their own font by browsing multiple libraries of SVGs and assigning them to alpha characters, making it possible to simply reference the font in CSS and display the glyph with the same scalability, flexibility and fidelity of any letterform. Now that you know that, you can forget it, because FileMaker doesn’t use them that way.
SVG: SCALABLE VECTOR GRAPHIC
SVG is a compact vector description that uses XML at its core to describe the image. Unlike a bitmap, which uses a pixel-by-pixel description of the image, an SVG file uses a combination of coordinates to describe the various elements of the image. SVGs can be (sometimes — see below) colored any way you want, scaled to virtually any size with no loss of detail (or creation of jagged edges) — and all of this in a way that is economical in terms of the amount of data needed to describe them to the app. Web browsers have long been able to work with SVGs, and now FileMaker Pro and FileMaker Go are?able to do the same thing, with the same fantastic benefits.
Like most standards, SVG has evolved over time, and the people and apps that create them have several options available for describing various aspects of the image. FileMaker recognizes certain parts of the SVG format and ignores others, some of which is detailed below. Depending on several factors, such as the app used to create the SVG, the intent of the person creating it (used in a font, colors locked in or variable,
SOURCES FOR SVG GLYPHS
There are many online sources available for SVG glyphs, representing a wide variety of industries and concepts. Here is a list of a few of them:
These four sites give you many thousands of options for finding icons to use in FileMaker. Note that every one of these sites has a license agreement that you should read and understand before using their icons. Of the sites listed above, I have found that Iconmonstr and Icomoon have the cleanest, most FileMaker-ready SVG glyphs. Flaticon offers a huge selection, but your downloaded files may require a certain amount of manipulation to make them ready for FMP. For example, you will probably want your button’s icon to be anchored to the upper-left corner of the button’s area, and scale according to that. You will also want to be able to color the icon according to various states (e.g. turn green when you hover over it). I downloaded several icons from various sites in order to demonstrate the differences and the amount of manipulation each might require to be FileMaker-ready. While we can expect some consistency from one file to the next when they come from the same source, I do not claim to have tried a large cross-section of the various glyphs available. You will need to do your own discovery on that.
EDITING SVG FILES
Here is a glyph representing a flashlight from iconmonstr:
And here is what it looks like under the hood (open it with any text editor – I like BBEdit for its Applescript features, but you can use anything):
<?xml version="1.0" encoding="utf-8"?> <!-- License Agreement at http://iconmonstr.com/license/ --> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="512px" height="512px" viewBox="0 0 512 512" style="enable-background:new 0 0 512 512;" xml:space="preserve"> <path id="flashlight-9" d="M253.62,96.622c0,0,0.687,27.728,2.397,94.886c0.335,13.302-2.431,26.521-8.08,38.575l-57.493,119.496 c-3.538,16.496,11.064,39.43,34.803,50.562c22.866,10.712,47.678,6.94,58.449-6.84l57.501-119.496 c5.649-12.054,13.562-22.867,23.989-31.115c52.372-40.854,74.953-58.633,74.953-58.633L253.62,96.622z M299.219,283.678 c-4.023,8.6-14.25,12.289-22.834,8.266c-8.582-4.023-12.271-14.25-8.248-22.842c4.023-8.566,14.25-12.272,22.834-8.248 C299.554,264.877,303.242,275.111,299.219,283.678z M275.463,50L462,137.426l-14.568,31.09L260.895,81.081L275.463,50z M50,329.311 c0,31.299,11.802,63.688,33.495,90.107C104.668,445.236,133.269,462,161.416,462c23.235,0,47.913-14.938,59.178-37.385 l-19.246-11.131c-18.038,32.506-55.196,32.287-69.907,9.874c-13.344-20.353-10.628-55.976,7.477-97.72 c17.267-39.849-5.7-70.041-35.775-70.041C76.471,255.598,50,279.771,50,329.311z M73.889,310.367 c3.152-15.809,12.489-32.725,29.254-32.725c14.384,0,26.387,14.25,15.557,39.212c-15.088,34.803-20.553,66.001-16.261,90.846 C79.405,380.944,67.1,344.365,73.889,310.367z"/> </svg>
As you can quickly see, this is not a lot of text, when you consider the complexity of the object being described. In fact, a bitmap version would likely take more to get the same result ? and it would not be scalable. This is a fairly typical SVG file, and it’s well formatted for FileMaker. We can easily break it down into five main parts:
- The header, which simply states that this file is based on XML.
- The source/license info.
- The DOCTYPE, which lets us know that we are dealing with an SVG, and what standard it follows.
- The SVG element, which is what we are primarily concerned with for purposes of this discussion.
- The vector graphic’s description, which is simpy a set of coordinates used to draw the graphic.
Let’s deconstruct that SVG element:
-
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
Right off the bat, we can see that more than half of this element simply describes what standard is being followed, so it can be properly interpreted. Every SVG version I have encountered is either 1.1 or 1.2. The differences are small, mostly having to do with mobile browsing.
-
x="0px" y="0px"
The top-left anchor point of the image. Usually 0 and 0.
-
width="512px" height="512px"
Okay, here’s where it gets interesting. The size parameter shown here is what you might call the “resting state” of the SVG. If you display it as-is in a web browser with no other filtering to control how it is displayed, this is the size it will be shown. However, that is as far as it goes, because otherwise, you can scale it larger or smaller with no real loss of fidelity. This is one of the two great things about SVG glyphs in FileMaker 14. These size parameters are also known as the viewport.
-
viewBox="0 0 512 512"
The viewbox is the area of the SVG that can be displayed at one time, and is made up of four parameters. In general, you should leave the first two (almost always 0 0) alone. The third and fourth parameters usually match up perfectly to the height and width parameters in the viewport. If you change the default size of the SVG, you should match the viewbox similarly, although it will still work without doing so. If you want a more nuanced understanding, check out JoniBalogna.com
-
style="enable-background:new 0 0 512 512;"
Uh… yeah. Ignore this – it’s been deprecated and only worked in Internet Explorer 10+.
-
xml:space="preserve">
I have stripped this last element off of several SVGs with no effect in FileMaker at all. It has to do with how white space is handled. For more, check http://www.xmlplease.com/xml/xmlspace/
The above is a good example of a well-behaved SVG. Now, let’s look at one of the delinquents in the collection, from flaticon.com:
So far so good, right? It looks like a nice clean arcade game icon. But unlike some icons from other sources like icomoon and iconmonstr, it won’t work so well in our FileMaker database. When we try to apply it to a button, it’s true, ill-tempered nature appears:
- The icon will be huge. Like the-amount-of-pancakes-a-sixteen-year-old-can-eat-in-one-sitting huge.
- You probably won’t be able to see the whole thing, just part of the upper left section, just like trying to see your teenager over the laundry in his room.
Left: a well-behaved icon with no issues. Right: an ill-tempered icon hiding from its responsibility.
- It will not scale, no matter how hard you argue that it should, while you slide the little scale slider back and forth. Is it even listening?
- As you drag the button’s handles, it will seem to float around in its box, taking up far too much space and contributing very little back.
Dragging the box larger only helps a little. Sound familiar?
There is a reason for all of this, and it has to do with that same SVG element we examined above. Let’s take a look at (part) of this SVG file:
<?xml version="1.0" encoding="iso-8859-1"?> <!-- Generator: Adobe Illustrator 18.1.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> <svg version="1.1" id="Capa_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 581.176 581.176" style="enable-background:new 0 0 581.176 581.176;" xml:space="preserve">
What’s missing? Easy: no “height” or “width” parameters. And this makes all the difference. It doesn’t matter very much what those parameters are – but it matters a whole lot if they are entirely missing. You may have noticed that the graphic for the Pac Man icon was rather large in your browser. Let’s add a size parameter and display it again:
<?xml version="1.0" encoding="iso-8859-1"?> <!-- Generator: Adobe Illustrator 18.1.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> <svg version="1.1" id="Capa_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" height="256px" width="256px" viewBox="0 0 581.176 581.176" style="enable-background:new 0 0 581.176 581.176;" xml:space="preserve">
To be fair, this manipulation is not really necessary to control the size in a browser; there are CSS filters that can be applied in the web code to scale, color, and otherwise manipulate the glyph. However, FileMaker does require it. Here’s what it now looks like in FileMaker:
At last, the surly glyph has decided to join the real world. Well done, Pac Man!
COLOR
You may have noticed that the examples from the FileMaker file have a unique color. That’s because I selected a color for the “normal” state for the glyph. This is the second great thing about SVG glyphs: you can apply custom fills to each of the button’s states. No more popping into Photoshop or Graphic Converter to create a different color version for each state. This gives you, the designer, more room to try different color schemes.
Not every SVG glyph can be handled this way. If a fill is specifically called out within the SVG file, it will be respected by FileMaker in lieu of any styling you attempt to apply. This is another scenario in which you may have to edit the SVG file, and it’s still super easy. Below is an SVG with a color value (black) already specified, followed by its entire text translation.
<?xml version="1.0" encoding="utf-8"?> <!-- Generated by IcoMoon.io --> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="32" height="32" viewBox="0 0 32 32"> <path fill="#000000" d="M31.604 4.203c-3.461-2.623-8.787-4.189-14.247-4.189-6.754 0-12.257 2.358-15.099 6.469-1.335 1.931-2.073 4.217-2.194 6.796-0.108 2.296 0.278 4.835 1.146 7.567 2.965-8.887 11.244-15.847 20.79-15.847 0 0-8.932 2.351-14.548 9.631-0.003 0.004-0.078 0.097-0.207 0.272-1.128 1.509-2.111 3.224-2.846 5.166-1.246 2.963-2.4 7.030-2.4 11.931h4c0 0-0.607-3.819 0.449-8.212 1.747 0.236 3.308 0.353 4.714 0.353 3.677 0 6.293-0.796 8.231-2.504 1.736-1.531 2.694-3.587 3.707-5.764 1.548-3.325 3.302-7.094 8.395-10.005 0.292-0.167 0.48-0.468 0.502-0.804s-0.126-0.659-0.394-0.862z"></path> </svg>
This time, instead of looking at the SVG element, we are going to take a look at the actual description of the vector graphic itself. Every part of an SVG image begins with a type of shape: stroke, rectangle, circle, ellipse, polyline, polygon, or path. In this case, it’s path, and the very next thing described is the fill, which is specified as #000000, the hexadecimal value for black. By simply removing this value altogether, we get an image that can be filled with any color we want.
<path d="M31.604 4.203c-3. <etc.>...
Left: SVG with hard-coded fill for the path. Right: the same SVG with the fill excised, and custom color applied in FileMaker.
In this article, I have introduced some of the basic concepts of fine-tuning SVGs for FileMaker Pro. I did not cover how you interact with them in the actual FMP interface, because there is plenty of documentation on that. In the future, I hope to add more info on manipulating and using glyphs in FileMaker. Which brings me to: do you have a favorite source for SVG icons? Fill us in in the comments. Enjoy!
(Database Design)
