Hi
I'm desperately seeking knowledge on how to reformat svg images for using as button icons.
I like to use this Material Design icon:
delete-black-48dp.svg.zip (1.1 KB)
It failed when I tried to convert it with https://fmsvg.com/
Does somebody have good experience on this?
Thanks a lot!
Immanuel
Graphic Converter can open them:
SVGbutton.fmp12 (212 KB)
You can learn more about svg
I’ll write more when I get to my mini
thanks a lot!
silly question: how did you get the svg onto the layout?
When you double-click on the button object that you previously put on the layout, the button set up dialog appears. When you choose any configuration that includes and icon (at the top), a selector with the built-in svg appears. At the lower left, there is a + button. Clicking on it will open a dialog to select the svg file.
SVG only go onto buttons objects.
yeah, thanks that's all fine.
the example from AHunter3 is obviously a png/jpg-converted image with button definitions. in that case I loose all transparency.
I even understand svg code. it's just hard to find thorough information about the required headers like
<svg
version="1.2"
...
and so on. I'll complete matt's video and will see... thanks indeed for your support!
https://fmhelp.filemaker.com/docs/edition/en/svg/
This is probably as detailed as you can find.
Here is your svg icon which works. delete-black-24onepath.svg.zip (923 Bytes)
Here is the explanation. I had to rewrite that entire file because it was poorly written and not compatible with FileMaker. See below the differences with your file and the cleaned one below. I put a little image on the side so you can understand how the conflicting paths were preventing proper display as their addition was creating a fully filled image.
Yeah that's correct. Sorry, I don't have an easy / immediate solution to copying and preserving the empty space as unoccupied when brought into FileMaker.
The important feature in the rewritten file is the class "fmfill" in the path element. That controls which paths are accessible to the icon color controls in FileMaker. Adding that class to any SVG is often enough to make it work in FileMaker.
Another gotcha is the relationship between x, y, width, height and the viewbox. In the rewritten file you can see that the viewbox uses the entire width and height of the SVG. The point definitions within the path will - usually - be within those boundaries. But it's not always the case. Designers often draw outside the document boundaries when they are designing for jobs that not-going-to-the-printer.
Whoever designed the SVG icons for FileMaker decided that 24x24 was the appropriate base. That's probably a pretty sensible reminder that the icons need to be legible when they are small but it isn't a compulsory view box size.
The most common issue I've experienced with SVG that I've foraged are that FileMaker interprets path fill differently to most. SVG that look fine viewed in a browser or an editor have odd gaps and missing bits when displayed in FileMaker.
Thanks, I felt lazy to write the whole explanation. You addressed all the points. I usually prefer when the base size is the same as the viewport.
In this particular SVG, there were two paths, the outlining and the inside path. I removed the outlining since it was either forcing what looked like a coloured background or if set to "none" would become black and, in this case, if the icon colour is set to black, you get a black square instead of a bin. That way, the inside path can be coloured by FileMaker and it can be put on any colour button.
Yes, in this case there was a rendering conflict caused by the presence of the first path. Deleting the first path "fixed" it for FileMaker. It's a good example of how fragile the SVG rendering is in FileMaker and that maybe one of the reasons they restrict the use of SVG to buttons.
You are awesome! That's fantastic, thanks very much for all of your precious efforts!
I even found out that Adobe Illustrator has a function "tidy up paths" which returned good results.
Have a very nice day!
how do you handle this? I do a lot of SVG design for FM Buttonbars and I usually do 96x96 px. But since every design tool can do scaling beyond 1000% nowadays that doesn't matter in the design process. Is there any known pitfall using a certain ratio/size?
Since SVGs are vector images, they scale well to any size. The base doesn't matter that much. To @Malcolm point, 24x24 makes sure that when it's small, it doesn't just become a •. LOL
There is a consequence to using any base size. Using a small base size will favour smaller images when scaled because there is less computation to approximate the base to the new size when pixels don't align. Larger scaling will show the simplicity of the design. Using a large base size will favour larger images when scaled, because when scaled small, excess details will muddle the images.
That said… screens no longer have 72 DPI. Many now come with 200+DPI. Scaling to smaller images is less impacted because of this.
Hope this helps.
but that shouldn't relate to SVG since that format is vectorbased?!
Appart from that I look at new icons in different sizes while designing - almost always to simplify because in small scaling it would be "non-readable". Basic icons in my solutions have to work from 18x18 to 60x60 px. Most icons are published in between 24x24 and 48x48 in layouts.
All the same I do the SVG work on a 96x96px canvas.
Right. But you are talking about a design challenge, not a vector scaling challenge.
This was my reference to that idea you mentioned:
To @Malcolm point, 24x24 makes sure that when it's small, it doesn't just become a •.
It does relate to SVG. The process of displaying a vector image to screen is called rasterization. The process produces an approximation of the vector image as a pixel image. If two lines must appear where only one pixel is available, then the lines must merge. How this is done is implementation dependent… but the more shrinking is called for from a base size, the more details are lost in the process. Similarly, the less detail is contained in the base size, the more obvious the lack of details show when enlarging.
if this is true for the FM display engine I will have to rethink/change my 96x96 technique 
thank you so much
