Posts tagged "web fonts"

Why Does My Page Look Different In BrowserLab?

Does Your Page Look Different In BrowserLab?

In a recent blog post we covered some reasons why you might see rendering inconsistencies in BrowserLab when looking at screenshots from Internet Explorer 9.  Now let’s take a look at why you might see some cross-browser testing differences between the way BrowserLab’s screenshots display your page versus how your page looks on a local machine.  If you’ve run into a situation where the screenshot from BrowserLab doesn’t square up with what you see locally in the exact same browser, there are a few known culprits.

Resource Availability

If you’re seeing major rendering differences, such as missing images or stylesheets, make sure that the resources you are referencing in your page are available to BrowserLab.  Start by increasing the Delay setting in BrowserLab, to give the resources a little more time to load. Make sure you aren’t referencing resources that you have installed locally or are only visible from inside your network.  If you are in doubt, ask a friend who is outside your own network to take a look at your page.  If your friend can’t see the missing resources, BrowserLab won’t be able to either.  If you need BrowserLab to be able to see content inside your network, you may want to take a look at this article about Egress IPs or use one of our options for testing local content.

Screen Resolution

The screenshots you get back from BrowserLab have all been rendered on browsers sized to 1024×768. If you are looking at the page on a browser that’s sized either larger or smaller, you could see some layout differences.  Try resizing your browser to 1024×768 and reload.  The very popular Web Developer add-on for Firefox has a tool to do this easily.

Browser Chrome

This one is really an extension of the same problem described above.  If you have installed any toolbars (like the Web Developer add-on suggested above), or if you are using a browser theme that changes the size of the borders, buttons and other chrome around the browser, you may get slight changes in window size, which could make the screenshot look different.  You’re most likely to run into this if you have multiple toolbars installed and are seeing vertical sizing or spacing issues.

Different or Missing Fonts

We try to keep our browsers as close to their default installation as possible.  This also means we have not installed any fonts beyond what ships with the OS.  If you are seeing font discrepancies, this may be behind them.  Consider using Web Fonts, as described in a previous blog post.

Browser and/or System Settings

If you have changed certain default settings on any of your browsers or in your OS, then it’s possible that you may run into subtle rendering differences.  A good example of this is the ClearType font smoothing setting in Windows.  If you’ve turned off font smoothing on Windows, you may see some differences in font rendering.  But more generally, remember one of our main philosophies: to try and keep our browsers as close to a default install as possible.

Operating System Differences

Remember that font smoothing issue from above?  ClearType font smoothing is on by default in Windows XP and higher, but not in Windows 2003.   It’s not practical for us to serve screenshots from every permutation of the various browsers and operating systems that are available.  We’ve tried to provide an experience that represents what a typical user may have installed, but you may find small rendering differences between OS versions, and even OS patch levels.

 

If you are seeing screenshot discrepancies that cannot be explained by any of the above causes, we’d love to hear about them!  Consider coming over to the BrowserLab User Forum and letting us know about the problem you’re seeing.

Duane O’Brien
BrowserLab Engineer

Release 1.5.3 adds Chrome 10, IE 9 & Firefox 4 RC

BrowserLab 1.5.3 is now live!

As part of our ongoing efforts to keep the browsers in BrowserLab current and relevant, we’ve released BrowserLab v1.5.3 today.  This release added Chrome 9 and 10 (Windows), Internet Explorer 9, and Firefox 4 RC (Windows). In addition, we’ve updated Safari to 5.0.4 (OS X).

When we do these kinds of releases, we also update our browser servers to include the latest system updates and security patches. The other notable change we made was to enable Font Smoothing on our Windows Server 2003 browser servers – now all of our browser servers have Font Smoothing enabled.

Tell a friend about BrowserLab! We need your help to raise awareness. In addition to this blog, there are a few ways to stay in touch with us:
Facebook: http://www.facebook.com/browserlab
Twitter: @adobebrowserlab, @brucebowman
BrowserLab User Forums: http://forums.adobe.com/community/cslive/browserlab

Next up: we’re working on more browser updates for OS X, as well as an update for our BrowserLab for Firebug extension so it will work with Firebug 1.7. You can expect these changes to come soon.

We’d love to hear from you in the comments!

Bruce Bowman
Adobe BrowserLab product manager

Using Web Fonts with BrowserLab

Before wide browser support for the CSS @font-face rule, web pages were limited to “browser safe fonts.” This meant the designer was constrained to using fonts that were available on every visitor’s machine. @font-face allows a web designer to make typeface decisions based on aesthetics rather than availability.

All modern browsers now support web fonts, in some form. Microsoft Internet Explorer has supported @font-face since 1997 in version 4, Apple Safari implemented support in 2008 in version 3.1, Mozilla Firefox added support in 2009 in version 3.5, and Google Chrome added support in 2010 in version 6.

Adobe BrowserLab has full support for @font-face. BrowserLab can help you ensure your @font-face declarations are working across multiple browsers. By giving you the ability to quickly test your @font-face declaration across target browsers, you can move on to designing the rest of your site. Give BrowserLab a try with your web fonts enabled pages.

When using @font-face you need to be aware of supported font formats and browser specific syntax.  There is currently no universally supported web font format. Failing to provide proper font formats and browser supported CSS will result in your page rendering inconsistently across browsers.  If done incorrectly, visitors will see the browser’s default font instead of the specified font.

There are some great font services that take care of cross browser support by dynamically generating the appropriate CSS for each browser. Typekit, Webtype, WebINK, and Fonts.com are some of the services available, and all of them generally take care of hosting and licensing. Using one of these services allows the quickest path to implementation without having to know too much about the underlying technology. Typekit provides many fonts created by Adobe, and we are working together to offer more Adobe fonts in the future.

If you find yourself needing to roll your own web fonts, there are a few basics that are required to ensure your intended fonts show up on all browsers:

First, and most importantly: Ensure your font license allows you to use a font on the web. Many foundries do not permit the use of their desktop fonts on the web. For more information, check out the Adobe Type blog on this subject.

Know your font formats. There are a few different versions of web fonts in use today.

  • Embedded OpenType (.eot) – Supported by Internet Explorer only.
  • TrueType/OpenType (.ttf/.otf) – Supported by the widest range of browsers, but, not supported in Internet Explorer. (this may change in IE9)
  • Web Open Font Format  (.woff) – Supported in recent versions of Chrome, Firefox and Internet Explorer, but not yet supported in Safari.

In addition to needing to worry about licenses and multiple font formats, browsers interpret CSS code differently, so writing a rule to include your fonts is less than straightforward. “Bulletproof” syntax for @font-face has evolved over the years to work around browser inconsistencies. Much of the syntax seems repetitive and counter intuitive. For a good history of @font-face and a clear explanation of the CSS syntax read the “The New Bulletproof @Font-Face Syntax” blog post at Fontspring. Learning how the syntax has evolved gives a clearer picture of how each browser handles @font-face.

FontSquirrel is a web service that will convert fonts for you and generate CSS code.  After uploading your fonts, FontSquirrel will convert your fonts for cross browser usage and generate CSS for you. The CSS code generated by FontSquirrel also happens to work just about everywhere, including mobile devices. If you use FontSquirrel to generate web fonts, make sure you have the proper license to do so.

I hope this brief introduction to web fonts has been helpful, and that you find BrowserLab to be a useful tool in helping you test your pages with web fonts.

Shout out to Paul Irish, Christopher Slye on the Adobe Type team, and Fontspring for their help and insight on web fonts.

Charlie Scheinost
Adobe BrowserLab Software Engineer