Table of Contents
Close Close table of contents

The Plain Text Wars

[note] This article was first 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;

plaintext_wars

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 workflow 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 files 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 files. But little do the user know that the plain text cake comes in a variety of flavors.

PlainText from Hog Bay Software has really strict utf-8 encoding rules, anything not utf-8 would not work in PlainText. I like that, that’s my kind of keeping it strict and minimal.

[Update] PlainText now supports the utf-16 format since v1.2.

Writer from Information Architects on the other hand encodes plain text files as utf-16.

Writeroom (also from Hog Bay Software) does not have any control of how it encodes the documents, it simply opens the files using the osx native open file functionality, and there is now way to change the default encoding via Writeroom settings. Result; a new file created in Writeroom would not be utf-8.

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 file, and that’s supposed to detect the format most of the time. You can try opening and saving the file in TextEdit, I think that will add a utf-8 metadata attribute that WriteRoom will use to open the file 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 files. So it keeps the current encoding of the document; open a file from Writer (utf-16) will save it as utf-16. Open a rich text document (.rtf) will save it as rich text formatting and so on.

The result has been a minor nightmare full of files being blank in one app, working in another and a lot of logging into Dropbox.com to revert and restore files.

The solution for now …

Here is what you have to do to get all files 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-8” for saving files. Then open all the text files that you want to ‘clean’, or that you have in your writing-environment. Do ”Save as …” and make sure the encoding is set to ”utf-8” in the Save as dialog. After that you have to go back and change the default TextEdit “Open”-settings to “utf-8”.

After that you must download the Writeroom 2.5 development Beta from the WriteRoom Dev Versions cos it supports setting the default encoding to utf-8.

Writer still has to change it’s standard encoding into utf-8 … we’ll have to wait for that to happened.

PlainText has loosened it’s encoding rules and now reads utf-16 (iA Writer files).

Andreas Saturday, 6 November, 2010    |    Agree or disagree? Please