Recently we discussed a problem that has cropped up in Safari 5.1 running under Lion, in which the browser will display Web pages with block-A characters instead of the desired text. We initially suggested that people check their fonts and rebuild their font caches. However, this issue shows up only in Safari and Chrome, which both use the WebKit engine, and specifically for those users who have font manager tools installed. It turns out this issue is likely a compatibility problem between how third-party font managers store fonts and a limitation in the WebKit framework that deals with the new sandboxing features in Safari and Lion.

That may seem like a mouthful, but it overall is a fairly simple idea. In order to enhance the security of Web processes, Apple has implemented new sandboxing techniques in the WebKit framework.

What is sandboxing?
Sandboxing is a method of isolating a process and the resources it has access to, in order to prevent any malicious or faulty code in it from interfering with other running processes and system resources.

Sandbox configuration in OS X is done through .sb configuration files that are set up for individual process types. These include applications, push services, the system clipboard, the system preferences, VPN services, and other system features including core technologies. In addition to centralized configuration files, some special processes defined in system frameworks (with WebKit being one of them) may have their own unique sandboxing configurations to either include or exclude specific system resources required for these processes to run in an isolated and secure mode.

When it comes to the block-A issue, the problem is that the special locations that third-party font managers use to store their font collections may differ from the locations specified in the sandbox configuration for WebKit.

OS X Font setup
OS X's font setup has some core fonts that are always active, which are located in the /System/Library/Fonts/ directory. These include Times, Helvetica, Geneva, Symbol, and other system fonts that need to be active at all times to display basic text for the system. In addition to the basic system fonts there is a font called LastResort that consists of nothing but the block-A characters seen by people experiencing this problem. This LastResort font is, as its name suggests, the font that the system will use if no substitute font can be located with which to display the text being presented. In essence, the use of this font is the system telling you that text is present and being rendered, but it has no way of showing it to you.

Besides these core fonts, OS X has two other default locations in the global library and user library folders, so there are three locations total for storing fonts in the system:

/System/Library/Fonts
/Library/Fonts
/username/Library/Fonts

What all these locations have in common is the subdirectory path /Library/Fonts, which is the path expected by the system for locating font collections. While these are the default paths, you do not necessarily need to use them for storing fonts, and can set up font collections in pretty much any folder you would like. The problem with doing this is that in order for custom paths to be used, applications will need to be aware of them. Third-party font manager tools set up these paths properly, but in Apple's new sandboxing technique, third-party font path locations may be excluded from the resources available to the sandbox.

This exclusion happens in the WebKit sandbox configuration file. As a result, if your fonts are managed by a third-party font manager tool then the system may resort to using the LastResort font instead of properly substituting fonts or showing the intended one.

How to fix it
This issue may be a bug, or it may be an intentional restriction by Apple that the developers of third-party font managers will have to contend with. For now, at any rate, if you are seeing this problem then the following options are available to try:

1. Stop using font managers
   The easiest option is to stop using your font manager. If you do not extensively work with fonts and have a font manager utility installed either as a demo or just to try out, then you might consider uninstalling the manager and disabling it. This should reset the system's font configuration to use the default font subdirectories noted above, and allow the WebKit framework sandbox configuration to properly access the fonts.

2. Consolidate fonts into the standard font locations
   If your font manager supports it, consolidate your font collections in the aforementioned default font directories, instead of having the fonts managed in separate folders. This should allow the font manager to continue functioning while still allowing the fonts to be accessed by the system and sandboxed processes.

3. Edit the WebKit sandbox configuration file
   The last option is to edit the sandbox configuration file that is not allowing access to the third-party font collection locations. Ultimately this is a fairly simple idea, but may be moderately complex to do as it requires editing a system file, and also depends on the specific directories your font manager uses.

   The WebKit sandbox configuration file is located in the WebProcess application in the WebKit framework, so to get to it you will need to follow this procedure:

   1. Go to the /System/Library/PrivateFrameworks/WebKit2.framework/ folder.

   2. Right-click (Option-click) the WebProcess application and choose "Show Package Contents."

   3. Navigate to the /Contents/Resources/ folder, and you should see a file called "com.apple.WebProcess.sb".

   

   Add these lines at this location in the WebKit sandbox configuration file, and Safari's sandboxed Web processes should now have access to the fonts.

   The com.apple.WebProcess.sb process is the sandbox configuration file, and while you can edit it directly in the current folder with some editor applications, it is best to back up the file and edit a duplicate of it. Doing this is not only safer, but allows you to edit the file with Apple's TextEdit program:

   1. Drag the file to your desktop (it should copy there).

   2. Rename the original file "com.apple.WebProcess.sb.bak" or something similar to indicate it is a backup.

   3. Right-click the file on your desktop, choose "Open With," and then open it with TextEdit.

   4. Locate the section called "Read-only preferences and data" (this should be commented with two semicolons before it), under which you should see an "(allow file-read*" line followed by a listing of paths and file pointers in parentheses that are lumped into groups like "Basic system paths," "Plugins," and "System and user preferences." You will be adding file paths to this list.

   5. Add the following entries to this list, making sure they are properly indented and look exactly as they are listed here. It does not matter where you add them in the list, but you can add them immediately after the "(allow file-read*" line to make things easier:

      (home-subpath "/FontExplorer X")
      (home-subpath "/FontExplorer X/Font Library")
      (home-subpath "/FontAgent Pro Fonts")
      (home-subpath "/Library/FontAgent Pro")
      (subpath "/Library/FontAgent Pro")

      Note that these paths are for FontExplorer X and FontAgent Pro, so if you have another font manager you should check with the developer to find out the specific paths to use, or you can attempt to guess the paths by browsing your system and checking your program's settings.

   6. Save and close the file.

   7. Copy the edited file from your Desktop to the framework folder, and authenticate when prompted.

   8. Change ownership and permissions of the file by opening the Terminal utility (in the /Applications/Utilities/ folder) and typing "sudo chown root:wheel" followed by a single space. Then drag the file you just copied to the Terminal window and press Enter, and then supply your password.

   When this is done, your fonts should now be included in the WebKit framework's sandboxed processes and Safari and Chrome should now display Web pages correctly. Do keep in mind that this fix is a bit of a crude approach, and since the WebKit sandboxing is relatively new there is a possibility it could lead to odd behavior. If you notice problems after performing these edits, you can always delete the edited file and change the backup to its original name, and that should restore all prior functionality.

For those who are more visual, here is an excellent video tutorial on how to apply similar edits to the sandbox configuration file:

Note that in the sandbox configuration file you will see a number of commented lines stating "FIXME: This should be removed when URL is fixed," followed by one or more paths to various system resources. These paths are likely included as specific workarounds for bugs and known issues referenced by the URL (an Apple internal bug tracking URL only), and since one of these paths is a home subpath for the "/Library/Fonts" directory, it indicates that there maybe be a few known issues involving WebKit sandboxing and the handling of fonts that will likely be fixed in the future.

---

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.

Originally posted at MacFixIt

Instagram is a long-time favorite photo app with users that lets you apply retro filters to your iPhone photos to turn quick mobile shots into art. It's easy to use, makes sharing photos simple and fun, and, best of all, it's free. The app has been out for quite some time and is extremely popular with users, but if you haven't had a chance to check it out, we think it's an app just about anyone can appreciate. Just beware: Instagram is addictive.

Instagram (free) requires only a couple of touches to produce great-looking images, but what's really special about Instagram are the sharing capabilities that let you tell the story of your life through photos.

Start by signing up with Instagram with an e-mail address, username, and password. From there you can configure Instagram to autopost to Facebook, Twitter, Flickr, Tumblr, Foursquare, and Posterous, or just choose to share images from within the app or via e-mail. You also have the option to turn any of these on or off if you don't want to share your shots with everyone.

Once you're all connected, you'll be able to snap a photo wherever you are, move and scale the image, add an effect with a touch of your finger, and then touch Done to share your photographic moment with the world. The app comes with several free custom-designed filters that can give your image various retro effects, a grainy black and white look, or even adjustable tilt-shift options. When you're satisfied with the look, you can add a caption along with optional geotagging, then share it right away.

Even with just the features mentioned, this free app would already be easy to recommend, but a couple of added features make it even better. Once signed up with Instagram, you can Follow other Instagram users on the Feed page, which shows recent images taken by you and your friends and lets you comment and "like" photos. Switch tabs to look at a Popular list that shows all the most popular Instagram images from all users. You also can look at a News tab, which shows the latest actions by your connected friends (liked, commented, or otherwise), so you can see what your friends are currently looking at. We think these features make Instagram an app you might look at every day, just to see what your friends are up to.

Overall, we think Instagram is an excellent way to take great-looking shots and share them with anyone. The in-app feed and news options make it a unique app for connecting with your friends across social networks. We highly recommend this app to anyone who wants to share images in fun and unique ways.

Google Chrome 13 moved today from the beta to the stable channel, delivering the new Instant Pages feature for quicker Google search results. Available to download for Windows, Mac, and Linux, Chrome 13 also comes with a long-missing print preview feature for Windows and Linux users, and location bar improvements on all platforms that let you search for sites in your history more effectively.

The pre-rendering technology that powers Instant Pages is based on Web standards, so while Google.com is likely the best-known site that uses it, the technology is available to other site developers.

Print preview had been a small but glaring hole in Chrome's feature list. Chrome stable for Mac still doesn't have the feature, which is powered by the PDF reader that comes built into Chrome. Meanwhile, the improvements to the location bar--Omnibox in Google-speak--make your history more easily searchable.

Chrome 13 stable also includes more than 5,200 improvements and bug fixes, along with 13 security fixes marked as "high" priority. Among these were a cross-origin script injection and cross-origin violation in base URI handling that netted $1,500 awards for the independent researchers who discovered them.

Chrome beta and Chrome dev are still on version 13 and version 14, respectively, although Google tends to update them to their next versions within a few days of updating the stable channel.

The Chrome browser's operating system sibling, Chrome OS, also is now on version 13 beta. Along with all the features in the current Chrome 13 beta, Google announced that it was aware of a 3G disconnection bug. The company advised rebooting the Chrome OS laptop as a workaround until a better solution had been found. The operating system also still lacks the promised offline support that was announced at Google I/O earlier this year. Offline support has been promised before the end of the summer.

Facebook has purchased digital bookmaker Push Pop Press, the companies announced today. Terms of the deal were not disclosed.

Push Pop Press made a name for itself by developing an iOS app version of former U.S. Vice President Al Gore's book "Our Choice." The application received widespread praise from critics and earned the company an Apple Design Award earlier this year.

But all that doesn't mean that Facebook will be getting into the digital-publishing business. According to Push Pop Press, Facebook is acquiring the company for its technology, which will be used in some way on the world's largest social network.

"Although Facebook isn't planning to start publishing digital books, the ideas and technology behind Push Pop Press will be integrated with Facebook, giving people even richer ways to share their stories," Push Pop Press said in a statement today. "With millions of people publishing to Facebook each day, we think it's going to be a great home for Push Pop Press."

Facebook echoed that sentiment in its own statement on the acquisition, saying Push Pop Press' co-founders, Mike Matas and Kimon Tsinteris, will be bringing some of their ideas to the social network.

"We're thrilled to confirm that we've acquired Push Pop Press, a start-up whose groundbreaking software changes the way people publish and consume digital content," a Facebook representative told CNET in an e-mailed statement. "We can't wait for co-founders Mike Matas and Kimon Tsinteris to get started, and for some of the technology, ideas, and inspiration behind Push Pop Press to become part of how millions of people connect and share with each other on Facebook."

Facebook's latest acquisition comes in the middle of what the company's co-founder, Mark Zuckerberg, called "launching season 2011." Last month, Facebook unveiled Skype video calling and group chatting. The company is also rumored to be working on a native iPad application.

Related stories:
• Facebook unveils video calling, new chat features
• Report: Facebook iPad app 'hidden' in iPhone code
• Facebook acquires file-sharing service Drop.io

Originally posted at The Digital Home