Building Font Imager
Hi, my Name's Kerri. I'm the brains behind the app you've most likely just come from and if you haven't you can find it [here]. I've called it 'Font Imager' for lack of a better name (I'm a programmer, not a product designer), but before I discuss how I built it, let me introduce you to why I built it.
Font Imager began as a solution for my boss, Tony, who was tired of browsing for sites like fa2png.io and downloading individual icon after icon in the same size and colour, he wanted a quick easy solution to get all the icons he could ever need in just a few quick seconds so he tasked me, an apprentice at the company, to come up with it. The final solution operates in a familiar wizard like fashion presenting each stage of the process step by step using floating panels and modals to convey each step to the user. The modals include narrative headers to explain and detail features of the wizard as well as a series of buttons to navigate and interact with the wizard throughout the process.
The App explained
The first step is where you decide what font you'd like to use to generate your icon set, simply click on the one you want and the wizard begins. Step 2 is the first modal, it introduces a series of form controls and a live preview of the first icon in the set. Two colour pickers will let you change the colour of the foreground (icon itself) and the background of the final icon, and two slider controls of my own devising inspired by the one seen on fa2png.io will let you change the size of the icon and the amount of space from the edge (margin) there will be between it and the icon. Pressing the 'Next' button will progress you to the third and final modal. A compact list of all the icons roughly how they'll appear in your downloaded package, each one with a little green tick in the bottom left corner representing that it has been selected for download. The user can use this panel to select any or all of the icons they want to download in their final package, downloaded by clicking the 'Download' button. Clicking off the modals will reset the wizard, along with the 'Cancel' buttons, and step 3 includes a button to take you back to the previous step. That's the app, so how did I build it?
I was maybe a little over-zealous in my ability during the planning stage, I told Tony I could get it built in 2 weeks with testing and whilst I did take just a little over that time there were various elements of my plan that immediately needed to be changed. For now I'll just say this. SVG fonts need standards. Anyway, the plan was simple:
- Get glyph data from the font's SVG file.
- Use the canvas' toDataURI function to send the images to the server.
- Use the server to package all the images sent into a .zip file and send that to the client.
So what went wrong?
Fun with fonts
I started out working just with FontAwesome. At first I tried loading it through a CDN, but this introduced the first problem, SVG files couldn't be read by the client if downloaded via a CDN due to COR (Cross-Origin-Request) restrictions, meaning I now had to store all svg files on the server. No big deal, it just makes adding new fonts a manual process and prevents me from automating it for custom font requests.
Once I got it on the server I got to work, fortunately it contained all the metadata I needed, icon offsets, unicode attributes and even glyph names! But it was one of the better fonts and I managed to get the canvas responding to it reasonably well and that was fine until I added Glyphicons Halflings. Glyphicons Halflings was not as nice, there were no glyph names and the icon offsets were all over the place, however it did have a unicode attribute. Let me reiterate, SVG fonts need standards.
At this point I went and downloaded a few other open source font sets to try including Devicons, Iconic and Weather Icons. After checking out the SVG files for all of them I found the only consistent attribute was the unicode attribute, and with that I found my solution. I quickly went back to all the font zips I'd downloaded and added in the CSS files to the server, using the unicode attribute of the glyphs I could get the canvas to render the character using the font from CSS instead of using the glyph from the SVG data itself.
Once I finally got the canvas to render several different icons from several different fonts I was happy and built a simple interface, the first panel let you pick the font you wanted and the second one would let you change the foreground, background, size and margin and then provide you with a download link. I built the interface with bootstrap and jquery to handle UI because it was quick and easy and I gave myself 2 weeks. But the app wasn't complete yet the download link didn't do anything.
Help me with this zipper would ya?
I set up the server to run using .NET MVC 5, this let me easily handle post requests and models. I set up the packaged font as a model, binding the image data and size data from the form and attempted to use the in built zip options to build a zip file from memory. Handling the images using MemoryStreams wasn't a problem but trying to get the inbuilt zip working was a nightmare, I took to google and found DotNetZip which was the solution. DotNetZip works using MemoryStreams too and I was able to get a zip working. The only problem know was that I couldn't download a file via ajax, doh!
This took a bit more time to figure out because I didn't know where I needed to look for answers, I tried to split the request up between a Get and Post request so that I could immediately redirect the Post to a Get and download the file that way, it didn't work. But after I found a few people online who had the same issues I was introduced to the 'content-disposition' HTTP header, this header let's the browser know that the request should result in a file download. Using this header I was able to append the zip file from memory, give it a name and a content-type of 'application/zip' and then I was able to dispose of everything before the request ended.
Or so I thought. I'll admit the design was crude and there was no narrative to guide you through the process but it worked. I refactored the client code first, creating a module for the packaging solution that built the canvas elements and sent the resulting image data to the server, and created a widget for my bound sliders, so called because they bound a range input control with a number input control providing the best of both. This code was reviewed and the review fortunately left me with very few things to correct, however Tony wanted the option to select which icons from the font to download. Okay, I thought, I'll just render all the icons below the control and update every time the generate button is pressed. This solution worked, there were issues with styling as the canvas element can't contain psuedo ::before or ::after elements but this was resolved by wrapping the elements in an <a> tag (I felt this was semantically best for the purpose, though a div would have worked just as well). The changes went through fine, nothing needed changing on the server and it was published to a test environment.
Upon considering it's potential for external Use Tony came back to me with some desired improvements. He took note of how the process was three steps and could better be presented through the final Wizard like interface, asked me to add some narrative to it so that a user could better understand the interface they were presented with and also wanted some company branding added in. These changes took about an afternoon to implement, most of them were further refactoring the way my IconPackager worked, now it's extensible so if I wanted to add more steps in it would be easy. Then the rest was markup. One problem that had occurred that was missed up until this point was some missing images from the color picker I had decided to use, my fault, I forgot to add them to the project in source control so they were only available on my local machine. This error resulted in my choice of color picker being questioned, but I clarified the issue and assured Tony I felt it was the best available pre-packaged tool for the job. This revision also included persisting the colour choices through cookies so that someone who frequently needs to use the same colour will be able to get it quickly without trying to remember what colour it was they'd used.
The end result of this revision is what's gone up. It appears to be performant enough for external use as well providing a much clearer interface.
Thoughts for the Future
It's possible that I will revisit this app simply because there are ways to improve the interface further (A redesign without bootstrap that's fully responsive would be nice), as well as server responsiveness. Server responsiveness could be improved by caching packages in a database allowing the users to download them faster (Right now it can take several seconds to respond which isn't ideal, though is expected).
I would also like to find a way to have users download their images by providing a .zip file of their own font, or a url to a hosted font solution but with COR restrictions and lack of hosting solution for custom zip files this is a problem for a much later day. However, if SVG fonts ever start conforming to a standard programmatically generating the glyphs without the font files could help with this solution greatly.
Thanks for the read.
https://github.com/itsjavi/bootstrap-colorpicker/ For the colour picker used.
https://bootswatch.com For the bootstrap theme (Superhero)
and http://fa2png.io for the bound slider idea and introducing the problem Font Imager solves.