Outlook, text formatting and signatures

Summary: appending three spaces to the end of each line of a text block (eg a signature block) in a plain text message will stop Outlook from joining lines and messing up your formatting.

Long version…

For a while now we’ve had niggling issues with formatting of plain text email signatures in Outlook.
Problem was that a signature sent as

--
Paul Haldane
Infrastructure Systems
Information Systems and Services, Newcastle University
Claremont Tower
Claremont Road
Newcastle upon Tyne
NE1 7RU

Would be displayed (by default) in Outlook as

--
Paul Haldane
Infrastructure Systems
Information Systems and Services, Newcastle University Claremont Tower Claremont Road Newcastle upon Tyne
NE1 7RU

I don’t understand why the last line isn’t joined on to the penultimate line but I assume that it’s another feature of Outlook’s rendering algorithm.

NB That’s not my real email sig – the one that I use is

--
Paul Haldane
Manager, Infrastructure Systems
Information Systems and Services
Newcastle University

The example I’ve used at the top has characteristics which lead to the problem appearing while my real sig doesn’t (which had been one of the puzzling factors during the investigation).

The correct rendering can be shown by the recipient selecting “restore line breaks” when looking at a message or un-ticking “Remove extra line breaks in plain text messages” (Options->Preferences->E-mail options). Even if we decided that changing the default setting for University managed machines to not remove extra line breaks was a good idea, we obviously can’t control the settings for external recipients.

One of the reasons that this issue was hard to track down was that not all sigs demonstrated the problem. Mine didn’t; our director’s did and our VC’s did (which is one of the things that gave the issue visibility).

Comparing the original versions of the three I guessed that the common factor might be line length. Both of the problem sigs had longer lines than mine – split was somewhere between 38 and 44 characters. More testing …

INPUT

o three four five EOL
0000 xxxx 1111 XXXX 2222 xxxx 3333 XXXX 4
One two three four five EOL

40

One two three four five EOL
0000 xxxx 1111 XXXX 2222 xxxx 3333 XXXXx
One two three four five EOL

39

One two three four five EOL
0000 xxxx 1111 XXXX 2222 xxxx 3333 XXXX
One two three four five EOL

OUTPUT

41

One two three four five EOL
0000 xxxx 1111 XXXX 2222 xxxx 3333 XXXX 4 One two three four five EOL

40

One two three four five EOL
0000 xxxx 1111 XXXX 2222 xxxx 3333 XXXXx One two three four five EOL

39

One two three four five EOL
0000 xxxx 1111 XXXX 2222 xxxx 3333 XXXX
One two three four five EOL

So the breakpoint is 40. Lines after that are joined.

One unexplained fact was that the longest line in the VC’s sig was

Vice-Chancellor: Newcastle University

Which if you count is only 37 characters. However previous attempts to fix the problem by appending spaces to the end of the line (see below) meant that the line had two non-breaking spaces and a space at the end bringing the length to 40. (Non-breaking spaces can be explicitly inserted by typing control-shift-space in Outlook’s message editor but there might be some cleverness going on that converts three adjacent spaces to a mixture of non-breaking and real.)

Tests and investigation had got us a reasonable model for when the problem would happen (and an explanation for why I didn’t see it with my sig). We didn’t yet have a solution.

Internet folklore suggests that adding three spaces to the end of each line (or two spaces at the start; or a tab at the end – opinions vary as to which is the most consistent) will result in messages being rendered in Outlook as intended.
I tried appending three spaces to each non-empty line in the input. This gave the desired behaviour; lines were rendered correctly by the recipient’s instance of Outlook (no matter what their setting for removing extra line breaks was).

I was just looking back through my open tabs to put in some references to the Internet folklore that I’ve mentioned and spotted a very informative post that I must have consistently skimmed over.
On
http://stackoverflow.com/questions/136052/how-do-i-format-a-string-in-an-email-so-outlook-will-print-the-line-breaks mtruesdell says the following …

Every message starts with continuation off.
Lines less than 40 characters long do not trigger continuation, but if continuation is on, they will have their line breaks removed.
Lines 40 characters or longer turn continuation on. It remains on until an event occurs to turn it off.
Lines that end with a period, question mark, exclamation point or colon turn continuation off. (Outlook assumes it’s the end of a sentence?)
Lines that turn continuation off will start with a line break, but will turn continuation back on if they are longer than 40 characters.
Lines that start or end with a tab turn continuation off.
Lines that start with 2 or more spaces turn continuation off.
Lines that end with 3 or more spaces turn continuation off.

This is from testing against Outlook 2007 – he’s obviously got more patience than me. It would be so much easier if Microsoft published the algorithm that Outlook uses – at the moment there’s nothing to say that this behaviour won’t change in future versions.

Driver support for Windows 7 using Dynamic Driver Provisioning

Just a bit of info for those who are considering using WDS Dynamic Driver Provisioning to add hardware support to Windows images, and also for anyone who is curious to know how we provide operating system support to the myriad of PCs, servers and laptops out there on campus

In order to fully support Windows 7 client deployment and to start to wind-down support for Windows XP, recently we converted 2 out of 3 of our Mixed-mode WDS servers to Native Mode. The Native Mode servers run on Server 2008 R2 and therefore include the option to use Dynamic Driver Provisioning (DDP).

So what is DDP and why is it good for us?

Microsoft tell us that this new WDS functionality provides the following benefits:

  • Eliminates the need to add driver packages manually by using the tools in the Windows Automated Installation Kit.
  • Minimizes the size of install images.
  • Makes it easier to update and manage drivers because the drivers are stored outside the images.
  • Eliminates the need to maintain multiple images for different hardware configurations.
  • Eliminates the need for additional tools to manage drivers (for example, the Microsoft Deployment Toolkit (MDT) or non-Microsoft solutions).
  • Eliminates the need to use an Unattended installation file to add drivers.

And Microsoft are quite right. So far, DDP is working beautifully in our environment. I wont say it’s not a little clunky in places, because it is. Certainly some of the Filters could be better. But this will hopefully come in later versions.

For us, DDP is the perfect solution because we don’t need anything fancy to deploy our operating system images – the MDT is a sledgehammer to crack a nut in our environment, where software is deployed separately using Group Policy and SpecOps (http://www.specopssoft.com/web/home.aspx).

For those who are interested in the detail of how we use DDP here at Newcastle, please feel free to browse my setup notes