When I released Iconic in font format it got a lot of positive feedback. However, it had one significant technical issues that kept it from being practical. The glyphs in the font had no logical assignment to Unicode characters, making the output semantically unsound. A few months back, Philip Shaw shared a much improved method for glyph assignment which I have implemented in the current version of Iconic. I thought it would be worthwhile to share that approach so that others may adopt it and that a standard can hopefully form. Read On…
When I made Iconic nearly two years ago, I was always committed to keeping it free. There are a lot of very good commercial icon sets, but I thought it was important to have a free alternative. I am unsure whether the success of Iconic was due to its design, its free model or a little of both, but the set has been downloaded hundreds of thousands of times and it being used on thousands of websites. I’m tremendously happy with how useful it has been for people. That said, the most impressive thing for me has been the willingness of complete strangers to contribute to this project. I am going to make that a lot easier now by open-sourcing the Iconic on Github. In doing so, I have high aspirations for the set moving forward. Read On…
Wigan font by Fontfabric. via TypeNeu
With embedded fonts being supported by all modern browsers in one form or another (be it EOT or @font-face), it is only a matter of time until font embedding becomes commonplace on sites catering to current generation browsers. There is a large collection of blog articles discussing the obvious ramifications of embedding commercially-licensed fonts, the inevitable rise in piracy and the equally inevitable decrease in type foundry profits. I have spent a lot of time thinking about this subject and how it relates to recent copyright
debacles conflicts. I would like to be optimistic that a proactive approach towards embedding licensed fonts is attainable and will be accepted by many of the major foundries. However, I do not think it will be happening anytime soon. Therefore, I think the more plausible solution for the immediate future, is to push for an embeddable, open source font collection. Read On…
I am a bit of a stickler about keeping my swf files as small as possible. One of the biggest hurdles I run into for keeping swf file sizes low is the embedding of fonts. There are best practices you can follow, such as using system fonts for large amounts of copy and not embedding characters that will not be used. Still, a couple fonts and/or a couple different weights and your file size is considerably higher. It was during a project where I was having this very problem when I came up with a little trick to help lower the embed size of fonts – and it is extremely easy to do.
One of the new features that fell under the radar for me was the custom anti-aliasing of fonts. The custom anti-alias feature allow you to control the thickness and sharpness of text within a text field. This feature can really be helpful for when type rendered by Flash appears blurry – something I run into quite often. During my playing around with this feature, I noticed that the thickness setting has a dramatic impact on the rendering of the type. I then came up with the idea that I could simulate the weights of a font family by changing the thickness of a textfield appropriately. For instance, if your Flash project uses three different weights (light, medium & bold), you can use one weight to simulate all three and cut your font embed size by two-thirds. This trick is very basic – just select the textfield you want to alter and, in the properties window, select the character you wish to embed then click the anti-alias dropdown and select ‘Custom Anti-Alias’.
From there, you alter the thickness to match the weight you want to achieve. The maximum range for thickness is -200 to 200. In my usage, I have noticed that the normal weight values (i.e. Medium, Heavy, Bold, etc.) equal about 75 to 100 thickness points. For example, if original font weight was Medium, a thickness value of 100 would resemble Heavy and a thickness value of 200 would resemble Bold. I experienced a much better result with increasing the thickness than decreasing it. In most instances, I will only drop the thickness to -75 as any lower begins to distort the typeface. Ultimately, this technique is all about feel and will vary from font to font. As you can expect, there is an Actionscript equivalent to the custom anti alias feature. This can be nice because you can simulate weights dynamically.
With a range of font weights this high, I had to use two fonts to cover the full range. As I mentioned before, my experience is that you can only take a font two weight up, but only one weight down. Still, one font can cover four different weights. Therefore, I used the Thin and the Bold as my base weights to generate the all other faux weights. As can be expected, the results improve the smaller the font’s point size. Helvetica is a perfect candidate for this method as it is a very uniformed typeface and has many weights. As can be assumed, other large families such as DIN, Interstate, Univers, Frutiger and Futura and perfect for this as well. I have not spent much time using this method of serifed fonts, but from the little experience I have, the results are quite similar, even with greater contrast between thicks and thins.
This easy little trick can shave quite a bit off of a swf’s file size. If you are ever in need of using many different weights from a font, I highly suggest giving this method a try, it may just make your swf lighter and its users happier.