Any developer knows the most dreaded response you’ll receive upon telling someone your profession: “So you’re a programmer? Hey, can you fix my Outlook/Google/Printer/Word/Other ?” Whether it’s friends, non-dev co-workers or your sweet old eighty-year-old grandma, (bless her heart,) there’s always an implicit assumption that knowledge of how to write code equates to an innate understanding of the ins and outs of every piece of software out there. While it can be gratifying to be reminded that your chosen field of employment is an important and valued one, it can also get pretty annoying.
The fact is, that assumption isn’t 100% wrong; it’s not easy to become a programmer without the sort of innate flexibility and familiarity with computers that makes it relatively easy to noodle out some sort of solution to whatever problem is thrown your way. Eventually. After some serious Googling.
It turns out that for every problem you’ve run into, odds are that ten other people ran into the same problem elsewhere on the planet. Hopefully, in the process of solving the problem, they put up their solution on the web in the hope that the next hapless geek to succumb to this problem will have their life made a bit easier
So! Here’s a Microsoft Word problem I discovered while (shameless plug incoming) authoring the book The Django Workshop (a great way to learn Django, plus associated bits and pieces like Javascript frontends and deployment. But I digress).
This project came to involve working on Word documents over 100 pages in length, and it seemed like the longer the document got, the worse the problem scaled to match it. Here’s how I solved it; with any luck, you’ll find this solution helpful down the line.
The Problem
A good book doesn’t just consist of line after line of entertaining prose. There are many factors: layout, formatting, fonts, et cetera. The same principles apply to brochures and pamphlets, reports, essays… honestly, any document out there makes use of headings, effects and the like. To make the process easier, Microsoft has long implemented the “Styles” pane in Word, offering the power-user a wide variety of preset options for how they want to stylise their text.
Having all these presets is tremendously useful, but with large documents, switching Styles in the styles pane started to take a long time, up to 10-20 seconds. Considering how these numbers start to add up when having to make multiple style changes in succession, it shouldn’t be surprising that this problem is extremely frustrating; it’s only worse when having to wait the same amount of time to undo an accidental style change.
Diagnosis
Smaller documents don’t seem to have this problem, so clearly it was related to the size of the document. I first assumed the slowdown might have been caused by Word reflowing the document after style changes (having to adjust the page layout for every page subsequent to the one being altered). So I tested this by making a style change on the last paragraph, and… still saw the slowdown. Therefore, it had to be something to do with the styles themselves.
In short, there had to be some sort of operation being performed on the entire document in relation to styles, one that occupied more time for longer documents. Eventually, I narrowed it down to an automatically-selected option: the Styles in use option.
When this option is selected, Word recalculates its list of in-use styles on each style change, so as to keep the list accurate (i.e. remove a style from the list when it’s no longer in use). My suspicion is that this is done by scanning through the document and rebuilding the list of each style it finds, which takes up all the extra time.
Solution
The obvious solution is to deselect using the Styles in use option to display the list of styles. Instead, select one of the other options. Using In current document seems to be a good compromise between fixing the issue and not showing ALL of the styles.
When using this mode, style changes are pretty much instant.
Possible Long-Term Fixes
A quicker approach for Microsoft to implement might be to keep a mapping between styles and a count of their use. When a style is applied, increment this count, and when it’s removed, decrement it. When a style’s count reaches zero, remove it from the list.
Even on typing that, I’m envisioning that it’s more difficult than it sounds. For example, imagine changing half of a paragraph from one style to another. Then imagine selecting a portion of the paragraph including both styles, and change that to a third style. Enabling Word to recognise that these partial decrements doesn’t count as actual decrements would be pretty difficult, as while no style is being removed, one is being added.
Conclusion
The document-scanning approach is admittedly the most effective solution when it comes to getting accurate returns, but the slowness on major documents is a deal-breaker. Hopefully Microsoft is aware of the problem and working on a fix; in the meantime, it’s easier to bypass the problem rather than fighting it. In short, Styles in use is slow. Try In current document instead.