The Plain Text Wars
[note] This article was ﬁrst published on a previous version of the Nofont.com site and is republished here for reference purposes only.
This isn’t actually a war, it’s just a pretty messed up situation caused by plain text puritanism and the loosing focus of the user in app development.
Read more about utf over at the Unicode.org faq
A couple of weeks ago I purchased Writer for the iPad along with PlainText for the iPhone/iPad. The goal was to set up a seamless, all-sync writing environment using these four apps;
Those would give me the ability to have the same interface no matter laptop, iPhone, iPad och any other device and as the kronan på verket; seemless syncing via Dropbox.com
… but it didn’t turn out that easy at all albeit the current plain text frenzy spreading the interwebs …
First of all; Writer for iPad doesn’t support subfolders, so it doesn’t integrate well in my workﬂow if I don’t want to change my way of working and my folder structure. I had to use the PlainText app on the iPad for the ﬁles that I kept outside Writers default folder.
The not so plain text encoding.
On the surface the apps looks great; just use the plain text format to encode your text ﬁles. But little do the user know that the plain text cake comes in a variety of ﬂavors.
PlainText from Hog Bay Software has really strict utf-
[Update] PlainText now supports the utf-
Writer from Information Architects on the other hand encodes plain text ﬁles as utf-
Writeroom (also from Hog Bay Software) does not have any control of how it encodes the documents, it simply opens the ﬁles using the osx native open ﬁle functionality, and there is now way to change the default encoding via Writeroom settings. Result; a new ﬁle created in Writeroom would not be utf-
Jesse the developer of PlainText and WriteRoom says in the WriteRoom Google group:
Sorry setting the default encoding isn’t supported. I just use the default os X call for opening the ﬁle, and that’s supposed to detect the format most of the time. You can try opening and saving the ﬁle in TextEdit, I think that will add a utf-
8metadata attribute that WriteRoom will use to open the ﬁle correctly.
Then there is the fourth part of the party; osx TextEdit app. By default TextEdit is set to use ”Automatic encoding” when opening and saving plain text ﬁles. So it keeps the current encoding of the document; open a ﬁle from Writer (utf-
The result has been a minor nightmare full of ﬁles being blank in one app, working in another and a lot of logging into Dropbox.com to revert and restore ﬁles.
The solution for now …
Here is what you have to do to get all ﬁles cleaned up and working on all devices/apps.
Start off by opening TextEdit, change the “Open and Save”-settings to “Automatic” for opening and “utf-
After that you must download the Writeroom
Writer still has to change it’s standard encoding into utf-
PlainText has loosened it’s encoding rules and now reads utf-