Bug of the moment 2006-04-03
You wouldn’t think that someone as jaded as I would still be so astonished at the sorts of bugs and design flaws that are slipping through into modern software. But one of the most peculiar to date (albeit at least second to KaZaA support in a business router) comes from TextEdit in Mac OS X Tiger (10.4.5). Generally speaking, in a text editing program, the width of the lines of text on the page come from one of two places: the size of the paper (no surprises here) or the ruler settings in force for the text.
But TextEdit has managed to dream up a third one: the width of the window at the time of printing. Had I posted this BOTM entry two days prior you might be forgiven for thinking I was having a laugh, but I am serious.
Our only connected and configured printer (and I was not planning on using my antediluvian Star LC-10) is on the iMac DV SE so I placed a Rich Text Format document (from Windows WordPad) onto my network share and then printed it from the iMac:
Hmm, that text is mighty small, isn’t it? (Not mentioning the margin size.) According to the festering Font palette foisted on the world by Apple, the text is 10 pt. 10 pt is small but it is definitely not that small. (For another unknown reason, it was being displayed close to that size on-screen as well.)
I was at a loss to explain what it was doing, until it dawned on me that the program was using the window size (of my maximised window) to set the line length. The window was wider than the page so the document was being scaled down to fit the extended line length across the width of the page. I reduced the window size to a narrow column and printed another copy, and now the page printed with the document narrower than the page:
Bear in mind that the only change to the font size on my end was going from 10 pt up to 12 pt, a difference rather greater than seen here. I did not intentionally do anything to the margins.
There is a solution to this, which is to switch off Format > Wrap to Window. This is equivalent to going into Word’s Page Layout view, showing the page outline complete with margins. In this mode, the page size is mysteriously displayed at 75% of actual size for no clear reason. However, it does then print your text at the intended size.
I had a suspicion that the cause of the problem was the Microsoft WordPad-generated file that I had fed to TextEdit, but a separate test with a fresh document indicates that the flaw is solely TextEdit’s. What appears to happen is that when you are in Wrap to Window mode, the right margin of the document is altered to match the window width. Why this is the case, I have no idea, and I can only guess that it is some sort of cheap hack to get you window wrapping without bothering to write the program properly.
I also solved the problem of the 75% size: Wrap to Window mode gets its zoom sizes wrong. I finally spotted a zoom control in the status bar of this mode, set to 100%. That is to say, 100% zoom is displayed as 75%. When previewing the document in Preview, the same mistake is made: all the zoom sizes are wrong. Unless Apple assume that everyone runs their 15″ iMacs at 800×600, I cannot understand how they managed to get that wrong, being the graphics experts they are.
I have not had any breakthrough on margins yet: they seem inexplicably set at about 3 centimeters. If TextEdit was a mere text editor I would let it get away with it, but Apple have clearly tried to make it into a proper low-end word processor. And failed.
Posted 3rd April 2006 – Comments and questions?