I’ve been experimenting using the css box model approach for future layouts done in Freeway, having watched Dan’s most recent screencast which was very helpful.
What I would like to able to do is continue to incorporate a main navigation system that uses image rollovers as opposed to html, so that I can display whatever font I like. Is this achievable using inline items?
Also does anybody have any experience incorporating the use of Cufon font replacement in Freeway? If I could get that working I wouldn’t need to use image rollovers for the navigation elements.
HI,
You don’t neet to use Cufon or SiFR (both use substitution tricks to change the fonts) - there is a much simpler way of using custom fonts: embedding them using just CSS.
Just use the FontSquirel tool to change your font into a suitable kit, and the Action will help you do the rest. Remember - the EULA for the font should allow you to embed the font, whatever system you decide to use.
I guess the sprite method is the way to go but having had a brief look at the process involved, in a way it defeats the object of using Freeway - a visual user interface that generates the code for you.
With regards to Paul’s comments about font replacement, I was interested in Cufon because I’ve read it is supported by most browsers & has received a lot of positive reviews. I’ve played with it in a Wordpress theme & was pleased with the results, so I wanted to implement it with Freeway which I have just figured out how to do.
I will definitely take a look at Caxton as well. I’m also interested in Paul’s Joomla action.
What I found with font replacement technologies like SiFR is that there is a performance hit with them. It can take a little while to draw the text. Fine for headlines, but less practical for body text. It is also harder to make the rendering in Freeway get close to the final output. I spent some time trying to get SiFR working in a way that I felt comfortable with in Freeway, and I found it to be a real PITA. It needs tweaks, adjustments, and you can never get Freeway to show the text accurately enough to make any sensible design decisions.
The beauty of using embedded fonts is that firstly, you get proper WYSIWYG rendering of your pages in Freeway. Any differences between what you see in Freeway and the browser are always there, regardless of the font being used, and those differences are generally consistent.
Secondly, as the font itself (or a converted version of the font) is downloaded and used by the browser directly, there is no impact on page drawing, and this means that you can use embedded fonts for body text as well as headlines.
Thirdly - it’s just CSS and the font files. No messing around with JavaScript, Flash or other proprietary stuff to get it working. It just works.
I just felt that it’s the proper answer to the problem, and I’m happier with the Caxton Action than I was with the SiFR work I was doing. I think I’m attracted to the simplicity of the whole thing. The FontSquirrel solution also seems to work with a wide variety of browsers, so it’s a definite avenue to explore IMHO.
I downloaded ‘Caxton’ from your site & spent some time exploring the possibilities of using embedded fonts using the action, having created a font kit via Font Squirrel. Very easy to implement and proper WYSIWYG rendering as you described.
I uploaded a test page http://www.davidhutton.com/caxton/ which uses an embedded font for a heading, a strapline & some body copy which also have styles applied to them from within Freeway. I then used browsershots.org to test the page in different Windows browsers.
The results were varied but overall the anti aliasing was awful, whereas it looks great on my mac. I’m wondering whether the previews supplied by browsershots aren’t accurate but until I can test the page on a live pc running the major browsers I don’t know.
The font I used was TrueType & I included the ‘Add Hinting’ option in FontSquirrel’s generator, so not sure where the problem lies. I would really like to implement this process in some future site designs so I guess I shall just have to investigate further.
Thanks again for your advice & for creating the action.
HI,
the BIG problem is how different OSes handle rendering letterforms (or glyphs). Mac OS X render them as they are defined. If a line crosses a pixel boundary, then antialiasing is applied. This creates a more designer friendly look to the page, but it can appear slightly blurred at smaller sizes.
Windows, however, jiggles the glyph’s points around so that they fall more comfortably onto pixel boundaries. This results in less antialiasing and a potentially distorted looking letter. Your example doesn’t work well in Windows - it suffers equally badly in Firefox and Explorer.
I’d suggest trying it without the hinting option and see if that makes a difference.