How much of a letter can be removed while maintaining readability?

How much of a letter can be removed while maintaining readability? Ecofont have a solution that uses up to 20% less ink. It works reasonably well so long as your expectations are kept within reasonable boundaries. Ecofont is compatible with Mac OS X, Windows, and Linux, and works just fine in OpenOffice, AppleWorks, and MS Office 2007.

The holes are not visible to the naked eye when you use it at the normal point size e.g. 10 or 12. Here is an example of it at size 12.

So, it’s not perfect and similar results may be obtainable by tweaking your printers settings… Ecofont is probably designed with ink gain in mind. Those tiny holes will fill up once the ink soaks into the paper. Question is, how will it act on coated stock, or when dry toner is used instead of ink?

Free to download, free to use.

So go get it and help save a tree. Or two.

SharePoint Event ID: 5139 WAS 503 woes

I struggled GREATLY with an error recently. IIS 7 failed with a 503 on request and the event log had the following entry.

Log Name: System
Source: Microsoft-Windows-WAS
Date: xx/yy/zz
Event ID: 5139

I have not fully discerned the problem but a fix was possible.

Disable IP6 functionality

There was an entry in the hosts file that looked like “fe80::98er:3968:5b73:2978 ServerName # Added by Office SharePoint Server Search” which needed to be removed.

With IP6 disabled it will not come back. If your farm, like mine, was down you need to disconnect and reconnect all boxes AFTER disabling IP6. This was rather painful as it was late in the AM when an Index server, the culprit with IP6, was attached to the farm.

I hope it is of help to somebody.

How to enable anonymous access for your SharePoint sites

  1. From Central Administration > Application Management > Application Security > Authentication Providers, select a Web application and the zone you want to modify. This is usually default.

  2. In the middle of the page, check Enable Anonymous Access and choose Save

  3. All site collections in that Web application can now have anonymous access enabled.

  4. Go to a site collection in the Web application you just enabled anonymous access for

  5. From Site Actions > Site Settings, open Advanced Permissions

  6. From the Settings drop-down menu, select Anonymous Access

  7. For this example, enable anonymous access for Lists and Libraries and click OK

  8. Browse to any document library in this site collection

  9. From the Settings drop-down menu, select Document Library Settings

  10. In the Permissions and Management column, select Permissions for this document library

  11. From the Actions menu, select Edit Permissions to break inheritance

  12. From the newly appeared Settings drop-down menu, select Anonymous Access

  13. Check View Items and click OK.

PDF Document Type Icon in MOSS

PDF Document Type Icon in MOSS

MOSS doesn’t install an icon for PDF files by default. It simply shows a generic white paper icon.
This is my procedure for fixing this issue:

  1. Download an appropriate icon for pdf document types.
    1. This is the icon from Adobe.
    2. Save to TEMPLATEIMAGES directory. (DEFAULT: C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12templateimages)
  2. Open the file docicon.xml. (DEFAULT: C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12templatexmldocicon.xml)
  3. Add a new Mapping element to the ByExtension element.
    NOTE: Be sure to change pdficon_small.gif to whatever image you downloaded to represent pdf documents.
  4. Save the edited docicon.xml file.
  5. Restart IIS (iisreset /noforce).

You should now see the PDF icons for

How solution deployment has changed development with SharePoint technologies


Anyone who is familiar with development & deployment of custom solutions on SharePoint Portal Server 2003 or Windows SharePoint Services will probably agree when I say there are certain areas lacking in the end to end process.

For example, here is a high level generic step by step process that usually happens:

  1. Spec written (some people seem to think this step is optional)
  2. Developer develops code etc… Usually on a stand-alone, single server SharePoint environment. (I personally use a VPC for all development these days)
  3. Developer packages code into an installer if you are lucky
  4. Testing
  5. Hand off to production people who go and install it on the server(s).

This would normally be really easy right? Well, in SharePoint land there are many areas where “things” need to be done during an installation. Some of these are (but not limited to):

  • Assembly deployment. GAC or BIN
  • Web.config changes. Additions to the safe controls list, CAS security policies,
  • Resource files like images,
  • Dwp files
  • Site definitions (list definitions etc…)

Depending on how your development team packaged these would depend on how much work you had to do to deploy them.

To make matters worse, depending on your physical SharePoint farm you might need to do install steps on each server. This brought in complexity around what servers had what versions at what time etc… A nightmare if you were managing a large farm with many servers.

How we make this better in MOSS and WSSv3:

In MOSS we have a good solution to all of this called the Solution Framework. Here is a little summary about what this is:

“The Windows SharePoint Services (WSS) solution framework provides a way to bundle together all of the components for extending SharePoint in a new file called a solution file (a CAB-based format with a WSP extension). A solution is a deployable, reusable package that can contain a set of features and site definitions, templates, Web Parts, and assemblies that you can apply to a site, and individually enable or disable.” – WSS SDK

Not only this but the Solution Framework takes care of deploying the solution to ALL front end web servers in the farm without the admin having to go to each box to do this manually!

You can:

  • Deploy the Solution package to the farm
  • Retract the Solutions package
  • When a new web server is added, automatically deploy the solution to it
  • Deploy new versions of the Solution

Practical example:

In the system I talked about in “Application Development on MOSS & WSSv3” we are using a Solution package to deploy:

  • A custom Site Definition
  • 6 Feature Definitions (another new MOSS technology) that are:
    • Custom Workflows x2
    • Timer Job
    • Content Type
    • Custom List definition
    • Custom Site Columns definition
  • Web part
    • SafeControls list entry

Note: I won’t talk about Features or how to create them; Todd has a good post on that subject here:

[Updated] This means when we want to deploy this solution to a new farm we simply use the STSADM -addsolution -filename to upload the solution to the farm. Once uploaded you can simply to into the “Solution management” section under the “Operations” tab in the Central Administration Site, and deploy that solution.

Once it is uploaded we can then choose to Deploy that solution.

This gives you options on when you want the deployment to take place and to what web applications. (In the shot above I had an assembly being deployed to the GAC, hence the warning)

Although all this will be/is documented in the WSS SDK, I thought I quickly go over how to make a solution file.

Consists of:

  • A CAB file containing
    • A Manifest.xml file
    • All the files for the Features etc… that make up your solution

Below is a cut down sample XML manifest.xml file for the example I used above (highlighted text is comments):

< ?xml version="1.0" encoding="utf-8" ?>
< xmlns="" solutionid="{79d1a62e-3627-11db-963e-00e08161165f}" resetwebserver="TRUE">

< deploymenttarget="GlobalAssemblyCache" location="Foo.Sharepoint.WebpartsFoo.SharePoint.WebParts.dll">
< assembly="Foo.Sharepoint.Webparts, Version=, Culture=Neutral, PublicKeyToken=63cce650e8605f5d" namespace="Foo.Sharepoint.Webparts" typename="*">
< /SafeControls>
< /Assembly>
< deploymenttarget="GlobalAssemblyCache" location="Foo.Sharepoint.Timer/Foo.Sharepoint.Timer.dll">
< /Assemblies>


< location="Foo.Sharepoint.TimerFeature.xml">

< location="Foo.CustomTypeFeature.xml">

< location="Foo.FooLibraryFeature.xml">

< location="Foo.ColumnsFeature.xml">

< location="Foo.Workflow.ProcessFooFeature.xml">

< location="Foo.Workflow.ProvisionFooFeature.xml">

< /FeatureManifests>

< location="FOO">
< location="1033XMLWEBTEMPFoo.XML">
< /SiteDefinitionManifest>
< /SiteDefinitionManifests>
< /Solution>

Then you package this up along with all your Feature files into a CAB file with a “.wsp” extension. In short each feature goes into a sub-dir in the CAB that matches the path you have in the Manifest.xml file. You can use cabmake.exe to do this, or any other tool you like.

Then you are ready to go and deploy!

Although this is probably a little more work to begin with, your deployment team will thank you for it immensely.

Installing OS 10.5 Leopard with a firewire drive and a DMG

Preface: I use my Macs for Photoshop, which I need frequently for image manipulation/creation beyond the abilities of GIMP . I also find CSS work in general easier with the Mac and accessing /editing content in SharePoint / MOSS folders is actually pretty easy so creating custom Master pages etc is a relatively smooth process.

The problem: I experienced an AWFUL lot of difficulty in getting to a functional version of 10.5 on my iMac G5 recently. Why? Because I made a DMG of the install disk and promptly lost the original. Duh. These are the steps I took to install from the DMG. Hopefully somebody will find this if they need it and avoid the pain I had.

  1. Restore the DMG to a partition on the Firewire drive.
  2. Copy OSInstall.mpkg to another location.
  3. XAR the copied OSInstall.mpkg and BBEdit the Distribution file inside.
  4. XAR it back and overwrite the original on the Firewire drive.
  5. Change boot drive and install.

First of all, just like anything I do with STSADM, put it all in a text file. That way you can just cut and paste and save yourself a fair amount of time and agravation when needed.

1: Restoring to the Firewire drive

  1. Open Disk Utility application from Applications -> Utilities.
  2. Click on the Restore tab.
  3. Drag the DMG file “Source” field or browse to it.
  4. Drag the icon of the partition (from the left pane) you want to put the installer on to the “Destination” field.
  5. Check the “Erase Destination” check box.
  6. To be safe check the Checksum box.
  7. Click Restore.
  8. Wait.

If you get device busy errors or something else just reboot and try again. Should take about 10 minutes (depending on your hardware.)

2: Getting XAR

  1. Download xar (tar and gz file).
  2. Expand the tar.gz file and open terminal and cd into its directory.
  3. Issue the folowing commands, pressing Return between each one and then waiting for its completion (Developer Tools required):
    $ ./configure
    $ make
    $ sudo make install
  4. Check that the install is in the right location (/usr » local » bin » xar) by issuing which xar; it should return the aforementioned location.

Now here is where the first handbasket from hell appeared. MAKE errored out with the following

ld: Undefined symbols:
/usr/bin/libtool: internal link edit command failed
make: *** [lib/librxar.1.dylib] Error 1

This is a specific issue with XAR 1.52.

The Fix: 1.5.2 seems to be missing the #define xar from lib/archive.c:

#define xmlDictCleanup() /* function doesn’t exist in older API */

Save yourself some pain and add that code in blue above in. MAKE should work just fine now.

3: Working with OSInstall.mpkg: Do this if you need to force the installer to bypass some checks such as for older hardware. The risk is yours if you do as they say…

  1. Copy the OSInstall.mpkg to the desktop. For 10.5, the package we need is in /System » Installation » Packages/ folder on the drive with 10.5.
  2. Go into Terminal and cd to the folder you put the mpkg in, then issue the following command to decompress the mpkg to the folder:
    $ /usr/local/bin/./xar -x -f OSInstall.mpkg
  3. Go into the OSInstall folder, and you’ll see a Distribution file and Packages folder.
  4. Open the Distribution file in a text editor, for example I use BBEdit. It’s an xml script, so you can just edit it. Look for minRam and the processor speed requirments, and change these, and any other options which could prevent install on your setup. Save the changes.
  5. Issue the following command to compress the files back into xar’d mpkg file:
    $ /usr/local/bin/./xar -c -f OSInstall.mpkg *.
  6. The OSInstall folder should now have a new OSInstall.mpkg file in it. We then need to copy this new file into /System » Installation » Packages folder on the drive with 10.5. Firstly I’d rename the existing OSInstall.mpkg so we have a copy of it, so cd into the /System » Installation » Packages folder on the drive with 10.5, and issue the following command in Terminal:
    $ sudo mv OSInstall.mpkg OSInstall_orig.mpkg
  7. We then need to copy over the new package, so issue the following command in Terminal:
    sudo rm "/Volumes/Mac OS X Install DVD/System/Installation/Packages/OSInstall.mpkg"
    sudo mv OSInstall.mpkg "/Volumes/Mac OS X Install DVD/System/Installation/Packages/"

4: Change the Startup Disk

Now that all remains is to go into the Startup Disk preference pane and select the drive you copied/restored 10.5 to, boot from that drive, and you should then be able to install without issues.

This may be useful too:

Will Office 14 be ready for release in 2009?

In late July it was suggested that Office 14, the codename for the successor to Office 2007, would be released in either late 2009 or early 2010. This led to speculation that the next version of Office would be simultaneously released with Windows 7, much like Office 2007 and Vista were.

Blogger Stephen Chapman recently posted a screenshot he obtained in July 2008, suggesting that Office 2009 would indeed be released this year:

However, this information is now outdated, and Microsoft still has not started the Office 14 beta program. Most Windows 7 testers may not have received any builds as of yet, but select testers have, many builds have already leaked, and a public beta is supposed to be released very soon (at latest Friday).

On the other hand, Office 14 does not even have leaked screenshots yet, let alone a private or public beta. For this reason, I find it doubtful that Office 14 will be released simultaneously with Windows 7, especially given how quickly development for Vista’s successor seems to be going. Nevertheless, the beta program for an office suite can be much shorter than that of an operating system, so there is still hope.